The Klątwa Set - Pars II et dimidia: Zemsta HATABS

No to jednak będzie mała aktualizacja i korekta tego, co pisałem wcześniej. Nie dawały mi spokoju te "pyknięcia" w tonach pilotujących. Przyjrzałem się im bliżej i okazało się, że są zbyt regularne, zbyt powtarzalne. Początkowo zakładałem, że taka była uroda magnetofonu, na którym dokonano zapisu, jednak dokładniejsza analiza tych miejsc wykazała, że owe "pyknięcia" nie powstały przez przypadek. To, co wcześniej przedstawiłem jako przykład, czyli fragment tonu synchronizującego przerwanego jakimś "trzaskiem", okazało się celowym zabiegiem. Dla przypomnienia wrzucę to jeszcze raz:

pwmc 00151 46 584 12 1 23 1 46 3463 ; count=4

To, co opisałem jako "potknięcia" a8cas-util, okazało się finalnie moim "potknięciem" i nadinterpretacją faktów. Z mojego wcześniejszego opisu wynikało, że widoczny tam fragment powinien być jednostajnym tonem synchronizującym, przerwanym jakimś "śmieciem". Okazało się jednak, że była to błędna interpretacja całej sytuacji. Po sprawdzeniu kilku plików zobaczyłem, że wszędzie wygląda to tak samo, czyli w rzeczywistości ta sekwencja składała się z:

• początkowej serii impulsów pilota

• impulsu reprezentującego "0"

• impulsu reprezentującego "1"

• końcowej serii impulsów pilota

Początkowo wszystkie testy robiłem w emulatorze i w wersji systemu Turbo 2000F, który wykładał się na tych "śmieciach" w środku pilota. Uznałem więc, jak wspominałem wyżej, że jest to niedoskonałość urządzenia zapisującego. Poprawiłem wszystkie te "uszkodzone" miejsca i uznałem sprawę za rozwiązaną, ponieważ wszystko zaczęło wczytywać się poprawnie. Przetestowałem zarówno pliki w formacie "new", jak i te nagrane w starym formacie, również te z dodanym loaderem, który tak naprawdę był wersją systemu turbo lokującą się w dolnej przestrzeni pamięci - nazwijmy go LoMem_Ldr.

Wszystko wydawało się działać idealnie, aż do momentu, gdy zacząłem ponownie sprawdzać całość podczas pisania drugiej części tej "przeklętej" sagi. Robiąc porządki w tekście i chcąc dodać linki do wszystkich istotnych materiałów, dorzuciłem także odnośnik do oryginalnej wersji Turbo 2000F sygnowanej przez MUEL, czyli tej lokującej się pod OS-ROM.

Post opublikowałem na forum, po czym coś mnie tknęło i zacząłem testować wszystko ponownie, tym razem wykorzystując już pliki ściągnięte bezpośrednio z mojego posta.

Jakież było moje zdziwienie, gdy zobaczyłem, że Silent Service, Fantastic Soccer i World Soccer nie wczytują się poprawnie. Loader najwyraźniej nie "załapywał" nazwy programu nagranego za nim, przez co reszta bloków nie była ładowana wcale. "Loader" nadal oczekiwał na blok zawierający nazwę wczytywanego programu.

Na szybko spróbowałem wczytać pliki .hex niezawierające moich "normalizacji" i "korekt". Te ładowały się bez problemu, mimo że zawierały owe "pyknięcia"! Po odkryciu tego faktu zorientowałem się, że te "pyknięcia" w tonie synchronizującym są konieczne, aby "LowMem_Ldr" był w stanie poprawnie zinterpretować nazwę nagranego za nim programu.

Po odkryciu tego faktu postanowiłem wyjaśnić sprawę do końca. Początkowo szybko zaktualizowałem problematyczne pliki hex/cas w archiwum, dodając im sekwencję dwóch bitów "0" i "1" występujących w trakcie trwania pilota, a potem zacząłem grzebać, aby dociec, o co właściwie chodzi. Jeżeli to czytacie, to znaczy, że udało mi się dojść do tego, co tak naprawdę tam się działo ;-)

Zacząć musimy od analizy samego loadera. Będę się starał opisać to w miarę prosto, jednak będzie niestety trochę asemblera, trochę opisu struktury plików i trochę działania loadera plików binarnych Atari DOS (.XEX).

Zatem popatrzmy, jak wygląda struktura bloków samego loadera (LoMem_Ldr):

chkxex t2kf_lomem_ldr.xex 

Input file is t2kf_lomem_ldr.xex and the file size is 1797 bytes.

Header is: $ffff
block 001: $1700-$1df6 ($06f7)
block 002: $02e0-$02e3 ($0004) --->  RUN/INIT $1d9d/$1d9d

File t2kf_lomem_ldr.xex is OK!

^^^ Na pierwszy rzut oka nie widać tutaj niczego niepokojącego. Owszem, plik ładuje się dość nisko, ale w przypadku nadrzędnego systemu, z którego jest ładowany, nie ma to znaczenia, bo mamy MemLo na poziomie $0800. Ładowanie od adresu $1700 w niczym nie przeszkadza. Nietypowa wydaje się jednak sekwencja RUN/INIT, czyli jednoczesne ustawienie wektorów RUN i INIT na ten sam adres startu.

Niby czemu miałoby to przeszkadzać? Po prostu program zostanie uruchomiony przez INIT, a nie przez RUN, więc teoretycznie nie powinno to mieć żadnego znaczenia. Okazuje się jednak, że w tym wypadku ma to znaczenie - ale o tym będę mógł opowiedzieć za chwilę, gdy wyjaśnię, jak działa loader plików .XEX/.COM/.EXE w takim systemie jak Turbo 2000F/KSO.

System turbo instaluje w systemie sterownik urządzenia. W tym wypadku jest to urządzenie "D:", aby zachować "zgodność" z programami, które odwołują się do "D:" tak, jak do stacji dysków. W systemie znajduje się więc sterownik, do którego można się odwołać przez CIO. Działają więc wszystkie operacje typu OPEN, CLOSE, GET, PUT. Loader plików binarnych zawarty w oprogramowaniu turbo bazuje właśnie na odwołaniach do urządzenia "D:" przez CIO, a więc używa funkcji OPEN, GET, CLOSE itd.

Przebieg ładowania pliku .XEX przez taki loader wygląda mniej więcej tak:

open_file(filename);

while_not_eof
{
   get_block_header();
   load_block();
   init_segment();
}

close_file();
jmp_to_run_vector();

Czyli loader otwiera urządzenie "D:" do odczytu funkcją OPEN i próbuje odnaleźć blok danych z nazwą pliku. Gdy mu się to uda, rozpoczyna ładowanie bloków danych. W kolejnych krokach loader odczytuje bajty nagłówka pliku, oblicza długość bloku i zaczyna ładować poszczególne bloki w odpowiednie miejsca pamięci. Po załadowaniu każdego bloku sprawdzane jest, czy blok nie był segmentem typu INIT. Jeżeli wektor INITAD ($2e2-$2e3) zawiera wartość niezerową, wykonywany jest skok pod adres, na który INITAD wskazuje. Wszystko dzieje się w pętli aż do napotkania końca pliku, czyli ładowane są kolejne bloki danych. Gdy osiągnięty zostanie koniec pliku, wykonywany jest skok pod adres określony przez RUNAD ($2e0-$2e1). Jeżeli wektor RUNAD nie został ustawiony w pliku, następuje skok pod adres pierwszego z ładowanych segmentów.

Pewnie znowu zastanawiacie się, z jakiego powodu zanudzam was takimi szczegółami technicznymi. Niestety jest to konieczne do zrozumienia mechanizmu, który za chwilę zacznę opisywać. Będzie to opis tego, co właściwie zaczyna się dziać po załadowaniu segmentu danych ($2e0-$2e3), czyli segmentu, który jednocześnie ustawia wektory INIT i RUN.

Przyjrzyjmy się zatem temu, co dzieje się, gdy loader plików zawarty w systemie 2000F (MUEL) skoczy pod adres $1d9d wskazywany przez wektor INITAD ($2e2-$2e3):

; kasujemy poprzedni wpis dla urządzenia "D:" w HATABS
; (na ślepo, zakładamy że on tam jest, )
; (i że jest dokładnie w tym miejscu, tzn. pod adresem HATABS+$0F)

    1D9D: A2 02             LDX #$02
    1D9F: A9 00             LDA #$00
    1DA1: 9D 29 03          STA HATABS+$0F,X
    1DA4: CA                DEX
    1DA5: 10 FA             BPL $1DA1
    
; przygotowujemy się do przepisania załadowanego kodu
; z lokacji $1700 do lokacji  $0700
    1DA7: A9 17             LDA #$17
    1DA9: 85 31             STA $31
    1DAB: A9 07             LDA #$07
    1DAD: 85 33             STA $33
    1DAF: A9 00             LDA #$00
    1DB1: 85 30             STA $30
    1DB3: 85 32             STA $32

; pętla kopiujące dane
    1DB5: A2 0E             LDX #$0E
    1DB7: B1 30             LDA ($30),Y
    1DB9: 91 32             STA ($32),Y
    1DBB: C8                INY
    1DBC: D0 F9             BNE $1DB7
    1DBE: E6 31             INC $31
    1DC0: E6 33             INC $33
    1DC2: E4 33             CPX $33
    1DC4: D0 F1             BNE $1DB7

; ustawiamy wektory     
    1DC6: A9 C2             LDA #$C2
    1DC8: 85 02             STA CASINI
    1DCA: 85 0C             STA DOSINI
    1DCC: A9 08             LDA #$08
    1DCE: 85 03             STA CASINI+1
    1DD0: 85 0D             STA DOSINI+1
    
; skok do procedury instalującej handler "D:"
    
    1DD2: 20 C2 08          JSR $08C2

; inicjalizacja wskaźnika stosu, etc.
    1DD5: A2 FF             LDX #$FF
    1DD7: 9A                TXS
    1DD8: A9 01             LDA #$01
    1DDA: 85 09             STA $09

; bezpośredni skok do procedury "screen open" w OS-ROM
    1DDC: A9 00             LDA #$00
    1DDE: 85 2B             STA ICAX2Z
    1DE0: A9 0C             LDA #$0C
    1DE2: 85 2A             STA ICAX1Z
    1DE4: 20 8E EF          JSR $EF8E

; zamykamy kanał IOCB#1 (używając CIO)
; (poprzednio otwarty przez stary handler "D:")
;
; !!! UWAGA! (w tej chwili wpisy w HATABS wskazują już na nowy handler!)
; !!! UWAGA! (to jest piękny przepis na katastrofę!                    )
;
    1DE7: A2 10             LDX #$10
    1DE9: A9 0C             LDA #$0C
    1DEB: 9D 42 03          STA ICCMD,X
    1DEE: 20 56 E4          JSR CIOV

; ustaw flagę oznaczającą "LOAD & RUN"
    1DF1: 38                SEC
    1DF2: 66 48             ROR $48
    
; skocz do procedury ładującej plik binarny (.XEX)
; (mówimy o świeżo załadowanej wersji systemu)
    1DF4: 4C FE 08          JMP $08FE

Teraz, mając już całość jak na talerzu, mogę spróbować wyjaśnić, dlaczego programy nagrane za tym loaderem miały w trakcie tonu pilotującego wrzucone dwa dodatkowe bity danych (0,1), które traktowałem jako przypadkowe śmieci. Istotne okazały się dwie rzeczy. Po pierwsze, ten "loader" jest uruchamiany tak naprawdę przez wektor INITAD ($2e2-$2e3). Po drugie, w procedurze startu tego loadera znajduje się sekwencja zamknięcia kanału IOCB#1, czyli kanału otwartego wcześniej przez poprzedni loader jako kanał do odczytu danych. Tak się ciekawie składa, że w chwili, gdy ten kod zostaje uruchomiony przez wektor INITAD, kanał jest cały czas otwarty.

