Hej!

Już ku formalności załączam archiwum z przekształconymi do formatu CAS, plikami zawierającymi grę Kuadryk (Kwadryk?) .

Archiwym zawiera 3 pliki:

1. Kuadryk (Sonix) [FSK].cas

2. Kuadryk (Sonix) [T2K].cas

3. Kuadryk (Sonix) [T2F, T2K, AST].cas

1] Plik zawiera grę zapisaną w prędkości standardowej. Sposób zabezpieczania z tym który opisywałem przy Gabi, a więc rekordy o niestandardowych rozmiarach, a do tego w strumień wtrącone bajty z niższą prędkości bitową.

2] Plik zawiera grę zapisaną w Turbo, przed grą w turbo zapisano loader ładujący się w prędkości standardowej, jednak z zabezpieczaniami (rekordy o różnej długości), ten loader oczekuje sygnału na drugim porcie Joysticka, a więc zgodność sprzętowa z KSO Turbo 2000. Impulsy kodujące zgodne z KSO Turbo 2000/Turbo 2000F, zabezpieczenie tożsame z tym które opisywałem parę postów wyżej z opisem zastosowanych zabezpieczeń w Gabi.

3] Plik zawiera również grę zapisaną w Turbo, jednak loader tym razem obsługuje systemy turbo które oczekują sygnału na linii DATA_IN portu SIO, a więc będą działać systemy takie jak AST, ATT, UM (i wszystkie które są włączane za pomocą linii COMMAND), Turbo 2000F (po wczytaniu loadera w standardzie należy szybko przełączyć magnetofon na tryb turbo). Loader ten jednak jest na tyle uniwersalny że jeżeli wykryje interface KSO Turbo 2000 podłączony do drugiego portu joysticka, to przełączy się na odbiór sygnału z tegoż źródła.

Widzisz, siedziało mi to jakoś z tyłu głowy, tzn. przyjrzałem się plikowi od Ciebie, a ponieważ był w niezłej formie i jakości, to zauważyłem że mimo tego że suma kontrolna (CRC) jest błędna, to zawsze tak sama, czyli wynikało z tego że nagranie jest poprawne jednak format danych jest nieco inny, zajrzałem więc do loadera, a tam od adresu $7B1:

07B6: B1 32     LDA ($32),Y ;BUFRLO
07B8: 48        PHA
07B9: 18        CLC
07BA: 45 31     EOR $31     ;CHKSUM
07BC: 85 31     STA $31     ;CHKSUM
07BE: 68        PLA
07BF: 20 3B 07  JSR $073B
07C2: 68        PLA

... jest procedura która po odczytaniu bajtu danych z taśmy dokonuje aktualizacji sumy kontrolnej, czyli:

07B9: 18        CLC
07BA: 45 31     EOR $31     ;CHKSUM
07BC: 85 31     STA $31     ;CHKSUM

jak widać pod adresem $7B9 została instrukcja CLC, co oznacza iż oryginalnie była w tym miejscu standardowa procedura liczenia CRC, która wyglądałaby tak:

07B9: 18        CLC
07BA: 65 31     ADC $31     ;CHKSUM
07BC: 85 31     STA $31     ;CHKSUM

... teraz wszystko stało się jasne, w dodatku z tyłu głowy miałem gdzieś te wszystkie informacje o formatach danych które były w ten sposób zabezpieczony o o których napisał Pajero w Atariki: Zapis z zabezpieczeniami. Do tego jak pisałem wcześniej wydawało mi się że był jakiś program W.Zabołotnego który miał zmianę formatu odczytanych danych, w dodatku pamiętałem ten tekst z IKS-a, bo kiedyś poprawiałem w Atariki wpis o turbo 2T06 ... no i do kompletu na pewno czytałem Twoje wpisy o Long Turbo Copy, tylko pamięć moja nie pozwalała sobie na przypomnienie nazwy programu, ale na szczęście Ty o tym pamiętałeś :D

Ależ sądzę że zrobili to celowo i z premedytacją, nie wiem czy byli świadomi istnienia formatu 1T czy też "patchowali" istniejące (późniejsze) Turbo 2000F... ale ten "pozostawiony" samotny "CLC", na to właśnie wskazuje. Po prostu zmianę sposobu liczenia CRC uważali za swego rodzaju zabezpieczenie... jak "silne" ono było to właśnie widać ;) Dużo bardziej się postarali w Gabi/Kwadryk ;)

