sun napisał/a:

Materiał na książkę detektywistyczną co najmniej. :)

Muszę przyznać ze sam się też nieźle przy tym bawiłem :) Największym zaskoczeniem przy tej kasecie było to że Turbo6000 dla Atari okazało się w 100% zgodne z TurboTape dla C64 :) co do bitu wszystko się zgadza jeżeli chodzi o format i struktury danych. Nawet kolejność przechowywania bitów na taśmie jest identyczna. Wierzyć mi się w to nie chciało i długo nie mogłem przyjąć do wiadomości że to taśma dla C64 ;-)

miker napisał/a:

Mam tylko takie pytanie. Czy na którejś z tych (lub innych) nie pałęta się gierka pod tytułem "Mam Plan"?

Wydaje mi się że na nic takiego nie trafiłem, ale będę miał w pamięci aby zwracać szczególną uwagę na ten tytuł.

uicr0Bee napisał/a:

Jak tylko dasz sygnał, poleci druga transza i za jakiś czas po tym doczekamy się nowego sezonu serialu :-) Oby jeszcze te epromy i taśmy poczekały z umieraniem.

Postaram się jak najszybciej ogarnąć z bieżącymi sprawami i dam znać. Zaczynam powoli pakować tę pakę dla Ciebie aby odesłać "materiał" po przeglądzie i analizie ;) Muszę tylko wygrzebać jeszcze sprężynę do klapki w ostatnio opisywanym magnecie z Blizzardem na UL1121 i będę mógł wysłać paczkę.

@fancyrats_rime dzięki za namiary na TapClean!  Kawał porządnego softu! Naprawdę "robi robotę", to co musiałem robić ręcznie załatwił od reki, wygenerował .PRG, posprzątał, odzyskał to co się dało:

  • "FIRE GALAXY"

  • "PITSTOP"

  • "PITSTOP II"

  • "EQUINOX"

  • "DEVIANTS"

  • "DAN DARE II"

  • "PUC MAN"

  • "VIXEN"

  • "TRAP DOOR"

  • "ONE MAN AND HIS DRIOD"

  • "MAGNUM FORCE"

  • "COMIC BAKERY"

  • "AIRWOLF"

  • "HARRIER ATTACK"

  • "CAESAR THE CAT"

  • "CHUCKIE EGG"

  • "FIGHTER PILOT"

  • "R.O.F."

  • "TOUR DE FRANCE"

  • "OUT RUN 2+'87"

Lista zawiera wszystkie pliki których nagłówki udało się odczytać, przekreślone pozycje są nieczytelne. TapClean świetnie pokazuje również dlaczego coś jest nieczytelne, przykład "zmiętolenia" taśmy w miejscu gdzie nagrano "Pitstop II":

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/TapClean_Pitstop_II.png

To naprawdę kawałek porządnego narzędzia! Ileż to czasu pozwala zaoszczędzić przy archiwizacji taśm! :) Przydałoby się podobne narzędzie dla Atari... ale tutaj pozostaje chyba tylko liczyć na pomoc braci szwedów, czyli "napisz.se" ;-)


Swoją drogą ta kaseta musi być mocno wiekowa patrząc po tytułach i datach ich wydania :) Jestem zdziwiony że aż tyle udało się odczytać z tej taśmy :)

Dzięki za informacje. Ja zupełnie z platformą C64 jestem nieobeznany jeżeli chodzi o systemy turbo i ogólnie współpracę z magnetofonem. W przeciwieństwie do Atari, to C64 udało mi sie zdobyć kiedyś za niewielkie pieniądze wraz ze stacją dysków i Action Replay-em, także nie miałem okazji nawet "powalczyć" z magnetofonem.

Co do softu to też chętnie się mu przyjrzę! może jeszcze się trafi jakaś zagubiona kaseta przeznaczona dla platformy C64 ;)

Dziś będzie o tym jak pewna przypadkowa kaseta zmieniła moje postrzeganie pochodzenia systemów turbo...

Zaczęło się bardzo niewinnie, od jednej z kaset która trafiła do mnie wraz z kolekcją magnetofonów uicr0Bee... ale to co potem się działo samego mnie wprawiło w osłupienie. Nie bardzo chciało mi się wierzyć w to co następowało gdy przekopywałem odmęty internetu aby się upewnić czy nie wyciągam zbyt pochopnych wniosków, ale im dłużej grzebałem tym głębsza robiła się ta "królicza nora" :D

Kaseta w pudełku nie prezentowała się jakoś specjalnie wyjątkowo:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/photos/unk_tape_case.jpg
^^^ na początku miałem wątpliwości w jakim systemie jest nagrana kaseta, bo zmyliły mnie literki "M" i "K" przy każdej pozycji, jednak przy RUN"T2 już wiedziałem o co chodzi... wychodziło na to że pliki zapisane w standardzie "Blizzard", a literki "M" i "K" oznaczają jakiego loadera należy użyć aby wczytać dany program:

  • M: Mikroloader

  • K: KOS

  • RUN "T2: załadowanie programu z poziomu Atari BASIC instrukcją RUN.

W owych domysłach pomogła wcześniejsza zabawa z różnymi cartridge-ami dla systemu Blizzard, np. cart Hurka Phoenix, wyglądał po uruchomieniu tak:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/scr/hurek_phoenix_menu.png http://seban.pigwa.net/uicr0bee/tapes/unk_tape/scr/hurek_phoenix_tos.png

W carcie od Hurka zamiast K.O.S. był autorski TOS, natomiast w cartach od Atares, której to jest przypisywane stworzenie systemu "Blizzard", można było spotkać zarówno Mikroloader jak i KOS:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/scr/atares_mikroloader.png http://seban.pigwa.net/uicr0bee/tapes/unk_tape/scr/atares_turbo_kos.png

sama kaseta nie wyróżniała się w jakiś specjalny sposób, ot niby zwykłe SONY EF60:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/photos/unk_tape_cass.jpg

Uznałem zatem że sprawa jest jasna i oczywista i kaseta powędrowała do pudełka "do zgrania", a ja zająłem się innymi rzeczami. Po pewnym czasie zabrałem się za zgrywanie kaset i wkładając ową kasetę do decka i słuchając tego co się tam znalazło zorientowałem się że na pewno nie jest to Blizzard.

Słuchając zapisu na taśmie (tym razem w słuchawkach, aby nie straszyć domowników i okolicznych zwierząt ;P) nie potrafiłem zorientować się cóż to za dziwny format zapisu danych obecny jest na taśmie. W pierwszym nagranym pliku nie potrafiłem nawet wyróżnić bloku zawierającego nazwę. Można było co prawda wyróżnić dwa powtarzające się fragmenty o bliźniaczym brzmieniu, ale żadnej przerwy pomiędzy tym fragmentem a dalszą częścią nagrania nie było... wydawało mi się że po prostu brakuje początku nagrania.

Zignorowałem więc pierwsze nagranie na kasecie i przysłuchałem się drugiemu z nich... wyraźnie można było wyróżnić ton pilotujący blok nazwy, ponownie ton pilotujący i następnie blok danych, co mniej więcej brzmiało tak: Track #2 - pilot tone + name segment + pilot tone + data (forma OGG).

A to co słychać na powyższym fragmencie brzmiało już dla mnie znajomo! Ja już gdzieś to słyszałem, chwila zabawy w edytorze audio aby zobaczyć jak wygląda ton pilotujący i zobaczyłem coś takiego:
http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/trk02_pilot_tone.png
^^^ gdy tylko zobaczyłem ten przebieg w którym doskonale widać kolne bajty tworzące sygnał pilota (1 dłuższy impuls oraz 7 krótszych to 8 bitów, które tworzą jeden bajt danych), byłem już na 100% pewien, że nie dość że to słyszałem to dodatkowo na pewno to już widziałem... tylko gdzie to było... długo myśleć nie musiałem, bo brzmienie i wygląda jest mocno nietypowe, tzn. wyróżnia się mocno spośród wszystkich innych systemów Turbo dla Atari 8-bit, które miałem okazję słyszeć i widzieć.

Nie tak dawno opisywałem w tym wątku system Turbo Star (plus), trochę wcześniej cartridge do tego systemu, a jeszcze wcześniej, na początku tego wątku w pierwszym poście podałem link do kaset które udało się zgrać. Kasety były w kiepskim stanie dlatego zgrałem je tak szybko jak tylko dostałem je w swoje ręce i patrząc na datę tego pierwszego posta doznałem lekkiego szoku ... 2014.07.20 ... no to dałem czadu ... tyle czasu już minęło?!? Wierzyć się nie chce... co prawda życie trochę mnie potargało w międzyczasie, ale i tak jestem mocno zszokowany O_o, ale kiedy? jak? kiedy to minęło? może jednak wpadłem w pętlę czasu! ;-)

... wróćmy jednak do głównego wątku... no więc Turbo Star (plus) przecież zgrywałem taśmy które miał uicr0Bee nagrane w tym systemie, leżą tutaj: Turbo Star Tapes. Jako że kasety były w dość kiepskim stanie to i nagrania są miernej jakości... no ale coś da się z nich odczytać, można natomiast porównać brzmienie :) Chociażby słuchając tej taśmy: Turbo Star Plus - zestaw programów (format FLAC).

Ucieszyłem się niezmiernie że sprawa jest wyjaśniona i w pudełku po prostu jest kaseta z programami dla Turbo Star Plus, lub też Turbo 6000, ponieważ Turbo Star (plus) to klon niemieckiego Turbo 6000, o którym więcej napisano na AtariWiki V3: Atari Datasette XC12 Turbo 6000 Baud Interface.

Aby przyspieszyć swoje działania, postanowiłem użyć po prostu emulatora Altirra, który to ma wsparcie dla obsługi systemów turbo, szybko się okazało że emulacja turbo używającego linii PROCEED, po prostu w Altirra nie działa poprawnie. Postanowiłem zatem skorzystać z pracy FUJI-ego i użyć emulatora Atari800 do którego FUJI dodał poprawki umożliwiające poprawną emulację systemów Turbo: Modified atari800 emulator.

Pod emulatorem uruchomiłem sobie cart od Turbo Star Plus na którym znajdował się loader, który po uruchomieniu prezentował się tak jak na zrzutach ekranu poniżej i przy próbie załadowania pliku zgranego z kasety pokazał coś takiego:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/tsp_loader.png http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/tsp_load_ex1.png

loader zatrzymał się po wyświetleniu nazwy i pokazał adres ładowania napotkanego programu... nazwa "spaprana" jakaś, chyba jakieś przekłamanie transmisji... ale adres jakiś dziwny... hehehe... zupełnie jak na C64! ależ dziwny przypadek... no ale co z tą nazwą? Prawdę mówiąc, to mi wygląda jak kod ATASCII pokazany jako kody ANTIC-a. Czyżby jakaś inna wersja systemu Turbo która kodowała nazwy nie w kodach ekranowych ale w kodach ATASCII?

Pomyślałem że zajrzę w kod loadera, w miejsce gdzie trzyma on odczytaną nazwę:

096C: 50 49 54 53 54 4F 50 20 20 20 20 20 20 20 20 20  PITSTOP

hahaha! a jednak dobrze mi się wydawało! Czyli mamy gierkę "PITSTOP", tylko jakoś nie pamiętam aby ona się ładowała tak nisko. Dziwne kodowanie, adres ładowania $801... dziwne dość to wszystko, nieprawdaż? Przecież ten loader tego nie załaduje, sam znajduje się dość nisko i adres ładowania tej gry pokrywa się adresami w której siedzi ten loader. Cholera, pewnie jakiś inny loader, albo inna wersja systemu potrzebna. Może w Turbo6000 było jednak trochę inaczej?