Teoretycznie, gdyby uruchomić ten kod przez wektor RUNAD ($2e0-$2e1), nadrzędny loader zamknąłby kanał IOCB#1 przed uruchomieniem wczytanego programu, a ponowne otwarcie kanału IOCB#1 przez nowy loader odbyłoby się bez problemów.

W tym wypadku dzieje się jednak inaczej. Bez wchodzenia jeszcze głębiej w szczegóły: wywołanie polecenia CLOSE dla IOCB#1 powoduje błędną reakcję procedury obsługującej CLOSE. Dlaczego? Ponieważ kanał IOCB#1 był otwarty przez poprzednią wersję handlera, czyli tę rezydującą pod OS-ROM, a tutaj program podmienia wpisy w HATABS w locie i instaluje swój nowy handler. W efekcie CLOSE #1 powoduje wywołanie procedury CLOSE już z nowego handlera! Wszystkie komórki dotyczące statusu kanału są ustawione przez inny handler, a nagle odpalany jest CLOSE tak naprawdę z innej wersji systemu. Normalnie powinno dojść do sytuacji, w której kanał zostaje zamknięty. Tutaj natomiast wywołanie CLOSE powoduje, że handler próbuje wczytać następny blok danych zamiast zakończyć odczyt.

I to właśnie jest problemem, bo przy standardowym formacie danych następny blok jest blokiem zawierającym nazwę pliku. Wywołanie CLOSE odczytuje więc ten blok, a następny "czysty" OPEN, wykonywany już przez właściwy loader, nie znajduje bloku nazwy. Wczytywanie programu tak naprawdę nigdy się nie zaczyna.

Ktoś wpadł na pomysł, aby dodać te dwa bity w trakcie pilota - bity, na których procedura odczytu bloku wywołana przez CLOSE się wysypie. Status błędu CLOSE nie jest sprawdzany, więc niczym to nie grozi. Dzięki temu następny OPEN poprawnie odczyta nazwę i loader zadziała prawidłowo.

Co ciekawe, rozwiązaniem tego problemu było tak naprawdę uruchamianie tego loadera przez wektor RUNAD. Wtedy, jak wspominałem, loader zawarty w MUEL przed wywołaniem kodu loadera po prostu zamykałby kanał IOCB#1, a ponowne wywołanie CLOSE przez nowy loader na zamkniętym kanale nie generowałoby już skutków ubocznych.

Warto jednak zaznaczyć, że efekt opisany wyżej występuje tylko w przypadku oprogramowania MUEL, które dołączałem do poprzedniego odcinka sagi o klątwie.

Zaczynam zastanawiać się, czy było to działanie celowe. Czy była to jakaś dziwna forma zabezpieczenia "z epoki", powodująca, że wszystko poprawnie działało tylko z cartridge'em od MUEL? A może był to efekt uboczny kombinowania przez kogoś już w czasach nowożytnych, zaś "pyknięcia" wstawione w pilota były obejściem problemu, które zadziałało trochę "przez przypadek"?

Mogę jedynie gdybać i snuć domysły. Nie mam jednak żadnej pewności, że te przypuszczenia są trafione. Coraz bardziej skłaniam się jednak do teorii, że kaseta i zapis na niej nie są tak stare, jak początkowo przypuszczałem.

Aby nie tworzyć kolejnych problemów, postanowiłem poprawić strukturę pliku loadera i usunąć "pyknięcia" z pilotów. Dodaję więc nową wersję plików w archiwum (v1.2).

Poprawka loadera (LoMem_Ldr) polega, tak jak wspominałem, na zamianie ostatniego segmentu danych z $2e0-$2e3 na zwykły segment RUNAD ($2e0-$2e1). Tak zmodyfikowany loader działa poprawnie z kilkoma wersjami softu Turbo 2000F, które miałem pod ręką.

Heh, no i zamiast odcinka III sagi wyszedł odcinek 2.5. Zatem przyjdzie wam jeszcze chwilę poczekać na obiecaną część III - trzecią i ostatnią :P Zaktualizowane archiwum znajduje się w poście z opisem części II.

The Klątwa Set - Part II: Tajemnice przeklętej taśmy

Wstęp, czyli zanim zacznie się właściwa klątwa

To był spokojny majowy wieczór 2026 roku. Dość dziwny był ten maj, bo całkiem chłodny, i nic nie zapowiadało wydarzeń, które miały za chwilę nastąpić...

No dobra, żartuję sobie trochę ;P, ale nie mogę obiecać, że dalej będzie "normalniej". Tematy, które tutaj poruszam, nie są przeznaczone dla ludzi "normalnych" - takie rzeczy tylko dla retro-świrów ;) Zatem zapnijcie pasy i jedziemy z tematem. Jak to u mnie bywa, zanim dopłynę do brzegu, poruszę pewnie masę tematów pobocznych i będę opowiadał o sprawach, które mój mózg jakoś łączy w jedność, choć większość ludzi nie zobaczy w tym żadnego "wspólnego mianownika" ani spójnej, logicznej całości... Wybaczcie, ja już tak mam ;-) Nie da się mnie naprawić.

Sprzęt do zgrywania, czyli dlaczego SHARP i Tascam

Operacja zgrywania kasety zaczęła się jak zwykle: stary deck SHARP, rejestrator cyfrowy Tascam DR-05X. Dlaczego taki zestaw do zgrywania? To zaraz się wyjaśni. Na początku chciałem jednak pokrótce opisać drogę, którą przeszedłem przy zgrywaniu taśm. Być może w jakiś sposób pomoże to komuś w przyszłości, jeśli zechce powalczyć ze starymi kasetami.

Wiem, że czekacie na opis zawartości kasety, ale skoro już jestem w fazie "lania wody", to wykorzystam ten moment "twórczego amoku" mojej słabości do opisania paru faktów z przeszłości. Liczę, że może kogoś zachęci to do zgrywania kaset, które ma pod ręką. Nigdy nie wiadomo, czy nie ma tam jakichś ciekawych artefaktów z przeszłości.

Zaczynałem - nazwijmy to może dość łagodnie - od "przerostu formy nad treścią", a potem stopniowo upraszczałem swoją konfigurację. Piszę o tym tylko dlatego, abyście nie sądzili, że do takich operacji potrzebna jest jakaś superkosmiczna konfiguracja i studyjny sprzęt za grube pieniądze. W 99% przypadków wystarczą proste i tanie rozwiązania. Ja mogę służyć tutaj jako "anty-przykład", z tym że ja ten sprzęt miałem już wcześniej i wykorzystywałem go do innych celów. To nie było tak, że kupiłem go specjalnie na potrzeby zgrywania kaset.

Początkowo do zgrywania kaset używałem komputera PC, karty "E-MU 1212M" oraz decka Technics RS-BX501. Ta konfiguracja była jednak zdecydowanie "przewymiarowana" i zupełnie niepotrzebna. Do tego miała poważną wadę: konstrukcja samego decka oraz jego mechanizmu z obrotową głowicą (auto-reverse) była zupełnie nieprzystosowana do łatwej regulacji głowicy przez użytkownika. Kasety zgrywałem zatem z fabrycznym ustawieniem głowicy, co w przypadku niektórych kaset stanowiło problem, ponieważ były one nagrane na różnych rozklekotanych sprzętach, często z "losowym" ustawieniem głowicy.

Z czasem trafiłem na takiego taniutkiego SHARP-a z lat 80., w którym bardzo łatwo można było zdjąć osłonę szuflady, do której wkłada się kasetę. Dzięki temu mam łatwy dostęp do śruby regulującej skos głowicy, co umożliwiało mi indywidualne dobranie skosu głowicy do każdej kasety, która wpadała w moje ręce.

Warto jednak krótko wyjaśnić, że w przypadku kaset w kiepskim stanie, nagranych na magnetofonach z rozjechaną/rozregulowaną głowicą, taki zabieg pozwalał mi wyciągnąć największą możliwą stromość zboczy odczytywanego sygnału. Każda odchyłka głowicy od idealnego środka ścieżki magnetycznej powodowała utratę tonów wysokich, a co za tym idzie - zmniejszenie stromości zboczy sygnału reprezentującego zapisane dane.

Ten stary SHARP, w którym mogłem bez problemu kręcić głowicą, sprawdził się o wiele lepiej niż jakiś Technics z garścią dodatkowych systemów na pokładzie - zupełnie nieużytecznych w przypadku zgrywania "surowych danych" z kaset, które przez "naście" lat leżały często w mało komfortowych warunkach.

A skąd w ogóle pomysł na E-MU? To nie była moja fanaberia ani wymysł, że potrzebuję super jakości 24-bit/192 kHz, aby zgrywać stare kasety. Karta była wykorzystywana przeze mnie wcześniej, gdy pomagałem Xray-owi w przygotowywaniu różnych materiałów dla Radia UXA. A to zgrywałem jakieś kawałki z OPL3/Adlib, C64/SID czy też paru innych platform. Karta sprawdziła się znakomicie w tej roli. Wcześniejszy Behringer BCA-2000 umarł śmiercią naturalną wraz z Windows XP, na którym producent postanowił zakończyć jego wsparcie - no ale dość dygresji. Chodziło mi jedynie o wyjaśnienie, że nie kupowałem E-MU 1212M tylko po to, aby zgrywać stare kasety z programami dla Atari ;-) Zapewne w większości przypadków sprawdzi się dowolna karta dźwiękowa, nawet ta wbudowana w system, którego używacie.

Początkowo, gdy używałem E-MU 1212M, a były to czasy, gdy królował jeszcze Windows 7 (E-MU działało sprawnie jedynie pod Windows), wszystko sprawdzało się idealnie. Soft dołączony do karty świetnie sprawdzał się przy zgrywaniu danych, nie gubił żadnych próbek, sterowniki ASIO działały znakomicie, a cały proces zgrywania materiału mógł działać w tle, podczas gdy ja wykorzystywałem komputer do robienia innych rzeczy. Z czasem kolejne poprawki dla systemu Windows powodowały coraz większe problemy z działaniem E-MU. Firmę "E-MU Systems" kupił Creative Labs, co skończyło się porzuceniem produktu i jego naturalną śmiercią: brakiem aktualizacji sterowników, coraz większymi problemami z zapewnieniem jakości zgrywanego strumienia danych itd.

Ja jeszcze przez jakiś czas próbowałem eksperymentów z innymi rozwiązaniami, ale szybko doszedłem do wniosku, że mam dość walki z tym wszystkim (uśmiercaniem produktów poprzez brak wsparcia i aktualizacji sterowników przez producentów) i że jedyną sensowną drogą jest jakieś urządzenie, które działa niezależnie, nie potrzebuje aktualizacji i po zakupie nie może zostać uśmiercone przez producenta przez brak sterowników czy zakończenie wsparcia. Zacząłem się przyglądać różnym rozwiązaniom dostępnym na rynku.

Początkowo co prawda wymyśliłem sobie, że sam mogę zrobić jakiś rodzaj rejestratora - ale wiecie co, zacząłem grzebać i szybko mi się znudziło. W dodatku zobaczyłem, że są gotowe rozwiązania, dostępne od ręki. Zacząłem się przyglądać różnym rejestratorom cyfrowym i koniec końców mój wybór padł na TASCAM DR-05X. Czemu akurat ten? Bo trafiłem na niego, gdy był dostępny w jakiejś promocji, w całkiem rozsądnej cenie.

