Dziękuję za sprawdzenie i dalsze zgłębienie tematu! Mamy jakąś jasność co do tego że pod tym adresem pan Grzegorz Kania nie mieszkał, przynajmniej w chwili w której powstawała książka telefoniczna. Na chwilę obecną można chyba uznać że zabrnęliśmy w ślepą uliczkę. No trudno, może przyszłość przyniesie jakieś wyjaśnienia.

Przyznam że już nie pamiętam czy te konkretne kasety były u mnie, możesz dorzucić do przyszłej paczki, zgram oczywiście. Ale rzucę jeszcze okiem czy czegoś nie pomieszałem i czy czegoś nie opuściłem. Białe pudło jak najbardziej było w moich rękach.

Powinno być "2.3" :-)
o-tu-o-ło: https://www.atari.org.pl/forum/viewtopi ... 25#p245325

tchoovay ;-)

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 ^^^

przeczytałem i ja ;-P
>>" Zainteresowani sami wiedzieliby, co zrobić z takim materiałem"
mimo że jestem zainteresowany, to bym nie wiedział. jako użyszkodnik t2000kso nie miałem kontaktu z tym 'new format'. zestawami maraudera z 'ajkiem'-tak, ale z czymś takim to nie..

Ja też miałem takie turbo, czyli tzw. "KSO Turbo 2000" dokładnie tę wersję z kablem do drugiego portu joysticka. Tyle że w moim wypadku ten interface zamontował mi człowiek mający swoje stanowisko na giełdzie komputerowej w technikum chemicznym na ulicy Saskiej. On chyba po prostu miał dość jak prosiłem go o nagrywanie mi programów na kasety w "normalu" ;-) Mam ten magnetofon do dziś... pewnie kiedyś przyjdzie pora na opis również tego "zabytku" :D

Starość, nie radość, pamięć już nie ta więc nie pamiętam u kogo byłem by zamontować Turbo 2000F. Jakieś blokowisko w Warszawie to jedyne co pamiętam (gówniarz byłem) i że przełącznik turbo/normal był z tyłu magnetofonu.

Cartridge miał chyba jakiś kopier z obsługą N: właśnie do zapisu bez przerw.

Ot tak :-)
Tak jak zdiagnozowanie i naprawienie błędu w grze Nexuss przy innej okazji :-)
https://www.atari.org.pl/forum/viewtopi ... 53#p246153
https://www.atari.org.pl/forum/viewtopi ... 56#p246156
https://www.atari.org.pl/forum/viewtopi ... 73#p246273

To była podróż przez najniższe kręgi zaświata kaset.Ale udało ci się wrócić do światła.

Pamiętam też niezręczność loaderów L1 i L2. Jeden z nich był autonomiczny i miał własną procedurę dekodowania bloków. Drugi był zależny od KSO, co uniemożliwiało użycie go jako pliku rozruchowego kasety. Tak właśnie programowano w tamtych czasach.

W XXI wieku moje specjalne loadery zazwyczaj ładują się pod bezpieczny adres, a następnie same się tam przenoszą.

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.