A może po prostu wczytać ten plik do jakiegoś programu kopiującego obsługującego Turbo6000? I podejrzeć co mamy właściwie w tym pliku, wystarczy parę bajtów aby wiedzieć o co chodzi:

0801: 0B 08 4F 04 9E 32 30 36 34 00 00 00 00 00 00 82

WHAT!?! Ci którzy przeczytali post o carcie SONIX, to zapewne zorientują się co tu widać...

Przecież do cholery jasnej to jest typowy nagłówek programu dla platformy C64.  Widać wszystko co trzeba, tzn. adres następnej linii $80b, nr. linii ($44F/1103) potem token instrukcji SYS ($9E) oraz adres uruchomienia: 2064.

WTF?!?! Jakim cudem udało mi się softem z Atari wczytać kasetę na której jak widać nagrane są programy dla C64.... to jakiś okrutny żart!?! Albo jakiś niewiarygodny wręcz przypadek... zatem trzeba zobaczyć czy uda się wczytać jakieś inne programy z tej kasety, bo "PITSTOP" to akurat na Atari jest... byłbym pewny  że to kaseta z softem dla C64 gdyby pojawił się jakiś tytuł gry której nie ma na Atari!

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/tsp_load_ex2.png

096C: 50 49 54 53 54 4F 50 20 49 49 20 20 20 20 20 20  PITSTOP II

aaarrrrghhhh!!! pfff! NEXT PLEASE! :D

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/tsp_load_ex3.png

096C: 44 45 56 49 41 4E 54 53 20 20 20 20 20 20 20 20  DEVIANTS

no dobra... to już jest jakiś trop, gra istnieje na platformę C64: DEVIANTS

http://www.gb64.com/Screenshots/D/Deviants.png

^^^ powoli zacząłem się godzić z tym że to jest kaseta zapisana w jakimś systemie Turbo dla platformy C64, który jakimś "przypadkiem" jest w 100% zgodny z niemieckim Turbo 6000... zarówno na poziomie kodowania bitów na taśmie, jak i formatu i struktur danych. Zgodne są nawet bajty wskazujące adresy ładowania! Szok i niedowierzanie! :)

No ale jak zweryfikować poprawność moich przypuszczeń i być pewnym na 100% że to coś da się uruchomić na C64? No skoro na naszej platformie dysponujemy formatem .CAS to może i na platformie C64 jest również jakiś sposób na archiwizację taśm? Okazało się ze jest i że istnieje masa softu tworzącego pliki w formacie .TAP które przechowują dane w postaci liczb określających długość impulsów zapisanych na taśmie.

Tylko pojawił się jeden problem, narzędzie konwertujące pliki .WAV na .TAP nie patrzą zupełnie na strukturę danych, a robią jedynie "surową" konwersję, wynikiem której jest plik zawierający kolejne długości pulsów zdekodowane w/g widzimisię algorytmu zawartego w danym narzędziu. Sama konwersja na ten format nic nie da, bo jeszcze trzeba wiedzieć jaki system turbo załadować aby wczytać to nagranie utworzone w systemie a jakimś systemie Turbo.

Sytuacja wydawała się beznadziejna, ponieważ w przypadku C64 systemy turbo są jedynie "programowe", żadne modyfikacje magnetofonu dla C64 nie są wymagane, ponieważ pracuje on od razu na takiej zasadzie jak nasze systemu turbo, a niska domyślna prędkość transmisji (300 bodów) wynika po prostu z jakiegoś niesamowitego nieporozumienia, albo niechęci ludzi piszących C64 Kernal ROM ;) Jak więc do cholery znaleźć system którego szukam, jak dla platformy C64 istnieje ich niezliczona liczba... każdy kto chciał pisał własny... ich mnogość mnie dobiła i już się miałem poddać, ale wpadłem na pomysł że to musi być bardzo wczesny system turbo ... dlaczego? Bo daty widniejące w loaderach dla systemu Turbo 6000 to 1988 rok:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/Turbo6000_4k_cart.png http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/Turbo6000_loader.png

Zatem system turbo którego klonem musiało być Turbo 6000, musiał pochodzić w roku wcześniejszego niż 1988. To już nieco ułatwiało zadanie, tzn. nie wydawało się ono tak niewykonalne jak wcześniej sądziłem... zaczęło się grzebanie po internecie, czytanie o "komodorowskich" systemach turbo, przeglądane każdej notatki i kawałka kodu na który napotkałem w sieci, artki o archiwizacji taśm dla C64... na początku naiwnie sądziłem że to może jakiś system turbo zawarty w BlackBOX czy Action!Replay... ale niestety nie... pliki .TAP wygenerowane przez narządzie które sobie upatrzyłem czyli: C64 Tapedecode, co prawda wygenerowało mi pliki .tap bez problemu, ale używając emulatora VICE nie udawało mi się ich załadować mimo iż emulator podczas dołączania pliku TAP dekodował nazwę, więc musiał wiedzieć co to za format turbo!

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/vice_tprg_ex1.png

Kolejne jakieś dziesiątki przejrzanych stron, normalnie zaczynało wyglądać na to że robię doktorat z systemów turbo dla Commodore64... prawdę mówiąc chyba "profilowanie przez google" mi pomogło, bo gdy tylko google się zorientował czego szukam, zaczął w końcu podrzucać sensowniejsze linki... i tak idąc po nitce do kłębka trafiłem na coś takiego:

C64 Turbo Tape
https://csdb.dk/gfx/releases/135000/135830.png

wszystko zaczęło pasować i układać się całość! Data powstania 1984! W dodatku to niemieckie rozwiązanie więc ta pozycja była idealnym kandydatem do bycia tym systemem turbo którego szukałem, zatem chwila prawdy:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/c64_deviants.gif http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/c64_pitstop.gif

Prawdę mówiąc gdy zobaczyłem "FOUND DEVIANTS" albo "FOUND PITSTOP", no to kopara mi totalnie opadła, nie do końca wierzyłem że udało się znaleźć ten właściwy system turbo. Jednak wyszło na to że to jednak ten :)

I tutaj zaczęła docierać do mnie taka trochę smutna prawda... Turbo 6000 okazało się klonem (i to jakim!?!) rozwiązania z platformy C64. Zacząłem grzebać w kodzie loadera, jednego i drugiego... procedury dekodowania strumienia danych oparte w przypadku platformy C64 na timerze układu CIA, natomiast w przypadku Atari na timerze układu POKEY. Podobieństwo procedury wczytującej bajt danych były tak uderzające że aż nie chciało mi się wierzyć jakiej jakości kalkę ktoś zastosował :)

Potem zdałem sobie sprawę że istnieje jeszcze jeden system dla platformy Atari który bazuje na tej samej zasadzie działania, tyle że nie wykorzystuje przerwań generowanych przez PIA jak przypadku Turbo6000, a jedynie timery układu POKEY, aby zorientować się czy impuls, który był transmitowany to "0" czy też "1"... tym systemem jest oczywiście Blizzard.

Czy autorzy Blizzarda bazowali na Turbo 6000 które to bazowało w 100% na C64 Turbo Tape? Tego nie mogę stwierdzić z całą pewnością, ponieważ zdarza się że ludzie wpadają na te same pomysły zupełnie niezależnie, ale przyznam że po tej przygodzie zmieniło się nieco moje postrzeganie wszystkich tych rozwiązań... do tej pory naiwnie sądziłem że jednak te wszystkie pomysły rodziły się jakoś niezależnie, ale wychodzi na to że wszystko ma jakiś jeden początek, z którego na drodze ewolucji i rozwoju powstają inne rozwiązania, oczywiście mniej lub bardziej bazujące na tym co powstało wcześniej.

Zastanawiało mnie jakie były początki powstania tego systemu turbo... grzebiąc pod odmętach internetu i googlując.... Mr.Google w końcu postanowił uraczyć mnie takim linkiem: "How TurboTape Works", a w artykule mamy bardzo fajny rysunek wyjaśniający jak jest dekodowany sygnał turbo za pomocą użycia timer-a, czy to będzie timer w CIA czy w POKEY, to już nie ma znaczenia, zasada działania jest taka sama :)

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/C64_TurboTape.jpg

Czy na tej kasecie znajdują się gry zapisane za pomocą "Turbo Tape 64", czy też za pomocą innego programu z nim zgodnego, tego już chyba nie będę w stanie ustalić, przyznam że nawet już nie mam sił na dalsze poszukiwania. Dla dociekliwych wystawiam dump tej kasety, wykonany za pomocą techniki użytej i opisanej w poprzednich postach, tzn.

kanał L) sygnał zgrany z wyjścia kolektora Q6
kanał R) sygnał zgrany z wyjścia ogranicznika (8 pin LM324)

C64 Turbo Tape example cassette dump (format OGG, Q=10)

Przyznam że nie miałem siły dekodować i sprawdzać wszystkich plików z tej kasety, ale kaseta nie była w stanie idealnym, części gier na pewno się nie wczytuje, np. próba wczytania "Pitstop II", kończy się niepowodzeniem:

http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/pitstop_II_err.png

...a i jeszcze jedna uwaga, gdy używałem softu z pakietu C64TapeDecode, musiałem użyć parametru "-r" przy przetwarzaniu plików .WAV na .TAP (widać Datasette ma fazę odwróconą o 180° w stosunku do tego co zgrałem przy użyciu XC12):

sbn@debian:~/lab/c64tapedecode/src$ ./wav2tap -r c64_trk06.wav >trk06.tap

Być może jest tak że niepotrzebnie prowadziłem całe to dochodzenie, bo ktoś bardziej zaznajomimy z platformą C64 powiedziałby mi od razu co to za turbo i jakiego softu należy użyć aby wczytać programy z tej kasety, ale cóż... cała ta przygoda wiele mnie nauczyła :) Kto by pomyślał że trafi mi się kaseta przeznaczona dla C64 w dodatku bez żadnego opisu sugerującego jakiekolwiek jej pochodzenie czy też zawartość. Założyłem po prostu że to kaseta z programami dla Atari i z uporem maniaka dążyłem do odczytania tych danych na Atari... to wszystko miało swoje dalece idące konsekwencje jak widać, czysto historyczne ale jednak. Przyznaję że nie sądziłem że coś mnie będzie w stanie jeszcze jakoś specjalnie zaskoczyć, jednak ten przypadek należy do takich, który zapamiętam na bardzo, bardzo długo.

Ponieważ to ostatnia kaseta z pudełka, moje posty w tym wątku nie będą już tak częste. Zachęcam was do publikowania swoich odkryć i analiz, nie obawiajcie się dzielić swoją wiedzą i spostrzeżeniami... kto wie jak wiele jeszcze pozostało do odkrycia na starych kasetach, zapomnianych taśmach, cartridge-ach i innych nośnikach.

Ja na jakiś czas muszę przerwać tą działalność, ale zapewniam was że jeszcze do niej wrócę. Muszę ogarnąć trochę pozostałych spraw, bo przyznam że stworzenie tego co tutaj wam zaprezentowałem zajęło trochę czasu, o wiele więcej niż sądziłem, ale cieszę się że udało mi się dobrnąć końca tego etapu.

Co mogę powiedzieć na koniec tego wątku? No może starą jak świat prawdę ... Everything is a Remix! <--- polecam obejrzeć, a na zakończenie tak mi się przypomniało jeszcze:

https://www.youtube.com/watch?v=Ns8bG9AbfwM