Użycie niezależnego rejestratora cyfrowego umożliwiło mi "uwolnienie" komputera od procesu zgrywania kaset. Nie musiałem już pilnować, czy coś dzieje się w tle, nie musiałem również uważać, aby nie zrobić restartu albo nie spowodować takiego dociśnięcia CPU, że program zgrywający dane zacznie się "dusić" i pominie jakieś próbki ze strumienia danych napływającego z karty dźwiękowej.

Wrzucałem kasetę, regulowałem głowicę (albo na ucho, albo z użyciem oscyloskopu), wciskałem REC na rejestratorze i mogłem zająć się czymś innym. Po kilkudziesięciu minutach plik audio był bezpiecznie zapisany na karcie micro-SD.

Powrót do przeklętej kasety

Ufff! Teraz chyba możemy wrócić do przerwanego wcześniej wątku...

Operacja zgrywania kasety zaczęła się jak zwykle: stary deck SHARP, rejestrator cyfrowy Tascam DR-05X, ustawienie głowicy "na słuch", wciśnięcie "REC" na rejestratorze, ustawienie poziomów i zajęcie się czymś innym na najbliższe 45 minut. Kaseta SKC, na której były zapisane programy, miała bowiem 90 minut długości (po ~45 minut na stronę).

Pierwsze objawy klątwy

Po zgraniu strony A przeniosłem plik audio (WAV, 48 kHz, 16-bit), szybko wrzuciłem go do Audacity i zacząłem słuchać oraz "oglądać" kształty zgranych fal. Wtedy zacząłem dostrzegać pierwsze oznaki "klątwy".

Tymi oznakami były nietypowe pyknięcia w sygnale pilotującym. Po drugie, natychmiast zauważyłem, że już pierwsze nagranie nie jest zapisane w standardowym formacie "Turbo 2000". Pierwszy blok był standardowy, jednak to, co następowało dalej po pierwszym bloku danych, nie było dalszymi standardowymi rekordami danych. "Na słuch" początkowo wyglądało to jak coś w stylu "*Speedy 2700/*AJEK", jednak po chwili słuchania dotarło do mnie, że to nie jest "Speedy 2700". Ten format danych brzmiał inaczej. Wyglądało na to, że pomiędzy impulsami 0/1 występują tony brzmiące jak "sync/pilot". Wtedy zaczęło mi coś majaczyć w pamięci: że kiedyś na giełdzie przy ul. Saskiej chłopaki wspominały o nowym formacie zapisu i nowej wersji oprogramowania systemowego dla Turbo 2000F.

Mając plik wave już na dysku, mogłem zacząć robić szybkie eksperymenty z użyciem emulatora. Do dyspozycji miałem Atari800 5.2.0 zmodyfikowany przez FUJI-ego tak, aby wspierał obsługę systemów turbo, lub Altirra, którą musiałem uruchamiać z użyciem Wine (używam Linuksa jako systemu operacyjnego "codziennego użytku").

