Przeglądałem właśnie jakieś moje stare stare papiery, które przeleżały w piwnicy ładnych naście lat... okazało iż mam coś takiego:

^^^ po otwarciu w nowym oknie/zapisaniu pliku będzie on większej rozdzielczości niż prezentuje to obecnie forum.

Przyznaję że nie pamiętałem że mam coś takiego. Wygląda na to że to "dokumentacja techniczna" systemu Turbo 2000F pochodząca z firmy MUEL. Skąd ją mam? Zabijcie mnie, ale nie pamiętam. Jest wielce prawdopodobne, że dostałem ją od człowieka który zamontował mi Turbo 2000F w magnetofonie (pisałem o tym wcześniej, tzn. wątek o giełdzie komputerowej w technikum chemicznym na ulicy Saskiej 78 w Warszawie).

Jest to schemat XC12 narysowany prawdopodobnie przez kogoś z MUEL (tak przynajmniej głosi tabelka technologiczna). Na schemat naniesiono informacje dotyczące montażu systemu turbo w magnetofonie. Schemat wygląda na narysowany w "OrCad Capture" dla systemu DOS. Zeskanowałem to w wyższej rozdzielczości, niż było wydrukowane/kserowane... lepiej wyglądać nie będzie.

Kto pomazał schemat (odręczne notatki)... jest możliwe że ja, bo niektóre cechy charakteru pisma wskazują że mogłem to być ja, "oryginał" był na tyle nieczytelny, że chyba podczas rozmowy z osobą przekazującą mi schemat dodałem jakieś uwagi typu "dla XCA12 47nF".  Ciekawe jest też to że napisano że należy usunąć 4.7nF znajdujący się przy głowicy ("C11 usunąć").

Najgorsze jest to że zupełnie nie pamiętam nic związanego z tym schematem, no ale skoro się "odnalazł" to dzielę się tym z wami. Zawsze to jakieś znalezisko z tamtych czasów.

Jeśli nie zamotali z adresami, to istnieje. Był opis gdzieś tu na forum nawet. Zasadniczo przydałby się Qmeg lub freezer, byłoby łatwiej. Albo @seban, ale trzeba by mu wysłać carta...

A masz jakiś komputer z systemem QMEG? Jeżeli to jest jakiś standardowy 8KB lub 16KB cart to za pomocą QMEG można dokonać DUMP-a w prosty sposób, przykład tutaj: QMEG Cart Dump tutorial

Wcześniej nie widziałem takiego carta, warto byłoby zrobić dump, naprawdę. A jak jeszcze Magnus/W.F.M.H. maczał w tym palce to naprawdę fajnie :D

Siedzę sobie spokojnie w lodówce... aż tu nagle...

^^^ AST from Hell, czyli produkcja kolejnego z członków grupy "The Distals".

...ale możecie być spokojni, nie będzie żadnego tear-down :P Na łagodniej zapaćkaną wersję tego interface udało mi się trafić już lata temu dzięki uprzejmości PET-a, który to wypożyczył mi swój magnetofon, więcej informacji w tym wątku: AST Turbo Cartrige i reszta.

Zdjęcie wklejam informacyjnie, jako obraz poglądowy, pokazujący jak bardzo autorzy rozwiązań próbowali zabezpieczyć swoje "osiągnięcia" :) Nie mam pewności czy to klon czy oryginał, ale układ i wygląda płytki sugeruje że to może być oryginalne wykonanie (zapewne jedno z wcześniejszych, bo potem jak widać w wątku wcześniejszych ograniczono się jedynie do paćkania w "brunatnej farbie" ;-)

Trzymam kciuki do końca :)

Super!

Niestety nie wiem skąd do mnie trafił. Zapewne z jakiejś aukcji, ale z jakiego miasta, to nie mam śladu.

off.t. a może nie?: z tym odwracaniem sygnału.

może któreś wykonania/wersje danego systemu turbo są (bardziej) podatne na odwrócony w fazie sygnał? wariacji na temat wykonania czy blizzarda czy t2000 jest co najmniej po kilka. może w którymś wykonaniu to ma znaczenie?.. (gdybam, bo się nie znam)

albo chodzi o coś innego,
ja też musiałem niedawno użyć opcji 'invert polarity...' w turgenie,
i to przy testowaniu ... zwykłego kso-t2000 (w magnetofonie ramika, na początku roku).

no - jak najszybciej sprawdzić czy kso działa w magnetofonie? na klaptopie z jakiegoś xexa robię wave'a, wygenerowanego turgenem na defaultowych opcjach, w miejsce słuchawek podłączam kabelek od adapteru kasetowego, ten wkładam do magnetofonu. atari-włącz, ciach - play, NRD***, wczytało elegancko, znaczy się działa, jest ok.

ale że wraz z magnetofonem miałem też taśmę/kasetę do testowania, to sobie pomyślałem, że nagram ramikowi trochę softu do tego kso, jakieś gierki, demka, kopiery..
zrobiłem wave'y turgenem, połączyłem w jedno dłuższe nagranie audio, klaptopa podłączyłem do decka technicsa i dawaj nagrywamy soft, z wysterowaniem ok 0db, silnie ale bez przesteru.
no i super, kaseta nagrana. wkładam do magnetofona, atari-włącz, wczytywanie kso-t2000, play, ...a taśma leci leci się kręci -ani myśli zatrzymać się po nagłówku z pytaniem czy wczytać program.
? ooso chodzi?
wróć - do testów z adapterem kasetowym. kurde, no działa. elegancko czyta dane, zatrzymuje po nagłówku, wczytuje bez problemu. z taśmy - nic. ech..
czy ta taśma jakaś lipna? a czy jednak sygnał nie jest ciut za silny? ile ja się nanagrywałem, wte, nazad, przewiń, testuj, a może inny xex/wav, a cholera wie co. a może generować falę prostokątną, a może sinus, a może 48khz, a może 44,1.. czemu z g.nianego adaptera kasetowego za 5zł wczytuje jak złoto od pierwszego strzału, a nagrany na taśmie ten sam sygnał, ten sam wave, atari/magnetofon zlewa jakby go nie było?.... tzn 'bywał' - raz na kilka-10 prób coś-tam odczytał. ale ogólnie porażka..

i już nic innego nie pozostało mi do przetestowania, jak zaznaczyć opcję 'invert polarity pulses', którą baktraaa ma w zasadzie każdym pluginie turbo w turgenie. ok, wygenerowałem wave'a z odwróconym sygnałem, nagrałem na decku ot byle jako z wysterowaniem, w zasadzie od niechcenia - a tu masz! wczytuje elegancko, wszystko co na taśmie nagrałem, sukces.

tylko teraz: nie wiem czy to jest przypadłość wszystkich magnetofonów/decków, czy tylko mój technics tak robi, że (na to wygląda po tych testach) sam z siebie przy nagrywaniu dźwięku na taśmie odwraca polaryzację sygnału??
nie wiem. ale tu u mnie pomogło.
ale jak zaznaczam tylko przy nagrywaniu danych na taśmę. przy wgrywaniu danych z adaptera kasetowego sygnału nie odwracam i nigdy tego nie robiłem, a działa. a nagrywając na taśmę - musiałem żeby się wczytywało.

wracając do wątku i opisywanego sprzętu:
a może kopiowanie kaset na tzw. 'jamniku', co onegdaj się robiło, a potem narzekało że to nie chce się wczytywać (ja narzekałem; i przegrywanie gier robiłem potem tylko kopierami), może taka skopiowana taśma miała właśnie odwróconą polaryzację sygnału i przez to nie chciała działać?
może kiedyś ktoś wpadł na taki trop (jeśli w ogóle jest on słuszny) i zrobił 'odwracacz' sygnału dla kopiowanych na magnetofonie kaset? (na zasadzie 'jak się nie wczytuje, to spróbuj przestawić wajhę, bo to może pomóc)

;-] seeban jak masz magnetofon 2kasetowy to możesz taki test wykonać..
ale - to i tak przy założeniu że magnetofony tak mają i odwracają sygnał przy zapisie. ale nie wiem czy tak robią i czy robią tak wszystkie a może tylko niektóre?...

(sory, żem się rozpisał)

czyli rozumiem że 'z założenia' sygnał blizzard ma odwróconą o 180st fazę w porównaniu do ast/um/2000f, a ten pstryczek jest tu potrzebny żeby jednym multi-interfejsem dało się wczytywać różne systemy turbo. bo czeba na to spoglądać z perspektywy lat 90tych; wtedy turgena nie było;-P

Hejka!

Dziś będzie dość nietypowy post, dlaczego nietypowy... ponieważ tym razem trochę będę się rozpisywał, ale nie tak jak zwykle o systemie turbo, a o kasecie. O kasecie znalezionej w wannie! stop... stop... to nie ten wątek! ;)