ps1) zapewne zapomniałem napisać o setce rzeczy które miałem w głowie podczas walki z tą kasetą. W głowie miałem tyle myśli i pomysłów, tyle rzeczy do zaprezentowania, że sądziłem że tego wyjdzie 10 razy tyle ile napisałem, ale wszystko to jakoś uleciało z głowy podczas pisania, a mimo tego napisanie tego zajęło mi pół dnia (oczywiście z przerwami i czasem niezbędnym na przygotowanie tych wszystkich plików). Miałem wklejać fragmenty kodów źródłowych loaderów z C64 i Atari, aby pokazać wam jak podobne są procki odczytu w przypadku C64, Turbo6000 czy Blizzarda. Przyznam jednak szczerze, nie mam już dziś na to siły, nie chcę obiecywać czy do tego jeszcze wrócę, ale jak będę miał chęci, siły i czas to dokonam takiego porównania, chociażby w przypadku procedury odczytującej bajt ze strumienia danych.

ps2) jeżeli mi się coś przypomni, albo gdy odpocznę i przejrzę jeszcze raz ten mój post, zapewne będę coś poprawiał.

ps3) dzielcie się wiedzą, zasobami, archiwizujcie i udostępniajcie! Te wszystkie carty, taśmy i magnetofony już umierają. Niebawem nie będzie możliwe odzyskanie niczego z kaset, pamięci EPROM w cartach też już zbliżają się do końca życia, z dnia na dzień mogą przestać działać (ładunki zgromadzone w komórkach pamięci EPROM bezpowrotnie ulatują!). w tym wątku mieliście kilka przykładów że dosłownie "cudem" udało się odzyskać zawartość niektórych umierających już cartów.

ps4) WIELKIE PODZIĘKOWANIA dla uicr0Bee-iego za udostępnienie wszystkich tych materiałów (kaset, magnetofonów i cartów). Zajęcie się tym zajęło mi sporo czasu, życie przeszkadzało jak mogło, ale w końcu się udało.a

ps5) nie traktujcie mnie jako jakiejś wyroczni czy "właściciela" tego wątku, piszcie w nim bez obaw. Nie obawiajcie się mnie "prostować", jest spora szansa że moje przemyślenia czy dywagacje mogą być błędne. Mogło mi się źle coś wydawać, lub miałem zbyt małe doświadczenie w danym temacie aby móc poprawnie coś ocenić. Konstruktywna krytyka mile widziana. Nie wierzę że nie popełniłem błędów (czy to merytorycznych czy to logicznych) pisząc te wszystkie posty. Także jeżeli ktoś odkryje jakieś nieścisłości  niech śmiało o tym pisze.

ps6) Link do skanu magazynu Compute! ze stycznia 1985, w którym to opublikowano kod "Turbo Tape" (do własnoręcznego wklepania!) dla komputerów C64 i VIC20: Compute! Magazine Issue 056

ps7) właśnie doczytałem że link na csdb.dk który podawałem wyżej, to "lame hack", oryginał ponoć to ten: Turbo Tape 64

https://csdb.dk/gfx/releases/21000/21139.gif

i jeszcze doczytałem że kasety nagrywane w PL były często i gęsto zapisane w standardzie ABC-Turbo:

ABC Turbo V1.0 lub ABC Turbo V2.0

https://csdb.dk/gfx/releases/33000/33133.png https://csdb.dk/gfx/releases/20000/20644.png

sprawdziłem, te turbo też wczytuje pliki z tej kasety bez problemu. Najlepsze jest to że: Turbo 250 a także V3 Turbo Tape, również bez problemu wczytują pliki .TAP wygenerowane z tej kasety.

https://csdb.dk/gfx/releases/20000/20633.png https://csdb.dk/gfx/releases/136000/136135.gif

^^^ wychodzi na to że "mnogość" systemów Turbo dla Commodore C64 to jakiś mit. Co bym nie kliknął z "cdsb.dk" to wychodzi na to że ładuje pliki w formacie TurboTape64. Czyli co? jeden oryginał a reszta to naśladowcy? ;)

ps8) Okazało się że Turbo wbudowane w Blackbox v3 też jest zgodne z TurboTape64:
http://seban.pigwa.net/uicr0bee/tapes/unk_tape/xmpl/black_box_v3.png

@AS: Ja również bardzo dziękuję! :) Cieszę się że Tajemnice Atari znalazły nowy dom! :)

Jacques napisał/a:

Może wystarczy dopisać, że leżały kiedyś na TOMSie ;)

No pewnie że leżały! I to nie raz, ale jeszcze wcześniej leżały na XC12 z systemem K.S.O. Turbo 2000. I te nie przespane noce kiedy wklepywałem "Heartlight", dzięki temu powstał ScrewLight.

ps) ponieważ transakcja została sfinalizowana i kupujący jest zadowolony, to sądzę że temat można już zamknąć :]

Hejka!

Wychodzi na to, że udało mi się uniknąć pętli czasu i na dnie pudełka został ostatni magnetofon. Swoją drogą był to pierwszy magnetofon który na samym początku "przygody z magnetofonową kolekcją uicr0Bee" wyciągnąłem z pudełka, ale  po wykonaniu kilku testów, zniechęcony jego stanem odłożyłem go "na później".

Chciał nie chciał, musiałem do niego wrócić po dłuższej przerwie. Magnetofon XC12 miał sporo "upierdliwych" problemów, tzn. po pierwsze pęknięty kabel łączący magnetofon z komputerem; kontaktował losowo. Po drugie interface zbierał straszny przydźwięk i zakłócenia z okolicy, ale gdy zobaczyłem gdzie umiejscowiono płytkę interfejsu zrozumiałem dlaczego.

Po trzecie totalnie rozwalone mocowanie klapki i brak sprężyny. Czego by się nie dotknąć to porażka! Zniechęcony rzuciłem okiem szybko na płytkę interfejsu turbo, zorientowałem się szybko, że to Blizzard i z czystym sumieniem odłożyłem go ze spokojem na później, no bo co może być ciekawego w kolejnym Blizzardzie? :)

Przyszedł w końcu ten czas kiedy ostatnia sztuka musiała trafić ponownie na warsztat, aby zostać doprowadzoną do przyzwoitości. Zdjęcia które tu zaprezentuje nie będą przedstawiały oryginalnego stanu magnetofonu, ale już po wykonaniu poprawek i napraw. Poprzednie, początkowe zdjęcia gdzieś mi przepadły, więc będę prezentował stan obecny tegoż egzemplarza.

Otwarcie magnetofonu sprawiło mi pewien problem, zacznijmy zatem od prezentacji nietypowego umiejscowienia interface turbo w magnetofonie, bo to właśnie jego lokalizacja (i kable do niego idące) była przeszkodą m. in. w otwarciu obudowy magnetofonu:

http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/photo/blz1121_loc2.jpg

http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/photo/blz1121_loc1.jpg

Na zdjęciach widać miejsce które wybrał montujący ten system, niestety zupełnie nie rozumiem skąd taki pomysł. Ta lokalizacja wymagała przeciągnięcia parunastu cm kabli do płytki z interface, w tym sygnału audio o dość niskiej amplitudzie, wzmacniacz na płytce interface ma dość duże wzmocnienie, więc idealnie zbierał wszystko z okolicy, łącznie z zakłóceniami od silnika... (tym razem chociaż bez "radia Erewań") na zdjęciach widać więc, że wymieniłem już przewód z sygnałem audio na ekranowany.

Gdy pierwszy raz spojrzałem na tę płytkę, rutynowo przyjąłem że to typowy "blizzard" oparty na UL1111 i UCY7400, wiec nie śpieszyło mi się do specjalnego analizowania tej płytki, jednak gdy przyjrzałem się jej ponownie, coś mi nie pasowało, tzn. zacząłem mieć wątpliwości czy aby na pewno jednym z zastosowanych układów jest UL1111.

Po pierwsze zastanawiała mnie ilość tranzystorów w przedwzmacniaczu, bo na tej płytce są dwa, a w przypadku typowego blizzarda opartego na UL1111 zazwyczaj wstępował jeden dodatkowy tranzystor, a pozostałe 5 szt. znajdowało się w UL1111, jednak w tym wypadku coś było inaczej, a wyglądało to tak...

góra płytki drukowanej:
http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/photo/blz1121_pcb_top.jpg

spód płytki drukowanej:
http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/photo/blz1121_pcb_bot.jpg

^^^ nie dość, że nie zgadzała się liczba tranzystorów (ale to jeszcze nie powód do niepokoju ;] bo być może autor uznał że BC107B użyte w przedwzmacniaczu mniej szumią niż tranzystory z UL1111) ... to jeszcze układ połączeń przy UL1111 zupełnie mi nie pasował do wyprowadzeń tegoż układu. Dodatkowo zastanawiały mnie bezsensowne połączenia pomiędzy pinami 1-14 oraz zwarcie pinów 8-9.

Przystąpiłem zatem do rozrysowania schematu, używając wcześniejszej technologii do zakrzywiania czasoprzestrzeni (The GIMP), szczególnie że również w tym wypadku autor interface zastosował zaawansowaną technologię maskowania, tym razem zza wielkiej wody, czyli The Itchy & Scratchy, o dźwięcznym polskim tłumaczeniu: "Poharatka i Zdrapek":

http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/photo/blz1121_rev_eng.jpg

^^^ przyznam że "Poharatka" z lewej strony sprawiła mi trochę kłopotów, ale autor płytki chcąc bardziej "zaciemnić" obraz sytuacji wykonał "fikcyjne połączenia", tzn. łącząc piny 14-1 oraz 8-9, przez co naprowadził mnie tylko szybciej na właściwy trop. Gdy rozrysowałem sobie wszystko oprócz wnętrzności tajemniczej "Poharatki", wszystko stało się jasne. Poharatkę zdradził "Zdrapek" z prawej strony który okazał się zwykłym 7400, stało się jasne że wewnątrz tajemniczej "Poharatki" muszą się znajdować 4 tranzystory, w dodatku w dość charakterystycznym ułożeniu... chwilę na to wszystko popatrzyłem i przypomniał mi się stary katalog elementów półprzewodnikowych CEMI z lat '80 w którym to był zaprezentowany układ UL1121, czyli nasz polski klon, japońskiego układu LB8021 firmy Sanyo.

Znając realia tamtych czasów i to że robiło się z tego się miało pod ręką, zastosowanie UL1121 mimo że jest to układ stosowany zazwyczaj do czego innego, wcale mnie nie dziwiło aż tak bardzo, w końcu 4 tranzystory zawarte w tym układzie mogły się równie dobrze sprawdzić jako elementy kluczujące tak samo jak te znajdujące się wewnątrz UL1111, dodatkowo w przypadku UL1121 zyskiwało się dodatkowe rezystory umieszczone w bazach tranzystorów, a więc stopień wyjściowy mógł być uproszczony i nie trzeba było dodawać już zewnętrznych rezystorów bazowych.

Oto co wyszło po odtworzeniu schematu:
http://seban.pigwa.net/uicr0bee/turbo_systems/Blizzard_UL1121/sch/blizzard_UL1121.png
^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Dla zainteresowanych również wersja wektorowa (PDF): Blizzard Turbo Interface - UL1121 version

Patrząc na schemat widzimy standardowe bloki typowe dla systemu Blizzard, czyli przedwzmacniacz i układ kształtowania impulsów zrealizowany na Q1,Q2 oraz Q3C. Potem multiplekser umożliwiający przełączenie/wybór który sygnał dotrze do wyjścia, tzn. czy zdemodulowany sygnał FSK pobierany z kolektora Q7 (FSK_data) czy też wzmocniony i ukształtowany (w falę prostokątną o bardzo stromych zboczach) sygnał Turbo.