Aby już nie przedłużać tego wywodu, powiem tylko, że chwilę mi zajęło, zanim zorientowałem się, czemu nie mogę poprawnie wczytać żadnego programu zgranego z tej kasety. Albo pojawiał się błąd 140 przy próbie wczytywania pierwszego bloku, albo - gdy już udało się to zrobić - następowało natychmiastowe wysypanie się komputera. Praca na emulatorze przyspieszyła zorientowanie się, co i gdzie się sypie oraz dlaczego. Szybko odkryłem, że pierwszy blok to loader, który próbuje ładować się bardzo nisko, przez co nadpisuje system turbo ulokowany w pamięci (używałem obrazu zrzuconego z cartridge'a "Klątwa"). Następne kroki polegały na użyciu wersji systemu Turbo 2000F od MUEL, który lokował się pod OS-ROM. Dzięki temu mogłem sprawdzić poprawność wczytywania programów zapisanych w "nowym formacie".

Co udało się odczytać ze strony A

Po wstępnej analizie zgranego materiału ze strony A okazało się, że ktoś przeprowadzał sobie na tej taśmie jakieś eksperymenty. Część gier została nadpisana inną zawartością, część była ucięta, a fragmenty niektórych nagrań były nieczytelne (pozostałości po starym/poprzednim zapisie). Zacznijmy może zatem od spisu tego, co udało mi się z tej kasety odczytać - oto "spis treści":

[NEW] Little Devil
[NEW] Decathlon
[NEW] Skateboard
[OLD] Tutunkhamun
[NEW] Jet Set Willy
[OLD] Kick Off [loader only]
[OLD] Hans Kloss
[---] nieczytelne pozostałości starego nagrania (Kick Off?)
[NEW] Screaming Wings
[NEW] Draconus (obcięty koniec nagrania)
[NEW] Rechnung Simulation
[NEW] TOTO-SYSTEM
[---] nieczytelne pozostałości
[OLD] Silent Service (LO-MEM SYS / loader)
[OLD] Silent Service (main program)
[NEW] Sex Test
[NEW] Moon Patrol
[NEW] Nadral
[NEW] Aztec
[NEW] Da'FUZZ
[NEW] Spellbound
[NEW] Zaxxon
[NEW] Taipei
[NEW] Draconus
[NEW] Super Cobra
[OLD] Fantastic Soccer (LO-MEM SYS / loader)
[OLD] Fantastic Soccer (main program)
[NEW] Yogi Bear and Friends in the Greed Monster
[NEW] Stack Up
[---] nieczytelne pozostałości poprzedniego nagrania
[NEW] World Soccer

Teraz mogę dodać krótki komentarz do powyższego spisu. [NEW]/[OLD] oznaczają format, w jakim zapisano daną grę/program. Pozycje oznaczone [---] to nieczytelne fragmenty.

Część "oryginalnych" pozycji na kasecie została nadpisana innymi programami. Np. gra "Kick Off" została ewidentnie nadpisana grą "Hans Kloss". Idąc dalej: końcówka gry "Draconus" (tej nagranej zaraz za Screaming Wings) została uszkodzona, tzn. ostatni segment gry, zawierający wektor RUN, jest ucięty, przez co loader "new format" nie uruchamia gry, tylko wraca do nadrzędnego systemu turbo.

Przyglądając się pozycjom Silent Service, Fantastic Soccer, World Soccer i analizując dodany "loader", z całą pewnością można potwierdzić, że ta kaseta była stworzona/nagrana dla systemu Turbo 2000F lokującego się pod OS-ROM. Skąd to stwierdzenie? Otóż ten "loader" to nic innego jak wersja systemu Turbo 2000F, która po załadowaniu lokuje się w niskich regionach pamięci (od $0700), ustawiając MEMLO na $199D (o ile dobrze zapamiętałem). Zresztą bardzo łatwo się o tym przekonać: po załadowaniu takiego loadera wciskamy RESET i lądujemy w wersji systemu Turbo 2000F, który siedzi na dole pamięci.

Ten właśnie "loader" nagrano przed grami, które podczas wczytywania ładowały się do pamięci pod OS-ROM. Właśnie stąd wniosek, że owa kaseta była używana z wersją cartridge'a, który zawierał soft dla Turbo 2000F ładujący się pod OS-ROM.

To jednoznacznie potwierdza, że cartridge "Klątwa" nie mógł poprawnie załadować większości programów zapisanych na tej kasecie. Żadna pozycja zapisana w "new format" nie miała szans, bo loader "nie współpracował" z softem zaszytym w karcie. Byłaby natomiast szansa na wczytanie pozycji "Hans Kloss", "Silent Service" czy "Fantastic Soccer", gdyby nie "pyknięcia" obecne w tonie pilotującym, których nie trawi wersja softu z "Klątwy".

Krótki bilans odzysku

Finalnie udało się odzyskać wszystko, co nie było na taśmie fizycznie zniszczone albo realnie nadpisane inną zawartością. Pliki, które sprawiały problemy, potraktowałem różnymi  metodami korekcji, filtracji i wzmocnienia sygnału - dałoby się o tym napisać kolejne kilkadziesiąt kilobajtów, ale to już temat na osobny wpis, a nie na tę część sagi.

Przetwarzanie WAV do HEX

No ale kurczę, do brzegu... do brzegu... Płynąc dalej, mogę napisać parę słów o tym, jak wyglądał proces przetworzenia zgranego pliku dźwiękowego. W tym wypadku, ponieważ zgrałem całą stronę jako jeden plik, używając emulatora i obrazu carta Turbo 2000F, próbowałem wczytywać "na żywca" poszczególne pliki, jednocześnie zaznaczając w projekcie miejsca, gdzie zaczynają się i kończą poszczególne nagrania. Po zakończeniu obróbki wyglądało to mniej więcej tak:

Mając już tak "obrobiony" projekt, bardzo łatwo mogłem dokonać eksportu poszczególnych fragmentów nagrania do oddzielnych plików ".wav". Potem do akcji wkraczał a8cas-util.pl, który rozpoznaje zarówno klasyczny format Turbo 2000/F/KSO, jak i pojedyncze bloki danych zapisane niezależnie. Konwersja przebiegała mniej więcej w ten sposób:

a8cas-util.pl conv -t turbo2000 05_jest_set_willy_05.14_07.08.dlt.wav 05_jest_set_willy_05.14_07.08.dlt.hex
Starting ecasound... started.
SUMMARY: Data blocks: 29 (0 Errors).
62 HEX blocks stored in file 05_jest_set_willy_05.14_07.08.dlt.hex.

Oczywiście zdarza się, że plik nie poddaje się konwersji bez różnych problemów. Wtedy przyglądam się plikowi w Audacity i stosuję różne korekcje albo zmiany parametrów konwersji.

Konwersję wykonuję zwykle do plików .hex, aby móc szybko obejrzeć strukturę przetworzonego nagrania. Gdy już otrzymam "paczkę" plików *.hex, które udało się skonwertować bez błędów, to teoretycznie mógłbym uznać sprawę za zakończoną i takie pliki opublikować. Najpierw chciałbym jednak, abyśmy przyjrzeli się strukturze takiego pliku "HEX", zawierającego opis struktury pliku po konwersji z pliku .wav.

Anatomia pliku HEX

Zapytacie: po co? To stanie się jasne nieco później. Na początek przykład na fragmencie pliku z kasety "Klątwy". Jest to gra "Jet Set Willy", zapisana w nowym formacie. Oczywiście powycinałem masę danych nieistotnych dla problemu, który chcę naświetlić. "..." reprezentują wycięte dane nieistotne dla tego przykładu.

A8CAS-HEX
FUJI 
pwms msb_first rising_edge_first 48000
pwmc 00093 46 4024 ; count=1
pwmd 12 23 00 ff 50 52 4f 47 52 41 4d 3a 35 20 a6 ; block no=1 ; length=13 ; checksum(modulo256)=a6 OK
pwmc 00000 46 1 ; count=1
pwmc 00151 46 584 12 1 23 1 46 3463 ; count=4
pwmd 12 23 f5 01 ff ff 06 08 ee 09 a9 80 8d 21 09 a9 00 ... 00 00 a9 ; block no=2 ; length=3075 ; checksum(modulo256)=a9 OK
pwmc 00000 46 1 46 1792 ; count=2
pwmd 12 23 ff ff 00 0c b4 19 d7 00 ; block no=3 ; length=8 ; checksum(modulo256)=d7 OK
pwmc 00000 46 11 ; count=1
pwmd 12 23 00 00 00 00 00 00 00 00 00 00 00 e0 f0 38 ... 01 70 00 ; block no=4 ; length=3511 ; checksum(modulo256)=70 OK
pwmc 00001 46 6 ; count=1
pwmd 12 23 00 20 75 29 be 00 ; block no=5 ; length=6 ; checksum(modulo256)=be OK
pwmc 00000 46 11 ; count=1

Zatem co widzimy w takim pliku? Nie wnikając w format zapisanych danych, chodzi mi tylko o fizyczną budowę takiego pliku HEX opisującego to, co "działo się" na taśmie.

Na początku mamy prosty nagłówek identyfikujący plik:

A8CAS-HEX
FUJI 

Po nagłówku następuje sekcja "pwms", która mówi o tym, jak traktować i interpretować dane oraz bloki (np. pwmc, pwmd) występujące dalej w pliku:

pwms msb_first rising_edge_first 48000

^^^ to mówi nam, że transmitowane bity są w kolejności od najstarszego (msb_first), potem że jako pierwsza leci narastająca krawędź zbocza (rising_edge_first), a następnie mamy określoną częstotliwość próbkowania. Ta częstotliwość jest kluczowa dla wyznaczenia czasu trwania impulsów, które reprezentują poszczególne stany (np. pilot, 0, 1).

Teraz warto zastanowić się, co tak naprawdę reprezentują bloki pwmc i pwmd. Zacznijmy może od bloku "pwmc":

pwmc 00093 46 4024 ; count=1

Co oznaczają te liczby?

• 00093 oznacza długość "ciszy" występującej przed rozpoczęciem sekwencji danych (w tym wypadku 93 ms).

• 46 oznacza długość pojedynczego impulsu (długość wyrażona w próbkach danych, tzw. samples). Aby obliczyć czas trwania, musimy pomnożyć długość impulsu przez odwrotność częstotliwości próbkowania (określonej w bloku pwms). W tym wypadku 46 próbek * (1/48 kHz) = 0,958 ms. Patrząc na specyfikację struktury zapisu dla formatu Turbo 2000, możemy domyślić się, że ta długość jest po prostu pilotem/tonem synchronizującym.

• 4024 - ta liczba określa liczbę impulsów, które zostaną wygenerowane.

Zestawiając to ze specyfikacją formatu, ten blok opisuje wstępny ton pilotujący, który powinien zawierać 4096 impulsów o długości 1 ms. Teoria teorią, a rzeczywistość rzeczywistością... Jak widać, po pierwsze długość impulsu nie wynosi dokładnie 1 ms, a po drugie a8cas-util wyliczył tylko 4024 impulsy zamiast 4096. Oczywiście jest to zupełnie normalne zjawisko. Po pierwsze, prędkości obrotowe silników zarówno magnetofonu zapisującego, jak i odczytującego mogą się nieznacznie różnić. Po drugie, będzie występowała nieliniowość przesuwu taśmy. Po trzecie, start silnika powoduje, że początkowe impulsy nie będą miały odpowiedniej długości i nie będą traktowane jako ton pilota. Wszystko to będzie powodowało, że każdy z takich zdekodowanych bloków będzie miał nieco inne parametry (w tym wypadku mozolnie obliczane przez a8cas-util).

Oczywiście procedury odczytu danych są na te wszystkie "niedoskonałości" zapisu przygotowane i wykazują się dużą tolerancją na tego rodzaju odchyłki. Dlatego to wszystko działa mimo tego, iż sam zapis magnetyczny, jak i taśma, na której jest on dokonywany, są dalekie od doskonałości.

Dodam jeszcze szybko opis bloku pwmd:

pwmd 12 23 00 ff 50 52 4f 47 52 41 4d 3a 35 20 a6 ; block no=1 ; 

^^^ ta sekcja zawiera 3 znaczące części: pierwsze dwie liczby (uwaga! są w formacie dziesiętnym!) określają długości impulsów reprezentujących stany logiczne dla "0" i "1", a dalej występuje blok bajtów zapisanych jako ciąg cyfr hex, znajdujący się w danym bloku danych. W tym wypadku:

• 12 - oznacza długość impulsu kodującego logiczne "0" --> 12 * (1/48 kHz) = 0,25 ms

• 23 - oznacza długość impulsu kodującego logiczne "1" --> 23 * (1/48 kHz) = 0,497 ms

• następne bajty to zawartość danego bloku danych

Jak widać na ww. przykładzie, długości impulsów "0" i "1" mieszczą się prawie idealnie w specyfikacji dla formatu Turbo 2000, czyli:

• "0" - impuls 0,25 ms

• "1" - impuls 0,5 ms

• "pilot" - impulsy o długości 1 ms

Normalizacja i ręczne egzorcyzmy

Teraz możemy wrócić do powodu, dla którego o tym wszystkim piszę. Teoretycznie wystarczyłoby te pliki .hex zamienić na .cas albo od razu konwertować je do formatu .cas, jednak uznałem, że skoro dokonujemy odczytu i odzyskiwania plików z kaset nierzadko w stanie agonalnym, to warto takie pliki po konwersji przywrócić do stanu "idealnego", tzn. zgodnego ze specyfikacją danego formatu (czy to będzie Turbo 2000, Blizzard, AST, etc.).

Pisząc "stan idealny", mam na myśli np. wyrównanie długości wszystkich impulsów, wyrównanie długości tonów sync/pilot, etc.

Idąc za ciosem: wyżej widać było, że długość impulsu pilota wynosiła 46 próbek (wartość idealna w przypadku plików 48 kHz to 48, gdyż 48 * (1/48 kHz) = 1 ms), "0" --> 12 (wszystko ok), "1" --> 23 (niewielka odchyłka, bo wartość idealna to 24).

Dlatego po takiej konwersji w większości przypadków "normalizuję" takie pliki, korygując wszystkie odchylenia od wartości standardowych.

Cały powyższy opis i tłumaczenie znaczenia poszczególnych liczb w pliku .hex miały na celu ułatwienie wam zrozumienia całego procesu i sposobu mojego postępowania. Być może zainspiruje to też kogoś do rozpoczęcia takich działań we własnym zakresie.

Jakie narzędzia wykorzystuję do tego celu? Początkowo robiłem to "półautomatycznie", używając edytora tekstowego i funkcji search&replace, jednak z czasem stało się to na tyle monotonne, że obecnie automatyzuję cały proces. Często wystarczy sed/awk, czasem prosty skrypt w Perlu, a coraz częściej jakiś skrypt w Pythonie. Początkowo walczyłem dzielnie i pisałem sobie jakieś dziwne wyrażenia regularne, jednak w dzisiejszych czasach, jeżeli dobrze napisze się prompt, to dowolny LLM bez problemu poradzi sobie z takim zadaniem, generując np. odpowiedni skrypt w Pythonie do przetworzenia wszystkich plików .hex do określonej, "znormalizowanej" postaci.

Jak było w tym wypadku? Wszystkiego po trochu. W niektórych przypadkach również "ręczna" edycja plików .hex i poprawki w krytycznych miejscach (np. uszkodzone bloki z nazwami plików), czasami jakiś skrypt w Perlu. Tutaj np. jeden z Perl-owych przykładów zmieniający długość pilota występującego po loaderze:

perl -pi.bak -e 's/^(pwmc 0000[01] 48 )2048(\s*;.*)?$/${1}2560${2}/' *.hex

^^^ zmieniamy długości wszystkich tonów pilotujących o długości 2048 impulsów na takie, które mają 2560 impulsów. Na wszelki wypadek tworzymy sobie od razu kopię plików (.bak).

Czasami nie da się zautomatyzować całego procesu i pozostaje ręczne dłubanie. Dotyczy to np. nagrań uszkodzonych lub taśm słabej jakości, z których mało co da się wycisnąć na poziomie automatycznego odzyskania czytelnego zapisu. Wtedy pozostaje ręczne dłubanie, zgadywanie i uzupełnianie brakujących fragmentów zapisu albo bajtów w wynikowym pliku .hex.

Po doprowadzeniu wszystkiego do jakiego takiego porządku i przetestowaniu, że wszystko się wczytuje, można dokonać konwersji na pliki .cas.

Od jakiegoś czasu uznałem, że nie ma sensu publikować oryginalnych ("surowych") plików .wav, bo po pierwsze zajmuje to dużo miejsca na serwerze, a po drugie często te pliki nie mają wartości bez odpowiedniej obróbki czy korekty. Byłyby kolejnym śmieciem w internecie, na który ktoś po latach by trafił i zmagał się z takim artefaktem, nie wiedząc, co się właściwie dzieje. Jeżeli uważacie inaczej, dajcie znać - mogę wrzucać i "surowe" zrzuty, o ile pigwa wytrzyma ;D

A i jeszcze jedno. Wcześniej pisałem o tych "pyknięciach" występujących w tonie pilotującym, które rozkładały na łopatki procedurę odczytu, powodując błąd 140. Tak wyglądało to w surowym pliku po konwersji:

pwmc 00151 46 584 12 1 23 1 46 3463 ; count=4

^^^ Jak widać, na tych "pyknięciach" potykał się "trochę" a8cas-util. Interpretując powyższy blok pwmc, widzimy, że:

• na początku mamy 151 ms ciszy

• 584 impulsy tonu pilota (długość imp. 46)

• jeden impuls "0" (długość imp. = 12)

• jeden impuls "1" (długość imp. = 23)

• 3463 impulsy tonu pilota (długość imp. 46)

Jak widać, śmieć na taśmie był interpretowany przez a8cas-util jako sekwencja bitów 0 i 1 następujących po sobie. To wystarczyło, aby procedura odczytu potraktowała te impulsy 0,1 jako początek bloku danych (skończył się już sync tone). Jednak po chwili znowu pojawiały się impulsy o długości tonu pilota, co powodowało, że procedura odczytu protestowała, bo po dwóch bitach danych pojawiał się impuls o długości, której procedura odczytu już nie dopuszczała po jej zdaniem "poprawnej" synchronizacji. To kończyło się błędem odczytu nr 140.

Co z tym zrobić? Najłatwiej poprawić takie bloki pwmc ręcznie, zastępując tę całą serię jednostajnym tonem pilotującym:

pwmc 00151 48 4096 ; count=1

Pliki CAS i wymagany system Turbo 2000F

Nie przynudzając dalej, nie pozostaje mi nic innego, jak wrzucić linki do plików CAS, które zostały już poprawione, "znormalizowane" i oczyszczone z większości zbędnego śmiecia (przynajmniej tego, który zauważyłem): "The Klątwa Tape" - archiwum zawiera pliki hex/cas. Wszystkie pliki są w takim stanie, w jakim były na oryginalnej taśmie (pozostawiłem oryginale loadery, nie podmieniałem żadnych plików), a więc pliki w "new format" zawierają oryginalny loader, który wymaga odpowiedniej wersji Turbo 2000F.

Dodać należy, że są to pliki "znormalizowane" i oczyszczone (mówię tutaj o długościach impulsów, pilotów, etc. zero ingerencji w dane zapisane na taśmie), jednak nadal pozostaje problem: jak je wczytać? W pierwszej części opisywałem, że loader "new format" wymaga konkretnej wersji systemu Turbo 2000F - tej lokującej się pod OS-ROM i mającej MEMLO na poziomie $0800. Taką wersją systemu jest np. wersja, którą dystrybuowała ze swoim Turbo 2000F firma MUEL. Poniżej w archiwum znajduje się zarówno obraz cartridge'a, jak i wersja .XEX, którą można uruchomić z dowolnie wybranego medium. Plik .bin (obraz carta) należy uruchamiać jako typ "Blizzard 4K cartridge". Zmodyfikowałem minimalnie kod procedury startowej, aby sama odłączała cartridge, co ułatwia testy pod emulatorem. Archiwum do pobrania tutaj: Muel Turbo 2000F - wersja rezydująca pod OS-ROM.

Strona B

A co ze stroną B? Otóż strona B nie zawierała sensownej zawartości. Ktoś próbował nagrać sobie kilka razy grę "Snowball". Przyznam, że jakość tego materiału była na tyle mało warta uwagi, że zupełnie się nim nie zajmowałem.

Ciekawostka crack-scenowa

Może poruszę jeszcze jeden temat. Na taśmie znajdują się dwie interesujące pozycje, biorąc pod uwagę atarowską crack-scenę, mianowicie:

Yogi Bear and Friends in the Greed Monster oraz Stack Up to releasy sygnowane przez Bloody Coders - taka ciekawostka historyczna. Pliki spakowane są za pomocą Power Packer-a z Amigi.

Co dalej?

Na dziś to chyba na tyle. Pozostaje mi do napisania część trzecią, w której udostępnię kod źródłowy nowej wersji loadera - takiej, która zadziała z każdą wersją cartridge'a. Dodatkowo udostępnię pliki .cas zawierające "odklątwioną" wersję plików z tej kasety. Te pliki CAS będzie można ładować używając dowolnego cartridge'a zawierającego system z serii 200X (2000F, 2001, KSO). Trzecia część chyba będzie najkrótsza. Muszę tylko nieco uporządkować źródła i wrzucić repo na GitHub.

PS: kolejny objaw klątwy

Już przy ostatnim teście dopadła mnie kolejna część klątwy. Zauważyłem, że pozycje Silent Service, Fantastic Soccer oraz World Soccer, do których dołączony jest loader - a właściwie cały system Turbo lokujący się na dole pamięci - mają problem z uruchomieniem. Ściślej mówiąc, problem dotyczy uruchomienia tego loadera w systemie Turbo 2000F od MUEL, do którego linkowałem powyżej. Tego problemu nie ma natomiast w przypadku użycia Turbo 2000 (pozycja 1 z menu) z cartridge'a od SONIX, o którym wspominałem w pierwszej części. Nie wnikałem co jest powodem bo wyszło mi to dosłownie przed chwilą,  ale ponieważ chcę już opublikować ten post, zostawiam wszystko w takim stanie jak jest. Tym bardziej, że za chwilę będę wrzucał "poprawioną" wersję plików z tej kasety - czyli wszystko w formacie "NEW", z nowym loaderem, który powinien uruchomić się z każdej wersji systemu.

ps2) część tej klątwy (MUEL) wyjaśniona, powodem był problem z tym że w emu miałem włączone urządzenie "H:", a loader w ciemno zakładał standardową konfigurację i zerował część tablicy HTABS "na ślepo", co powodowało że usuwał wpis dotyczący urządzenia "H:", zamiast "D:", a ponowa próba instalacji handlera dla urządzenia "D:" kończyła się niepowodzeniem.