Zaczęło się prozaicznie... podczas zgrywania kaset od Uicr0Bee, trafiłem na coś takiego:

Wyglądało na kolejny zestaw programów nagrany w Turbo Blizzard. Tym razem etykieta wskazywała że będzie to zestaw #37 od firmy Atares z Chorzowa. Chociaż kolejny rzut oka na zawartość pudełka spowodował, że nie byłem już taki pewny zawartości kasety:

Po wyjęciu kasety z resztek pudełka w którym została umieszczona, widzimy wkładkę na której możemy podziwiać odręcznie wykonany spis programów, wykonany charakterem pisma wskazującym że pisała to dość młoda osoba:

Mamy zatem do czynienia z totalnym miksem :) resztka pudełka zawierająca etykietę zestawu Atares Blizzard #37, wkładka od kasety Stilon Gorzów, z ręcznie wykonanym spisem, a kaseta nieznanej marki z nieznaną zawartością.

Jako że miałem inne kasety do zgrania, to tę sztukę odłożyłem na bok, aby później się nią zająć, a czas płynął i płynął, a ja zgrałem już wszystkie inne kasety z zawartością których nie było takiego problemu, bo zawartość zgadzała się z etykietami.

Gdy zbliżałem się do "końca zapasów" magnetofonowych, postanowiłem celem relaksu i odpoczęcia od serwisu zaawansowanych pamięci taśmowych wrócić do tych kaset które zostały do przejrzenia i ew. zgrania. Na części kaset zamiast programów trafiłem na jakąś muzykę nagraną w kiepskiej jakości, parę kaset z niezidentyfikowanymi nagraniami, no i 3 kasety którym postanowiłem poświęcić większą uwagę.

W oczy ponownie rzuciła mi się powyższa kaseta, a to oznaczało że przyszła na nią w końcu pora. Kasetę szybko wrzuciłem w decka aby posłuchać co tam jest nagrane... odpalam... słucham... no cisza.... totalna i kompletna cisza... bleeeeh! No ale jak to!?! a ja liczyłem na jakieś ciekawe znalezisko... i co znalazłem? zapis szumu cząstek materiału ferro-magnetycznego których domeny magnetyczne osiągnęły maksymalną entropię?!? no co za lipa!

Ale zraz, przecież jest jeszcze strona B, a w zasadzie to druga strona, bo kaseta nie miała opisanych stron. Zasugerowałem się tym że strona A musi być tą stroną na której umieszczono naklejkę z resztkami napisów "ATARI   ATARI".

Odpalam drugą stronę... czekam i nagle słyszę pisk, dość znajomy... a że łeb mam już nieźle zryty tą całą analizą systemów turbo i metodami różnego zapisu na taśmie, to od razu wiem że zapis bazujący na PWM, i że ślad dźwiękowy jest charakterystyczny na systemu Blizzard.

No to pomyślałem sobie że jednak zestaw Blizzard #37 od Atares (bo niestety zrycie beretu jeszcze nie jest na takim poziomie że mózg dekoduje mi automatycznie wybrany system turbo :P). Zatem zgrywamy... 30 minut z głowy, trzeba się zająć czymś innym.

Zapuściłem zgrywanie, podsłuch w głośnikach... domownicy grożą mi eksmisją... zupełnie nie rozumieją że owe piski które wystraszyły wszystkie zwierzęta z okolicy, a psy spacerujące za oknem nagle dały dyla, tylko właściciele wołali... "Pimpuś wracaj! Wracaj! Niech ja cię tylko dorwę... Pimpuś! Lojalnie ostrzegam! Do nogi!!!!"...

... no więc te piski mogą nieść super ważną informację z zamierzchłych dziejów i mogą przyczynić się do lepszego poznania historii informatyzacji naszego kraju ;]

Zlitowałem się nad okolicznymi zwierzątkami, domownikami i sąsiadami... i wyłączyłem "odsłuch". Pomyślałem że później podejrzę w jakim stanie jest kaseta, analizując plik który powstanie po zgraniu zawartości tejże.

Jakież było moje rozczarowanie gdy wczytałem plik zawierający zgrany materiał do edytora audio:

Mimo iż średni poziom wzmocnienia karty dźwiękowej ustawiłem tak aby poziom sygnału oscylował na poziomie 0dB, w wskaźnik poziomu wysterowania pokazywał poziom bliski 0dB, to okazało się że wskaźnik pokazuje uśrednioną wartość, a zapis na taśmie zdegradowany jest do tego stopnia że wysokie częstotliwości praktycznie giną w szumie.

W systemie Blizzard wyróżniamy trzy szerokości impulsów (a zarazem 3 częstotliwości sygnału):

• impuls trwający 0.50ms (2000Hz) ---> ton synchronizujący (tzw. pilot)

• impuls trwający 0.25ms (4000Hz) ---> oznacza logiczne "1" (1/2 czasu trwania imp. synchro)

• impuls trwający 0.16ms (6250Hz) ---> oznacza logiczne "0" (1/3 czasu trwania imp. synchro)

Jak widać na powyższym obrazku, częstotliwości kodujące logiczne "0", praktycznie nie przetrwały, ich amplituda spadła tak bardzo że nie ma szans na poprawny odczyt/dekodowanie sygnału z tak zapisanej kasety.

Próbowałem oczywiście wczytać to co się zgrało na realnym sprzęcie (czy to nagrywając zgrany plik na kasetę, czy też używając adaptera kasetowego). Efekt był zawsze taki sam... nawet rekord zawierający nazwę nie dawał się odczytać, a jak się udało, to następny rekord danych był przekłamany na tyle że system blizzard meldował błąd 143 (błędna suma kontrolna) lub błąd 140. Jednym słowem kompletna katastrofa.

Ale nie postanowiłem się nie poddawać tak łatwo. Ciekawość mnie zżerała, bo nie wiedziałem co za pliki umieszczono na kasecie, a nazwy które udało się odczytać, albo zdekodować brzmiały:

"1", "6", "7", "8", "9"

... tak więc ktoś postanowił nadać kolejnym plikom nie nazwy mówiące co za program jest nagrany, a kolejne numery. Plik nr 1 miał nazwę "1", plik numer 30 nazwę "30". Bardzo śmieszne, nieprawdaż? :)

Zacząłem się bawić w cyfrową obróbkę tegoż sygnału, jednak po wieczorze spędzony na filtrowaniu, podbijaniu, korekcji tego sygnału okazał się wieczorem kompletnie straconym. Patrząc na "wykres" dźwięku sam nie byłem pewien czy sygnał przedstawia kodowane "0" czy też "1". Po pewnym czasie patrzenia się w to zdałem sobie sprawę że mogę napisać własny software-owy dekoder tego sygnału, lub kod który podciągnie "kondycję" tegoż do poziomu który będzie bez problemu dekodowany przez Blizzarda. Zacząłem klepać kod, któremu musiałem koniecznie nadać jakąś nazwę kodową, no bo jak taki "rewolucyjny" projekt nie będzie miał nazwy kodowej? :) i tak powstał "wave shaper". Zacząłem kombinować z kodem i przetwarzaniem tego zdegradowanego sygnału w jakąś strawną postać, jednak nie dawało to sensownych rezultatów.

Zgrałem tą taśmę jeszcze kilka razy w różnych konfiguracjach filtrów, korekcji i ustawień przedwzmacniacza (nawet z przesterami). Zmieniłem nawet deck-a na inny sądząc że sobie lepiej poradzi. Wszystko na marne, wszystko powyżej 5KHz na taśmie wydawało się nie istnieć, więc "0" kodowane przez 6250Hz, miały poziom przysłowiowego "kreta na Żuławach".

Już prawie pogodziłem się porażką... gdy mnie oświeciło... pomyślałem sobie... durniu jeden! a może magnetofon na którym było na nagrywane miał inaczej ustawioną głowicę? może gdyby użyć magnetofonu XC12 i spróbować dostosować ustawienie głowicy do tego na czym to było nagrywana, będziemy można liczyć na coś więcej, chociaż odrobinę więcej pasma! to już by się dało ogarnąć, potrzebuję naprawdę niewiele...

Wytargałem mojego starego XC12, w którym od dawna nie ma już "klapki", ale w tym wypadku to zaleta bo będę miał łatwy dostęp do głowicy i jej śruby regulacyjnej. Po odpaleniu tego wszystkiego, podczas odsłuchu szybko okazało się że faktycznie regulacja głowicą odrobinę poprawia "kondycję" sygnału, ale nie jest to znacząca poprawa... może jednak te parę % poprawy wystarczy aby dało się odzyskać dane z tej taśmy?