Przełączenia multipleksera dokonuje się za pomocą linii DATA_OUT. Tak, tak.. tą samą linią, która jest wykorzystywana do zapisu danych na taśmie, ale jak wspominałem już wcześniej linia ta podczas odczytu danych nie ma żadnego wpływu na zapis danych ponieważ przełącznik Odczyt/Zapis w magnetofonie jest przestawiany w pozycję "zapis", dopiero po wciśnięciu przycisku REC, w przypadku gdy mamy wciśnięty PLAY ten sygnał nie jest nigdzie wykorzystany, a za pośrednictwem POKEY-a i jego rejestru SKCTL możemy sterować tą linią dowolnie. Ktoś więc wpadł na pomysł że można za pomocą tej linii przełączać interface do pracy w turbo. Domyślnym stanem linii DATA_OUT (tak ją ustawia system) jest logiczne "1", i w tym wypadku interface będzie pracował w trybie "normal", natomiast ustawienie bitu #7 w rejestrze SKCTL powoduje wystawianie logicznego "0" na linię DATA_OUT, to też wykorzystuje oprogramowanie systemu Blizzard, przestawiając interface do pracy w tryb "Turbo".

Hola! Hola! Ktoś zaraz zawoła... "Ale co podczas zapisu danych?!?! Przecież machanie linią DATA_OUT czy to w trybie FSK czy też w trybie Turbo będzie powodowało ciągłe przełączanie interface z trybu "normal" (FSK) na "turbo" (PWM) i vice versa". Dokładnie tak będzie, jednak nie ma to żadnego znaczenia dla użytkownika czy systemu operacyjnego... bo przecież skoro dokonujemy zapisu danych, to w jakim trybie pracuje sekcja odczytu danych nie ma to dla nas najmniejszego znaczenia.

Wracając do analizy schematu pozostał nam ostatni blok nazwany "output stage", czyli "sekcja wyjściowa", zadaniem tej sekcji jest po pierwsze utworzenie wyjścia typu "open collector", bo tego wymaga standard SIO, który umożliwia dzięki temu zabiegowi podłączenie wielu urządzeń do jednej magistrali szeregowej. Zastosowanie tego typu wyjścia, zabezpiecza wyjścia nadajników przed sytuacją w której więcej niż jedno urządzenie chciałoby wystawić na magistrale swoje dane, które byłyby w przeciwnym stanie logicznym do danych wystawianych przez inne z urządzeń. W przypadku wyjść typu "open-collector" (pol. "otwarty kolektor). Żadne z urządzeń podpiętych do magistrali nie ulegnie fizycznemu uszkodzeniu. Co prawda dane ulegną przekłamaniu (wygra ten nadajnik który wystawia "0"), ale to co najwyżej może skończyć się błędem transmisji.

Gdyby taka sytuacja nastąpiła w przypadku standardowych wyjść typu "push-pull",  w chwili gdy jedno z urządzeń wystawiło by "1" czyli +5V, a drugie "0" czyli 0V ... wtedy mogło by nastąpić by uszkodzenie wyjść urządzeń wywołujących konflikt na magistrali, a jeżeli nie uszkodzenie to przepływ dość znaczącego prądu, który z upływem czasu degradował by strukturę krzemową tworzącą linię nadawczą.

W przypadku magistrali używającej wyjść typu "otwarty kolektor", na magistrali po prostu cały czas panuje stan logiczny "1", a urządzenia nadające dane mogą jedynie "ściągać" ten stan do zera. Prąd płynący w przypadku wystawienia "0" przez którekolwiek z urządzeń jest ograniczony rezystorem znajdującym się w kolektorze tranzystora urządzenia nadawczego, a jeżeli na magistrali jest więcej urządzeń i każde z nich zawiera swój rezystor kolektorowy, to prąd ten będzie nieco większy (równoległe połączenie wszystkich rezystorów kolektorowych) jednak będzie on i tak znikomy z tym prądem który mógłby popłynąć w momencie konfliktu na magistrali zbudowanej z typowych układów z wyjściem typu "push-pull".

Zatem tranzystor Q3B i rezystor R9 tworzą wyjście typu "otwarty kolektor" (ang. open-collector)... ale pojawia się problem... taki układ dokonuje odwrócenia fazy sygnału o 180°, tzn. jeżeli na bazie tranzystora Q3B pojawi się "1" logiczna to tranzystor włączy się, "ściągając" wyjście to poziomu masy (0V) a więc na wyjściu pojawi nam się zero logiczne, zatem nasza "1" stała się zerem, natomiast gdy na bazie tranzystora będzie panował potencjał bliski 0V ten będzie w stanie wyłączenia, więc na jego kolektorze będzie panował potencjał +5V (dzięki rezystorowi R9). Zatem aby przywrócić fazę na wyjściu układu do pierwotnego stanu, z użyciem Tranzystora Q3D oraz rezystora R8 zrealizowano kolejny odwracacz fazy. Podwójne odwrócenie fazy (2x180° = 360° = 0°) daje nam wyjście typu "otwarty kolektor" z nie zmienioną fazą sygnału.

O i to chyba cała tajemnica pracy tegoż interface. Opisana co prawda bardzo pobieżnie i "po łebkach", jednak myślę że udało mi się nieco przybliżyć wam "tajniki" pracy tych układów, które na pierwszy rzut oka wyglądają na skomplikowanie i zagmatwane, jednak przy bliższym poznaniu wcale takie nie są :)

http://seban.pigwa.net/aa/music_vs_rocket_science.jpg

Ponieważ to na chwilę obecną jeden z ostatnich postów opisujących systemy turbo przed dłuższą przerwą, nasunęła mi się refleksja związana z minionymi czasami i tym z czym musieli się zmagać konstruktorzy tych wszystkich interfejsów... dostępność półprzewodników była jaka była, dość trudno było zdobyć pewnie te wszystkie układy w tamtych czasach... pamiętam jak polowałem na układy i części chociażby w "bomisach", a na zestawy "młody elektronik" w składnicy harcerskiej na marszałkowskiej. A gdy była posucha totalna to rozdłubywałem nawet tzw. "logistery", aby wydobyć z nich części elektroniczne.

Jednak te czasy wyróżniała jedna rzecz: mieliśmy własne półprzewodniki, tzn. własną ich produkcję. Były one jakie były, ale nawet jeżeli większość tych układów to klony i kopie zachodnich rozwiązań, albo układy wykonane z klisz zdobytych różnymi dziwnymi drogami, to oczywiście można na to narzekać i psioczyć, jednak mieliśmy zdolność produkowania własnych układów, co było moim zdaniem kluczowe.

Niestety to zostało ubite, gdybyśmy do dziś mieli możliwość produkcji własnego krzemu, nasz rodzimy rynek miałby szansę się rozwinąć, a wiedza dotycząca technologii produkcji oraz możliwości również by się rozwinęły. Mogliśmy mieć własne układy, doświadczenie i wiedze... ta szansa została wtedy zaprzepaszczona, bardzo żałuję że nikt nie próbuje przywrócić produkcji układów półprzewodnikowych w Polsce, wszyscy uważają że to bez sensu, bo już jest zbyt duża konkurencja, a moim zdaniem jest wprost przeciwnie. Mielibyśmy szansę na odtworzenie i  zdobycie wiedzy, wykształcenie nowych zdolnych młodych ludzi potrafiących zaprojektować i zbudować własne układy. Teraz jesteśmy skazani na używanie tego co nam chińczyk (o ile  będzie chciał) wyprodukuje.

Hej!

uicr0Bee napisał/a:

A może po prostu zhakowany?

Też tak myślałem, ale w takim razie dlaczego ktoś zmienił tylko komunikat na ekranie sygnalizującym błąd, a nie zmienił napisów w głównym ekranie loadera? Do kompletu ten loader jest mocno "zaciemniony" przez użycie "nielegalnych" instrukcji 6502C, do kompletu "zaszyfrowany" (co prawda przez zwykły XOR, ale zawsze to jednak :P). A do tego jeszcze *AJEK dość mocno chyba "chronił" swój soft... tzn. nigdy nie widziałem żadnego jego softu puszczonego na giełdzie, można było jedynie zobaczyć efekty pracy jego "kopierów" ... bo na giełdach pojawiały się tylko pliki nimi "potraktowane".

Fajnie byłoby zobaczyć po latach jak wyglądały te programy *AJKA, ale nie mam zbytnich nadziei że cokolwiek przetrwało, bo skoro było takie "tajne" to jest bardzo małe prawdopodobieństwo że gdzieś się zachowało.

Natomiast po latach muszę przyznać że dzięki *AJKOWI to ja się sporo nauczyłem o błędach 6502 i "nielegalnych" instrukcjach :) Analizując kod jego loadera do Speedy jako jeszcze dość młody człowiek miałem sporo "zabawy" :)

uicr0Bee napisał/a:

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

Niestety pewnie gdzieś się wala ;) A piszę niestety ponieważ wersja którą puściłem wtedy jak się okazało ma fatalny w skutkach błąd (nie zapisuje się ostatni segment danych jeżeli nie występuje po nim sekwencja INIT). Ale źródła jakimś cudem przetrwały, więc po prostu poprawię ten głupi błąd i wystawię wszystko na mojego github-a.

uicr0Bee napisał/a:

Czekamy z niecierpliwością na cd.

Kończę właśnie przerysowywać tego Blizzarda do KiCAD-a, wiec niebawem będzie i opis kolejnej wersji blizzarda, a potem opis przygód z kasetą z archiwum "X" ;)

Hej!

Tym razem postaram się streścić. Dziś będzie o kolejnej kasecie z której udało się odzyskać część programów. Niestety to kolejna kaseta w bardzo złym stanie, mocno sfatygowana, taśma zniszczona w wielu miejscach, części programów nie dało się niestety odzyskać.

Na pierwszy rzut ucha kaseta wyglądała na typową  dla systemów K.S.O. Turbo 2000 lub Turbo 2000F/2001, jednak po pierwszym bloku następował już ciąg bloków w niestandardowym formacie. Na początku "na ucho" nie kojarzyłem cóż to za format, ale szybko wyjaśniło się z czym mam do czynienia gdy spróbowałem wczytać kasetę z użyciem realnego sprzętu. A stało się to dość szybko, ponieważ mój klasyczny sposób działania, tzn. zgranie kasety za pomocą dobrej jakości decka i tym razem się nie sprawdził (tak samo jak w przypadku ledwie odzyskanej kasety z blizzardem) ponieważ żadnego z programów zgranych za pomocą decka nie udało mi się potem wczytać poprawnie do komputera. Tutaj problemem był jednak inaczej ustawiony skos głowicy w magnetofonie który dokonał zapisu. Brakowało góry pasma przy odczycie za pomocą decka, zatem wróciłem do XC12 w którym mogłem kręcić głowicą i dokonać zapisu ścieżki audio bezpośrednio z kolektora tranzystora Q6 jak i z wyjścia ogranicznika sygnału.

Powtórzyłem zgranie danych tą samą metodą którą zastosowałem w poprzednim przypadku, tzn. kanał lewy to wyjście tranzystora Q6 a kanał prawy to sygnał zgrany z wyjścia ogranicznika (pin 8 układu LM324).

Przy próbie wczytania i uruchomienia pierwszego nagrania na taśmie moim oczom ukazała się następująca sekwencja obrazów:

http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/spd_2700a.png http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/spd_2700b.png
http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/spd_2700c.png http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/spd_2700d.png

Gdy to ujrzałem wszystko stało się jasne, wspomnienia wróciły i przypomniałem sobie nawet swoją walkę z nagraniami zapisanymi w tym formacie oraz to, że "wpieniony" tym że handlarz z giełdy nagrywał ludziom pirackie gry zabezpieczone przez zapis w tym "niestandardowym" formacie, postanowiłem napisać "Anty *AJEK Copy", co też uczyniłem w 1992 roku:

http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/antyajek.gif