Bardzo dziękuję za miłe słowa! Ja również chylę głowę przed Twoimi projektami i całą inżynierią wsteczną którą praktykujesz i dzielisz się ze światem. Przy Twoich osiągnięciach moje zabawy z magnetofonami, cartami i kasetami to jest wręcz poziom "przedszkola" :)

Ja też mogłem mieć jakieś 14-15 lat, nie bardzo pamiętam już czy to był początek lat '90 czy jeszcze czas tuż przed '90. Niestety nie pamiętam już dokładnie szczegółów, ale ten człowiek który mi montował to turbo, albo wcale nie wziął ode mnie pieniędzy, albo to były jakieś grosze. Czasy były jakie były... jako dzieciak nie dysponowałem żadnymi znaczącymi środkami pieniężnymi które mogłem przeznaczyć na takie wydatki. Zresztą na pewno obawiałbym się sam dłubać w tym XC12 na który tak długo czekałem :) potem oczywiście rozkręciłem ten magnetofon jak popatrzyłem jak ten człowiek to montuje to wtedy dopiero nabrałem odwagi do własnoręcznego dłubania.

A widzisz! Ciekawa i cenna informacja! To ja pierwszy raz kopier który zapisuje w "new format" zobaczyłem na dopiero jak w tym wątku pojawił się ten cart od SONIX. Na saskiej mieli co prawda dwie odmiany softu systemowego dla Turbo 2000F (stary lokujący się nisko w RAM i ten oznaczony literą "N", lokujący się po OS-ROM). Ale żaden z tych systemów czy cartów nie posiadał wbudowanego kopiera dla "nowego formatu". Również na kasecie "systemowej" nie było nic takiego dostępne. Być może piraci giełdowi trzymali to rozwiązanie dla siebie, bo trafiałem gry zapisane w tym formacie od czasu do czasu.

The Klątwa Set - Part I: Anatomia przeklętego zestawu

To będzie pierwsza część nieco dłuższej opowieści o kasecie dołączonej do zestawu "Klątwa". W tej części opisuję sam zestaw, problem z kompatybilnością różnych wersji software dla Turbo 2000F oraz powód, dla którego ta konkretna konfiguracja praktycznie nie miała prawa działać. W kolejnej części przejdę już do samej zawartości kasety i tego, co udało się z niej odzyskać.

Pewnie pamiętacie, jak parę postów temu opisywałem cartridge dla "Turbo 2000F" z doklejonym napisem "Klątwa". Do kompletu do tego cartridge'a był również magnetofon z przeróbką "Turbo 2000F" oraz kaseta z programami zapisanymi w Turbo 2000F, która teoretycznie powinna się wczytywać z użyciem magnetofonu oraz cartridge'a przeznaczonego dla tego systemu.

Po przywróceniu magnetofonu do życia mogłem wreszcie przetestować całą konfigurację. Naprawa objęła dołożenie brakującego kabelka SIO, wymianę wzmacniacza operacyjnego LM324, zastąpienie połamanych styków czujnikami Halla - o czym też wkrótce napiszę - wymianę kilku kondensatorów, pasków oraz licznika. Ten ostatni był połamany i wcześniej zalany czymś lepkim i żrącym.

Do przetestowania miałem więc następujący komplet:

• magnetofon CA12 z Turbo 2000F,

• cartridge z systemem "Turbo 2001",

• kasetę z programami zapisanymi w systemie Turbo 2000F.

Teoretycznie wszystko powinno zadziałać. Przed rozpoczęciem prób na realnym sprzęcie zgrałem jednak kasetę do postaci cyfrowej, żeby mieć kopię na wypadek jakiejś nieplanowanej katastrofy - na przykład wkręcenia taśmy, gdyby CA12 postanowił zrobić sobie psikusa. :P

Już pierwsze, wstępne analizy zgranej kasety zaczęły mi dawać pewien obraz sytuacji. Powoli zaczynałem się domyślać, skąd mogła wziąć się naklejka "Klątwa". Wszystko układało się w historię tak nieprawdopodobną, że trudno uwierzyć, aby poprzedni właściciel tej kombinacji sprzętu miał aż takiego pecha przy jej kompletowaniu.

Spróbuję to wyjaśnić dość prostym językiem i w miarę zwięźle, opisując mój tok postępowania.

Zaczęło się od obserwacji przebiegu WAV zgranej kasety. Analizując fragmenty nagrań zauważyłem, że magnetofon, na którym dokonano zapisu programów, miał pewną przypadłość. Po rozpoczęciu zapisu, jeszcze w trakcie tonu synchronizującego, pojawiało się krótkie zniekształcenie sygnału - ostre zbocze słyszalne jako charakterystyczne "pyknięcie".

Samo w sobie nie musiałoby to być dużym problemem, ale tutaj pojawia się istotny szczegół: istniało kilka odmian oprogramowania dla systemu Turbo 2000F. Część z nich różniła się adresami pamięci, w których lokowały się procedury systemu - jedne wersje zajmowały niski obszar pamięci, inne umieszczały większość kodu w RAM pod OS-ROM. Istniały też odmiany z nieco zmodyfikowanymi procedurami odczytu.

Nie wnikając zbyt głęboko w szczegóły techniczne: jedne wersje procedury odczytującej dane tolerowały nagłą przerwę w tonie synchronizującym. W takiej sytuacji restartowały synchronizację i ponownie czekały na odpowiednią długość pilota. Inne wersje, gdy już rozpoznały sygnał pilotujący o odpowiedniej długości, zakładały, że po zakończeniu tonu pilota mogą pojawić się wyłącznie impulsy odpowiadające zerom i jedynkom. Impuls o innej długości powodował błąd nr 140.

Pech chciał, że wersja oprogramowania zawarta na cartridge'u "Klątwa" należy właśnie do tej drugiej grupy. To wersja, która nie toleruje przerwania tonu pilota, jeżeli wcześniej uzna, że odebrała już wystarczającą liczbę impulsów synchronizujących.

Ale to nie jedyny problem w tym wypadku. Przed dalszymi wyjaśnieniami muszę jeszcze dodać, że wersja softu z tego cartridge'a lokuje się na dole pamięci, w obszarze $0700-$199D. To za chwilę okaże się bardzo istotną częścią całej układanki.

Teraz muszę opisać kolejny klocek tej układanki. System Turbo 2000F, gdy powstawał, był w 100% zgodny - przynajmniej jeżeli mówimy o formacie zapisu danych - z "KSO Turbo 2000". KSO Turbo 2000 z kolei odziedziczyło format zapisu danych po systemie Turbo 2T06.

W dużym uproszczeniu: te systemy turbo w swoim natywnym formacie zapisywały dane w blokach po 3072 bajty. Przed każdym z takich bloków występował ton pilotujący, a następnie seria impulsów reprezentujących zera i jedynki danych zapisanych w danym rekordzie.

Z czasem ktoś zauważył, że tony synchronizujące pomiędzy kolejnymi rekordami danych zajmują sporo miejsca na taśmie. Ktoś zatem wpadł na pomysł, aby zmienić format zapisu danych tak, by pozbyć się długich "pilotów" przed każdym rekordem. W ten sposób opracowano tzw. "nowy format" zapisu danych, który miał zredukować liczbę tonów pilotujących, a tym samym jeszcze bardziej przyspieszyć wczytywanie programów.

Ten format rozwiązywał jeszcze jeden problem występujący przy klasycznym formacie zapisu danych. Chodziło o to, że przy klasycznym zapisie w blokach po 3072 bajty oprogramowanie systemu musiało mieć zarezerwowany bufor pamięci o takiej właśnie wielkości. To do niego trafiał odczytany rekord.

Po dodaniu rozmiaru kodu obsługującego cały system turbo okazywało się, że wolna pamięć dla ładowanych programów zaczynała się np. dopiero od wspomnianego wcześniej adresu $199D. Dla większości programów ładowanych z DOS-u nie był to wielki problem, bo MEMLO dla DOS-u często oscylowało na podobnym poziomie, zależnie od używanej wersji DOS-u.

Problem z tak wysokim MEMLO pojawia się natomiast w przypadku gier, które ładują się nisko do pamięci RAM. Jeżeli taka gra zajmuje obszar poniżej $199D, może po prostu zniszczyć bufor danych systemu turbo albo sam kod systemu. Loader plików binarnych nie chroni tych obszarów krytycznych - zakłada, że ładowany program nie nadpisze ani jego samego, ani buforów używanych przez system turbo.