^^^ "Kurka wodna! Nie jest źle! są szanse!". Pomyślałem sobie że co prawda jesteśmy na granicy, ale w porównaniu z tym co było wcześniej to i tak różnica jest diametralna!

Zacząłem znowu zabawę z obróbką tego sygnału po stronie PC, udawało się nawet wczytać jakieś jedno-blokowe programy... jednak te pliki zawierające więcej bloków nadal miały cholerne przekłamania (błędy CRC)... poprawiłem parę rekordów ręcznie, domyślając się co może być w tym miejscu... ale to robota na długie godziny dla jakiegoś szaleńca... jeszcze nie teraz pomyślałem sobie :) To przecież kompletne wariactwo.

Patrząc na te serie zer i jedynek które były kodowane za pomocą różnej szerokości impulsów zacząłem pomstować na twórców Blizzarda... czy oni sobie nie zdawali sprawy że jakiś człowiek po 30 latach będzie próbował odtworzyć ten zapis?!?! Przecież Turbo2000 trochę wolniejsze i od razu znikają problemy z tak wysokimi częstotliwościami, tam wszystko się czyta nawet po 30 latach, gdy zostało nagrane na kiepskiej jakości taśmie!!! Do cholery... co ich podkusiło aby próbować wyciągać te 6.25KHz z magnetofonów Atari, mało tego.. to wszystko było nagrywane na "parchatych" taśmach które z założenia nie potrafiły dobrze przenieść wyższych częstotliwości...

... patrząc jak "skorka w gnat" w te ciągi próbek na ekranie... doznałem małego oświecenia... do cholery jasnej! czemu ja się z tym bawię w domenie cyfrowej! Przecież od dawna wiadomo że gdzie cyfra nie może tam analoga pośle, wyciągnijmy zatem z tej taśmy co się da na poziomie analogowym! W domenie cyfrowej przy obróbce tego sygnału to błądzę trochę po omacku... każdy zastosowany filtr wprowadza mi zniekształcenia fazy zależne od częstotliwości impulsów, a to już powoduje kompletny rozjazd wszystkiego.

Zacząłem bawić się podkręcaniem mojego XC12 tak aby osiągnął szczyty swoich możliwości, zatem pogmerałem trochę przy wzmacniaczu wejściowym (pasmo, ciut większe wzmocnienie)... potem podłączyłem sobie do niego płytkę Blizzard i zacząłem się przyglądać całej ścieżce sygnału za pomocą oscyloskopu, widząc te przebiegi w poszczególnych punktach interfejsu Blizzard wiedziałem już że mam jednak szansę na odczyt tej taśmy, potrzebuję naprawdę niewiele większe wzmocnienie i dam radę to odczytać.

Konkretne "oświecenie" nastąpiło w chwili gdy spojrzałem na ekran oscyloskopu na którym na kanale "A" miałem widok sygnału pochodzący z kolektora Q6, a na kanale "B" sygnał z ogranicznika (8 pin LM324). Zdałem sobie sprawę że ten ogranicznik działa w identyczny sposób jak mój kawałek kodu z "wave shaper", to już musiało się udać, szybki mod w XC12: zrobiłem dwa dodatkowe wzmacniacze buforujące i zacząłem zgrywać sygnał bezpośrednio z bebechów XC12 (col.Q6 - kanał lewy, wyjście ogranicznika - kanał prawy), gdy obejrzałem nagranie wiedziałem że jestem już "w domu":

^^^ YES! YES! YES! Coś co nazwałem "delta shaping" w swoim kodzie i nie radziło sobie z niskiej jakości sygnałem w domenie cyfrowej idealnie zadziałało w domenie analogowej! Na powyższym obrazku widać też że faza sygnału na wyjściu ogranicznika jest odwrócona o 180° względem tego co pojawia się na kolektorze Q6, ale "dekodowanie" takiego sygnału to już "pikuś". Analog POWER! :)

Nagle okazało się że większość plików udaje się poprawnie odczytać! Były oczywiście problemy z niektórymi plikami, bo taśma dodatkowo była mocno zmiętolona w paru miejscach, gdzie nawet analogowa magia nie dawała rady, ale upór i wielokrotne próby odczytu powiodły się.

Przy okazji tych eksperymentów będziecie mogli "posłuchać" co słyszy interface turbo, zobaczycie "nausznie" (czytaj: usłyszycie :P) jaka jest rola ogranicznika sygnału zbudowanego na U1C. Nazwa ogranicznik jest mocno krzywdząca, ponieważ ogranicza on co prawda amplitudę sygnału na wyjściu do pewnego poziomu, ale sygnał wejściowy wcześniej pozostaje na początku dość silnie wzmocniony, a dopiero potem obcięty (znormalizowany) tak aby miał cały czas taką samą amplitudę.

Zatem przedstawiam wynik tych prac w postaci pliku audio (skompresowany do formatu OGG z Q=10, co zupełnie nie zaszkodziło danym): Blizzard Tape - Blast from The Past!

kanał lewy: sygnał obecny na kolektorze tranzystora Q6
kanał prawy: sygnał obecny na wyjściu "ogranicznika" zbudowanego z LM324 (U1C)

Po raz pierwszy chyba w historii tego forum można sobie posłuchać jak pracuje kawałek układu elektronicznego... i uzmysłowić sobie co właściwie słyszy interfejs turbo :)

UWAGA! Głośny szum występujący w chwilach ciszy na kanale prawym to efekt działania "ogranicznika", gdy nie ma na taśmie zapisanego żadnego sygnału, wyciąga on wszystko co się tam znajduje, cały "analogowy" szum oraz zakłócenia pochodzące od silnika magnetofonu. Na szczęście procedury odczytu systemu turbo nic sobie nie robią z tego szumu/zakłóceń ponieważ oczekują impulsów o konkretnych długościach (0.5ms, 0.25ms lub 0.16ms), wszystko inne zostaje ignorowane. Dodatkowo przed każdym rekordem danych mamy ton synchronizujący, który pozwala procedurom odczytu zorientować się że po jego zakończeniu będą leciały już bity danych.

Sygnał zgrano buforując go za pomocą wzmacniaczy buforujących zrealizowanych za pomocą wzmacniaczy operacyjnych TL072. Wykorzystując sygnał z kanału prawego można bez problemu odtworzyć/wczytać pliki nagrane na analizowanej tutaj kasecie.

Myślę że ten plik może być doskonałym plikiem testowym przy pomocy którego można testować własnoręcznie napisany dekoder plików dla systemu Blizzard. To bardzo dobry i pewny materiał do obróbki przez softwarowy dekoder strumienia danych dla systemu Turbo Blizzard.

Ale co z programami znajdującymi się na tej kasecie?!? Co tam się znajduje??? A to już w oddzielnym poście. Zabieram się za pisanie drugiego postu, a ten już publikuję, bo zrobił się zbyt długi i zagmatwany. Namieszałem tutaj tyle wątków i opowieści, że kwestię software który znalazłem na tej taśmie poświęcę oddzielny post, aby już nie mieszać tutaj :)

Pora przedstawić software który znalazł się na owej tajemniczej kasecie opisanej w poprzednim moim poście. Dlaczego chcę poświęcić oddzielnym post opisowi zawartości tej kasety? Ponieważ gdy zacząłem uruchamiać programy z tej kasety okazało się, że jej zawartość to prawdziwy wehikuł czasu, przynajmniej dla mnie... większość z tych programów to proste programy napisane w Atari BASIC, ale gdy uruchomiłem niektóre z nich, natychmiast znalazłem się z czasach emisji programu "Radiokomputer". Nastąpiła tak potężna retrospekcja że automatycznie odmłodniałem o 30lat ;)

Jak wspominałem już wcześniej, nazwy programów zapisanych na taśmie to po prostu kolejne cyfry, które oznaczają po prostu nr pliku nagranego na taśmie... taśma więc zdradzała swoje tajemnice sukcesywnie w miarę odczytu i dekodowania poszczególnych plików.

Zatem aby nie przeciągać sprawy zobaczmy co udało się odczytać z taśmy:

P01.BAS        - Wielomian
P06.BAS        - Działania na liczbach zespolonych
P07.BAS        - Color Cycling #1
P08.BAS        - Color Cycling #2
P09.BAS        - muzyka: Stevie Wonder 
P10.BAS        - BASIC Synth
P11.BAS        - Biorytm
P12.BAS        - BASIC ATARI 65XE (Opis instrukcji BASIC)
P13.BAS        - English Grammar 1.0 (by Olgierd Niemyjski)
P14.BAS        - Odmiana czasowników angielskich (W.Lapis)
P15.BAS        - Język Niemiecki
P16.BAS        - Egzamin z Fizyki dla klas 1 i 2 L.O. (Tomasz Nabdzyk)
P17.BAS        - Program do analizy i modyfikacji gen. znaków
P18.BAS        - Symbole Elektroniczne (Maciej Jachimczuk) [Radiokomputer]
P19.BAS        - Graph IT (c) 1980 Atari, 2D plotting program
P20.BAS        - Świat Test / [org: World Quiz, H.P. Lord, March 1984]
P21.BAS        - Pytania (gra liczbowa)
P22.BAS        - Pytania II (gra liczbowa)
P23.BAS        - dodawanie ułamków
P24.BAS        - wykres i tabelka funkcji
P25.BAS        - Punkty w przestrzeni (gra matematyczna)
P26.BAS        - Rysowanie w przestrzeni
P27.BAS        - procedura rysowania okręgu (symetria x8)
P28.LST        - procedura instalująca PL znaki (wczytywać przez ENTER)
P29.BAS        - Ortografia (wypożyczalnia ZET)
P30.BAS        - Sound Efekte by Peter Gerstner (c) 1985.06.03
P31.BAS        - "Arkanoid"
P32.BAS        - "Snake"
P33.BAS        - Wyścig Kotów, A.Reczuch, 1988
P34.BAS        - Hammurabi, 1987
P35.BAS        - Atari Football Manager, (c) 1985 Addictive Games Ltd.
                 (przekład na j. polski Atares sp. z o.o. 1988)

P36.BAS        - "Tron" (2 graczy)
P37.BAS        - "Wisielec" (by I.Foreman, converted by E.Darkowska)
P38.BAS        - Italic (zmienia fonty na pochyłe)
P39.BAS        - Sprite Starfield
P40.BAS        - Mini Organy (Computer Shop)

P41.BOT        - loader "!" w formacie "BOOT"
P41.CAS        - wersja CAS

P42.XEX        - Earth Views (c) 1984 by R.G. Wilson

P43.BOT        - Character Font by Steven Lee - edytor fontów (format BOOT)
P43.CAS        - wersja CAS

P44.XEX        - Fun With Art
P45.XEX        - Will Harvey's Music Contruction Set (Electronic Arts)

P46.BOT        - BASIC autostart bootloader (format BOOT)
P46.2          - jakiś program w BASIC (zabezpieczony przed listowaniem)
P46.3          - dane ładowane przez program
P46.4          - dane ładowane przez program
P46.5          - dane ładowane przez program

P47.BAS        - przykładowe przerwanie DLI (każda linia ekranu GR.0 w innym kolorze)
P48.XEX        - JBW's Quick UnASsember v.1.5
P49.BAS        - konwerter systemów liczbowych
P50.BAS        - generator napisów 3D w trybie GR.9

P51.BAS        - Nato Commander
P51.DAT        - Nato Commander data file (dane ładowane przez P51.BAS)

P52.BAS        - Number Blast (c) 1981 by Richard Wiitala
P53.BAS        - Number Catch by David L. Clark

P54.BAS        - Poznaj Swój Kraj, (C) 1987.07 Aleksander Czaja
                 (dla słuchaczy Radiokomputera)
                 [bazuje na World Quiz?]
              
P55.BAS        - Historia na wesoło, (c) Krzysztof Haberski, Ciechocinek 87.08.30
                 (dla słuchaczy Radiokomputera)

P56.BAS        - Biorytmy i Biopowinowactwo (by Dziadzio Irek?), 1989.03 IrK.Tychy

P57.XEX        - Nasza Ziemia / Instrukcja
                 by R.G. Wilson (c) 1984 Antic Publishing,
                 wersja polska: K. Leski, 1987

P58.XEX        - Nasza Ziemia - na podstawie "Earth Views"
                 by R.G. Wilson (c) 1984 Antic Publishing,
                 wersja polska: K. Leski, 1987

P59            - Eurobusiness (c) PioSoft
              
P59.XEX        - Turbo Basic XL
P59.1          - AUTORUN.BAS (uruchamiany przez Turbo Basic XL)
P59.2          - blok danych
P59.3          - blok danych
P59.4          - główny program (Turbo Basic XL)
P59.5          - blok danych
P59.6          - blok danych
P59.7          - blok danych
P59.8          - blok danych

Jak widać na taśmie znalazło się 59 programów, większość to programy napisane w Atari BASIC, jednak jest również kilka plików w formacie Atari-DOS (XEX). Po zgraniu tego okazało się że jest to ponad 500KB danych! Czyli ponad 0.5MB danych upchniętych na jednej stronie kasety! :) Cóż za osiągnięcie! :)

Większość tych programów pochodzi z lat '80. Część była emitowana na antenie radiowej podczas trwania audycji "Radiokomputer". Pamiętam jak nagrywałem część z tych programów, jednak nie przetrwały one w moich zasobach. Gdy po latach ponownie je zobaczyłem, moje zaskoczenie było ogromne.

Dla większości z was, mój zachwyt i rozwodzenie się nad tym wszystkim pewnie będzie dużym zaskoczeniem, ponieważ te programy nie są jakieś "super", często są to dość prymitywne twory, jednak wspomnienia jakie wywołały wynagrodziły mi cały ten wysiłek i poświęcony czas na ich odzyskanie.

Pewnie część (a może nawet większość) z tych programów pewnie już dawno leży sobie gdzieś w sieci, przyznaję jednak że nie sprawdzałem i nie szukałem tego nigdy w zasobach sieciowych. O części programów nie pamiętałem, wspomnienia wróciły dopiero wtedy gdy je ujrzałem po latach ponownie. Zatem gdybym ich nie zobaczył, za nic nie przypomniałbym sobie ich nazw, a nawet dokładniejszego wyglądu.

Postaram się streszczać, a zatem może kilka ciekawostek, które wyniknęły podczas uruchamiania programów z tej kasety.

1) Nato Commander by Sid Meier (tak! ten Sid Meier!) ---> nie miałem bladego pojęcia że jest napisany w BASIC. Dodatkowo na taśmie brakowało pliku z danymi które próbowała doczytać gra. Na szczęście na atarimiania.com znajdował się dump wersji kasetowej która zawierała brakujący plik. Pozwoliłem sobie dołączyć brakujący plik do archiwum. Gdyby ktoś chciał to archiwum nagrać ponownie na kasetę może to obecnie uczynić, gra zacznie działać :)

2) Plik P46, nie udało mi się go uruchomić, jest zabezpieczony przed listowaniem. Program po uruchomieniu próbuje coś doczytać, ale chyba nie pasują mu nazwy plików. Zawartość plików które zostały umieszczone za głównym programem sugeruje że są to jakieś dodatkowe ekrany/plansze które powinny zostać odczytane po uruchomieniu programu. Ponieważ programu nie da się wylistować, nie chciało mi się marnować więcej czasu na walkę z tym problemem.

3) Na kasecie nagrano parę plików w formacie BOOT, pewnie do Blizzard był jakiś loader ładujący te zbiory, i podstawiający pod urządzenie "C:" handler obsługujący Turbo Blizzard. Pozwoliłem sobie dodać do archiwum również wersję CAS tych programów (łatwiej je uruchomić pod emulatorem).

Aby nie przedłużać już więcej pozwalam sobie załączyć archiwum zawierające zbiór tych programów, zamienionych na pliki które bez problemu można uruchomić pod emulatorem (bez potrzeby nagrywania ich na taśmę):

Blizzard Tape - Blast from The Past! - archiwum zawierające wydzielone pliki.

Czy wszystkie te programy znajdują się już w zbiorach sieciowych? Nie wiem, nawet tego nie sprawdziłem. Jeżeli tak, to czy cała ta moja robota poszła na marne? Zdecydowanie nie! Doświadczenie zdobyte w walce z tą kasetą przydadzą się na przyszłość.

Ostatnia uwaga. Program "P59" to gra Eurobusiness, która składa się z wielu plików i te pliki muszą być nagrane na taśmę w takiej kolejności jakiej je ponumerowano. Można oczywiście grę uruchomić z dyskietki, ale to wymaga ingerencji w pliki P59.1 oraz P59.4 (są to pliki w formacie Turbo Basic XL), w ich ciele umieszczono procedury odczytu z urządzenia "T2:", należy je zmienić na odczyt z "D:". Zresztą w sieci pewnie leży oryginalna wersja dyskowa z której to wykonano tę wersję przystosowaną do Blizzarda :)