Wszystkie te systemu turbo, czyli KSO 2000, Turbo 2000F, Turbo 2001, etc. są zgodne w 100% z Turbo 2T06 Wojciecha Zabołotnego i sądzę że właśnie na tym rozwiązaniu bazowały, format zapisu na taśmie w tych wszystkich systemach jest dokładnie taki sam jaki stworzył/przedstawił/wymyślił W.Zabołotny ... nawet procedury transmisji KSO2000, T2000F, etc. są identyczne jak w Turbo 2T06. Te systemy i ich oprogramowanie to ewolucja w czystej postaci bazująca na tym czemu podstawy dał W.Zabołotny.... zresztą to samo dotyczyło się rozwiązań sprzętowych... to po prostu różne drogi do osiągnięcia tego samego celu.

A widzisz... czyli jednak nie miałem urojeń tylko sklerozę :) Pamiętałem że to był program od W. Zabołotnego :) Tylko nie kojarzyłem który :)

Następny kawałek układanki, czyli "Gabi" na warsztacie... udało się przeprowadzić konwersję do plików CAS, jednak nie jest ona optymalna, a to z tego względu że narzędzia zarówno Krótkiego (FSK) jak i i FUJI-ego (FSK/Turbo) nie przewidywały takich "myków" (czytaj takich niestandardowych metod zapisu) jakie wystąpiły w nagraniach (wydanych przez SONIX), ale o tym za chwilę.

Archwimum zawiera 3 pliki:

1. Gabi (Sonix) [FSK].cas

2. Gabi (Sonix) [KSO2000].cas

3. Gabi (Sonix) [T2000F, AST, KSO].cas

(1) plik CAS zawiera wersję Gabi zapisaną w standardzie. Narzędzie Krótkiego (a8cas-convert) poradziło sobie z konwersją tyle że nie do końca optymalnie, jednak wygenerowało poprawny plik CAS, tzn. taki który da się wczytać używają emulatora atari800. Jeżeli chodzi o Altirra to początkowo sądziłem że nie radzi sobie ona z tak zapisanym plikiem (loader po rekordzie z zabezpieczeniem twierdzi że nastąpił "błąd wczytywania"), chociaż bez problemu wczytuje plik w formacie WAV, wszystko wskazuje na to że Altirra ma błąd. Plik CAS nie wczyta się poprawnie, jednak gdy przełączymy w opcjach "Turbo Support" na "Always ON", a następnie załadujemy plik CAS, to on wczyta się i uruchomi bez najmniejszego problemu... tak... tak... to jest zupełny idiotyzm, bo przy "Turbo Support" ustawionym na "Always ON", nie powinno się dać załadować żadnego pliku w standardzie, jednak w tym wypadku to działa... dlaczego? nie wiem, nawet nie próbowałem wnikać. A odkryłem to przez przypadek gdyż wcześniej testowałem pliki zapisane w Turbo.

Może dwa słowa o zabezpieczeniach jakie zastosował Sonix, nie są one jakieś super skomplikowane, jednak jak widać "upierdliwe" zarówno dla narzędzi konwertujących jak i dla emulatorów. Nagranie składa się z loadera, który to potem ładuje dalszą cześć nagrania składającą się 512 bajtowych rekordów danych, jednak w kilku momentach nagrania (w przypadku GABI są to dwa miejsca) w rekordzie danych po występują bajty zapisane z obniżoną prędkością (nie 600 bodów tylko coś około 300 bodów) ... loader wie dokładnie kiedy te bajty w strumieniu danych nastąpią i ponieważ "podmienia" on wektor SERIN, to w chwili gdy taki bajt ma nastąpić przestawia on prędkość odczytu na obniżoną, następnie po odczytaniu takich "spowolnionych" bajtów, przywraca standardową prędkość transmisji.

Narzędzie do konwersji WAV-->CAS nie zakładają takiego scenariusza, ale wychodzą z tego obronną ręką, tworząc blok FSK od miejsca wystąpienia "spowolnionego" bajtu do końca rekordu (zamiast DATA) w pliku CAS. Nie przeszkadza to oczywiście w niczym poza estetyką pliku, jak widać emulator atari800 a nawet "oszukana" Altirra dają radę to wczytać. Pewnie by się to dało ręcznie nawet edytować i poprawić, ale to już pozostawię zapaleńcom i miłośnikom nagrań w formacie zabezpieczonym przez Sonix. Dysponując plikiem oryginalnym czy nawet plikiem CAS można sobie już zrobić z tego wszystko.

(2) Plik CAS zawiera wersję nagraną w formacie Turbo, długości impulsów PWM są zgodne z Turbo2000F/KSO Turbo 2000, tyle że format danych jest dość specyficzny... narzędzie FUJI-ego nie potrafiło nad nim zapanować (zaraz wyjaśnię dlaczego), więc należało przy konwersji do pliku CAS użyć formatu "genric" (opcja -t generic w a8cas-util), a więc zamiast typowych bloków "pwmd", są bloki typu "pwml".