Tutaj "nowy format" pokazuje swoją drugą zaletę. Po pierwsze nie wymaga bufora 3072 bajtów na odczytywany rekord danych, ponieważ ładuje dane bezpośrednio pod adres wskazany w nagłówku. Po drugie loader obsługujący ten format jest o wiele krótszy niż rozbudowany handler systemu Turbo, więc MEMLO dla takiego loadera może być znacznie niższe niż w przypadku używania natywnego formatu.

Pojawia się też trzeci aspekt tej sprawy: programy zapisane w takim formacie były znacznie trudniejsze do skopiowania. Jeżeli użytkownik nie dysponował programem kopiującym dedykowanym temu formatowi, nie mógł swobodnie powielić tak zapisanego programu.

Muszę przyznać, że gdy zetknąłem się z tym formatem w przeszłości, nie posiadałem ani nie znałem żadnego programu kopiującego nagrania w tym formacie. Trafiałem jednak na takie nagrania na tyle rzadko, że nie było to dla mnie dużym problemem. W dodatku pozycje, które spotykałem wtedy w tym formacie, nie były żadnymi unikatami ani nowościami, więc po prostu przechodziłem obok nich obojętnie.

W moim przypadku znacznie częściej natykałem się na programy zapisane w formacie znanym jako "Speedy 2700". Dlatego właśnie w latach 90. powstał "Anty *AJEK Copy", który zyskał drugą młodość jakiś czas temu, gdy w kolekcji uicr0Bee trafiłem na kasetę zapisaną w tym formacie.

W tamtych czasach zakładałem, że dla plików zapisanych w "new format" musi istnieć jakieś narzędzie, którym posługiwali się piraci giełdowi. Musieli przecież jakoś od czasu do czasu zapisywać niektóre programy w tym formacie, szczególnie te długie albo ładujące się na tyle nisko do pamięci RAM, że normalna odmiana systemu Turbo 2000F/2001 nie dawała rady ich załadować.

Siedząc w swojej informacyjnej bańce ograniczonej do warszawskiej giełdy na ul. Grzybowskiej i ul. Saskiej, nie byłem świadomy istnienia jakiegokolwiek programu kopiującego obsługującego "nowy format". Dopiero po latach, gdy tutaj na forum pojawił się cartridge "Turbo 2000 v.3.0" od SONIX", dowiedziałem się, że taki program jednak istniał. Dzięki uprzejmości Dely'ego, który wykonał dump cartridge'a, możemy cieszyć się kolejną ciekawostką historyczną z epoki.

Po uruchomieniu carta i wybraniu opcji "Turbo 2000F+":

...możemy zobaczyć, że mamy do dyspozycji opcję "NCOPY". Okazuje się, że jest to program kopiujący umożliwiający odczyt i zapis plików w "nowym formacie".

Mając już "na tapecie" wątek Turbo 2000F+, mogę wspomnieć, że przed powstaniem "new format" autorzy rozwiązań związanych z systemem Turbo 2000F wpadli wcześniej na jeszcze jeden pomysł. Chcąc rozwiązać problem gier i programów wymagających wolnej przestrzeni adresowej w niskich lokacjach pamięci, wymyślili sobie, aby umieścić kod programu obsługującego system oraz 3 kB bufor danych pod OS-ROM, czyli w wysokich lokalizacjach pamięci: $C000-$CFFF oraz $D800-$FFFF.

Na dole pamięci umieszczono jedynie niewielki zestaw procedur umożliwiających kodowi znajdującemu się pod OS-ROM korzystanie z odwołań do ROM-u. Korzystanie z procedur w OS-ROM, gdy ten jest wyłączony, bo właśnie włączyliśmy RAM w obszarze ROM-u, jest dość problematyczne. ;P

Dzięki przeniesieniu większości kodu systemu pod OS-ROM uzyskujemy bardzo niskie MEMLO. W przypadku Turbo 2000F+ znajdującego się pod OS-ROM jest to $0800, co pozwala ładować programy zajmujące dość niskie obszary pamięci.

Pojawia się jednak inny problem: programy, które podczas ładowania próbują lokować się pod OS-ROM, mogą zniszczyć system turbo albo zawartość bufora przechowującego aktualnie wczytany rekord danych.

Pierwszy system Turbo 2000F lokujący się pod OS-ROM, z którym się zetknąłem, był rozwiązaniem sygnowanym przez firmę MUEL. Nie było wtedy jednak jeszcze mowy o "new format". Sądzę, że "new format" powstał jako następny krok ewolucji systemu.

Nie mam niestety pojęcia, kto jest autorem koncepcji "nowego formatu". Jak wspominałem wcześniej, podobne podejście do ładowania danych bez podziału na bloki wprowadził *AJEK. Jeszcze wcześniejsze rozwiązania tego typu można było spotkać w czeskich systemach turbo z serii Turbo 2000.

Wasze zdziwienie może zapewne budzić fakt, że napisałem tyle tekstu i wyjaśnień o systemach turbo, ich lokowaniu się w pamięci, formatach danych itd. Miałem przecież pisać o "przeklętej kasecie". Niestety musiałem poruszyć tyle wątków pobocznych przed właściwym wyjaśnieniem problemów z tą kasetą, ponieważ wszystkie te informacje są kluczowe dla zrozumienia problemu człowieka, który próbował cokolwiek wczytać z tej kasety przy użyciu opisanego wyżej kompletu sprzętu.

Podsumujmy zatem najistotniejsze informacje:

• Istniało kilka wersji oprogramowania obsługującego Turbo 2000F:
      - wersje lokujące się w dolnym obszarze pamięci, z wysokim MEMLO, np. $199D,
      - wersje lokujące się pod OS-ROM, z niskim MEMLO.

• Istniały dwa formaty zapisu danych:
      - klasyczny format zapisujący dane w blokach po 3 kB,
      - "nowy format", zapisujący każdy segment pliku binarnego jako długi, ciągły blok bez podziału na rekordy danych.

I teraz rzecz dość istotna: "nowy format" wymagał specjalnego loadera umożliwiającego wczytywanie danych w tym formacie. System znajdujący się na cartridge'u nie wspierał "nowego formatu". Obsługiwał jedynie klasyczny sposób zapisu danych, czyli ten z podziałem na bloki po 3 kB.

Aby wczytać program zapisany w "nowym formacie", tuż przed właściwym programem umieszczano więc loader. Po uruchomieniu wczytywał on dalsze dane, obsługując już "nowy format".

Zakładam, że postępowano w ten sposób, aby umożliwić w przyszłości zmiany kodu loadera w razie wykrycia w nim problemów albo gdyby zaszła konieczność zmiany formatu danych. Loader zapisany przed właściwym programem na taśmie dawał pełną swobodę wyboru tego, co znajdzie się potem na taśmie. Tak samo postępowano w przypadku loaderów L1 czy L2 - nagrywano je jedynie przed programami, które tego wymagały. Zakładam, że tutaj autorowi pomysłu przyświecała podobna idea. Program ładujący dane w "nowym formacie" był po prostu zapisany jako jeden blok w standardowym formacie Turbo 2000.

I teraz zbliżamy się do momentu, w którym wszystko stanie się jasne. Tą ogromnie pokręconą drogą doszliśmy właśnie do kwestii tego loadera.

Otóż taki loader powinien być bytem niezależnym i samowystarczalnym. Jednak z jakiegoś nieznanego mi powodu twórcy loadera obsługującego "nowy format" postanowili uzależnić go od istniejącego pod spodem systemu Turbo.

Tutaj pojawiają się dwa problemy:

• loader ładuje się w obszar $0806-$09EE,

• w kodzie loadera są bezpośrednie odwołania do procedur konkretnej wersji systemu turbo, umieszczonych w konkretnych miejscach pamięci.

Przypomnę tylko, że system turbo w cartridge'u "Klątwa" to wersja lokująca się nisko w pamięci RAM, w obszarze $0700-$199D. Dodam również, że większość pozycji zapisanych na omawianej kasecie to gry zapisane właśnie w "nowym formacie".

I teraz możemy wreszcie połączyć kropki: jakakolwiek próba załadowania programów z tej kasety przy użyciu "Klątwa Cartridge" nie miała żadnych szans powodzenia.

Jeżeli już udało się ominąć pyknięcie w pilocie pierwszego bloku, to załadowanie bloku zawierającego loader natychmiast niszczyło system turbo znajdujący się w pamięci. Loader pakował się w obszar $0806-$09EE, nadpisując istniejący już tam kod. Nawet gdyby jakimś cudem trafił w mniej istotne fragmenty systemu, to chwilę później i tak wykonywał bezpośrednie skoki do procedur na siódmej stronie pamięci, zakładając, że zostały one dostarczone przez konkretną wersję systemu - na przykład Turbo 2000F+.

Co ciekawe, nie są to żadne rozbudowane procedury. To naprawdę dwa proste kawałki kodu odpowiedzialne za przełączanie ROM/IRQ/NMI. Gdyby zostały wbudowane bezpośrednio w loader, byłby on niezależny od systemu, z którego został załadowany.

Jedyne, co przychodzi mi do głowy, to celowe działanie autora tego loadera. Być może po prostu chciał "przywiązać" to rozwiązanie do wersji systemu, której sam używał. Jeżeli faktycznie takie było założenie, to udało mu się w 100% doprowadzić człowieka, który trafił na tę "pułapkę", do siwych włosów. ;)

Cartridge "Klątwa" nie miał nigdy realnych szans na wczytanie programów z tej kasety. Po pierwsze: pyknięcia w tonie pilota były traktowane przez soft w cartridge'u jako błąd. Po drugie: loader "nowego formatu" zawieszał cały system już w momencie ładowania go do pamięci.

Magnetofon można było zaklinać, egzorcyzmować, wymienić połowę elementów elektronicznych i mechanicznych, a i tak nic by to nie dało.

Potwierdzeniem może być fakt, że po doprowadzeniu magnetofonu do sprawności i tak nie mogłem poprawnie wczytać żadnego programu właśnie ze względu na opisane wcześniej zjawiska. Dopiero używając cartridge'a "Turbo 2000F v.3.0" od SONIX udało mi się wczytać większość programów bez większych problemów, pomijając oczywiście kwestie plików uciętych i nadpisanych na samej kasecie: eksperymenty? Testy? Bezsilność walczącego z systemem? Próby dogrywania innych programów? Tego pewnie już nigdy się nie dowiemy.

Mogę jedynie podejrzewać, że poprzedni właściciel tego kompletu - magnetofonu, cartridge'a i kasety - napotkał tak złośliwe combo, że uznał cały sprzęt za przeklęty.

Oczywiście może być też tak, że nie jest to żaden komplet, tylko przypadkowa zbieranina różnych artefaktów. Być może programów z tej kasety nikt nigdy nie próbował nawet wczytywać. Bo skąd na kasecie programy zapisane w "new format", jeżeli założymy, że użytkownik magnetofonu posiadał jedynie cartridge niewspółpracujący z tym formatem danych?

Równie dobrze każdy z tych przedmiotów może pochodzić z innego miejsca i czasu. Niemniej jednak naklejka "Klątwa" pozwala snuć różne dziwne pomysły... ;-)

Poświęciłem na to wszystko sporo czasu, mimo że tak naprawdę nie jest to już dziś szczególnie praktyczna wiedza i zapewne nikomu się bezpośrednio nie przyda. Zaintrygowało mnie to jednak na tyle, że mimo pełnej świadomości kompletnie nieuzasadnionego nakładu pracy i czasu brnąłem w ten temat jak "zaklęty". :)