ps1) no tym razem to chyba popłynąłem totalnie, dwa posty dotyczące jednej zmaltretowanej kasety na której był mało interesujący i miejscami wręcz prymitywny software napisany w Atari BASIC. Uwierzcie mi jednak proszę, gdy uruchamiałem te programy, mając naście lat byłem tym wszystkim zachwycony (szczególnie te które udało mi się nagrać z Radiokomputera, a potem co nie zawsze się udawało; poprawnie wczytać :P)

ps2) muszę was zmartwić, niestety tego typu opisów będzie pewnie więcej w przyszłości, o ile jeszcze coś takiego w moim mniemaniu unikalnego wpadnie w moje łapki. W tej chwili mam jeszcze dwie kasety w zapasie, też niby ciekawe ale z innych powodów. Nie ma nich żadnego super-starego lub super-unikalnego softu, za to formaty w jakich te kasety są zapisane, są nietypowe, co pozwoli na kolejny mój nudny i przydługi wywód.

ps3) no skleroza! zapomniałem o tym napisać w pierwszym poście. Pewnie część z was zauważyła że na kasecie po P01 pojawia się dopiero P06... otóż pomiędzy P01 a P06 ktoś nagrał długi "pisk" niszcząc zawartość kasety na odcinku P02...P05. Dlaczego? tego nie wiem, ale słuchając tego "tonu" widać jak bardzo jest on zakłócony, w kilku miejscach występowania tego tonu, kaseta jest po prostu pognieciona. Zakładam zatem że została wciągnięta, zmiędlona i zawartość została uszkodzona, zatem ktoś postanowił to nadpisać owym piskiem aby oznaczyć uszkodzony fragment taśmy?

Dzień Dobry!

Dziś będzie mała zmiana, wrócimy na chwilę do tematu cartridge. A wszystko dzięki uprzejmości Dely-ego! Ale po kolei...

Wszystko zaczęło się od postu forumowicza fancyrats_rime, który zaprezentował zdjęcie cartridge "Turbo 2000 v3.0" od firmy SONIX. Pozwolę sobie to zdjęcie wrzucić poniżej, aby było wiadomo o czym mowa (autor zdjęcia: fancyrats_rime)

^^^ Ów cart wydał się dość interesujący. W moim mniemaniu był to dość rzadki egzemplarz. Po pierwsze nie miałem pojęcia że SONIX wydawał carty odsługujące system Turbo2000, a dokładniej rzecz ujmując jest to oprogramowanie dla systemu Turbo 2000F/Turbo 2001. Tutaj jednak producent carta nazwał ów system po prostu Turbo 2000.

Po prezentacji carta przez fancyrats_rime pojawiła się nadzieja że może uda się zdobyć zawartość tegoż cartridge, było nie było, był to dla mnie okaz unikalny. Wcześniej takiego carta na oczy nie widziałem (ale ja dość mało widziałem :P), więc uznałem to za ciekawy i rzadko występujący "okaz":

Okaz dla mnie tym bardziej interesujący ponieważ wszystko wskazywało na to, że stworzeniu tej paczki softu brał udział Magnus/W.F.M.H., a więc przedstawiciel wczesnej sceny małego Atari, który miał na koncie dość kultowe produkcje. Magnus swego czasu udzielał się na tym forum, a Dracon-owi udało się swego czasu przeprowadzić dość obszerny wywiad z Magnusem.

I właśnie terazm gdy po latach wypływa na świat taka produkcja Magnusa, nie mogłem się oprzeć chęci zajrzenia "do wnętrzności" tego carta, może nawet nie tyle do wnętrzności ale do kodu uruchamiającego ten cart. Zafrapowało mnie to jedno słowo, "Compacted". Po tym jak fancyrats_time opublikował informację o tym karcie, pojawiło się w wątku parę postów sugerujących aby wykonać jego dump, jednak temat jakoś umarł śmiercią naturalną, a ja pogodziłem się z faktem że ów historyczny jakby nie było cart, zaginie w odmętach przeszłości.

Jakież było moje zaskoczenie gdy odezwał się do mnie Dely, że wpadł w jego ręce podobny cart i oświadczył że może spróbować wykonać "dump". Nie kryłem swojej radości i aż podskoczyłem z wrażenia, po czym po wymianie paru e-mali, pewnego pięknego dnia Dely podesłał zawartość pamięci EPROM skrywającej się w cartridge! Za co należą się mu ogromne podziękowania!

Gdy otrzymałem plik, mogłem już "zatopić swe zęby" w kodzie aby sprawdzić co w przysłowiowej trawie piszczy i co oznacza owo tajemnicze słowo "Compacted" w rzeczywistości. Ale przed tym, należą wam się dwa słowa wyjaśnienia dotyczące budowy cartridge.

Jak się okazało (po zawartości EPROM) cartridge zawierał w sobie 8KB pamięć EPROM, w której "upchnięto" cały ten soft widoczny na zrzucie ekranu powyżej. Konstrukcja elektroniczna to najbardziej prymitywna i najtańsze możliwe rozwiązania, gdzie zamiast możliwości odłączenia programowego, czy też czasowego to użytkownik robi za "wajcho-tron", czyli wyłącza cartridge ręcznie. Schemat postępowania w przypadku takiego cartridge jest następujący:

• umieścić cartrige w porcie wyłączonego komputera, przełączyć wajchę na pozycję ON

• włączyć komputer i poczekać do czasu aż ujrzymy napis "TURN OFF CARTRIDGE"

• ponowne uruchomienie carta polega na przełączeniu przełącznika w pozycję ON i wciśnięciu RESET

Co prawda nie widziałem carta w środku bo nie było takiej potrzeby, ale musi się on składać z pamięci EPROM typu 2764 i przełącznika sterującego linią RD5, co implikuje że cart po uruchomieniu zajmuje przestrzeń adresową $A000-$BFFF. Zakładam iż konstrukcja tego carta jest bliźniacza (elektrycznie) z cartem Turbo 2001, dodawanym do systemu Turbo 2001 montowanym przez firmę TOMS, cart tego typu opisywałem już w tym poście.

Uznałem zatem, że nie warto grzebać w bebechach carta który posiada Dely, ponieważ nic odkrywczego zapewne tam nie ujrzę, a cart będzie mógł pozostać w stanie nienaruszonym.

Pfff... znowu przynudzam... nieprawdaż? Może pora zatem w końcu dobrać się do zawartości EPROM i zajrzeć do wnętrzności kodu. Uruchommy to zatem pod emulatorem i zobaczmy co robi cart gdy już wyświetli napis "TURN OFF CARTRIDGE":

(245:248,  0) A=01 X=41 Y=27 S=FD P=30 (      )  41DF: D0 FB             BNE $41DC
Altirra> u 41dc
    41DC: AD 13 D0          LDA TRIG3
    41DF: D0 FB             BNE $41DC
    41E1: 8D FA 03          STA GINTLK
    41E4: 8D C6 02          STA COLOR2
    41E7: 8D 0E D4          STA NMIEN

no tak, standard... czeka w pętli na zmianę stanu lini TRIG3 która jest podpięta pod również pod RD5 i dzięki temu możemy monitorować jej stan, przez co program może wiedzieć w jakim stanie jest cartridge (aktywny/nieaktywny). Tutaj po prostu kawałek kodu czeka w pętli do czasu aż użytkownik wyłączy cartridge za pomocą przełącznika.

No dobra, ale co się działo wcześniej, co cart robił zaraz po starcie? Od jakiego adresu zaczął wykonywać się kod? To możemy sprawdzić analizując nagłówek carta znajdujący się pod adresami $BFFA-$BFFF:

Altirra> db bffa L6
BFFA: 01 A0 00 04 63 A0 11 92 10 05 83 00 42 42 00 00 |....c.......BB..|

a zatem jak widać powyżej:

CART INIT = $A063
CART RUN = $A001

pod adresem $A063 jest po prostu instrukcja RTS. A więc INIT praktycznie nie istniej :) Zajrzyjmy zatem pod $A001:

Altirra> u a001
    A001: A9 08             LDA #$08
    A003: 2C 0F D2          BIT SKSTAT
    A006: F0 2B             BEQ $A033
    ...

Zaraz! zaraz... o co chodzi! widać tu dwie rzeczy, po pierwsze pierwsze co robi kod, to sprawdza stan klawisza SHIFT, testując 3-ci bit rejestru SKSTAT ($D20F). Gdy jest wciśnięty to jest uruchamiany inny kawałek kodu! A zatem... "Let's Test It!":

hahaha! :) No tak... Magnus postanowił dopisać kawałek kodu testujący zawartość pamięci EPROM. Pod adresem $A033 znajduje się prosta procedura licząca sumę kontrolną (modulo 256) obszaru $A001-$BFFF, a następnie porównuje ją z poprawną sumą zapisaną pod adresem $A000:

Altirra> u a033
    A033: A0 01             LDY #$01
    A035: A2 A0             LDX #$A0
    A037: 84 1C             STY $1C
    A039: 86 1D             STX $1D
    A03B: A9 00             LDA #$00
    A03D: AA                TAX
    A03E: 18                CLC
    A03F: 61 1C             ADC ($1C,X)
    A041: E6 1C             INC $1C
    A043: D0 F9             BNE $A03E
    A045: E6 1D             INC $1D
    A047: A4 1D             LDY $1D
    A049: C0 C0             CPY #$C0
    A04B: D0 F1             BNE $A03E
    A04D: A2 02             LDX #$02
    A04F: CD 00 A0          CMP $A000
    A052: F0 02             BEQ $A056

Gdy suma się zgadza zostaje wyświetlony napis "O.K", w przeciwnym wypadku "ERR", pod adresem $A02D zostały umieczone owe komunikaty (w kodach ekranowych ANTIC):

Altirra> dbi a02d
A02D: 2F 0E 2B 22 21 24 A0 01 A2 A0 84 1C 86 1D A9 00 |O.KBAD.!...<.=. |

btw. skąd ja to znam... jeżeli ktoś  jest posiadaczem gry Yoomp! na cartridge, proponuję włączyć komputer z włączonym klawiszem SHIFT, ot mała taka niespodzianka :) Tyle że ja pisząc tamten kod postanowiłem użyć nieco bardziej rozbudowanego mechanizmu liczenia sumy kontrolnej niźli zwykłe sumowanie "Modulo 256", ale ja miałem masę miejsca :) Więc mogłem zaszaleć, tutaj Magnus był ograniczony do 8KB i jak widać po kodzie, walczył o każdy bajt :)

Wróćmy jednak do tego co się dzieje gdy SHIFT nie jest wciśnięty, bo tutaj zaczyna się robić ciekawie.

    A008: A0 64             LDY #$64
    A00A: A2 A0             LDX #$A0
    A00C: 84 1C             STY $1C
    A00E: 86 1D             STX $1D
    A010: A0 01             LDY #$01
    A012: A2 08             LDX #$08
    A014: 84 1E             STY $1E
    A016: 86 1F             STX $1F
    A018: A0 00             LDY #$00
    A01A: A2 20             LDX #$20
    A01C: B1 1C             LDA ($1C),Y
    A01E: 91 1E             STA ($1E),Y
    A020: C8                INY
    A021: D0 F9             BNE $A01C
    A023: E6 1D             INC $1D
    A025: E6 1F             INC $1F
    A027: CA                DEX
    A028: D0 F2             BNE $A01C
    A02A: 4C 0B 08          JMP $080B

Co my tu mamy? Skracając wywód do maksa, to jest procedura przepisująca segment pamięci o długości 8KB. Przepisywania rozpoczyna się od adresu $A064 (źródło) a zawartość jest kopiowana pod adres $0801 (cel) ... a następnie jest wykonywany skod pod adres $80B.

To brzmi dość znajomo, nieprawdaż? A przynajmniej wygląda znajomo dla użytkowników C64. Dlaczego? Ponieważ $801 to typowy adres ładowania plików .PRG na platformie C64, popatrzmy zatem co kryje się pod $801:

Altirra> db 801
0801: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0811: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0821: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0831: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0841: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0851: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0861: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
0871: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|

aaa... już nic :) widać w chwili pojawienia się napisu już jest po sprawie i obszar został wyczyszczony :) Zatem zastawmy pułapkę (breakpoint), na adres $80B pod który wykonywany jest skok.

Altirra> ba r 80b
Breakpoint 0 set on read at 080B.

RESET maszynki i czekamy aż breakpoint zadziała, po czym sprawdzamy co mamy od $801:

Altirra> db 801
0801: 0B 08 4B 43 9E 57 46 4D 48 00 A0 00 78 A9 30 48 |..KC.WFMH...x.0H|
0811: 28 EA EA B9 5F 26 99 CB 00 C8 D0 F7 4C 00 01 03 |(..._&......L...|
0821: F8 5F 0F E0 7F 3D 80 FF F5 00 FE D7 03 F8 5F 0F |._...=........_.|
0831: E0 7F 3D 80 FF F5 00 FE D7 03 F8 5F 0F E0 7F 3D |..=........_...=|
0841: 80 FF F5 00 E0 39 F4 12 B1 7D 81 2D 6F CE F1 E5 |.....9...}.-o...|
0851: 8C BB 84 C7 3A 86 A1 87 8F 46 21 40 41 16 55 ED |....:....F!@A.U.|
0861: 4C 2E 00 2F 26 26 43 8D 2A 38 3D 32 29 24 27 94 |L../&&C.*8=2)$'.|
0871: 5C 11 11 FA DE 38 11 12 EC 09 26 0F 38 49 11 00 |\....8....&.8I..|

hmmm... no to już teraz można mieć pewność co do platformy użytej do kompresji zawartości tego carta, ale aby to lepiej pokazać, zmieńmy na chwilę platformę i wczytajmy dowolny program:

zajrzyjmy teraz pod adresy od $801:

(C:$e5d4) m 801
>C:0801  0b 08 90 06  9e 32 30 34  39 00 a0 00  78 e6 01 b9   .....2049...x...
>C:0811  65 18 99 fa  00 c8 d0 f7  4c 00 01 ca  f5 1b c9 25   e.......L......%
>C:0821  d0 eb d0 a8  20 18 00 c0  37 d0 e3 84  01 58 4c 03   .... ...7....XL.
>C:0831  08 25 ea f0  25 20 fa 25  43 52 55 4e  43 48 01 ff   .%..% .%CRUNCH..
>C:0841  ce 81 fb 25  2d 9a 53 45  52 cd 54 41  52 47 45 54   ...%-.SER.TARGET
>C:0851  20 44 49 53  4b 64 77 50  41 43 99 54  4f 20 ca 6c    DISKdwPAC.TO .l
>C:0861  45 20 41 47  41 a8 21 cb  11 53 41 56  49 4e 47 20   E AGA.!..SAVING 
>C:0871  f9 25 d9 00  10 f0 0b e2  9b e6 b2 ca  d0 f3 4c f3   .%............L.
>C:0881  09 8d 20 0c  84 b1 11 f8  f6 84 49 c8  b9 ff ff d1   .. .......I.....

Co my tu widzimy? Pod adresami $801,$802 mamy adres w pamięci określający gdzie znajduje się następna linia programu, w tym wypadku jest to lokalizacja $080b (little-endian)
A potem zaczyna się stokenizowany program w BASIC-u, czyli mamy:

$0b,$08 ---> to jest adres informujący BASIC pod którym adresem znajduje się następna linia programu.
$90,$06 -> $690 -> 1680 (dec) ---> wygląda na to że mamy tutaj po prostu numer linii
$9e ---> to jest token komendy SYS
$32,$30,$34,$39 ---> tutaj mamy zapisane w kodzie ASCII: "2049" czyli argument dla funkcji SYS, który  w tym wypadku jest adresem uruchomienia.
$00 ---> to po prostu znacznik końca linii

Mając tę wiedzę możemy już zinterpretować dane znajdujące się obecnie pod $801 w naszym wypadku:

Altirra> db 801
0801: 0B 08 4B 43 9E 57 46 4D 48 00 A0 00 78 A9 30 48 |..KC.WFMH...x.0H|

zatem:
$0b,$08 ---> adres następnej linii
$4b,$43 ---> nr linii 17227, lub ew. litery "KC" wpisane przez Magnusa? czyżby żarcik?
$9e ---> token komendy SYS
$57,$46,$4d,$48 ---> tutaj powinien być adres dla SYS, ale Magnus podmienił te bajty na napis "WFMH" ;-)
$00 ---> koniec linii

a wiec wychodzi na to że Magnus do kompresji danych w tym carcie użył jakiegoś crunchera z platformy C64. Przeglądając kod depackera można się tylko co do tego bardziej upewnić (np. inkrementacja komórki $400 podczas dekompresji, w przypadku C64 to początek pamięci ekranu więc podczas dekompresji zmiana znaku w prawym górnym rogu mówiła użytkownikowi że coś się dzieje i program pracuje /trwa dekompresja/).

Jeżeli ktoś jest zainteresowany kodem depackera, może sam go sobie przejrzeć. Prawdę mówiąc nie chce mi się szukać którego dokładnie programów na C64 użył Magnus bo jest ich cała masa, a teraz chyba nie jest to już istotne. Być może jest to Cruel Cruncher, lub taki cruncher który najefektywniej spakował dane tego carta.