W tamtym czasie miałem okazję przetestować ten program na kilku plikach które udało mi się znaleźć na kasetach kolegów. Program wydawał działać się całkiem dobrze. Jednak był to czas kiedy pliki binarne nie były jeszcze masowo kompresowane za pomocą cruncherów takich jak. np. Cruncher 5.0 od Magnusa, czy innych wynalazków zmieniających diametralnie format pliku podczas kompresji. Po odbezpieczeniu paru gier zapisanych w tym formacie uznałem że wszystko działa doskonale i sprawę uznałem za zakończoną a program puściłem na giełdzie i o całej sprawie zapomniałem.

Jakież było moje zaskoczenie gdy po latach Speedy 2700 znów mnie powitał ;) Nawet zapomniałem że ekran startowy loadera tak wyglądał, zajrzałem więc "do środka", okazało się ze loader ten sam, tak samo "zaciemniony" przez użycie nielegalnych instrukcji oraz wykorzystanie "błędów" 6502C (np. wykonanie instrukcji JMP ($AFF) powinno zakończyć się przez skod pod adres zawarty w komórkach $AFF,$B00... niestety błąd w 6502C powoduje że skok jest wykonywany pod adres zawarty w komórkach $AFF,$A00).

Nadarzyła się wiec okazja aby przetestować swój stary kawałek softu... jakież było moje zdziwienie że program ów bez problemu wczytał kilka plików zapisanych na tej kasecie (takich które dały się poprawnie wczytać). Po zapisaniu tychże programów ponownie na dyskietce w postaci plikowej, cieszyłem się jak dziecko że tak stary soft działa bez problemu :) Radość nie trwała długo, ponieważ bawiąc się przenoszenie kolejnych plików z kasety okazało się że mój wiekowy program ma błąd polegający na tym że czasami pomija on zapis do pliku wyjściowego ostatniego bloku danych wczytanych do bufora :) Pliki którymi dysponowałem w 1992 roku konwertowały się bez problemu, niestety pliki z tej kasety w większości spakowane są cruncherem 5.0 Magnusa, mój program się na nich wykłada pomijając zapis ostatniego bloku :] I wyszło na to że po tylu latach powinienem wydać wersję poprawioną tegoż softu... znalazłem nawet źródła tego "wiekopomnego dzieła", napisane jeszcze w MAC/65 w dodatku wszystkie lokalizacje i adresy są w tych źródłach zapisane w systemie dziesiętnym, a etykiety typu W0, Q1, S1, K5... są bardzo pomocne i czytelne :D

Gdy zobaczyłem te źródła po latach moje zaskoczenie było ogromne, że niby ja pisałem taki kod?!? Szok i niedowierzanie...

0490 m2  jsr on
0491     ldx 0
0492     ldy 1
0493     stx 212
0494     sty 213
0495     ldx 205
0496     ldy 206
0497     stx 0
0498     sty 1
0499     ldy #0
0500 i0  jsr roff
0501     ldy #0
0502     lda (0),y
0503     pha 
0504     jsr ron
0505     pla 
0506     jsr bput
0507     bpl ok3
0508     jmp error
0509 ok3 jsr in

pfff... chyba znowu popłynąłem (czytaj "delikatnie odbiegłem od głównego tematu")... pora zatem wrócić na ziemię :-)

Próbowałem odczytać wszystkie programy znajdujące się na kasecie, niestety marnie to wyglądało... nawet analogowa magia kończyła się w większości plików takim obrazkiem:

http://seban.pigwa.net/uicr0bee/tapes/AJEK_Speedy_2700/ajek_error.png

Widząc ten ekran po raz kolejny zacząłem się zastanawiać skąd pochodziła ta kaseta i dlaczego ekran błędu zawierał informację "(C)*ATAR, HIT*PILA 1992", przecież w/g mojej wiedzy *AJEK działał na terenie warszawskiej giełdy, o ile mnie pamięć nie myli to giełdy znajdującej się na pietrze w klubie Stodoła.

Czy te napisy mogą sugerować że kopier *ajka tworzący te pliki mógł być "personalizowany", dla różnych "studiów komputerowych" z tamtych czasów? w tym wypadku to ATAR/HIT PIŁA? Czy ktoś z was słyszał o kimś takim?

Strona A kasety nie pozostawiła złudzeń, nie dało się praktycznie odzyskać żadnego programu... zużycie i wiek taśmy powodował że cały czas występował albo błąd sumy kontrolnej albo występowały zaniki nagrania w miejscach zagnieceń na taśmie...

Na szczęście ktoś postanowił nagrać dokładnie ten sam zestaw programów na drugiej stronie kasety, która to strona była w o wiele lepszym stanie, a na kasecie znalazły się następujące programy:

  • Gallahad

  • Guard

  • Jaffar

  • Koło fortuny

  • Krucjata

  • Najemnik

  • Tank vs Tank

  • Vicky

Niestety nie wszystkie z tych programów udało się odzyskać, nawet mimo o wiele lepszego stanu nagrań na "stronie B". Nie udało się mi odzyskać pozycji: Koło fortuny, Najemnik, Vicky. Z tym że "Vicky" był już nagrany w standardowym formacie, prawdopodobnie z dodanym loaderem L2 (loader.07).

Pozostało mi zatem podać link do archiwum zawierających odzyskane nagrania, archiwum zawiera wydzielone pliki WAV zawierające poszczególne poprawnie wczytujące się pliki:

*AJEK Speedy 2700 - Atar Hit Piła

A gdyby ktoś chciał się pobawić w taśmowego detektywa dodaję również zapis całej strony "B", bez żadnych cięć i manipulacji: *AJEK Speedy 2700 - Atar Hit Piła - cała strona B. Format OGG zakodowany z jakością Q10, sygnał przetrwał więc praktycznie bez strat.

Przypominam, że pliki w zawierają dwa kanały, tak jak pisałem wcześniej:

kanał L ---> sygnał zgrany z kolektora Q6
kanał R ---> sygnał zgrany z wyjścia ogranicznika (pin 8 układu LM324)

Pliki WAV można "wczytać" nawet na emulatorze, np. Altirra lub Atari800 z patchem umożliwiającym obsługę systemów Turbo od FUJI-ego: Modified atari800 emulator

Chciałbym kiedyś zobaczyć oryginalny kopier generujący tak zapisane pliki. Co prawda dysponując samym loaderem bez problemu można taki program kopiujący sobie napisać, jednak co oryginał to oryginał, po prostu kawałek historii. Pewnie przepadł bezpowrotnie w odmętach przeszłości.

Ufff.... koniec kolejnego tematu... pozostał jeden magnetofon z Blizzard Turbo, oraz jedna kaseta niespodzianka... jednak opis dotyczący kasety będzie dość długi... muszę znaleźć chwilę czasu aby to spokojnie opisać. Co prawda dane zapisane na taśmie nie przedstawiają większej wartości, jednak z historycznego punktu widzenia... no powiem wam że było to dla mnie spore zaskoczenie. Nigdy nie myślałem że jedna kaseta może tak wiele zmienić ;)

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.

Cześć!

Oj, ale tu się narobiło O_o ... prawdę mówiąc nie spodziewałem się takiego obrotu sprawy. AS czy jesteś pewien swojej decyzji?

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)

http://seban.pigwa.net/atari/Turbo2000_v3_(SONIX)/turbo_2000_v30_fancyrats_rime.jpg

^^^ Ó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":

http://seban.pigwa.net/atari/Turbo2000_v3_(SONIX)/Turbo2000_v30_(sonix).png

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!":

http://seban.pigwa.net/atari/Turbo2000_v3_(SONIX)/cart_tst_pass.png

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:

http://seban.pigwa.net/atari/Turbo2000_v3_(SONIX)/c64_vice-scr.png

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ść.

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?

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:

http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_a.jpg

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:

http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_b.jpg

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:

http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_c.jpg

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:
http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_ex1.png

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?

http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_ex2.png

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

http://seban.pigwa.net/uicr0bee/tapes/blizzard%20-%20blast%20from%20the%20past/blz_ex3.png
^^^ 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 :)

Dzień Dobry!

Mam do zaoferowania kolejne gazety, które zupełnie niepotrzebnie przeleżały zbyt dużo czasu, a teraz być może komuś się jeszcze przydadzą. Tym razem będą to "Tajemnice Atari", numery z lat 1991...1993.

Gazety są w stanie dość przyzwoitym, przeczytane kilka/kilkanaście razy, przeglądając je na szybko nie znalazłem jakichś tragicznych zniszczeń, jednak niektóre okładki naszą ślady uszkodzeń czy jakieś plamki. Przypominam zatem że te egzemplarze nie są w żadnym stopniu kolekcjonerskie, tzn. nie leżały grzecznie na półce aby pięknie wyglądać, były czytane i używane i to nie jeden raz. W najgorszym stanie są te pierwsze Tajemnice Atari, wydane jeszcze w formie składanej kartki. Przyznam że ten pierwszy numer ledwie się trzyma w całości i jest poplamiony (widać to na zdjęciu).

Gazety przeleżały te wszystkie lata na początku w mieszkaniu na regale, a potem w kartonach na regale w miejskiej suchej piwnicy, więc nie jest to spleśniałe, śmierdzące czy zagrzybione, etc. i przypominam że, to nie są numery kupowane gdzieś po aukcjach, tylko autentycznie kupione przeze mnie w tamtym czasie w kiosku, numery które oferuję to:

1991: 1,2,3,4,5,6,8
1992: 1,2,3,4,5,6-7,8,9,10,11-12
1993: 1-2,3,5,6-7,8,9,10 (brak nr 4)

Cena? Tym razem chciałbym wystawić to jako licytację, cena startowa 50zł + koszty wysyłki.
Czas licytacji no powiedzmy poniedziałek do północy (24:00)

Wysyłka? Paczkomat Inpost lub kurier Inpost.

Na koniec jeszcze zdjęcia sprzedawanych czasopism:

takron27 napisał/a:

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 ja miałem to samo, tylko w przypadku plików wygenerowanych w standardzie Blizzard. Nagrywałem na decku Technics-a. Tylko zamiast ponownego nagrywania, przełączyłem wajchę :D

takron27 napisał/a:

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.

a może jest odwrotnie? tzn. chińczyk lutuje losowo przewody do głowicy, i cześć adapterów ma odwróconą fazę, a część nie? Każdy z tych adapterów który spotkałem był w wersji "mono", nawet jak producent zapewniał że jest stereo :D A przewody przy głowicy były jak mówię lutowane "losowo".

takron27 napisał/a:

;-] 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?...

Niestety nie mam żadnego decka dwu-kasetowego, mam tylko decka Technicsa (chyba jest to RS-BX501, ale nie mam go przed oczami teraz więc pewien nie jestem), Marantz-a SD551,  oraz TASCAM-a model CD-A500. Ale nagrywałem tylko na Technics, bo do niego mam najłatwiejszy dostęp (w sensie kabli, etc.)

takron27 napisał/a:

(sory, żem się rozpisał)

i o to chodzi! oby więcej takiego pisania! Z wielką chęcią i zaciekawieniem przeczytałem opis Twojej walki i przemyślenia :)

takron27 napisał/a:

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

Albo Baktraaa testował plugin dla Blizzarda na magnetofonie z jakimś innym interface, takim który ma inną "konfigurację" fazy  i uznał że domyślna polaryzacja taką którą wybrał jest właściwa dla wszystkich interface zgodnych z Blizzard?

Trzeba też brać pod uwagę że w przypadku AST/UM czy Turbo 2000F faza chyba nie ma większego znaczenia... machałem tą wajchą gdy testowałem odczyt AST, UM i Turbo 2000F... wszystko działało w obu położeniach wajchy, dopiero przy Blizzard pojawił się problem. Przy Turbo 2000F, efekt przełączania wajchy był widoczny natychmiastowo, bo domyślny kolor ramki zmieniał się z czarnego na szary (kolor pasków ma bezpośrednie przełożenie na stan linii DATA_IN).