Niby wystarczyło tylko zgrać kasetę i udostępnić ją na forum. Zainteresowani sami wiedzieliby, co zrobić z takim materiałem. Jednak moja wewnętrzna ciekawość oraz wspomnienia z przeszłości nie pozwoliły mi przejść obok tego tematu obojętnie.

Musieliście też długo czekać na moją dalszą aktywność w tym wątku. Mimo że to "tylko jedna kaseta", poza samą obróbką materiału, analizą kodu loadera i deasemblacją wiedziałem, że samo napisanie posta wyjaśniającego zajmie mi sporo czasu. Dlatego odkładałem ten temat, ile się dało. W końcu jednak, chcąc zrzucić kolejny temat ze swoich barków, postanowiłem się zawziąć i zacząć pisać.

Zapewne mało kto dobrnie do końca, bo to, co tu wypisuję, dla większości ludzi będzie pewnie niszowymi bredniami człowieka z epoki, w której 8-bitowy mikroprocesor był szczytem techniki. Zatem pora zakończyć już tę część. Myślę, że powstaną jeszcze dwie kolejne. W części drugiej opiszę zawartość kasety: co udało się z niej odzyskać, co było ucięte albo nadpisane i jakie niespodzianki znalazły się na taśmie. Część trzecia będzie już podsumowaniem oraz krótkim opisem tego, jak postanowiłem zdeasemblować loader i stworzyć jego poprawioną wersję - bardziej uniwersalną oraz niezależną od wersji systemu dołączonej na cartridge'u.

na zakończenie jeszcze "bohaterowie odcinka" o których mowa:

^^^ zdjęcie auorstwa uicr0Bee ^^^

Kurdę! Co za uparty egzemplarz! Nie dość że tyle go reanimowałem to znowu nie działa? :( Ale silnik w ogóle się kręci? czy jest kompleta cisza?

POKE 54018,52

z poziomu BASIC-a i PLAY ... jaki daje efekt? kompletna cisza? (brak odgłosu silnika?).

Jakby co podeślij go jeszcze raz, nie będzie nam taki magnetofon się stawiał ;-)

A widzisz nie pamiętałem już że AUTOCOPY 3.0 ma inną długość bloku, sprawdzę.
Jeżeli chodzi o LDX #$A3 - jest dokładnie tak jak piszesz, chodzi o inną początkową wartość sumy kontrolnej.

No tak mój błąd, powinien być oczywiście " ; ", ale w przypadku XASM nie ma to znaczenia (a ja używam do kompilacji projektu XASM), XASM zapewnia wsteczną zgodność z QA, a więc wszystko co będzie po poprawnym mnemoniku będzie ignorowane, dlatego ' (apostrof) przechodzi w XASM a w MADS nie.

nie wiem jak w MADS, ale w XASM dyrektywa "ERT" (error if true) generuje błąd kompilacji jeżeli warunek jest prawdą. W tym wypadku to sprawdzenie czy skompilowany kod nie przekroczył adresu $CFFF. Jeżeli skompilowany kod przekroczy ten adres, to XASM po prostu zgłosi błąd. Usunięcie tabulatora zapewne spowodowało że "ERT" zostało potraktowane jako etykieta (nie używam MADS [ za małe  i za proste projekty robię ] - a więc to jedynie moje domysły).

Dzięki za skany! :) Każdy taki materiał jest bardzo fajnym i cennym historycznie znaleziskiem!

@tOri: dzięki za miłe słowa! To naprawdę była fajna przygoda... wyszło tak jakoś samo z siebie ;) Można narzekać na AI/LLM-y ale w tym wypadku to własnie model językowy był motywatorem do działania bo odwalał najnudniejszą robotę, taką za którą nie wziąłbym się sam przed długi czas, ponieważ okno czasowe jakim dysponowałem nie było zbyt duże.

@JLS: a to też jest ciekawa informacja! Nie pamiętasz może czy ten człowiek pod tym adresem nazywał się może Grzegorz Kania? Dopytuję to w niektórych carta do Blizzarda tam gdzie widnieje "KNS Corp.", "KNS" lub "KNS Corporation", widnieje też albo "G. Kania", lub "Grzegorz Kania". Ja to wszystko dopytuję się w celu zrozumienia zależności lub raczej niezależności firmy ATARES i KNS. Można jednak założyć że skoro przeróbkę na Blizzard zrobiłeś w Gliwicach to ten człowiek który tę przeróbkę wykonał (z dużym prawdopodobieństwem był to pan G. Kania / KNS Corp) nie był podmiotem zależnym od ATARES. Zastanawiam się też czy KNS Corp. to był niejako "szyld" pod którym działał pan G. Kania czy też w skład KNS Corp. wchodziło więcej osób. Zastanawiałem się również czy też ów "KNS" nie było skrótem np. od "KaNia Software" ;-) Ale to już czysta spekulacja jest.

Moje dociekania biorą się stąd ze początkowo myślałem że software/hardware jaki powstał dla Blizzarda rodził się ATARES, jednak im więcej kopię i im więcej czasu poświęcam na próbę zrozumienia zależności to wychodzi mi na to że system nie miał jednego autora, tylko to była ciągła ewolucja do której każdy działające wokół tego tematu dokładał swój wkład.

To pewnie jest już nie do ustalenia, ale ciekawi mnie czy ATARES które to potem w swoich cartridge miało software (loadery, KOS, etc.) sygnowane przez KNS w jakiś sposób dogadało się autorem tychże programów czy też było to na zasadzie czystej "partyzantki" i brania z rynku istniejących rozwiązań i pakowania ich do swoich produktów.

ZABEZTUR - rekonstrukcja ROM-u z pomieszanymi liniami adresowymi/danych

Dziś w wątku temat nieco odbiegający od tego, co zwykle tutaj prezentuję - postanowiłem zająć się czymś, co męczyło mnie od dłuższego czasu...

Zacznijmy może od tego że na stronie ś.p. Jerzego Soboli, w dziale schematy, na dole strony znajdują się również dumpy różnych ROM-ów. Jeden z nich opisany jest opisany tak:

zabeztur.zip - ROM kartridża TURBO 2000 zabezpieczający przed kopiowaniem nagrane programy.

Jakiś czas temu mnie to mocno zaintrygowało. Niestety zawartość dumpa wyglądała na kompletną sieczkę - losowy, nieczytelny ciąg bajtów. Przez długi czas odkładałem temat, bo brakowało zarówno czasu, jak i sensownego pomysłu, jak się za to zabrać. Zacząłem się nawet zastanawiać, czy dump nie jest po prostu uszkodzony. Nie chciałem również zawracać głowy Jerowi taką błahostką, odkładając temat na później. Jak się okazało nie zdążyłem zapytać i już nie będę miał takiej możliwości :(

Mimo wszystko temat nie dawał mi spokoju. Wracało co jakiś czas, aż w końcu stwierdziłem, że pora spróbować jeszcze raz - tym razem bardziej metodycznie. Nie chciało mi się jednak zaczynać całkowicie od zera, więc postanowiłem wspomóc się dużym modelem językowym (padło na ChatGPT 5.4). Pomógł mi on przygotować podejście do analizy danych oraz zaproponować metody, których ręczne opracowanie zajęłoby sporo czasu.

Zakładałem, że JER poprawnie odczytał zawartość EPROM-u, ale wszystko wskazywało na to, że:
- albo EPROM był uszkodzony i dump faktycznie jest błędny,
- albo PCB miało celowo pozamieniane ścieżki.

Coraz bardziej prawdopodobne wydawało się to drugie - czyli przemieszane linie adresowe i/lub danych.

Brute force wszystkich możliwości nie wchodził w grę - to daje (8+12)! permutacji, czyli coś około 2432902008176640000 możliwości :P

Zamiast tego zastosowałem podejście etapowe.

1. Dane (D0..D7)

Na początek założyłem, że problem może dotyczyć wyłącznie permutacji bitów danych. 
Przetestowałem wszystkie 8! permutacji, czyli 40320 możliwości, ale zamiast przeszukiwać wszystkie i sprawdzać "czy działa", użyłem heurystyki:

- histogram wartości bajtów
- częstość występowania typowych opcode-ów 6502 (A9, 20, 4C, 60, D0, F0 itd.)

Dobra permutacja szybko się wyróżnia - rozkład bajtów przestaje wyglądać losowo i zaczyna przypominać kod maszynowy.

2. Dolne linie adresowe (A0..A3)

Po poprawieniu danych ROM nadal był niespójny, ale już "prawie wyglądał jak 6502".

Kolejny krok to "brute force" dla A0..A3 (11880 przypadków, bo 12P4 = (12!)/(12-4)! = 12 × 11 × 10 × 9 = 11880) z oceną lokalnej składni:

- dopasowanie sekwencji typu:

A9 xx
20 xx xx
4C xx xx
8D xx xx
D0 xx
60

Na tym etapie pojawił się pierwszy "żywy" kod - nadal rozbity globalnie, ale lokalnie sensowny.

3. Środkowe linie (A4..A7)

Tutaj zaczęły pojawiać się fragmenty tekstów, więc do punktacji dodałem:

- premię za ciągi ASCII
- dopasowanie fragmentów słów (np. "TURBO", "format", "plik")

Obraz ROM-u stawał się coraz bardziej czytelny, choć napisy nadal były porozrywane.

4. Górne linie (A8..A11)

Przełomowy moment nastąpił, gdy zauważyłem, że fragmenty napisów istnieją, ale są rozdzielone między różnymi obszarami pamięci.

Przykład:

"Zly fo"  ...  "rmat pliku"

Czyli dane były poprawne, ale większe bloki (strony) były źle ułożone.

Na tym etapie wystarczyło brute force dla 4! = 24 wariantów i dopasowanie pełnych stringów:

- "Zly format pliku"
- "TURBO COPY"
- "dlugosc"
- itd.

Jeden wariant wyraźnie się wyróżnił - i to był właściwy kierunek.

Wynik

Po odwróceniu wszystkich permutacji:

- ROM jest w pełni poprawny
- system uruchamia się w emulatorze
- teksty i logika programu są spójne

Finalne mapowania

Dane:

CART        -> EPROM 2732
-------------------------
D0          -> D1
D1          -> D0
D2          -> D5
D3          -> D4
D4          -> D7
D5          -> D6
D6          -> D2
D7          -> D3

Adresy:

CART        -> EPROM 2732
-------------------------
A0          -> A2
A1          -> A10
A2          -> A11
A3          -> A9
A4          -> A3
A5          -> A8
A6          -> A7
A7          -> A6
A8          -> A5
A9          -> A4
A10         -> A0
A11         -> A1

Podsumowanie

Plik, który początkowo wyglądał jak losowy szum, koniec końców okazał się poprawnym zrzutem pamięci EPROM. Nie wiem, czy pozamieniane linie adresowe/danych miały być rodzajem zabezpieczenia, czy raczej ułatwieniem prowadzenia ścieżek na płytce drukowanej. Niestety nie widziałem oryginału, z którego JER wykonywał dump, więc mogę się jedynie domyślać.

Całość udało się odtworzyć wyłącznie na podstawie:
- analizy statystycznej danych
- struktury kodu 6502
- oraz fragmentów tekstów obecnych w ROM-ie

Początkowo zakładałem, że nie uda mi się odkryć tajemnicy tego pliku, ale w końcu udało się ją rozwiązać i przestało mnie to "męczyć", teraz mogę stwierdzić że była to fajna zagadka - zdecydowanie warta poświęconego czasu! Naprawdę cieszę się, że cała ta zabawa zakończyła się sukcesem, mimo że odkrycie zawartości wywołało u mnie raczej uśmiech na twarzy, bo po tej całej walce moim oczom ukazał się następujący obraz:

^^^ zatem z dużym prawdopodobieństwem można przyjąć, że to nie jest: "ROM kartridża TURBO 2000 zabezpieczający przed kopiowaniem nagrane programy", tylko raczej: "ROM kartridża TURBO 2000 zabezpieczony przed kopiowaniem". Zabezpieczeniem był nietypowy układ ścieżek na płytce cartridge ;) Cart z identyczną zawartością był już opisany w tym wątku, a dokładniej w tym poście: Turbo 2000 COPY <--- z tym że ten cart nie miał pozamienianych linii danych/adresowych.