Bardzo pobieżnie szacując (pi*oko) udało się skompresować około 12.5KB do 8KB włączając w to procedury dekompresji. Dzięki temu w 8KB carcie udało się "upchnąć" trochę więcej softu, całkiem estetyczny ekran startowy a nawet mały scroll z reklamą :)

Co zostało do zrobienia? Chyba tylko udostępnienie linku zawierającego zawartość pamięci EPROM:

Turbo 2000 v.3.0 (SONIX)

hash pliku z zawartością carta:

SHA256: B3CD2B7CC6FCCAA587B924B529D88831EAC69F4E277DC513DD3AE63829CA624D

Na koniec WIELKIE podziękowania dla DELY-ego za to że znalazł czas na zrobienie dump-a i podesłanie mi zawartości. Dzięki temu mogłem was zanudzić kolejną porcją moich dywagacji ;] ... a tak na serio to cieszę się że udało się zarchiwizować kolejną perełkę. Jak dla mnie to dość unikalny cart i cieszę się że mogłem dostać w łapki jego zawartość i poddać je analizie.

Być może gdy nadejdą kolejne długie zimowe wieczory, albo znajdę spory zapas wolnego czasu pogrzebię  znowu w cruncher-ach z C64 i być może uda się znaleźć ten którym Magnus spakował dane zawarte w tym carcie.

A i jeszcze jedno, gdyby kogoś to interesowało pewnie można w prosty sposób przerobić ten kod tak aby nie była potrzeba wajcha tylko cart sam się odłączał i działał jako cart typu "Phoenix 8k". Dajcie znać czy przygotować taką wersję binarki. Wykonanie wersji XEX też nie jest problem, o ile ktoś wyrazi zainteresowanie, wtedy opiszę procedurę takiej "zmiany" formatu w oddzielnym poście. Może się komuś przyda na przyszłość.

Hej!

Zgodnie z prośbą w tym poście postaram się wyjaśnić moją metodę postępowania pozwalającą dokonać konwersji pliku bin/rom do postaci XEX, niestety będzie trochę przynudzania, bo nie da się tego od tak napisać bez podstawowej wiedzy o systemie operacyjnym Atari i strukturze danych nagłówkowych zawartych w cartridge. Postanowiłem że zrobię z tego taki mini poradnik, więc nudnawe wywody będą nieuniknione. Ten "mini poradnik" będzie tyczył się typowych cartów o pojemności 8K, jednakże bardzo łatwo go przystosować do standardowych cartów 16K (wystarczy tylko pozmieniać trochę zakresy adresów i wartości niektórych stałych).

Co mam na myśli pisząc typowy cart 8K? Otóż chodzi o cartridge który standardowo po podłączeniu do komputera lokuje się w przestrzeni adresowej $A000-$BFFF. Cartridge który będziemy poddawali konwersji nie może być typem cartridge, który dokonuje przełączania banków lub jest w jakiś sposób zabezpieczony przez łatwą konwersją,  np. próbując zamazać obszar w którym się znajduje, co w przypadku cartridge mu się nie uda, ale w przypadku uruchomienia carta z pamięci RAM, tak jak w tym wypadku, będzie mógł to zrobić i taka konwersja bez zmian w kodzie carta się nie powiedzie. Na szczęście większość cartów dla systemów turbo nie jest w żaden sposób zabezpieczona (wyjątkiem są niektóre carty dla Blizzarda, ale to przypadki sporadyczne). Zatem do dzieła! :)

Co nam będzie potrzebne?

• ulubiony cross-assembler, w moim przypadku to xasm, ale może to być MADS czy cokolwiek innego.

• plik zawierający zawartość pamięci EPROM cartridge, którego konwersji chcemy dokonać.

• informacje dotyczące mapy pamięci cartridge, a konkretniej informacje dotycząca "nagłówka cartridge" w którym są zwarte adresy inicjalizacji i uruchomienia

• dowolny/ulubiony edytor tekstowy oraz odrobina chęci i cierpliwości.

Co musimy wiedzieć o strukturze danych zawartych w obrazie carta?

Po pierwsze to jaką przestrzeń okupuje cartridge w pamięci komputera. W przypadku standardowego 8KB cartridge jest to obszar $A000-$BFFF. W przypadku gdy kod systemu operacyjnego stwierdzi obecność cartridge automatycznie dostosuje rozmiar wolnej pamięci, a MMU w obszar $A000-$BFFF zmapuje pamięć umieszczoną carcie. Należy dodać, iż system operacyjny Atari jest jednym z niewielu systemów operacyjnych dla komputerów 8-bit, który potrafi się rozeznać ile ma pamięci do dyspozycji i jakie urządzenia podłączono mu do portów, po czym automatycznie dostosowuje wszystkie ważne elementy konfiguracji systemu.

Po drugie musimy wiedzieć, jak system operacyjny dokonuje inicjalizacji i uruchomienia kodu zawartego w cartridge. Tutaj opiszę to w sposób uproszczony, ale wystarczający aby zrozumieć o co chodzi.

Pierwszym etapem uruchamiania kodu zawartego w cartridge jest wywołanie przez system operacyjny kodu którego adres umieszczony jest w lokalizacjach $BFFE,$BFFF. To tzw. "Cartridge Init address". System operacyjny wykonuje skok pod adres wskazany w tych komórkach zaraz na początku procedury RESET, gdy ten kod zawarty w cartridge zakończy swoją robotę następuje powrót do wykonywania RESET przez system operacyjny. Należy dodać iż system sprawdza parę znaczników pod adresem $BFFD i w zależności od ich ustawienia podejmuje odpowiednia akcje. Po szczegóły odsyłam albo do linku który podałem do atariki, albo np. do książki W.Zientary pt. "Podstawowe procedury systemu operacyjnego", a konkretnie do rozdziału: 2.3.1. Procedury rozpoznania cartridge'a i RAM. Gdy już system wymota się ze swoją procedurą startu i stwierdzi że należy uruchomić cartridge to dokonuje skoku pod adres na który wskazują komórki $BFFA,$BFFB.

Dysponując tą okrojoną nieco wiedzą, w zasadzie moglibyśmy już dokonać konwersji obrazu karta na postać file/xex, pewnie w części przypadków to by zadziałało, wystarczyłoby zawartość pliku zawierającego "dump" umieścić w obszarze $A000-$BFFF, wykonać skok pod adres CART_INIT, a następnie skok pod adres CART_RUN. Oba adresy są zawarte w pliku zawierającym "dump".

Tak jak napisałem, w części wypadków zadziałało by to bez problemu, ale po pierwsze podczas wczytywania pliku zniszczylibyśmy display-list i zawartość pamięci ekranu, co skutkowałoby losowo-chaotycznymi śmieciami na ekranie, ale to by się dało nawet jakoś zignorować, ponieważ część cartów i tak od nowa inicjuje ekran, ale niektóre z nich liczą że to system operacyjny odwalił już całą potrzebną robotę.

Drugim problemem jest to, że przy takiej uproszczonej ścieżce postępowania, system operacyjny nadal uważałby że w obszarze $A000-$BFFF jest pamięć RAM i taką informację przekazał by on innym programom, który by go o to "zapytały". A po drugie próbując otworzyć edytor ekranowy system zniszczyłby bezpowrotnie obszar $BC20-$BFFF, w którym znajdowałby się dane pochodzące ze "zrzutu" cartridge.

Tak jak wspominałem już wcześniej system operacyjny Atari jest na tyle "sprytny" że potrafi dynamicznie dostosować swoje zasoby w zależności od tego czy w porcie obecny jest cartridge, czy też może Atari BASIC jest włączony (on też jest rodzajem cartridge, tylko takim wbudowanym do środka komputera i też potrafi zająć obszar $A000-$BFFF). Dla czystej przyzwoitości powinniśmy zatem chociaż sprawić złudzenie że cartridge jest obecny, albo że chociaż był obecny podczas startu komputera :)

Możemy tego dokonać w sposób chociażby minimalistyczny  i w 99% przypadków będzie to działanie wystarczające. Upraszczając mocno ten temat należy powiedzieć że w Atari-OS są dwie kluczowe lokalizacje określające konfigurację i rozmiar pamięci, jest to komórka RAMTOP (adres $6A) oraz RAMSIZ (adres $2E4). Wystarczy zatem odpowiednio ustawić te komórki, zamknąć i otworzyć edytor ekranowy, tak aby system operacyjny mógł ponownie zarezerwować pamięć na bufor ekranu i display list pod nowym adresem, tzn. poniżej lokalizacji $A000, bo jak pamiętamy w obszar $A000-$BFFF będziemy ładować zawartość carta.

Ale kiedy i jak te wszystkie operacje należy wykonać? Można tutaj zastosować dwa podejścia:

• Załadować wszystko gdzieś niżej do pamięci, wykonać wszystkie te operacje, tzn. dostosowanie RAMTOP, RAMSIZ, zamknięcie i otwarcie edytora. Potem przepisać załadowane dane w obszar $A000-$BFFF i wywołać procedury INIT i RUN cartridge.

• Skorzystać z dobrodziejstw formatu binarnego pliku Atari DOS i wykonywać te wszystkie operacje podczas wczytywanie się pliku do pamięci.

Zdecydowanie jestem zwolennikiem rozwiązania nr 2. Podczas ładowania kolejnych segmentów pliku możemy uruchomić zładowany fragment kodu, wykonać potrzebne operacje (zmiany RAMTOP, RAMSIZE, ponowna inicjacja edytora ekranowego), a następnie załadować pozostałą część danych i po załadowaniu wszystkich danych uruchomić nasz kod, który to zasymuluje (w bardzo prymitywny i uproszczony sposób) procedurę startu cartridge wykonywaną przez system operacyjny.

Jeżeli kod w cartridge będzie domagał się wyłączenia cartridge lub czekał na jego automatyczne odłączenie, lub też próbował odłączyć cart zapisując cokolwiek do obszaru $D5xx, to w tym wypadku wszystko będzie dla niego już "wyłączone", ponieważ fizycznie cart nie jest włożony do portu i rejestr TRIG3, który testuje kod zawarty w carcie wskazuje na to że cart jest już odłączony. Dlatego też w tym wypadku nawet nie zauważymy napisu "TURN OFF CARTRIDGE", który wyświetlał się w przypadku fizycznego cartridge umieszczonego w porcie.

Ufff! Miało być szybko i zwięźle, ale się znowu nie udało ;) Ten wywód to naprawdę minimum, które trzeba wiedzieć aby zrozumieć co będzie działo się kodzie poniżej.

Może zatem wkleję kod który z pliku BIN/ROM generuje plik .XEX, a potem pokrótce opowiem co robią poszczególne kawałki kodu, zatem całość wygląda tak:

        opt    h+

RAMTOP  equ    $6a
RAMSIZ  equ    $2e4
PORTB   equ    $d301
BASICF  equ    $3f8

        org    $9b00       ; page under screen memory will be safe place!

init    lda    #$a0        ; set the RAM-TOP and the RAM-SIZE to $A000 (only hi-byte)
        sta    RAMTOP
        sta    RAMSIZ

        lda    #$ff        ; disable BASIC (if turned on)
        sta    PORTB
    
        lda    #$01        ; set BASIC flag to OFF! (BASIC will be disabled after reset)
        sta    BASICF

        ldx    #$02        ; close "E:" vector
        jsr    editor
        ldx    #$00        ; open  "E:" vector

editor  lda    $e401,x     ; use "E:" HTAB to call CIO functions
        pha
        lda    $e400,x
        pha
        rts

main    jsr    cini        ; call cartridge INIT code
        jmp    ($bffa)     ; jump at cartridge RUN vector
cini    jmp    ($bffe)

        ini    init

        org    $a000
        ins    "turbo_2000_v30_(sonix).bin"

        org    $bf36        ; patch decruncher code
        inc    $9c42

        org    $a000        ; patch CRC value
        dta    $ea

        run    main

^^^ powyższy kod kompilujemy wywołując xasm z następującymi parametrami:

xasm cart8k2xex.xsm  -o turbo_2000_v30_(sonix).xex

w katalogu musi być obecny plik "turbo_2000_v30_(sonix).bin", a "cart8k2xex.xsm", to plik zawierający powyższy kod źródłowy. Wynikiem kompilacji programu będzie: turbo_2000_v30_(sonix).xex

...i teraz już dość szybki opis co się właściwie dzieje w kodzie:

na początek mamy włączenie generowania nagłówków dla plików formacie Atari-DOS (XEX):

        opt    h+

deklaracje stałych:

RAMTOP  equ    $6a
RAMSIZ  equ    $2e4
PORTB   equ    $d301
BASICF  equ    $3f8

pod adresem $9B00 umieścimy nasz kod (poniżej pamięci ekranu i DL, po otwarciu edytora ekranowego z RAMTOP ustawionym na $A000:

        org    $9b00       ; page under screen memory will be safe place!

tutaj ustawiamy RAMTOP i RAMSIZ, na wartość #$A0

init    lda    #$a0        ; set the RAM-TOP and the RAM-SIZE to $A000 (only hi-byte)
        sta    RAMTOP
        sta    RAMSIZ

wyłączamy BASIC (gdyby był włączony)

        lda    #$ff        ; disable BASIC (if turned on)
        sta    PORTB

ustawiamy flagę BASIC-a na wyłączony (gdyby BASIC nie był odłączony podczas startu systemu)

        lda    #$01        ; set BASIC flag to OFF! (BASIC will be disabled after reset)
        sta    BASICF

zamykamy i ponownie otwieramy edytor ekranowy:

        ldx    #$02        ; close "E:" vector
        jsr    editor
        ldx    #$00        ; open  "E:" vector

editor  lda    $e401,x     ; use "E:" HTAB to call CIO functions
        pha
        lda    $e400,x
        pha
        rts

^^^ tutaj zawsze robiłem szereg odwołań do systemowego CIO aby zrobić to jak należny, tzn. poprzez wywołanie; CLOSE #0, a następnie OPEN #0,12,0,"E:". A podpatrzyłem tę metodę u JAC-a, o dokładnie tutaj: Atari 8-bit Programming Tips and Recommendations . Urzekła mnie jej prostota. W dodatku jest w pełni zgodna z różnymi wersjami Atari-OS.

tutaj kod który wywoła po załadowaniu wszystkich danych, czyli skok do Cartridge Init a potem skok pod adres Cartridge RUN.

main    jsr    cini        ; call cartridge INIT code
        jmp    ($bffa)     ; jump at cartridge RUN vector
cini    jmp    ($bffe)

A tutaj następuje segment INIT, czyli uruchomienie kodu od etykiety "init":

        ini    init

Tutaj ładujemy dane  (plik zawierający zawartość dump-a, czyli: "turbo_2000_v30_(sonix).bin") pod adres $A000:

        org    $a000
        ins    "turbo_2000_v30_(sonix).bin"

A tutaj mała poprawka w kodze depackera, we wcześniejszym poście wspominałem że depacker dla C64 robił zwiększenie wartości komórki $400, podczas dekompresji, co skutkowało pojawieniem się zmieniającego się znaku na ekranie przy dekompresji, zatem zmieńmy to tak aby coś działo się i na naszym ekranie (bo dekompresja trochę trwa):

        org    $bf36        ; patch decruncher code
        inc    $9c42

No ale wspominałem również że Magnus dodał test CRC zawartości EPROM, zatem dowolna zmiana w obszarze $A000-$BFFF spowoduje też zmianę CRC i aby test działał poprawnie, powinniśmy po zmianach (INC $400 na INC $9C42) dokonać korekcji bajtu zawierającego CRC, zatem ustalamy adres segmentu na $A000 i ładujemy tam jeden baja zawierający nową poprawioną sumę kontrolną:

        org    $a000        ; patch CRC value
        dta    $ea

A teraz pozostało nam tylko dodać segment wskazujący adres uruchomienia naszego pliku, zatem ustawiamy wektor RUNAD znajdujący się pod adresem $2E0 na adres procedury MAIN:

        run    main

and... That's All Folks! :D

możemy jeszcze podejrzeć, że plik wygenerowany przez xasm ma następującą strukturę, za pomocą narzędzia chkxex od MadTeam, lub jeżeli mamy Pythona (ver.3.x) pod ręką, chkxex.py z pakietu TCX Tools:

Input file is turbo_2000_v30_(sonix).xex and the file size is 8268 bytes.

Header is: $ffff
block 001: $9b00-$9b29 ($002a)
block 002: $02e2-$02e3 ($0002) ---> INIT $9b00
block 003: $a000-$bfff ($2000)
block 004: $bf36-$bf38 ($0003)
block 005: $a000-$a000 ($0001)
block 006: $02e0-$02e1 ($0002) --->  RUN $9b21

File turbo_2000_v30_(sonix).xex is OK!

^^^ czyli wszystko zgodnie z przewidywaniami :)

Gdyby coś było niezrozumiałe, pytajcie śmiało postaram się rozwiać wątpliwości, ew. wytłumaczyć coś bardziej szczegółowo gdyby było niejasne. A dla zainteresowanych do tego posta dodaję plik  cart8k2xex.xsm zawierający kod źródłowy omawianego przypadku.

A może po prostu zhakowany?

Czy oryginalna wersja tego Anty..  jest gdzieś udostępniona?

Czekamy z niecierpliwością na cd.