Zauważyłem też inną rzecz, ale to przy mocno zdegradowanych kasetach, ale to temat na następny post, jak będę pisało tych kasetach, bo zostały mi 3 szt. do "przerobienia", a wszystkie 3 szt to ciekawe przypadki :)

EDIT:

Albo napiszę od razu, bo potem zapomnę. Popatrzmy na fragment sygnału podchodzącego z bardzo zdegradowanej taśmy:

http://seban.pigwa.net/aa/degraded_tape.png

Teraz możemy wyobrazić sobie że konfiguracja sprzętu i softu jest taka że mierząc długość impulsów (aby określić czy mamy transmitowane 1 czy 0) analizujemy czas trwania pomiędzy zboczami znajdującymi się w dolnej połówce wykresu (poniżej zera). Jak widać sygnał zapisany na taśmie uległ degradacji w specyficzny sposób, tzn. wyższe częstotliwości są bardziej stłumione, w dodatku w dolnej połowie (poniżej zera) sygnał uległ większej degradacji (osłabieniu) niż w dodatniej połówce (powyżej zera)... gołym okiem widać że dekodowanie bazujące na dolnej połowie nie powiedzie się nijak, długości impulsów zostaną po prostu zaburzone przez asymetrię sygnału, gdyby jednak dekodować w tym wypadku na podstawie tylko i wyłącznie górnej połówki sygnału, to widać że mamy o wiele większe szanse na poprawne zdekodowanie sygnału.

W tym wypadku staje się zatem jasne dlaczego przełącznik służący zmianie fazy może pomóc w niektórych przypadkach przy odczycie. Ale to tylko wypadku gdy procedury odczytu dla danego systemu turbo są napisane tak że nie "szkodzi im" odwrócenie fazy sygnału o 180 stopni, a jak pokazało życie niektóre systemy nie tolerują odwrócenia fazy.

Zatem przełącznik fazy może mieć dwojakie zastosowanie, w przypadku systemów niewrażliwych na odwrócenie fazy, przełączenie przełącznika w chwili gdy mamy problem z odczytem pliku może pomóc w poprawnym odczycie, gdyż dekodowanie będzie się odbywało na drugiej połówce sygnału.

Natomiast w przypadku systemów wrażliwych na polaryzację możemy sobie odwrócić fazę w chwili gdy dostaniemy kasetę zapisaną z odwróconą polaryzacją/fazą.

@pancio.net Nie wiem czy ten interface dałby radę z Turbo6000, z wrocławskim Turbo3000 nie podołał, co mnie trochę zdziwiło, bo Blizzard jest szybkim systemem dość, więc Wrocławskie Turbo3000 powinno dawać radę na tym interface również. Dodatkowo Turbo6000 śle dane poprzez linię PROCEED, to jeszcze przełącznik we wtyczce SIO by się przydał :D

Tak samo ten interface nie chce zupełnie działać z Atari Hard Turbo. Nie wnikałem już za bardzo, tzn. magnetofon jest już skręcony i ogarnięty, więc podłączanie oscyloskopu i pomiary to przy jakiejś innej okazji, np. jak wykonam sobie ten interface oddzielnie, tak będzie mi łatwiej ;]

Jeżeli chodzi o przełącznik "fazy" to zauważyłem że pliki Blizzard wygenerowane przez Turgen wymagają przełączenia tego przełącznika SW2 w pozycję 1-2. Inaczej TOS/Loadery dla Blizzard nawet nie chcą przeczytać nazwy poprawnie. Przełączenie przełącznika "magicznie" rozwiązuje problem. W przypadku AST/UM czy Turbo2000F faza sygnału nie ma znaczenia, działa wszystko poprawnie w obu pozycjach.

Dzień Dobry Wieczór!

Po dłuższej przerwie chciałem zaprezentować jedną z ostatnich perełek/ciekawostek z pierwszej transzy magnetofonów, które zostały mi udostępnione/wypożyczone przez kolegę Uicr0Bee celem przeprowadzenia analizy i archiwizacji i przeglądu tychże, zeszło mi się z tym "trochę", ale cóż życie... wiele z obecnej partii nie zostało. Właściwie jest to przedostatnia sztuka, i chyba ostatnia dość ciekawa sztuka. Dlaczego ciekawa? Otóż...

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/XC12_HJ$_UniTurbo.jpg
^^^ mamy tutaj turbo nieznanego mi pochodzenia, nazwane HJ$ UniTurbo, a gdy przyjrzymy się bliżej naklejce:

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/XC12_HJ$_UniTurbo_label.jpg
^^^ to widzimy że magnetofon z tym systemem turbo ma możliwość współpracy z trzeba systemami Turbo: Blizzard, AST oraz Turbo 2000F/2001.

Bez zbędnych ceregieli zaglądamy do środka , aby obejrzeć płytkę interfejsu:

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/hjs_uni_turbo_pcb_top.jpg
^^^ jak to była z systemami turbo z tamtych czasów, możemy zaobserwować zaawansowane techniki maskowania, tutaj prawdopodobnie zastosowano rosyjską technologię wojskową typu "наждачная бумага", jednak takie rzeczy nie są dla nas żadną przeszkodą, prawda? :) Miał co prawda chwilę zwątpienia patrząc na tę plątaninę kabli i magnetofon leżał parę dni rozkręcony  ja nie miałem jakoś do niego ani cierpliwości ani odpowiedniego nastroju aby zabrać się za analizę.

Do tego wszystkiego wnerwiał mnie jakiś parchaty tranzystor NPN którego nie potrafiłem zidentyfikować, widniało na nim oznaczenie F1900H i widać było że to jakiś "wylut" ze sztukowanymi nogami:

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/HJ$_F1900H.jpg
^^^ pogmerałem trochę o internecie, ale jakoś nie byłem w stanie dowiedzieć się co to za osobnik, był może jestem zbyt młody i moja wiedza dotycząca półprzewodników z tamtych czasów jest po prostu znikoma.

W końcu jednak zignorowałem jegomościa i pogodziłem się z faktem że prawdopodobnie nigdy się nie dowiem co to za typ :) Wtedy też zabrałem się za rysowanie schematu... ale przed jego prezentacją zobaczmy co mamy na spodniej warstwie płytki:

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/hjs_uni_turbo_pcb_bot.jpg
^^^ o rany, ale "zamiąch" pomyślałem sobie i skorzystałem z najnowocześniejszej technologii kwantowej i dokonałem zakrzywienia czasoprzestrzeni (bazując na osiągnięciach Neo... "There is no spoon!") uzyskując coś takiego:

http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/photo/uni_turbo_pcb_matrix.jpg
^^^ użycie zaawansowanego oprogramowania do zakrzywiania czasoprzestrzeni ("GIMP") pozwoliło na spokojną analizę, bez ciągłego majtania płytką turbo z obawą że coś zaraz urwę :) jedyne co ucierpiało na napisy na scalakach które postanowiły zakrzywić się razem z czasoprzestrzenią ;-)

Przeszkadzała trochę rosyjska technologia maskowania, jednak szybki test pokazał że +5V (Vcc) idzie tylko do 14-tych wyprowadzeń tylko dwóch z trzech scalaków, a więc dwie TTL-ki i coś innego... gdy zdałem sobie sprawę że to coś innego to nie może być nic innego niż UL1111 (tak wynikało z pomiarów miernikiem na zakresie diodowym)... byłem już w domu... bo tę konstrukcję już kojarzyłem... śledząc sygnał od wejścia wiedziałem już że będzie to jakaś wersja systemu Turbo Blizzard oparta na UL1111, a w tym skojarzeniu pomógł ów F1900H, ponieważ jedna z wersji Blizzarda zawiera jako pierwszy tranzystor wejściowy właśnie oddzielny tranzystor, a pozostałe 5 szt. znajduje się wewnątrz układu UL1111. Teraz poszło już szybko i jakoś chęci do dalszego działania powróciły, a to zaowocowało szybkim narysowaniem całości układu na kartce za pomocą ołówka (gumka też się parę razy przydała :P), potem tylko musiałem znaleźć siły aby to przerysować do KiCAD-a:


http://seban.pigwa.net/uicr0bee/turbo_systems/HJ$_universal_turbo/sch/HJ$_Universal_Turbo.png
^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Dla zainteresowanych również wersja wektorowa (PDF): HJ$ UniTurbo System.

Co możemy powiedzieć o tej hybrydzie? Otóż górna część (preamp & shaper, Data Mux oraz Output Stage) to nic innego jak typowe interface Blizzard z tamtych czasów (a właściwie jedna z wersji oparta o UL1111, bo były też takie zrobione na oddzielnych tranzystorach)

Skoro jest to typowy Blizzard to jak osiągnięto zgodność z Turbo 2000F czy AST? W przypadku Turbo 2000F sprawa wygląda tak że nie ma tam żadnej automatyki która by przełączała Normal/Turbo a jest jedynie fizyczny przełącznik Normal/Turbo zamontowany w obudowie magnetofonu. W przypadku Blizzard przełączania Normal/Turbo dokonuje się zmianą stanu linii DATA_OUT, natomiast w przypadku AST przełączenie dokonujemy za pomocą linii COMMAND.

Tak więc w przypadku AST/BLIZZARD sterowanie multiplekserem odbywało się za pomocą tranzystora Q2C sterowanego przez sygnał wygenerowany przez dwie bramki NAND opisane jako "Write Combiner", jednak oprogramowanie dla Turbo 2000F/2001 nie steruje niczym licząc na to że to użytkownik przełączy magnetofon na system turbo. Co zrobił autor HJ$ UniTurbo? Za pomocą przełącznika postanowił odcinać sygnał sterujący tranzystorem Q2C co powoduje permanentne przełączenie multipleksera na system Turbo. Jednak dziwny sposób obrał autor tegoż rozwiązania, po przełączeniu przełącznika w pozycję Turbo 2000F, baza tranzystora Q2C pozostaje w powietrzu, to że ten tranzystor nie przełącza się losowo można zawdzięczać chyba tylko temu że znajduje się on wewnątrz układu scalonego i leży na wspólnym podłożu z innymi tranzystorami. Nie bardzo rozumiem czemu w pozycji Turbo2000 baza nie jest dołączana do masy. Taka konfiguracja jest jak najbardziej możliwa ponieważ w magnetofonie i tak zastosowano "przełączniki hebelkowe", które z racji budowy łączą środkowy styk z którymś ze skrajnych styków. No ale skoro działało tak jak to widać na schemacie, to zawsze jeden kabel mniej do lutowania? nieprawdaż? :)

A jak autor zapewnił zgodność tego systemu z systemami AST i jego klonami (np. ATT czy UM [Unerring Master])? W przypadku tych systemów sterownie multiplekserem przełączającym Turbo/Normal odbywało się nie za pomocą linii DATA_OUT (tak jest w przypadku Blizzard) a za pomocą linii COMMAND. Zatem autor zastosował dwie bramki NAND za pomocą których dokonuje "sumowania" sygnałów COMMAND i DATA_OUT tak że w praktyce staje się możliwe sterowanie przełączaniem multipleksera za pomoć obu tych linii. To samo dotyczy zapisu danych. Normalnie zapis w Normal, Blizzard czy Turbo 2000F jest dokonywany za pomocą "ręcznego" (czytaj programowego) sterowania linią DATA_OUT, w przypadku AST do tego celu wykorzystano linię COMMAND, także ten "sumowany" sygnał (COMMAND i DATA_OUT) jest wykorzystany również jako sygnał sterujący głowicą zapisującą.