Dla porządku oczywiście wrzucam link do tego, co udało się zdekodować: WZab_2T12_recovered.bin.zip

Skróty plików zgadzają się w 100% z tymi, które są udostępnione w w/w poście:

MD5    : b74515156ce99bbb658ef342a91f051f
SHA256 : 2821fec46fb1caf4ad75f0f2f5905987671df0d5d18c7f9d098d95a23ae7154b

A dla jeszcze większego porządku - aby każdy zainteresowany mógł samodzielnie zdekodować plik ze strony JER-a - dodaję skrypt w Pythonie: descramble_WZab_2T12.py, przykład użycia:

python3 descramble_WZab_2T12.py WZab_2T12_scrambled.bin -o WZab_2T12_recovered.bin 
Gotowe.
Wejscie : WZab_2T12_scrambled.bin
Wyjscie : WZab_2T12_recovered.bin
Dane    : (1, 0, 5, 4, 7, 6, 2, 3)
Adresy  : (2, 10, 11, 9, 3, 8, 7, 6, 5, 4, 0, 1)

Skróty pliku wynikowego:
  MD5    : b74515156ce99bbb658ef342a91f051f
  SHA256 : 2821fec46fb1caf4ad75f0f2f5905987671df0d5d18c7f9d098d95a23ae7154b

I to chyba tyle na dziś - dobranoc wszystkim!

Hejka!

No właśnie ową "klątwę" zostawiłem na sam koniec licząc że będzie to ciekawy przypadek... a mówimy o takim nieboraku:

^^^ otóż ta dodatkowa naklejka z napisem "KLĄTWA", była dość intrygująca.

Prawdę mówiąc liczyłem na jakieś dziwne combo typu cart zawierający grę "KLĄTWA" oraz dodatkowo soft do Turbo 2000F/2001, jednak okazało się to dużą nadinterpretacją z mojej strony... normalnie klątwa mnie dopadła i spotkał swego rodzaju zwód ;-) bo jakże to tak? Nie będzie nowego wyzwania!?! Bleh... Nie wiem kto sobie wymyślił taki numer, ale w pełni mu się to udało... może Turbo 2001 okazało się prawdziwą klątwą dla właściciela tego kartridża ;-P

Z pewną taką nieśmiałością zabrałem się do otwierania tego carta... i moim oczom ukazał się las... (to żart oczywiście :P) ... a tak naprawdę ukazała się następująca płytka drukowana:

Strona elementów:

Strona lutowania:

Jak to zobaczyłem to wydałem z siebie jęk zawodu... otóż jest typowy kartridż oparty o 4kB pamięć EPROM, mieszczący w sobie tylko i wyłącznie oprogramowanie systemu Turbo 2000F/2001 oznaczone w tym wypadku sygnaturą v.2.2, mówię oczywiście o naklejce na obudowie. Po uruchomieniu oczywiście można zobaczyć co następuje:

Standardowy cart dla Turbo 2001 zawierał 2KB pamięć EPROM i nie zawierał programu kopiującego, był zmontowany na identycznej PCB, o czym pisałem już w tym poście: Turbo 2001 v.2.1. Również w tym wątku pojawił się dump tożsamego carta udostępniony przez użytkownika "Yezy", dokładnie w tym poście: Turbo 2001 + COPY.

Zawartość pamięci "wyklętego" carta okazała się tożsama z tym co udało się wrzucić na forum Yezemu, ale dla porządku i weryfikacji poprawności zrzutów umieszczam również i ten dump: Turbo 2001 v.2.2. Skróty (MD5/SHA256) plików się zgadzają z tym co udostępnił Yezy:

t2k1_v22_klatwa.bin | 61e5ee7ab9a59c7544c317935acaa8af                                  | MD5
t2k1_v22_klatwa.bin | 1a4ea1b4f5f4e653f6813672a391f9735dd219bf3ac004fc35828c874e293380  | SHA256

Co mi więcej pozostało? Dla porządku narysowałem schemat tego co było na PCB:

oczywiście do pobrania wersja wektor: Turbo 2001 4K CART (PDF).

Jak więc widać jest to typowy cart z tamtego okresu który mapuje się w oknie $A000-$BFFF, a ponieważ pamięć ma tylko 4kB a okno wynosi 8kB, to w obszarze $A000-$BFFF widać dwa powtórzenia zawartości pamięci, tzn. obszar $A000-$AFFF zawiera dokładnie to samo co obszar $B000-$BFFF. Cartridge wyłącza się samoistnie po paru sekundach, do tego czasu soft zawarty w carcie kopiuje się do RAM i cierpliwie czeka na odłączenie się kartridża aby przejść dalej.

Program kopiujący "Universal Copy II" dodany do carta był napisany przez Jakuba Kruszonę. Nie mam natomiast żadnej pewności czy autor programu kopiującego pozwolił na to działanie, czy też twórcy carta po prostu umieścili ów program bez wiedzy autora.

No i taki smutny koniec, nieco przeklęty nam się trafił na koniec. To chyba był ostatni cart z obecnej transzy od uicr0Bee, teraz pozostało mi doprowadzić magnetofony które mi pozostały w pudle do porządku, ale to nie będzie ciekawa robota... jeden to magnet w standardzie, drugi (ten do którego był dołączony "Klątwa" kartridż to magnet z Turbo 2000F/2001 pozbawiony kabelka.

Czeka nas w wątku chwilowa przerwa bo muszę obrobić to co pozostało i zająć się na chwilę czym innym, ale obiecuje że niebawem będzie trochę o kasetach w formacie AST, także proszę o cierpliwość i na chwilę obecną odmeldowuje się.

PS) Będę miał do Was, szanowni forumowicze, kilka pytań dotyczących Atares i KNS Corporation. Może ktoś coś jeszcze pamięta - ale to w następnym poście (za jakiś czas), bo muszę najpierw uporządkować to, co udało mi się do tej pory ustalić. Nie chcę pisać chaotycznie, więc wolę zebrać wszystko do kupy i dopiero wtedy zadać konkretne pytania. Być może ktoś z Was będzie w stanie rozwiać moje wątpliwości i rzucić nieco światła na tę historię. Na razie pozwoliłem sobie nieco rozbudować wpis na Atariki o firmie ATARES. Jeśli ktoś ma coś do dodania albo uściślenia - będę wdzięczny za informacje.

Hej!

Po krótkiej przerwie następny cart od uicr0Bee, dziś postaram się krótko i zwięźle, w sumie to miała być formalność, bo to kolejny klon carta z serii "Blizzard HIT", o których pisaliśmy już w tutaj: Blizzard HIT - z kolekcji Dely-ego oraz tutaj, gdzie zaprezentowałem kolejny klon z tej serii: Blizzart HIT - modern clone <--- w tym wypadku wszystko wskazywało na to że była to "nowożytna' replika.

W sumie do tego carta też miałem podejść "po łebkach", bo w sumie to kolejna odmiana Blizzard 32K cart z softem "HIT" w środku. Jednak tym razem autor tego rozwiącania, postanowił nie usuwać do końca śladów po oryginalnym autorze tejże składanki, a jedynie dopisał swoje inicjały do linii z "credits", pozostawiając Artura Miareckiego jako autora oryginalnej "składanki". Sam cart prezentuje się tak:

górna warstwa płytki drukowanej wygląda tak:

a dolna strona prezentuje się następująco:

Po uruchomieniu widzimy następujący ekran powitalny:

^^^ Widzimy na nim standardowe menu carta "Blizzard HIT", jednak tak jak wspominałem wyżej pozostała informacja o autorze oraz inicjały "H.M", które prawdopodobnie są inicjałami autora PCB. Dodatkowo na naklejce pamięci EPROM widzimy napisy: "HIT1" oraz wersję oprogramowania "3.93".

Jak wspominałem wyżej, miałem podejść do tego klona "po łebkach", ale w ostatniej chwili tknęło mnie że ta PCB jest nieco inne i schemat nieco się różni od cartów prezentowanych wcześniej, te różnice mnie na tyle zaciekawiły że postanowiłem przerysować schemat na nowo:

oczywiście do pobrania schemat również w wersji wektorowej: Blizzard 32k - HIT clone "HENS".

Kończąc już ten post pozostaje mi udostępnienie pliku zawierającego zrzut pamięci EPROM: blz_hit_hens.bin.zip.

34ea8c233be22c17e8a02e2eb532dbaf04b89d61a7868d701209aa504572b142  blz_hit_hens.bin | SHA256

hash pliku jest oczywiście inny niż we wcześniej wymienionych klonach, ale to z tego względu że pozmieniano linię zawierającą "credits". Porównując pliki różnice znajdziemy właściewie tylko w tych miejscach gdzie dokonano modyfikacji napisów.

A i jeszcze jedno; Cart to standardowy cart mapujący się w przestrzeni $A000-$BFFF. Cart posiada na pokładzie pamięć 27256, czyli 256kb (kilo-bitów), a więc 32kB. 8kB okno umieszczone w obszarze $A000-$BFFF ma przełączaną zawartość (4 banki po 8 kB). Przełączenie następuje przed odwołanie do obszaru $D500-$D5FF, to powoduje aktywność sygnału ~CCTL, który jest podłączony do wejścia zliczającego licznika 7493. Licznik generuje dwa dodatkowe bity adresu A13,A14. Cart startuje z włączonym BANK #0, kolejne aktywności w obszarze $D5xx powodują przełączanie banków, a w chwili 4 odwołania następuje wyłączenie cartridge. Czyli po starcie mamy BANK #0, potem BANK #1, BANK #2, BANK #3, CARTRIDGE OFF. Kolejne uruchomienie carta wymaga albo cyklu wyłącz/włącz komputera, albo naciśnięcie na carcie przycisku (resetuje przerzutnik RS oraz lincznik 7493 wewnątrz carta) oraz wciśnięci RESET na klawiaturze komputera, wtedy to system operacyjny wykryje pojawienie się cartridge i uruchomi go ponownie. Przypomną tylko jeszcze, że aby uruchomić obraz pod emulatorem wybieramy typ cartridge "Blizzard 32K".

Teraz zaczynam się zastanawiać czy ten "klon" jest faktycznie klonem czy też może to była współpraca Artura Miareckiego i kogoś kto podpisywał się inicjałami "H.M.", a cart był sygnowany jako "HENS". Schemat wygląda na wczesną wersję projektu, klony miały nieco inną konstrukcję (pozbyto się tranzystora, wykorzystano inne części liczników 7490/7493). Ale ja to mogę sobie jedynie dywagować, na te moje dywagacje mógłby pewnie odpowiedzieć jedynie sam autor (Artur Miarecki). Jeżeli ktoś wie kim mógł być H.M. lub HENS proszę o informacje, być może udałoby się wtedy ustalić pochodzenie tego cartridge.

Na dziś tyle! Do usłyszenia niebawem.