A wszystko to wymuszone zostało przez format danych który zastosowano do zapisu... niby w tym formacie danych są normalne impulsy zgodne z Turbo2000F/KSO (tzn. sync, "0", "1"). Format danych niby identyczny z tzw. nowym formatem Turbo 2000F, gdzie każdy segment danych w pamięci jest zapisywany jako oddzielny blok, poprzedzony blokiem nagłówka (gdzie i ile danych będzie zawierał następny blok) ... jednak w przypadku tego formatu, rekord danych nie kończy się normalnie... następuje seria bajtów danych, a potem zamiast bajtu CRC jest jeden impuls sygnału pilotującego, co jest sygnałem dla loadera że to koniec bloku danych, a po tym impulsie, jest zapisany właśnie bajt CRC.

Zatem każdy program kopiujący czy też narzędzie nie "będące świadome" tego typu zabiegu, będzie traktowało taki przypadek jako błąd czy przekłamania danych, a loader sprawdza dokładnie i oczekuje tego "błędnego" impulsu jak znacznika końca danych.

Generalnie wygląda to tak jakby *AJEK maczał w tym loaderze palce, zastosowane mechanizmy i kod loadera jest dość podobny do tego co potem nastąpiło w Speedy2700 napisanym przez *AJEK.

Format danych jest po prostu drobną modyfikacją tego co się zwało "nowym formatem" Turbo 2000F lub tym formatem danych który baktraaa nazywa formatem L3 w swoim Turgen.

(3) Ten plik jest właściwie tożsamy z plikiem #2, różnica jest taka że loader niby jest przeznaczony dla systemów Turbo 2000F/AST/ATT/UM (oczekuje danych na linii DATA_IN portu SIO), jednak co ciekawe ten loader w przeciwieństwie do pierwszego loadera, jednak ten loader próbuje wykryć system turbo (jak speedy2700) i jak znajdzie podłączony interface KSO Turbo 2000 do drugiego portu JOY-a to przełączy się na odbiór danych z tego interface. Loader z pliku #2, nie próbuje wykonać auto-detekcji tylko od razu oczekuje sygnału z interface KSO2000.

Dane z tego nagrania udało się cudem wyłuskać, bo taśma miejscami była mocno zmiędlona, ale pomógł prymitywny konwerter którego używałem od obrobienia wcześniejszych nagrań z "Winter Olympiad 88".

Jak pisałem pliki wygenerowane z użyciem "-t generic" zawierają bloki "pwml" zawierające po prostu surowe dane określające długości poszczególnych impulsów zapisanych na taśmie, dlatego też o wiele dłuższe niż standardowe pliki zawierające segmenty "pwmd". Ale to już jest jakiś punkt zaczepienia, zawsze można napisać prosty konwerter, znając format danych i występujące w tym formacie "zabezpieczenie" odbiegające od standardowych rozwiązań.

Jak znajdę jeszcze wolniejszą chwilę to postaram zająć się też "Kwadrykiem", wszystko wskazuje na to że to przypadek podobny do GABI :)

ps) aby wczytać pliki CAS zapisane w turbo używając zmodyfikowanego przez FUJI-ego emulatora atari800, należy pamiętać aby opcja "Invert polarity durging READ" była ustawiona na "NO" (jest to pokłosie tego impulsu zabezpieczającego, po którym następuje bajt CRC).

wychodzi na to, że temat jest do zamknięcia ;)

Hej!

W sumie to chciałem kupić z ciekawości, bo mam jeszcze takie karty od Promise i 3ware, ale masz rację to jest kolekcjonerski box, a ja bym tego na pewno w pudełeczku nie trzymał, więc odpuszczam bo szkoda w takim stanie kartę do pracy zaprzęgać ;) Może ktoś z duszą kolekcjonera będzie tym zainteresowany :)

Hej!

Jak najbardziej tak! Szczegóły przesłałem na e-mail.

pozdrawiam serdecznie
Sebastian

to nie "moja" wersja SP :) Obrazek w moim poście jest podlinkowany ze strony MadTeam ;-)

Pytałeś o manipulację segmentami i optymalizację plików .xex, do tego SP nadaje się wręcz idealnie, ale ja nie jestem "poważnym graczem", jeżeli nawet coś dłubię to nic poważnego. Dla mnie SP ma 99% tych funkcji o które pytałeś, dlatego byłem zaskoczony trochę Twoim postem, bo nie raz dyskutowaliście o SP tutaj na forum w różnych wątkach...  i właśnie dlatego postanowiłem załączyć ów obrazek.

Wygląda na Turbo 2000F/2001... byłem co prawda ciekawy, ale nie licytowałem bo byli inni chętni, i widzę że słusznie postąpiłem bo na koniec się zrobiła "bitwa" snajperów ;)

jak najbardziej podtrzymuję, jutro napiszę e-mail, aby się jakoś zgadać na odbiór.