Pozostała jeszcze kwestia drugiego przełącznika, który umożliwia wybranie fazy sygnału wyjściowego. W jednej pozycji (1-3) sygnał na wyjściu ma fazę zgodną z oryginalną konstrukcją, a więc odczyt w "normal" działa bez problemu. Natomiast w drugiej pozycji przełącznika faza sygnału wyjściowego jest odwracana o 180 stopni. Po co coś takiego? Nie zdążyłem jeszcze tego sprawdzić, ale być może jest tak że są niektóre systemy lub loadery wrażliwe na fazę sygnału, autor uznał taką funkcjonalność za pożądaną i zamontował drugi przełącznik w obudowie poczciwego CA12. Zapomniał co prawda opisać do czego ów przełącznik służy, ale po rozrysowaniu schematu wszystko stało się jasne.

No dobra, teoria teorią, a jak to wszystko ma się w praktyce? Przeprowadziłem trochę testów... ten system i ten magnetofon faktyczynie czyta bez problemu i obsługuje takie systemy jak:

- Blizzard Turbo
- AST/ATT/UM
- Turbo 2000F/2001
- Wrocławskie Turbo 2000 (nie sprawdzałem jeszcze turbo 3000)

Na jakie problemy napotkałem? Interface nie bardzo chciał czytać Atari Hard Turbo (to już drugi taki przypadek interface), nie bardzo wnikałem dlaczego, mogłem przełączyć np. przełącznik zmieniający fazę sygnału, ale gdy robiłem testy było dość późno i zupełnie o tym nie pomyślałem. Sprawdzę to jeszcze raz i gdyby się coś zmieniło w temacie to zaktualizuję ten post.

Magnetofon był dość sfatygowany, ale po odświeżeniu, wymianie paska, zrobieniu porządku w kablach i małej ich reorganizacji wszystko zaczęło śmigać, obudowa nadal jest mocno zmęczona jednak magnetofon mechanicznie wydaje się całkiem sprawny i czyta wszystko.

W przypadku tego systemu za pomocą bardzo prostych środków uzyskano system który może obsłużyć większość systemów turbo dostępnych w tamtym czasie na rynku. Dodanie dwóch bramek które pozwoliły uwzględnić sterowanie interfejsem także za pomocą linii COMMAND do interface Blizzard spowodowało powstanie ciekawej hybrydy.

A może ktoś z was spotkał się tym turbo i wie kto je montował, albo skąd pochodzi? (tzn. z jakiego regionu Polski?) Czy ktoś kojarzy kto to był "HJ$" który podpisał się pod tym system? Wszelakie wspomnienia, wskazówki lub uwagi do tego co napisałem są mile widziane :)

I to chyba wszystko co mam do powiedzenia na temat tego systemu i magnetofonu. Gdyby mi się coś przypomniało będę aktualizował ten wątek. Zawsze jest szansa że o czymś zapomniałem... :)

693

(85 odpowiedzi, napisanych Sprzęt - 8bit)

Hej!

Dzięki za linki, faktycznie fajna strona :) Ktoś wykonał masę mozolnej pracy.

Może tylko sprecyzuję swoje zdanie o 6581... jeżeli muzyka była pisana na 6581 i tylko na nim brzmi tak jak powinna (takie było zamierzenia autora), to jest jak najbardziej OK. Ale 6581 został poprawiony (i to parę razy) i tak oto mamy 8580. Ten układ traktuję jako ten najbardziej popularny i ten pod który powstało najwięcej kawałków, zatem uznałem że SlightSID będzie wspierał domyślnie właśnie ten typ układu.

Teoretycznie SlightSID da się przystosować do pracy z 6581 (zmiana kondensatorów dla filtrów oraz przestawienie przetwornicy podwyższającej napięcie z 9V na 12V). Jednak uznałem że domyślnie SlightSID będzie zmontowany tak aby pracował z 8580. Nie robiłem żadnych zworek konf. itp. uznałem to za niepotrzebne ryzyko, bo włożenie w wersję dla 6581 układu 8580 spowoduje jego zniszczenie (zbyt wysokie napięcie zasilania).

Słuchając moich ulubionych kawałków na 6581 doszedłem do wniosku że nie cierpię jego "pykania" (błąd w gen. obwiedni) oraz właśnie owych filtrów brzmiących w większości kawałków nie tak jakie było zamierzenie autora muzyki.

Dla przypomnienia jak brzmi SlightSID z dwoma SID8580R5:

1) Hokuto by Nata (stereo)
2) Melanoma Mood by Randall (stereo)
3) E.G. Blues by Hermit (stereo)
4) Driver by X-Ray (mono)
5) Cybernoid II by Jeroen Tel
6) For Avantgarde by Red Devil (mono)
7) Flimbo's Quest by R.Ouwehand & J.Bjerregaard (mono)

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

http://seban.pigwa.net/aa/AST_from_TheDistals.jpg
^^^ 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" ;-)

fancyrats_rime napisał/a:

Cart jest znajomego. Zrzuciłbym wsad gdyby był wcześniej otwierany (wkręt pod etykietą). Tak, wiem że EPROM może zdechnąć, no ale to nie moja zabawka więc jedyne czym mogę poradzić to fotki. Chyba, że istnieje nieinwazyjna metoda wykonania dumpa.

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

Z pewną obawą sięgnął po następny magnetofon z pudełka... ręce mu drżały, ponieważ nie był pewny swojej przyszłości... nie chciał również zaburzyć kontinuum czasoprzestrzennego. To mogło by się skończyć rozdzieleniem rzeczywistości na dwie niezależne ścieżki... a to mogłoby być bardzo ryzykowne! Przecież istniało spore ryzyko iż komputer kwantowy n-wymiarowej cywilizacji bawiącej się w symulacje Earth v.666 mógł tego nie wytrzymać... głupio byłoby położyć im ten projekt przez jakiś magnetofon... (ach te durne błędy w kodzie symulacji, przez niektórych zwanej "The Quantics")

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_XC12_bot.jpg

ufff... no dobra :] tym razem wam daruję... spróbuję zakończyć ten temat szybko i konkretnie. Kolejna pamięć taśmowa przerobiona na turbo, jeszcze z oryginalną plombą :) Nie jestem pewien czy to co leży przede mną to oryginał czy jakaś podróbka, nigdy nie miałem w rękach magnetofonu z turbo "Unerring Master"... a domyślam się że owe "UmEx" może oznaczać coś w stylu Unerring Master Extended?

Na tę chwilę zakładam iż tak właśnie jest, być może ktoś z was miał turbo od Unerring Master o nazwie "Atari Turbo System". Jak wieść gminna niesie, rozszerzenie to bazowało w jakiś sposób na na AST, a więc  mniej więcej wiadomo czego można się spodziewać... "Czas na rozwałkę...", eeee, stop... to nie ten kanał :P

Magia internetu sprawia że wynik rozkręcania mamy natychmiastowo:
http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_XC12_ins.jpg
^^^ oj będzie trochę czyszczenia, magnetofon trochę "zarósł kurzem".

Szybki rzut oka na płytkę:
http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_pcb_top.jpg
^^^ co my tu mamy? już widać że zamiast wzmacniacza operacyjnego µ741 zastosował układ zawierający 4 bramki NAND z wbudowanym przerzutnikiem Schmitta na wejściach. No cóż, można i tak, ale czy to rozwiązanie dobrze się sprawdzi w praktyce? Mam trochę obaw, bo poziomy na które reaguje przerzutnik w bramkach układu 74132 są ustalone przez producenta układu i nie da się ich zmienić w łatwy sposób, zapewne autor rozwiązania dostosował sygnał wejściowy do poziomów które będą pasowały panu Schmittowi, który to będzie pilnował wejść bramek :P

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_pcb_bot.jpg
^^^ szybki rzut okiem na spód płytki i można przystąpić do rysowania schematu. Wszędzie sporo przypalonej kalafonii, zarówno na płytce z interfejsem turbo jak i na płytce XC12 do których dotykał się montujący ów system. Wychodzi za na że zabrakło też kondensatorów 100nF, bo wejściowy kondensator złożono z 68nF i 47nF. Być może magnet wrócił do jakichś poprawek.

Na pierwszy rzut oka układ wygląda na mocno... jakby to napisać... no chyba trochę przekombinowany, widać że starano się niby ograniczyć liczbę układów scalonych, ale widać również że w przypadku 74132 połączono kilka bramek w szereg, a jedną zostawiono zupełnie nie podłączoną. Potem bramek zabrakło chyba, bo dołożono parę tranzystorów, ale zaraz wszystko będzie wiadomo, gdy tylko spojrzymy na schemat:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/sch/UmEx_Tubro.png
^^^ Po otwarciu obrazka w nowej zakładce będzie on zaprezentowany w wyższej rozdzielczości. Dla zainteresowanych również wersja wektorowa (PDF): UmEx Atari Turbo System

Patrząc na schemat widać że konstruktor miał jakąś odmienną koncepcję w stosunku do tego co było obecne w tamtym czasie na rynku, nie wiem co było powodem takiego działania, ale chyba nie mnie to chyba oceniać. Tak jak można było przewidzieć bramki NAND z układu 74132 tworzą układ kształtowania impulsów (ale czemu aż 3 szt. skoro używając 1 szt. dałoby się osiągnąć ten sam efekt,  pozostałe bramki można by wykorzystać w dalszej części układu). Tak jak można było przewidzieć zastosowanie bramek z układem Schmitta wymusiło ustalenie odpowiedniego ich "punktu pracy", C1/C2 odcinają składową stałą a R3 i R4 tworząc dzielnik napięciowy ustalają punkt pracy na około 1.135V (kto chce sam może to sprawdzić: Voltage Divider Calculator), lub użyć Atari BASIC:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_div_calc.png

Potem już mamy standardowe "bloki" wspólne czy to dla AST czy to dla czeskiego Turbo 2000, a jest to multiplekser umożliwiający wybór czy naw wejście DATA_IN zostanie podany standardowy sygnał FSK czy też sygnał turbo wychodzący z "ukladu kształtowanie impulsów (The Shaper)". Multiplekser został zrealizowany z 4 bramek NAND z otwartym kolektorem, tym razem jednak nie jest to 7403 jak w większości innych systemów, a 7401, który ma właściwie tylko inny układ wyprowadzeń (mogę się domyślać, że przy zastosowaniu 7401 układ ścieżek na płytce był o wiele bardziej optymalny). W tym wypadku multiplekser sterowany jest sygnałem COMMAND (tak jak w przypadku AST czy innych wcześniej opisywanych systemów turbo; Wrocławskie Turbo 2000/3000, AHT, AutoTurbo czy czeskie Turbo 2000)

Dodatkowo aby zachować pełną zgodność z AST należało jeszcze umożliwić zapis danych za pomocą tej samej linii COMMAND, autor wykorzystał dwa dodatkowe tranzystory, aby wykonać "wired OR", czyli potocznie rzecz mówiąc "sumę na drucie" ;P, umożliwiło to zapis sygnału na taśmie zarówno za pomocą linii COMMAND jak i SIO_DATA_OUT.

Zapewne dało by to się zrealizować wszytko wykorzystując bramki zawarte w 74132, ale sądzę że autor rozwiązania wybrał inne rozwiązanie aby nie komplikować zbytnio płytki drukowanej, dodatkowo rozdzielił sobie sekcje odczytu i zapisu na płytce (fizycznie znajdują się różnych obszarach/końcach płytki).

Zastanawia też zaprojektowanie układu w ten sposób że niektóre sygnały są negowane po dwa razy, dając w efekcie sygnał wejściowy... np. zastosowanie na wejściu linii COMMAND tranzystora, odwraca fazę sygnału o 180 stopni, przez co później aby przywrócić fazę do oryginalnej postaci, następuje następna negacja, tym razem na bramce NAND pracującej jako inwerter. Teoretycznie wystarczyło by po prostu doprowadzić sygnał COMMAND bezpośrednio. Nie wiem czy w ten sposób chciało osiągnąć jakiś rodzaj bufora (duża impedancja wejściowa takiego układu), czy też konstruktor miał coś innego na myśli.

