W poprzednim artykule opisałem główne zasady działania programów znanych jako EXE-packery. Jednakże w jednym z akapitów popełniłem pewien duży błąd, nie wspominając o bardzo ważnej rzeczy związanej ze starymi komputerami.
Niniejszy artykuł jest sprostowaniem części mogącej wprowadzić naszych czytelników w błąd oraz małym uzupełnieniem w formie ciekawostek.
Press Play On Tape
W komentarzach padły zarzuty, iż tryb Turbo nie ma nic wspólnego z kompresją kodu. Wspomniałem o nim, ponieważ najbardziej rozbudowaną ideą zapisu kodu, aby wczytywał się z taśmy jak najszybciej, było skompresowanie go, zapisując go dopiero po kompresji w trybie Turbo. Zapomniałem o dodaniu najbardziej istotnej informacji, że tryb ten przede wszystkim powodował zmianę formatu modulacji zapisu bitów na taśmie, aby były one zapisywane gęściej oraz odtwarzane dzięki temu z większą prędkością przesyłu.
Dlaczego wspomniałem o trybie Turbo w kontekście kompresji kodu? Tytuły, które zawierały własny program wczytujący resztę w trybie Turbo, były zwykle kompresowane. Wczytywanie programu odbywało się więc w taki oto sposób:
- Ładowany jest program Turbo.
- Program Turbo wczytuje (skompresowany) kod, korzystając ze swojego „szybszego” formatu zapisu danych.
- Następuje dekompresja wczytanego kodu lub jego części po odczytaniu całej zawartości z taśmy.
- Główny kod jest uruchamiany (następuje skok do jego początku).
Tutaj chciałbym również zaznaczyć, iż po przeprowadzeniu poszukiwań, w różnych źródłach natrafiłem na informacje, iż nie wszystkie programy ładujące dekompresowały kod po jego wczytaniu i program mógł być zapisany w trybie Turbo, ale nie był skompresowany. Zdarzały się także sytuacje, gdy sam program był skompresowany, ale nie był zapisany w trybie Turbo. Bywało z tym różnie w zależności od producenta programu lub gry.
Teraz dodatkowo jeszcze wytłumaczę pewną kwestię techniczną – pewnie wiele osób się nad tym zastanawiało: dlaczego czasami przy uruchamianiu gierki na naszym komodorku przed ekranem tytułowym widzieliśmy zmieniające się szybko przez kilka sekund w charakterystyczny sposób znaki lub glitche graficzne?
Źródło: https://commons.wikimedia.org/wiki/File:Turboload_commodore_64.gif
Commodore 64 (jak sama nazwa wskazuje) miał 64 KB pamięci operacyjnej, z czego część była zarezerwowana dla wewnętrznych układów (procesora graficznego, układu dźwiękowego i pozostałych). Rozpakowujący się właśnie program nie może nadpisać jeszcze nierozpakowanej części ani samego kodu dekompresującego tym już rozpakowanym. Sprytnie wykorzystano te zarezerwowane części pamięci (dla procesora są one widziane tak jak każda inna część operacyjna), gdyż często służyły one jako bufor lub nawet sam kod dekompresujący był wykonywany właśnie z nich. Układ graficzny i dźwiękowy interpretowały zawartość tego „własnego” obszaru pamięci jako zawartość wyświetlanego obrazu, a w drugim układzie jako wartości odtwarzanego dźwięku – stąd też bardzo często przed samym ekranem tytułowym widzieliśmy przez chwilę migające znaki i glitche lub słyszeliśmy trzaski i szumy.
Ciekawostka: za czasów komputerów 8-bitowych oraz 16-bitowych jeszcze przed erą PC występował specyficzny podział dla nazewnictwa kompresorów kodu: packery wykorzystywały proste algorytmy takie jak np. RLE (zapisywanie powtarzających się sekwencji znaków w skróconej formie), natomiast crunchery to programy wykorzystujące bardziej zaawansowane algorytmy porównywalne z późniejszymi EXE-packerami dla PC (paradoksalnie pierwotne określenie takich narzędzi przyjęło się bardziej), zwykle z rodziny LZ (stąd wzięła się również nazwa LZEXE – jednego z pierwszych popularnych EXE-packerów dla systemów DOS). Określenia packer i cruncher, w zależności od użytego rodzaju kompresji, przeszły również do świata komputerów Amiga.
Fast, Small, Good
Jeden z naszych czytelników zapytał, dlaczego nie wspomniałem o pewnym wynalazku z naszego rodzimego podwórka, tym razem jednak znanym na świecie – chodzi o EXE-packera o nazwie FSG, który obsługuje on pliki .EXE w formacie Win32 PE.
FSG jest produkcją grupy crackerskiej xtreeme, działającej w Polsce na początku lat dwutysięcznych – większość popularnych programów antywirusowych z góry traktuje pliki nim skompresowane jako podejrzane, ponieważ jest on często wykorzystywany do kompresowania malware’u.
Ta produkcja w porównaniu do „wewnętrznych” EXE-packerów różnych innych grup crackerskich i demoscenowych została wydana na świat, a summa summarum jakość tego EXE-packera była całkiem niezła jak na standardy w tamtych czasach.
Fragment pliku .NFO z opisem dołączony do instalatora FSG 1.33
Co takiego wyróżnia FSG wśród innych EXE-packerów, że zalicza się on do kategorii „wynalazków”?
- Jest to produkcja pochodząca ze sceny crackerskiej.
- Napisany został w czystym kodzie assembly.
- Kod dekompresora w ostatniej wersji to tylko 158 bajtów – 197 bajtów w starszej wersji kompatybilnej z Windows 10.
- Podobny stopień kompresji jak najpopularniejszy UPX.
- Poczucie humoru twórców.
FSG wydawany „podziemnymi” ścieżkami nigdy nie był użyty przez jakiekolwiek oprogramowanie komercyjne lub nawet bezpłatne. Stał się jednak bardzo popularny wśród grup crackerskich, demoscenowych oraz wśród producentów oprogramowania malware (do dziś jeszcze można znaleźć świeże produkcje nim spakowane).
Instalator FSG 1.33 (wygląda bardzo podobnie
jak ówczesne instalatory tzw. „ripów” gier)
Jeśli macie ochotę sprawdzić, czy wasz program antywirusowy także traktuje FSG jako coś niebezpiecznego lub posłuchać muzyki chiptune i zobaczyć crackscenowe animacje (twórcy FSG stworzyli dla niego klimatyczny instalator i cracktro), to FSG w wersjach 2.0 (uwaga: pliki spakowane za pomocą tej wersji nie działają w Windows 10, podobnie jak sam instalator i EXE-packer) oraz 1.33 możecie znaleźć tutaj. A muzykę z instalatora znajdziecie na YouTube.
O czym jeszcze mogliście nie wiedzieć
Na koniec jeszcze pięć innych ciekawostek związanych z EXE-packerami.
- Pliki .EXE zawierające 64-bitowy kod dla systemu Windows mają taki sam format jak te 32-bitowe – bardzo szybko wszystkie EXE-packery obsługujące kod 32-bitowy dostały obsługę kodu 64-bitowego, gdy systemy 64-bitowe weszły do powszechnego użytku, gdyż wymagało to jedynie zmiany kodu samego dekompresora.
- Od około 1997 roku „standardowe” 64 KB lub 128 KB w układzie przechowującym oprogramowanie BIOS w komputerach PC przestało wystarczać pod względem pojemnościowym – domyślacie się już na pewno, po jakie metody sięgnięto. Tutaj ciekawa sprawa, jaką odkryłem: Award użył algorytmu kompresji, a nawet formatu pliku wynikowego identycznego jak archiwizator LHA, tworząc nietypowe archiwum SFX rozpakowujące się do określonych adresów pamięci zamiast na dysk jako obraz BIOS do zaprogramowania w układzie płyty głównej.
- Słynny niegdyś program antywirusowy MkS_Vir w wersji dla DOS był spakowany autorskim EXE-packerem, który powstał tylko i wyłącznie dla niego (oglądaliście dema pokazowe efektów działania opisanych w encyklopedii wirusów? Są to oryginalne fragmenty kodów z nich wydobyte).
- W Windows Me plik IO.SYS był skompresowany EXE-packerem, dla którego nie znaleziono żadnego działającego podobnie przy dekompresji – prawdopodobnie tak jak ciekawostka powyżej powstał on tylko na potrzeby tego pliku (zawiera on główne moduły trybu MS-DOS w Windows Me).
- UPX w najstarszych swoich wersjach posiadał easter egga polegającego na tym, że nie mógł rozpakować swojego własnego pliku wykonywalnego, wyświetlając komunikat błędu „cannot unpack UPX ;-)”.
Komentarze
Te paski podczas ładowania programu z taśmy były widoczne cały czas, a nie tylko chwilkę np. w spectrum
Te paski były lub nie, mogły zmieniać kolor w trakcie ładowania kolejnych segmentów, mogly być zastapione innym rejestrem koloru, cokolwiek. Generowane były przez procedury zapisu i odczytu więc programista mógł zrobić co chciał. Czasem dla hecy loadery w ZX spectrum zmieniały kolory pasków. W Atari paski standardowo nie występowały, ale już niektóre systemy turbo je miały.
A paski były z tego że zmiana koloru ramki to był zazwyczaj jeden store do pamięci. To w procedurach odczytu z magnetofonu jeszcze dało się wcisnąć. Więc były popularne jako rodzaj diagnostyki. Wprawny atarowiec z Blizzardem po synchronizacji pilota nagrania (paski stoją, idą w górę, idą w dół, stablinie, niestabilnie) wiedział w jakim stanie jest nagranie.
Paski jak najbardziej – wspomniałem natomiast o samych glitchach wizualnych i dźwiękowych. Przy ładowaniu „standardowym” również przesuwały się paski dookoła głównej części ekranu, ten jednak był po prostu pusty w tym czasie.
Na Commodore 64 z tego co pamietam to inne paski byly przy wgrywaniu przez turbo, a inne bez turbo i po kolorach paskow mozna bylo wywnioskowac czy sie laduje normalnie czy sa bledy. W kazdym razie strasznie draznila mnie ramka dookola ekranu ktorej nie dalo sie zagospodarowac.
Systemy Turbo nie zawsze zmianiały modulacje. Czasami zagęszczały zapis najzwyczajniej nagrywając tak samo tylko gęściej. Takie „turbo” o miernym, ale zawsze przyśpieszeniu, widywano np. w Atari (np. CASA Turbo Tape). Tak więc dyskutowanie co to znaczy „Turbo” jest kłopotliwe i lepiej temat zostawić. Zainteresowanym polecam hasło „Systemy turbo” w atariki oraz hasło „Fast loader” na c64-wiki. Temat jest zbyt szeroki aby dało się go zredukować do kilku zdań.
Jest niezwykle mało prawdopodobne aby rejestry układów dzwiekowych były uzywane jako pamięć. Po pierwsze jest ich bardzo mało (w SID i POKEY), po drugie pełnią rózne role przy zapisie lub odczycie, jak to rejestry, więc gubią informacje. Wszelakie trzaski i szumy to prawdopodobnie zwykłe dziadostwo programisty ktory ustawiał sobie układ dzwiekowy defaultowo po czym nastepny rozpakowany chunk, intro czy inny trainer ustawiał go też defaultowo tylko inaczej. Albo najzwyczajniej trzaski byly zamierzone jako częśc algorytmów rozpakowania. Był kiedyś cracker C64 w PL ktorego ksywy nie pomnę ktory uznal że wysyłanie każdego wypakowanego bajta do SIDa to naprawdę fun. Efektem czego z telewizora prawie wypadała membrana głośnika. Taki suprise.
Owszem, pamięc ekranu dośc często jest wykorzystywana przez loadery, ale tutaj hint: pamięc ekranu NIE jest częscią układów graficznych i jest zwykłą pamięcią ram a nie żadną „zarezerwowaną”. Choć mała uwaga: komputery MSX miały organizację pamięci Video daleko odbiegającą od normalnych 8-bit i tam jak by się ktoś strasznie upierał można powiedzieć … ale nie … nawet tam nie można.
Pamięc Video w C64/Atari nie rózniła sie niczym od zwykłego RAMu bo nim była. W Atari pojęcie pamięci video bylo nawet nie tylko swobodnie interpretowane, ale interpretowane przez „prawie koprocesor”. Nie mozna mówić że to jakaś rezerwowana pamięć, ekranem mógł być w Atari prawie każdy obszar adresowalny przez cpu/antic. Pamieć jak każda inna. Lenistwo programistów powodowało że w C64 atrybuty ekranu nie były modyfikowane tak aby ukryć ten „kod załadowany w ekran”. W Atari było łatwiej ukryć bo koprocesor ANTIC nie musiał wyświetlać wszystkiego.
W ZX bylo nieco inaczej, ale tam róznica jest detaliczna i na poziomie hacków sprzetowych sir Sinclaira, praktycznie niewidocznych po stronie software. Po dwóch kieliszkach nie różniła sie niczym od reszty RAMu.
Warto wiedzieć że Atari z powodu zancznie bardziej skomplikowanego systemu DMA niż C64 musiało w większośc loaderów Turbo wygaszać ekran w ogóle bo inaczej DMA generowało trudne do ogarnięcia opóźnienia CPU.
Zaznaczam że temat bardzo cieżki, nie rozumiem potrzeby brnięcia dalej w tą tematykę.
Chyba że to desperacka próba wypełnienia trescią :D Polecam the Onion News w celu wyjasnienie o co chodzi :D
„Zarezerwowaną pamięć” miałem w artykule na myśli jako taką, w której teoretycznie nie powinien znajdować się kod, a dane graficzne (w kolejnym drugim zdaniu napisałem przecież, że dla procesora widziana była ona jako zwykła pamięć operacyjna) – większość manuali określała to w taki sposób: co tam zapisze się do tego obszaru to jest już to co znajduje się na ekranie (chodzi o textmode oczywiście).
Autorze… Sopel … trochę motasz wszystko.
Po pierwsze rozpakowywanie „na ekranie” było głównie z tego powodu że wykorzystywany był autorun (czyli że się gra uruchamiała od razu po wczytaniu bez wpisywania RUN albo SYS 49152 (bo tam zwyczajowo był start asmów). Ale to głównie, bo w sumie chodzi o miejsce.
I, tutaj ktoś mógłby pomyśleć że to bez sensu, bo nie trzeba na ekranie – i miałby rację! – nie trzeba na ekranie… chyba że nie ma już innego miejsca w pamięci – a nie ma, bo grę najczęściej złamano (spiracono – i np. przerobiono np. z dysku na taśmę co znaczy dodatkowy kod obsługi kasety lub sprawdzania) i dodatkowo dodano intro (bez intra ani rusz, TomiSoft pozdrawia ;) oraz depacker … i to wszystko zajeło tyle że nawet po pakowaniu jedyne wolne miejsce na bufor depakowania to ekran. I tyle magii.
Natomiast paski i piski to… żart. Ot bajer. Ładujemy akumulatory przez rejestry ramki albo ekranu, albo po prostu losowymi danymi depakowania. Można STA $c300 a można STA $d020 ;-) Ładnie mruga, widać że się coś robi, etc. NICZEGO WIĘCEJ W TYM NIE MA.
A turbo nie ma nic do pakowania. Turbo to sztuczka (loader) potrafiący omijać ułomności systemu (tak samo jak ominięto niemożliwość wyświetlania czegokolwiek na ramkach).
Jak działa turbo masz tutaj: https://en.wikipedia.org/wiki/Fast_loader (w sekcji Development). I tyle magii.
Przykro mi, ale w tym artykule jest ponownie namieszane, jak w poprzednim, jeśli chodzi o komputery 8-bitowe (C64). Autor pomieszał turbo z kaset i programy z dyskietek. Zaprezentowana grafika ewidentnie o tym dowodzi, jako, że widnieje na niej rozszerzenie .d64, które to odpowiada obrazom dyskowym. To co widzimy, to dekompresja programu w pamięci i to się zgadza, ale wszystko to odbywa się już po wczytaniu programu. Co więcej tutaj faktycznie istniały bootloadery, które same doczytywały sektory z dysku. Turbo kasetowe i dyskowe to kompletnie inna sprawa. Co więcej turbo dyskowe zmieniało protokół przesyłania danych kablem (wykorzystywało w inny sposób linie sygnałowe, pobierając więcej bitów naraz), a wręcz można było przerobić stację do transmisji równoległej (stacja dysków, to tak naprawdę był drugi C64).
Natomiast co do błędnie powiązanych z tym zapisów z kaset, to turbo tam różniło się od zapisu normalnego tym, że przy nie-turbo na kasecie każdy program/gra była zapisywana podwójnie, celem wykrycia i korekcji błędów (starsi pamiętają kręcenie śrubką i ustawianie skosu głowicy). W przypadku turbo zapisana była tylko jedna kopia, stąd czas jest o połowę krótszy, za cenę wyższego ryzyka „loading error”. A to, że paseczki pojawiały się po wpisaniu „run”, to już kompletnie odmienna sprawa.
Kolorowe paseczki rastra pojawiały się w kasetowym turbo (zwykle czerwono-czarne, zależnie od autora turbo). Ich istnienie nie ma większego znaczenia, poza tym, że informują wizualnie o wczytywanych blokach danych. W przypadku zwykłego odczytu ekran był w jednolitym kolorze (ekran był wyłączany, by VIC nie wysyłał dodatkowych przerwań pobierających dane z generatora znaków, przez co wszystkie cykle zostawały dla procesora i nie powodowało to np. wystąpienia IRQ w trakcie wykrywania zboczy na taśmie).
Także turbo a faktyczna kompresja programu, to jest zupełnie inna sprawa.
Serio był zapisywany 2x i to jest nie Turbo a Turbo to 1x? Czego to człowiek się nie dowie na portalu nie na temat.
Ten screen dodałem tylko jako przykład co mogło wyświetlać się przy rozpakowywaniu, jako że nie mogłem znaleźć innego bardziej podobnego ani wygenerować samemu .
No, ten akuratnie jest pierwszy na wiki :D
Do zrobienia takiego screenshota należy zapodać emulator c64 i poszukać na allegro dowolnej kasety z lat 80/90 z pirackimi grami.
„assembly” to po polsku Asembler.
A pamięć ekranu, była wykorzystywana przez programy służące do omijania zabezpieczeń antypirackich.
Pierwsze programy zajmowały tylko część pamięci RAM. Można było więc załadować najpierw program kopiujący, później właściwą grę którą można było skopiować na inną taśmę. Żeby się przed tym zabezpieczyć, producenci zaczęli tworzyć programy zajmujące cały RAM, tak żeby nie było miejsca na program kopiujący. Wtedy pojawiły się programy typu COPYCOPY, które umieszczały swój kod w pamięci ekranu, co pozwalało na kopiowanie programów zajmujących cały RAM. Dodatkowo takie programy potrafiły dokonywać modyfikacji w kodzie załadowanej gry, np. zwiększając ilość „żyć” czy wprowadzając inne funkcjonalności.
„assembly” to po polsku „montaż, układ wielu częsci, zgromadzenie”. Czasami nazywano tak kod źrodlowy w asemblerze lub pojawiało się w dwusłowiu „assembly language”, „assembly code” ale samo z siebie nie było używane jakoś zbyt często bo ma inne wyraźne znaczenie w angielskim a te zlepki też trafiały się sporadycznie.
„assembler” topo polsku asembler i to było uzywane powszechnie obok „asm”, „machine language” i „code”. Na koniec „code” wygrało i w ściecie hackerskim obecnie oznacza napisany program, najczęsciej w asemblerze.
W artykuje powinno się pojawić „Napisany został w asemblerze” oczywiście o ile autor ma wiedze czy przypadkiem tamten autor nie pisał wprost w kodzie maszynowym … bo i tacy magicy się czasem trafiali.
Gry na C64 można było kopiować za pomocą innych zaawansowanych systemów łamania zabezpieczeń. Potrzebny był do tego magnetofon z dwoma slotami na kasety i funkcją kopiowania. W jednym nawet kiedy głowice były czyste udawało się kopiować w trybie „turbo” ;) z wciśniętym na raz play i fwd a w drugiej kasecie rec
To były czasy… ehh
Ta, moj ojciec kiedys zeby bylo szybciej to skopiowal cala kasete 90min na wiezy w trybie high speed. Zadna gra nie dzialala. Wszystkie mialy „loading error”. Musialem pozniej jeszcze raz najpierw LOAD, zmiana kasety i SAVE.
Na Atari też ten system działał.
Miałem w reku niemiecką kasetę do Atari zabezpiecznoą w ciekawy sposób, pomiędzy blokami pojawiala się bardzo głośna szpilka o wysokiej częstotliwości. Była za wczesnie aby komputer ją zinterpretował jako dane (kod ładujący odczekiwał okresloną ilość ms) i jednocześnie doststecznie glośna aby automatyczna regulacja wzmocnienia zwykłego magnetofonu podowała zaburzenia poziomu nagrywania danych po niej. Efektm czego kopiowanie takiej kasety było bardzo utrudnione, w przecietnym sprzecie audio prawie niemożliwe. Magentofon Atari radził sobie z tymi szpilkami znacznie lepiej.
No i chyba wychodzi na to że jak już pisać artykuły to możliwie tumanistyczne. W tekście technicznym do tego stopnia ludzie nie spoczną do czasu znalezienia wszelkich merytorycznych błedów a tutaj z litości nie ma co wyciągać wszsytkich. Zaś redakcja Z3S mogła by czasem przeczytać coś zanim wrzuci. Choć nie przypuszczam aby to tutaj dużo pomogło, do oceny merytorycznej trzeba sepcjalisty. Dlatego dobra rada do Z3S: skupcie się na publikacjach o których macie śladowe pojęcie co do ich zgodności z rzeczywistością. Marki nie zbudujecie publikując wszystko jak leci żeby norme wyrobić.
Może jesteś chętny do korekty następnego artykułu? Bo krytykować wszyscy, tylko pisać i korygować nie na komu :)
Nie ma już nikogo kompetentnego i Z3S bierze z łapanki? Jest gorzej niż myślałem.
W przypadku tych artykułów koretka nie pomoże. Tu nie ma co korygować, należy wywalić pierwszy akapit z pierwszego artykułu zamiast pisać sprostowania bez sensu które dodają jeszcze do pieca dodatkowe brednie.
Nie, nie jestem chętny. Ale mały hint: korektor od spraw merytorycznych bardzo często kontaktuje się w sprawach wąpliwych z szeroko rozumianą spolecznością. 15 minut szukania dało by Wam dostęp do społeczności ludzi zajmujących się tymi tematami do dzisiaj. Wystarczyło wskoczy na chwile na atariage czy atariarea. Pomogą, nie tylko pod kątem Atari. Przypadkowy pieniacz z forum, jak ja, nie jest właściwą osobą do kontaktu.
Tylko po co. Autor napisał o Turbo dla przyciągnięcia uwagi, bo taka moda. No i masz. Przyciągnął.
Całkowicie się zgadzam,widocznie Sopel to początkujący dziennikarz IT mam nadzieje,że się rozkręci.
Krytykować karzdy może, lecz pisać artykuły mało komu się chce…Krytykować łatwo a pisać porządne artykuły bardzo trudno,
Myślę, że Sopel za kilka artów,
będzie pisał znacznie lepiej…
Sopel-podasz jakiś kontakt?
Liczę że z czasem karzdy art będzie lepszy… Kiedy ukarze się kolejny art? Trzymam za Ciebie kciuki…
możesz napisać na wykopie https://www.wykop.pl/ludzie/soplowy/
„W Windows Me plik IO.SYS był skompresowany EXE-packerem, dla którego nie znaleziono żadnego działającego podobnie przy dekompresji – prawdopodobnie tak jak ciekawostka powyżej powstał on tylko na potrzeby tego pliku (zawiera on główne moduły trybu MS-DOS w Windows Me).” – proszę Was, dajcie komuś to do przeczytania nim opublikujecie. Uprasza się o jakieś pozory profesjonalizmu.
Każdy, kto się pieni o to czy i w jaki sposób zmieniana była modulacja, czy zawsze, wszędzie, czasami i jak się to nazywało kompletnie minął się z przesłaniem artykułu.
Nauki ścisłe mają taką brzydką cechę że detale są istotne. Nie można pisać bzdur a nastepnie powiedzieć że skoro reszta fajna to sobie darujemy czepialstwo. Tak to nie działa w publikacjach technicznych czy naukowych, spodziewany jest pewien poziom merytoryczny. Oczywiście można sobie pisać byle co w internetach ale wydawało by się że Z3S gdzieś aspiruje.
I skoro reszta była ważna to po co ten pierwszy akapit w pierwszym artykule który postawił pod znakiem zapytania wiarygodnośc reszty?
@Sebo,
jak dla mnie to jesteś Krulem pod postami Sopla (może pod innymi też bywałeś, nie wiem nie pamiętam).
Masz ten styl, merytorykę, argumenty…
Tak, wiem że merytoryka i argumenty to zło wcielone. Lepsze jest machanie rękami i dużo emotikonek.
Ale sie spinacie. Dobrze sie czytalo. Moze male niescilosci, ale punktujcie z zrodlami, a nie jedziecie dla zasady. Chlop sie wyrobi. Dzieki za art.
Sebo, nie jesteś przypadkiem TYM Sebą z Our 5oft? ;)
Nie.
@TSP, @Sebo, no i wtopa, pomyliłem grupy, po tylu latach mętlik w głowie, chodziło o Slight, nie o Our 5oft, choć tych też serdecznie pozdrawiam :)
Odnośnie trybu turbo w Commodore 64:
https://www.atarimagazines.com/compute/issue57/turbotape.html