Przez to wszystko schemat który narysowałem, wygląda jak wygląda... nie miałem cierpliwości tego przerysować aby było nieco bardziej czytelne, dużo sygnałów jest wspólnych dla sekcji odczytu jak i zapisu. Nieszczęsny COMMAND występuje w #n postaciach i plącze się a to tu, a to tam ;-)

Skoro już mamy schemat i mniej więcej wyrażone myśli które miałem w głowie, to co pozostało? zapomniałbym... modyfikacja toru zapisu, tak jak w innych systemach turbo zmniejszono rezystor R6, ale nie zmieniono jego wartości poprzez wylutowanie starego  i włożenie innego o mniejszej wartości (np. 4.7kΩ), do fabrycznego 10kΩ, dolutowano od spodu:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_wrt_res.jpg
^^^ no właśnie? ile? kolory są tak czytelne że można się nabawić daltonizmu... na początku myślałem że pierwszy pasek jest może niebieski... ale nie pasowało mi to do pomiarów:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_wrt_res_meas.jpg

szybka zabawa Atari BASIC i wyszło mi że...
http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_ras_par.png

^^^ to musi być jednak szary pasek, bo 8.2kΩ połączone równolegle z 10kΩ powinno dać owe ~4.5kΩ. Pomiar pokazał co prawda ~4.7kΩ, ale zwalmy to na kiepskiej jakości rezystory w dodatku o równie kiepskiej tolerancji.

To co jeszcze zostało do zaprezentowania? W magnetofonie znajdowała się taka oto kaseta:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_tape.jpg

I na jej widok bardzo się początkowo ucieszyłem, ponieważ liczyłem na jakieś super oprogramowanie systemowe... niestety bardzo się zawiodłem... i to z dwóch powodów. Po pierwsze jedyne oprogramowanie systemowe które znalazło się na tej kasecie to uniwersalny loader, który zwawiera w sobie również handler oraz test głowicy:

http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_loader1.png http://seban.pigwa.net/uicr0bee/turbo_systems/UmEx/photo/UmEx_loader2.png

Reszta "oprogramowania" zawartego na kasecie okazała się po prostu "zestawem gier" nagranych w standardzie Unerring Master:

UmEx_001 [loader].wav
UmEx_002 [River Raid].wav
UmEx_003 {World Karate].wav
UmEx_004 [Swat].wav
UmEx_005 [Pitstop II].wav
UmEx_006 [Moon Patrol].wav
UmEx_007 [Decathlon] (corrupted).wav
UmEx_008 [Tennis].wav
UmEx_009 [Kik Start].wav
UmEx_010 [Ballblaster].wav
UmEx_011 [Fantastic Soccer] (error, damaged tape).wav
UmEx_012 [Star Trek].wav
UmEx_013 [Action Biker].wav

Oczywiście zgrałem tę kasetę do postaci "audio", niestety druga zła wiadomość była taka że kaseta były miejscami mocno zmiętolona, część programów udało mi się odzyskać, niestety w miejscu gdzie był nagrany "Fantastic Soccer", zmiętolenie było tak duże że nic się nie dało zrobić ;/ (przynajmniej ja nie umiem). Wersja gry Decathlon nagrana na kasecie jest uszkodzona, tzn. gra działa, ale ma miejscami popsute niektóre elementy grafiki. Niemniej zostawiłem wszystko takie jak było nagrane na kasecie. Podzieliłem tylko obraz na poszczególne pliki .wav: UmEx Atari Turbo System Tape Dump.

Zainteresowani tematem mogą sobie te pliki nagrać albo na kasetę i wczytać na magnetofonie wyposażonym w Turbo (może być to ATT, AST, Czeskie Turbo 2000, Wrocławskie Turbo 2000 lub nawet zwykłe Turbo 2000F).

Ci który używają emulatora Altirra mogą sobie również wczytać te pliki za pomocą emulatora, włączając w opcjach emulację systemu turbo sterowanego/aktywowanego linią COMMAND.

Na koniec może parę słów podsumowania. Mając ten system na biurku postanowiłem sprawdzić jego działanie z kasetami nagranymi dla innych systemów turbo, szybkie testy pokazały że ta płytka interface pracuje jako tako z:

- Wrocławskie Turbo 2000
- Czeskie Turbo 2000
- AST

Niestety z nieznanych mi powodów loader dla systemu Atari Hard Turbo zupełnie nie radził sobie z tą płytką interface, zamiast widocznych pasków, na ekranie panowała kompletna ciemność. Nie bardzo chciało mi się wnikać dlaczego tak jest, ale widać poziom przełączania bramek w 74132 jakoś nie odpowiadał loaderowi AHT. Na początku myślałem że to wina poziomu zapisu (nagrania w AHT mam zagrane na poziomie ~0dB) jednak kaseta dołączona do tego systemu jest również nagrana ze sporym poziomem i to w dodatku na dwóch kanałach to samo (dzięki temu mimo zmiędleń taśmy udało się odtworzyć część nagrań).

aaaa... bym był zapomniał. Autor przeróbki w tym magnetofonie zrobił mały "zamiąch" i zamienił sobie kabelki we wtyczce SIO. Dodatkowym przewodem owiniętym wokół kabla magnetofonu nie idzie wcale sygnał COMMAND jak to było w poprzednich systemach turbo, a sygnał audio z kanału lewego, sygnał COMMAND został puszczony pomarańczowym kablem, którym oryginalnie szedł sobie sygnał audio z kanału lewego.

Po co wykonano taki zabieg? Nie wiem :) Może oryginalnie eliminowano sygnał audio z kasety odcinając go zupełnie i wykorzystując zwolniony w ten sposób pomarańczowy kabel do podłączenia COMMAND. Być może właściciel magnetofony wnerwiony na to że stracił podsłuch danych/przesłuchy przyszedł z reklamacją i dociągnięto mu dodatkowy kabel którym puszczono sygnał audio z lewego kanału? Teraz można tylko gdybać i dywagować :)

EDIT:

ps1) ja nie mam żadnej pewności czy to jest oryginale rozwiązanie Unerring Master czy też jakiś podrabiany klon.

ps2) nie wiem czy to wina tego magnetofonu czy tej wersji interfejsu, ale zdarzało mi się że ładowanie programów kończyło się niespodziewanie błędem (bez wyraźniej przyczyny). Nie chcę grzebać w tym i zmieniać tu czegokolwiek, więc uznałem że jak 1 na 10 ładowań pójdzie nie tak, to nie warto poświęcać "oryginalności" systemu i dłubać i zmieniać tutaj cokolwiek. Niemniej jednak czytając wcześniej forum wyrobiłem sobie jakąś taką opinię że turbo UM było całkiem fajne i stabilne. Jedno trzeba przyznać. Soft dla UM (tan na carcie) jest o 3 generacje do przodu w porównaniu do AST.

ps3) aaaa właśnie, na śmierć zapomniałem...  cart to Turbo UM: Unerring Master Super Cartridge

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:

http://seban.pigwa.net/atari/muel/Turbo2000F_MUEL.jpg
^^^ 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.

Hej!

No właśnie miałem pisać, aby w miarę możliwości wykonać dump tego carta, bo ja nawet o tym nie słyszałem.

A co do tego magnetofonu, to u mnie efekt odbioru wszystkiego (łącznie z radiem Erewań ;-P) występował też w jednym z egzemplarzy który miałem "na warsztacie" i pisałem o tym parę postów wyżej. Powodem był specyficznie uszkodzony Q6. Warto sprawdzić jeszcze kondensatory C30 i C31 (w starszych wersjach PCB dla XC12 montowane "na partyzanta", też o tym wspominałem wyżej, nawet załączyłem zdjęcie).

A gdy mi sprawiał problemy kanał lewy, czyli tor "audio" z tranzystorami Q3 i Q4, to zamieniałem je na takie o mniejszym wzmocnieniu. Inne sposoby rozwiązania problemów z tą częścią magnetofonu zaprezentował i opisał Jer na swojej stronie: Serwis Magnetofonu.

ZuluGula napisał/a:

Mozna by zrobic nowe płytki pcb do tych magnetofonów, tak jak sie to robi do komputerów. Sprzęt audio duzo wiecej zyskuje z dobrej jakości płytek oraz użytych komponentów w porównaniu ze sprzętem cyfrowym. Mozna by od razu przewidziec miejsce na jakies turbo.

No też kiedyś o tym myślałem, ale czasu na chwilę obecną brak :( trzeba by zupełnie inny rodzaj demodulatora FSK zastosować, nie taki jak w serii magnetofonów Atari oparty na filtrach aktywnych, ale taki nazwijmy to "cyfrowy", z podwajaniem częstotliwości lub oparty o PLL, tak aby wyciągał bez problemu większe prędkości transmisji FSK, w domyśle nawet Turbo2600. A co do klasycznego Turbo opartego na PWM to już byłaby jedynie formalność ;-)

takron27 napisał/a:

ja przy kso-t2000 nigdy nie ruszałem C4, nie wywalałem ani nie zmniejszałem nawet. i gra. tak więc i tu nie ma raczej potrzeby skoro to taki sam 'format danych/zapisu'.

Ja też początkowo miałem C4 zostawiony na miejscu, ale potem jak przyszło Turbo2000F i zacząłem eksperymentować z odczytem innych systemów turbo, usunięcie C4 zdecydowanie pomogło, tzn. w takim sensie że mogłem czytać wyższe prędkości transmisji. Z usuniętym C4 daje się czytać Wrocławskie Turbo 3000, co jest niewykonalne z włożonym C64 (sprawdzone empirycznie).

Jak pisałem już wyżej, miałem w rękach magnetofony z Turbo 2000F z usuniętym C4, z jakich powodów? nie wiem. Jest oczywiście tak jak pisałeś, tzn. do odczytu formatu Turbo 2000 (czy to KSO czy F) nie jest potrzebne "gmeranie" przy C4.

Co do czeskiej przeróbki do której link załączyłeś, ciekawym "mykiem" jest to że wykorzystuje się przewód którym normalnie leci audio jako linię COMMAND, co prawda traci się chyba podsłuch audio z kanału lewego, ale za to nie trzeba plątać dodatkowego przewodu wokół oryginalnego kabla. Natomiast patrząc na to jak dalece ta wersja interface ingeruje w tor odczytu, to chyba wolę klasyczną wersję opartą o 741 i 7403. Być może jestem w błędzie i te modyfikacje nie niosą ze sobą pogorszenia stabilności demodulatora FSK (taki żarcik, bo czy da się to jeszcze bardziej zepsuć? ;P), ale nigdy jeszcze na tą wersję turbo nie trafiłem i nie mam doświadczenia w tej kwestii. Nigdy też nie znalazłem czasu aby wykonać tę wersję przeróbki.

tOri napisał/a:

Masz seban zacięcie :) A w sumie dzięki Twojej pracy postawię kiedyś jeden z magnetofonów "na nogi"

No mam taką nadzieję! Ten wątek tworzę z takim wręcz uporem maniaka, właśnie po to aby zmotywować innych do odratowania swoich magnetofonów i przywrócenia ich dawnej świetności :) Sam przecież wszystkich magnetofonów nie uratuje :) Fizycznie po prostu nie dam rady :D

Do kompletu ma to zapewne jakąś wartość historyczną, może być tak że ten sprzęt bezpowrotnie przepadnie, a jakiś obraz z przeszłości zostanie w tym wątku uchwycony i być może nawet przetrwa w odmętach sieci.