Cześć!

Prawdę mówiąc to mam mieszane odczucia... bo jeden z joyów po naprawie działa nieco gorzej niż drugi ... i nie wiem czy to dlatego że jeden z wydruków wyszedł gorzej czy też dlatego że był bardziej "męczony", zaraz po wymianie oba sprawowały się znakomicie ... a po jakimś czasie jeden z nich zaczął wyraźnie "mulić", tzn. czuję że wymaga większego wkładu siły aby dany kierunek załapał, szczególne odczuwalne są "skosy".

Potem czasu na hobby ubyło i nie miałem okazji więcej srogo męczyć tych joyów, a że nadarzyła się okazja i tanio dorwałem oryginał (CX-40) to przesiadłem się na niego. Po jakimś czasie RZóG podrzucił mi do testów obecnie produkowany CX-40+ ... i początkowo myślałem że ten CX-40+ zupełnie nie będzie mi leżał, bo zamiast blaszek ma po prostu klasyczne rozwiązanie oparte o "gumki przewodzące"... ale koniec końców spodobało mi  się to na tyle że obecnie używam właśnie CX-40+, a tamte chińskie produkty gniją gdzieś na dole szuflady... więc testy wytrzymałościowe na razie zostały odłożone... ale być może przy najbliższej partyjce Megablast-a czy Joust-a może wezmę je na warsztat ponownie.

CX40+ w środku wygląda tak (zdjęcie dzięki uprzejmości RZóG):

2nd test: uploaded material: 1920x1080p@50Hz, H264 codec (encoder: ffmpeg + vaapi)

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

[info] Available formats for vcvdYA6xjFI:
ID  EXT   RESOLUTION FPS CH │   FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR ASR MORE INFO
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                  mhtml │ images                                  storyboard
sb2 mhtml 56x45        0    │                  mhtml │ images                                  storyboard
sb1 mhtml 112x90       0    │                  mhtml │ images                                  storyboard
sb0 mhtml 225x180      0    │                  mhtml │ images                                  storyboard
233 mp4   audio only        │                  m3u8  │ audio only          unknown             [en] Default
234 mp4   audio only        │                  m3u8  │ audio only          unknown             [en] Default
139 m4a   audio only      2 │    2.58MiB   49k https │ audio only          mp4a.40.5   49k 22k [en] low, m4a_dash
140 m4a   audio only      2 │    6.84MiB  129k https │ audio only          mp4a.40.2  129k 44k [en] medium, m4a_dash
251 webm  audio only      2 │    5.26MiB  100k https │ audio only          opus       100k 48k [en] medium, webm_dash
269 mp4   180x144     25    │ ~  7.81MiB  144k m3u8  │ avc1.4D400B    144k video only
160 mp4   180x144     25    │    4.09MiB   77k https │ avc1.4D400B     77k video only          144p, mp4_dash
603 mp4   180x144     25    │ ~  6.47MiB  120k m3u8  │ vp09.00.11.08  120k video only
278 webm  180x144     25    │    3.10MiB   59k https │ vp09.00.11.08   59k video only          144p, webm_dash
229 mp4   300x240     25    │ ~ 13.66MiB  253k m3u8  │ avc1.4D400D    253k video only
133 mp4   300x240     25    │    9.10MiB  172k https │ avc1.4D400D    172k video only          240p, mp4_dash
604 mp4   300x240     25    │ ~ 10.54MiB  195k m3u8  │ vp09.00.20.08  195k video only
242 webm  300x240     25    │    6.49MiB  123k https │ vp09.00.20.08  123k video only          240p, webm_dash
230 mp4   450x360     25    │ ~ 31.63MiB  585k m3u8  │ avc1.4D4015    585k video only
134 mp4   450x360     25    │   18.75MiB  355k https │ avc1.4D4015    355k video only          360p, mp4_dash
18  mp4   450x360     25  2 │   23.59MiB  447k https │ avc1.42001E         mp4a.40.2       44k [en] 360p
605 mp4   450x360     25    │ ~ 20.59MiB  381k m3u8  │ vp09.00.21.08  381k video only
243 webm  450x360     25    │   10.68MiB  202k https │ vp09.00.21.08  202k video only          360p, webm_dash
231 mp4   600x480     25    │ ~ 53.18MiB  983k m3u8  │ avc1.4D401E    983k video only
135 mp4   600x480     25    │   38.28MiB  725k https │ avc1.4D401E    725k video only          480p, mp4_dash
606 mp4   600x480     25    │ ~ 30.01MiB  555k m3u8  │ vp09.00.30.08  555k video only
244 webm  600x480     25    │   18.46MiB  350k https │ vp09.00.30.08  350k video only          480p, webm_dash
22  mp4   900x720     25  2 │ ≈ 61.08MiB 1129k https │ avc1.64001F         mp4a.40.2       44k [en] 720p
136 mp4   900x720     25    │   52.87MiB 1002k https │ avc1.64001f   1002k video only          720p, mp4_dash
247 webm  900x720     25    │   30.15MiB  571k https │ vp9            571k video only          720p, webm_dash
311 mp4   900x720     50    │ ~107.71MiB 1992k m3u8  │ avc1.640020   1992k video only
298 mp4   900x720     50    │   76.57MiB 1451k https │ avc1.640020   1451k video only          720p50, mp4_dash
612 mp4   900x720     50    │ ~ 73.49MiB 1359k m3u8  │ vp09.00.40.08 1359k video only
302 webm  900x720     50    │   50.65MiB  960k https │ vp09.00.40.08  960k video only          720p50, webm_dash
312 mp4   1350x1080   50    │ ~134.03MiB 2478k m3u8  │ avc1.64002A   2478k video only
299 mp4   1350x1080   50    │   99.27MiB 1881k https │ avc1.64002A   1881k video only          1080p50, mp4_dash
617 mp4   1350x1080   50    │ ~105.89MiB 1958k m3u8  │ vp09.00.41.08 1958k video only
303 webm  1350x1080   50    │   76.02MiB 1440k https │ vp09.00.41.08 1440k video only          1080p50, webm_dash
623 mp4   1800x1440   50    │ ~249.54MiB 4615k m3u8  │ vp09.00.50.08 4615k video only
308 webm  1800x1440   50    │  181.44MiB 3437k https │ vp09.00.50.08 3437k video only          1440p50, webm_dash

^^^ o! a jednak coś się zmieniło od czasu moich ostatnich eksperymentów, nie dość że dostałem teraz 50fps, to jeszcze VP9 mi się trafiło. Jak pisałem wcześniej pod koniec 2023 roku, wrzucając taki materiał nie dostałem ani VP9 ani 50fps. Niestety poziomy scroll szarpie od czasu do czasu mimo że odświeżanie monitora ustawione jest na 50Hz.

Hej!

@dely: To może inaczej i bardziej szczegółowo... jak wrzucasz stream na YT to ten generuje masę dodatkowych strumieni różnej jakości, np. to wideo które dałeś jako przykład (sf_oDFk93EI) jest dostępne w następujących formatach:

[info] Available formats for sf_oDFk93EI:
ID  EXT   RESOLUTION FPS CH │    FILESIZE   TBR PROTO │ VCODEC          VBR ACODEC      ABR ASR MORE INFO
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────
sb3 mhtml 48x27        0    │                   mhtml │ images                                  storyboard
sb2 mhtml 80x45        0    │                   mhtml │ images                                  storyboard
sb1 mhtml 160x90       0    │                   mhtml │ images                                  storyboard
sb0 mhtml 320x180      0    │                   mhtml │ images                                  storyboard
233 mp4   audio only        │                   m3u8  │ audio only          unknown             Default
234 mp4   audio only        │                   m3u8  │ audio only          unknown             Default
599 m4a   audio only      2 │    11.78MiB   31k https │ audio only          mp4a.40.5   31k 22k ultralow, m4a_dash
600 webm  audio only      2 │    12.49MiB   33k https │ audio only          opus        33k 48k ultralow, webm_dash
139 m4a   audio only      2 │    18.67MiB   49k https │ audio only          mp4a.40.5   49k 22k low, m4a_dash
249 webm  audio only      2 │    18.51MiB   48k https │ audio only          opus        48k 48k low, webm_dash
250 webm  audio only      2 │    24.25MiB   63k https │ audio only          opus        63k 48k low, webm_dash
140 m4a   audio only      2 │    49.55MiB  129k https │ audio only          mp4a.40.2  129k 44k medium, m4a_dash
251 webm  audio only      2 │    47.80MiB  125k https │ audio only          opus       125k 48k medium, webm_dash
597 mp4   256x144     15    │    13.40MiB   35k https │ avc1.4d400b     35k video only          144p, mp4_dash
602 mp4   256x144     15    │ ~  46.12MiB  118k m3u8  │ vp09.00.10.08  118k video only
598 webm  256x144     15    │    13.55MiB   35k https │ vp9             35k video only          144p, webm_dash
269 mp4   256x144     30    │ ~  80.04MiB  204k m3u8  │ avc1.4D400C    204k video only
160 mp4   256x144     30    │    37.66MiB   98k https │ avc1.4D400C     98k video only          144p, mp4_dash
603 mp4   256x144     30    │ ~  81.10MiB  207k m3u8  │ vp09.00.11.08  207k video only
278 webm  256x144     30    │    41.11MiB  107k https │ vp09.00.11.08  107k video only          144p, webm_dash
229 mp4   426x240     30    │ ~ 137.19MiB  350k m3u8  │ avc1.4D4015    350k video only
133 mp4   426x240     30    │    87.92MiB  230k https │ avc1.4D4015    230k video only          240p, mp4_dash
604 mp4   426x240     30    │ ~ 143.77MiB  367k m3u8  │ vp09.00.20.08  367k video only
242 webm  426x240     30    │    83.39MiB  218k https │ vp09.00.20.08  218k video only          240p, webm_dash
230 mp4   640x360     30    │ ~ 300.40MiB  767k m3u8  │ avc1.4D401E    767k video only
134 mp4   640x360     30    │   191.08MiB  499k https │ avc1.4D401E    499k video only          360p, mp4_dash
18  mp4   640x360     30  2 │   228.57MiB  597k https │ avc1.42001E         mp4a.40.2       44k 360p
605 mp4   640x360     30    │ ~ 269.82MiB  689k m3u8  │ vp09.00.21.08  689k video only
243 webm  640x360     30    │   146.51MiB  383k https │ vp09.00.21.08  383k video only          360p, webm_dash
231 mp4   854x480     30    │ ~ 549.71MiB 1403k m3u8  │ avc1.4D401F   1403k video only
135 mp4   854x480     30    │   375.30MiB  981k https │ avc1.4D401F    981k video only          480p, mp4_dash
606 mp4   854x480     30    │ ~ 441.89MiB 1128k m3u8  │ vp09.00.30.08 1128k video only
244 webm  854x480     30    │   258.67MiB  676k https │ vp09.00.30.08  676k video only          480p, webm_dash
22  mp4   1280x720    30  2 │ ≈ 833.23MiB 2126k https │ avc1.64001F         mp4a.40.2       44k 720p
136 mp4   1280x720    30    │   764.61MiB 1998k https │ avc1.64001f   1998k video only          720p, mp4_dash
247 webm  1280x720    30    │   477.62MiB 1248k https │ vp9           1248k video only          720p, webm_dash
311 mp4   1280x720    60    │ ~   1.53GiB 3995k m3u8  │ avc1.640020   3995k video only
298 mp4   1280x720    60    │     1.12GiB 2988k https │ avc1.640020   2988k video only          720p60, mp4_dash
612 mp4   1280x720    60    │ ~   1.56GiB 4088k m3u8  │ vp09.00.40.08 4088k video only
302 webm  1280x720    60    │  1023.48MiB 2674k https │ vp09.00.40.08 2674k video only          720p60, webm_dash
312 mp4   1920x1080   60    │ ~   2.64GiB 6910k m3u8  │ avc1.64002A   6910k video only
299 mp4   1920x1080   60    │     2.07GiB 5547k https │ avc1.64002A   5547k video only          1080p60, mp4_dash
617 mp4   1920x1080   60    │ ~   2.36GiB 6175k m3u8  │ vp09.00.41.08 6175k video only
303 webm  1920x1080   60    │     1.63GiB 4356k https │ vp09.00.41.08 4356k video only          1080p60, webm_dash

te wszystkie strumienie są generowane na podstawie jednego wrzucanego video. Ilość formatów które YT generuje i ich jakość zależy od kilku czynników, od rozdzielczości materiału czy FPS-ów źródłowego jak najbardziej, ale ilość generowanych streamów zależy również od tego ilu subskrybentów i jak bardzo oglądany jest dany kanał.

Do niedawna było tak że wrzucało się 1080p@50Hz i taki strumień dołaczał również YT generowanych przez siebie streamach. Ja z moją bliską zeru ilością subskrybentów, a w dodatku z filmami "niepublicznymi", dostawałem początkowo 50fps gdy uploadowałem materiały w rozdzielczości 1080p@50Hz, potem YT zmieniło politykę i okazało się że 1080p@50/60Hz dla takich "pikusiów" jak ja jest niedostępne. Jednym ze sposobów ominięcia tego ograniczenia było przeskalowanie materiału do 2048x1152, dopiero wtedy dostawałem kodek VP9@50Hz. W innym przypadku zrzucali mnie do h264(avc1) i 25fps. Tak było jeszcze w grudniu 2023, ale być może znowu się coś zmieniło sprawdzę.

Dodam tylko że nie zależało to od kodeka... bo używałem robiłem upload w h264, h265, vp8, vp9, av1. Nie miało to żadnego znaczenia.

Jako użytkownik który wrzuca filmy na których nie da się "zarobić" (czytaj wyświetlić reklam) jestem dla YT czystą stratą więc próbują mnie ograniczać jak mogą, przynajmniej tak mi się wydaje. Zrobię zaraz dodatkowy test i wrzucę jeden z .MKV które wrzucałem wyżej i zobaczymy co mi YT z tego zrobi.

Hej!

Chwilę mi to zajęło aby to dobrze zgrać, ale się udało. Z tym że aby to obejrzeć w płynności są wymagane pewne wymagania, których pewnie nie spałełni większa część forumowiczów. Skracając i upraszczając wszystko:

1) Poniższe filmy nagrane są z częstotliwością 49.86Hz (dokładnie taką jaką generuje Atari 8-bit)
2) Aby uzyskać w 100% płynne odtwarzanie trzeba mieć monitor refresh rate ustawiony na 50Hz (lub mieć monitor z freesync i player który to ogarnie)
3) pliki są umieszczone w kontenerze .MKV w środku kontenera video w formacie h.264
4) niektóre pliki mają na początku zniekształcone audio, spowodowane jest to faktem iż zapomniałem wyłączyć AGC (ARW) w graberze i ten starał się wyciągnąć coś z ciszy która panowała przy wczytywaniu/dekompresji niektórych produkcji (nie chciało mi się tego ponownie zgrywać)

do pobrania:

• Drunk Chessboard

• Equation of Time

• Eugenia

• Five to Five

• Ilusia

• MemoPad 480i

• Oczopląs Faraona

• Our 5oft - Unity Part

• Overmind - disk #1

• Qlkee

• Revenge of Magnus

• Recycle!

• Rigolletto

• Shake!

• Visdom II demo

"boldem" zaznaczyłem te produkcje w których występują wizualne artefakty.

a) Out 5oft - Unity Part - błędne kolory przy nałożeniu się PMG na grafikę w trybie GTIA
b) Revenge of Magnus - tło z grafiki PMG nad wszystkim sinus scroll w Hi-Res, ale jak widać na załączonym filmie grafika PMG drży (zły timing przy zmienianiu X-POS obiektów PMG)
c) Visdom II demo - w przypadku efektu przesuwających się prostokątów w trybach 9/10 widać że w trybie 10 brak przesunięcia o cykl koloru pomiędzy trybem 9/10.

Zapewne będzie problem z trymami HIP/TIP/RIP (nie sprawdzałem tego jeszcze). Ale sądzę że autor rozwiązania poprawi to. Muszę tylko jeszcze zgrać referencyjne materiały z użyciem RetroTink 2x z wyjścia normalnego GTIA.

ps) pliki leżą na pigwie, na YT nie da się tego wrzucić tak aby YT nie zrobił z tego sieczki (YT robi konwersję/rekompresję materiału przy wrzucaniu materiałów na ich serwery). Wszystkie te pliki zajmują około ~1GB, mogą się pojawić jakieś artefakty kompresji h.264, ale starałem się aby bitrate materiału był dość wysoki.

Z Twojego opisu wynika iż posiadasz Turbo 2000F/2001.

Soft do tego turbo w postaci .XEX był chociażby w tym poście: Turbo 2000F CMD & Phase Select Patch v.1.2. Wersję .XEX możesz załadować z dowolnego urządzenia I/O (SIO2PC, SIC! Cart, AVG Cart, SDRIVE, SIO2SD, etc.).

Jeżeli chciałbyś zbudować sobie cart albo uruchomić jako emulowany cart z poziomu np. AVG Cart to tutaj masz zawartość pamięci EPROM: Turbo 2001 v.2.1 Cartridge

@willy: spoko nic się przecież nie stało! nie ma za co przepraszać! Przecież spokojnie sobie wymieniamy poglądy i dyskutujemy. Mi też chwilę zajęło zanim zrozumiałem po co i dlaczego c0pperDragon wymyślił sobie owe "lumacode", jak już załapałem i wiedziałem jaki obraz potrafi generować RGB2HDMI to nie mogłem się doczekać aż zobaczę to na własne oczy. Na szczęście RZóG-owi udało się to kupić gdy tylko się pojawiło w sklepie i miałem możliwość przetestowania tego rozwiązania.

A co do Twojego rozwiązania, faktycznie teraz pamiętam jak o tym pisałeś... ale przyznam szczerze, wtedy sądziłem że używając FIQ będzie ciężko to  samplować precyzyjnie beż żadnego dodatkowego sprzętowego FIFO... chyba koniec końców doszedłeś do podobnych wniosków i porzuciłeś projekt?

W przypadku RGB2HDMI mają dodatkowe CPLD które umożliwia samplowanie z rozdzielczością chyba coś około 10ns. Nie dokopałem się chyba nigdy (nie miałem potrzeby) jak dalej przenoszą ten sygnał, ale gdzieś coś mi mignęło w użwają do tego celu GPU z maliny... nie wiem tylko jak, ew. źle zrozumiałem co co kiedyś przeczytałem i mogę bredzić :)

@alex: ale wiesz że link do repo który zapodałeś to tylko taki dev-board z MAX10 (od Altera/Intel) + transceiver HDMI i nic poza tym? tam nie nic poza upscalerem na FPGA, to jest platforma testowa na której c0pperdragon sobie robił development i test dla danej platformy. Albo jestem ślepy albo nie widzę nic poza tym co zostało napisane w readme: D-Video board - Read Me. Reasumując nie ma tam żadnego kodu HDL-owego który by cokolwiek czytał z GTIA czy magistrali danych JIL. Ale może jestem ślepy i nie widzę?

@grzybson: ależ to żaden offtopic! dzięki za info! 

Ja mogę dodać tylko że c0opperDragon zrobił również "ULA Digitizer", można go znaleźć również w jego sklepie Tindie. Nie podaję linków aby nie było że coś reklamuję i promuje, każdy możne znaleźć na własną rękę. Jeżeli chodzi o "ULAdigitizer" to nie testowałem tego i za mało znam się na ZX spectrum więc trudno mi się nawet na ten temat wypowiedzieć.

Ale nawiązując do tematu który poruszyłeś, to podobny projekt (w sensie użycia RPi Pico) o nazwie GTIA2DVI powstaje dla Atari: https://github.com/maaakit/GTIA2DVI.  Człowiek o pseudonimie "markit" zaprezentował go na AoL w tym wątku: GTIA2DVI.

Ja się bardzo cieszę że jest tyle możliwości do wyboru i w dodatku że MarkIt zrobił ten projekt w pełni otwarty! (Open Hardware/Software). Takich projektów nam potrzeba na scenie! :)

Wrzucę filmy to sam zobaczysz (ew. wpadnij do mnie i sam się przekonaj). Dlaczego sądzę że to emulacja GTIA? Bo np. kolory które wychodzą z nałożenia się grafiki PMG na "playfield" (w bardzo konkretnych przypadkach) wychodzą inaczej niż w przypadku bezpośredniego wyjścia z GITA, albo pozycje obiektów PMG np. w przypadku pierwszej części "Revenge of Magnus" (sinus scroll w hi-res + tło na PMG w górnej połowie ekranu) potrafią być inne niż w przypadku wyjścia z GTIA... efekt jest taki że obraz gwiazdek w tle jest poprzesuwany albo wręcz pozycje obiektów drżą o jedną linię skaningową.

Sądzę że autorowi prościej było wykonać emulację GTIA niż bawić się z precyzyjnym dekodowaniem sygnału "COLOR" z czym jak widać problem ma również autor projektu GTIA2DVI.

C0pperdragon ma doświadczenie w te klocki, a świadczą o tym chociażby jego pozostałe projekty (chociażby pełna emulacja VIC-II z wyjściem RGB, etc.). Mam również VIC-II digitizer, ale przyznaję że jeszcze nie zdążyłem go przetestować.

Samego RGB2HDMI używałem również z innymi maszynami i byłem bardzo zadowolony z rezultatów, jak tylko zobaczyłem że
c0pperdragon wypuścił pierwsze wersje swoich digitizerów z "lumacode" to od razu postanowiłem to przetestować. Czekam jeszcze na TIA digitizer i na pewno nie omieszkam zamieścić tutaj swoich doświadczeń z tymże również.

Jeden myk jest fajny z tym lumacode, tak jak pisał autor używa on 2-bitów do opisania stanu wyjścia/linii transmisyjnej... a więc mamy 4 możliwe stany do zakodowania na jednym drucie, całość protokołu pomyślana jest tak że tworzy on sygnał zbliżony do analogowego sygnału video (jeden ze stanów ma poziom "sync", pozostałe 3 stany służą do enkodowania transmitowanych bitów luminancji i chrominancji... a to powoduje że jak taki sygnał lumacode podepniesz do czegoś dekodującego composite video to widać obraz, co prawda nie jest to odwzorowanie właściwe, ale możesz dzięki temu zobaczyć że "digitizer" działa, oto przykład wyjścia z digitizera podpięty do "RetroTink 2x":

ekran Atari BASIC:

intro do gry Ballblazer:

a tutaj przykładowy "atari control picture", wyjście z GTIA_digitizera podpięte do RGB2HDMI:

screen z dema "Equation of Time / Our 5oft", w odpalonym menu RGB2HDMI:

Dzięki RZóG-owi mam to w rękach od jakiegoś czasu. Obraz wygląda super, ale są niewielkie błędy w emulacji GTIA (bo FPGA na płytce "GTIA Digitizer" emuluje GTIA. Miałem pisać o tym wcześniej, ale nie miałem zgranych jeszcze filmów aby pokazać jak to wygląda. Postaram się nagrać video aby było można ocenić samemu, dodam tylko że samo RGB2HMI oparte na PiZero z wyjściem HDMI generuje idealny obraz, w dodatku pixel perfect i ultra smooth. Cały pomysł z LumaCode jest świetny. Mam w rękach kilka rozwiązań:

1) S-Video + RetroTink 2x
2) GBS-8200 + VBXE + GBS Control
3) OSSC + VBXE 1.x
4) RGB2HDMI + GTIADigitizer

W chwili obecnej mogę powiedzieć tyle że jeżeli autor rozwiązania poprawi emulację GTIA to będzie to najbardziej odpowiadające mi rozwiązanie.

pozostałe rozwiązania preferuję w następującej kolejności:

1) S-Video + RetroTink 2x
2) VBXE + OSSC
3) VBXE + GBS-8200 z GBS control

poniżej fotki zarówno płytki GTIA digitizer jak RGB2HDMI wraz z Pi-Zero:

wysłałem e-mail via forum, piszę czysto informacyjnie gdyby miał nie dotrzeć :)

Hej!

Miałem wcześniej o tym napisać, ale zawsze jakoś pojawiały się inne tematy i zapominałem o tym napisać... Zacznę od tego że ja nie znając innych rozwiązań w tamtym czasie, obcowałem tylko z KSO Turbo 2000 i Turbo 2000F i miałem zupełnie przeciwne doświadczenia do Twoich, tzn. bardzo duża kompatybilność tegoż systemu z różnymi narzędziami które pracowały ze stacją dysków, masa użytków które działały pod DOS ze stacją dysków,  działała "od pierwszego strzału" i to bez żadnych przeróbek! Wszelakie programy kopiujące, edytory tekstu, assemblery (w tym niegdyś mój ulubiony MAC/65), przykładów mógłbym mnożyć wiele...

Natomiast jeżeli chodzi o wczytywanie gier to zaraz nawiążę do tego problemu, ale może na początek zapytam, którego softu do obsługi turbo używałeś? Pytam bo prosty podział jest na dwie wersje... jedne z wersji Turbo 2000F/2001 lokowały się pod OS-ROM, a drugie z wersji lokowały się od $0700. KSO Turbo 2000 (Joy Port) spotkałem tylko wersję lokującą się nisko (od $700).

Dlaczego o tym piszę? A już tłumaczę... gdy weźmiesz pod uwagę wersje plikowe gier które były dostępne w tamtych czasach na giełdzie były to gry które często ładowały się bardzo nisko w pamięć, albo takie które to ładowały swoje porcje danych pod OS-ROM, były również takie pozycje które zarówno ładowały się nisko i podczas ładowania umieszczały dane pod OS-ROM komputera.

Teraz zapewne rozumiesz co się działo jeżeli próbowałeś ładować grę która niszczyła jakiś konkretny obszar pamięci podczas wczytywania? Należy również mieć świadomość że w przypadku Turbo 2000F/KSO standardowy blok danych ma rozmiar 3072 bajty, więc pomimo kodu obsługującego system/handler turbo, należało w pamięci mieć miejsce na 3kB bufor przechowujący dane aktualnie wczytywanego rekordu danych.

Tak więc do wyboru miałeś albo KSO/Turbo2000F wersji która miała MEMLO na poziomie ~$1A00, albo wersję która lokowała się co prawda od OS-ROM i jej MEMLO było co prawda na poziomie $800 ale za to zajęta była część przestrzeni pod OS-ROM. Rozwiązań tego problemu było kilka... pominę na razie sprawę loaderów L1 czy L2, bo to była taka proteza raczej niż dobrze napisane loadery. Nie pamiętam już dokładnie co robił L1, ale L2 o ile dobrze pamiętam po prostu relokował sobie ów 3kB bufor na rekord danych pod OS-ROM i dzięki temu obniżał MEMLO 3kB

Przyznam że znając te "ograniczenia" systemu od podszewki to jeżeli z jakąś gra był problem to początkowo sobie albo ją modyfikowałem tak aby wczytywała mi się bez problemów (starałem się nie korzystać z loaderów L1 czy L2), potem ktoś z giełdy poprosił mnie o przerobienie loaderów L1, L2 tak aby bufor danych umieszczały banku dodatkowej pamięci, a jeszcze później zrobiłem sobie cart który oprócz pamięci EPROM miał w sobie 8KB RAM mapowane w $8000-$9FFF i ten dodatkowy RAM wykorzystywałem jako bufor na rekord danych wczytanych z taśmy, więc problem niejako rozwiązał się sam, ale to rozwiązanie przestałem szybko rozwijać bo na horyzoncie pojawiła się możliwość posiadania stacji dysków TOMS 720. Jak czas pozwoli do odkopię moje stare zapiski i przeszukam kartony i może uda się to wyrwać z odmętów przeszłości.

Ale jakie było rozwiązanie dla "szarych" użytkowników? Jednym z rozwiązań było przepuszczenie opornej gry przez jakiś cruncher... w późniejszym czasie mógł być to np. Cruncher 2.69, Cruncher 4.64 czy potem Cruncher 5.0 od Magnusa. Te crunchery co prawda zmieniały strukturę oryginalnego pliku ale za to generowały wyjściowy plik który nie wymagał niskiego MEMLO do wczytania programu.

Natomiast przed nastaniem ery Cruncher-ów powstał jeszcze tzw. "NEW FORMAT" czyli inny format zapisu danych, nie podzielony na rekordy jak standardowy format "Turbo 2000F/KSO", format ten charakteryzował się tym że poszczególne bloki danych ładowały się konkretne/docelowe miejsca pamięci, przez co procedura ładująca mogła być prosta i krótka a do tego nie było potrzebne miejsce na bufor który przechowywałby aktualnie wczytywany rekord danych.

Handlarze giełdowi umieszczali na swoich taśmach/zestawach nagrania w formacie "Speedy 2700", który to był nieco efektywniejszą odmianą "nowego formatu" Turbo 2001.

Należy oczywiście pamiętać ze format danych Turbo 2000F/KSO jest tak naprawdę tym co zaproponował pan Wojciech Zabołotny w swoim systemie Turbo 2T06 i większość softu do cartów czy też ładowanych z taśmy tzw. "KOS-ów" (Kasetowy System Operacyjny) dla Turbo 2000F/KSO jest pochodną bazującą na pracy wykonanej przez W.Zabołotnego.

Część rozwiązań w tym systemie ma swoje pewne ograniczenia i wady, jednak w owym czasie nie pamiętam abym był specjalnie przejęty ograniczeniami tegoż systemu... byłem naprawdę bardzo z niego zadowolony. Mogłem bez problemu użwać chociażby Turbo Basic XL, MAC/65 czy też sporej masy innych narzędzi które nie były przewidziane do pracy z taśmą. A jednak działały bez problemu.

Ładowanie gier które wymagały niskiego MEMLO było jakimś tam wyzwaniem, ale przyznam że dzięki temu bardzo szybko zgłębiłem zarówno tajniki działania tegoż systemu jak i też techniki stosowane przez osoby wykonujące wersje plikowe gier.

Zdaje sobie oczywiście sprawę że na pewno jestem dość mocno "spolaryzowany" jeżeli chodzi preferowanie tego rozwiązania... ale z drugiej strony patrząc na to ile walki musiałem podjąć np. w celu wykonania jakichś dumpów kaset zapisanych w Blizzard czy innych systemach, to w moim przypadku kasety zapisane w Turbo 2000F/KSO szły o wiele lepiej i szybciej ... no chyba że to były nagrania zapisane w Speedy 2700 z którymi to już musiałem się nieco więcej użerać. Być może moje odczucie "łatwiejszego" przetwarzania kaset nagranych w Turbo 2000F/KSO wynika własnie z tego że długo obcowałem z tym systemem w przeszłości i podświadomie omijam pułapki zastawione na mnie przez upływ czasu i starzejące się taśmy.

Znowu wyszedł mi jakiś koszmarnie długi post... a miało być krótko i konkretnie... ale ja chyba tak nie potrafię... miałem co prawda jeszcze kilka myśli i wątków do rozwinięcia, ale prawdę mówiąc tyle razy już zboczyłem z tematu głównego że nie pamiętam o czym chciałem jeszcze napisać. Jak mi się przypomni to nie omieszkam dopisać/uzupełnić.

Dzień dobry!

W dniu dzisiejszym pozwolę sobie powrócić do tematu “The Eidolon”, a powodem do powrotu do tego tematu były ostatnie posty szanownego kolegi Piguły, w których walczył on z kolejnymi taśmami przybyłymi z przeszłości i napotkał on na nich obraz tejże gry, tym razem wersji przeznaczonej dla systemu KSO Turbo 2000, a więc wersji turbo bazującej na transmisji danych z wykorzystaniem interfejsu podłączanego do drugiego portu joysticka.

Tę wersję opracował niejaki “*AJEK”, bazując na wersji zrobionej przez ludzi z “Unerring Masters”, dla która to zaistniała wcześniej na tym forum jako nagranie znajdujące się za zestawie nr. 4 firmy Empex z Łodzi. Podczas prób odtworzenia tamtej wersji okazało się że co prawda udało się poprawnie zdekodować nagrania, ale niestety okazało się również że tamtej wersji brakuje plików z poziomu ósmego gry, zatem mimo usilnych prób przywrócenia tej pozycji wszystkie wysiłki rozbiły się o brak końcowych fragmentów nagrania.

Gdy teraz okazało się że pojawiła się inna wersja tejże pozycji, tym razem przygotowana przez *AJKA pojawiła się nadzieja że tym razem uda się odtworzyć całość! Tym bardziej że wersja *AJKOWA bazowała na wersji od “Unerring Masters”.  Usiadłem więc do roboty i podjąłem kilka prób konwersji nagrań dostarczonych przez Pigułę… niestety część bloków na taśmie okazała się uszkodzona w sposób uniemożliwiający poprawne odtworzenie wszystkich uszkodzonych bloków. Siedząc i analizując rekordy, zastępując część z nich (tych w których sygnał zanikał do takich poziomów które uniemożliwiały dekodowanie) “połatałem” i poskładałem to w całość.

Przyszedł zatem czas na końcowe testy i nie przypuszczając jeszcze co mnie czeka, zabrałem się ochoczo do testów… po dłuższej chwili zabaw we wczytywanie kolejnych poziomów dotarło do mnie że *AJKOWA wersja jest również niekompletna i zabawa kończy się na poziomie szóstym! Normalnie się zagotowałem… tyle walki na nic? Mogę dokleić co prawda brakujące bloki z wersji “UM”, ale i tak będzie brakowało końcowych plików! Myślałem że przysłowiowy szlag mnie trafi… tyle walki i roboty na nic? Prawie pogodziłem się porażką i pomyślałem że opiszę sprawę na forum i być może za jakiś czas ktoś znajdzie kasetę w pełną wersją tejże gry zawierającej wszystkie pliki i jakimś cudem udostępni jej zawartość.

Zacząłem się zastanawiać jakie jednak są szanse na taki obrót sytuacji, stwierdziłem że dość niewielkie. Spokoju jednak mi to nie dawało bo ta wersja gry sygnowana przez “Unerring Masters”, była wersją która nie wymagała żadnej dodatkowej pamięci, a do jej wczytania wystarczało jedynie 64kB RAM. Zacząłem się zastanawiać jak wygląda wersja dyskowa tejże gry i czy nie dałoby się wyłuskać z niej brakujących plików i wygenerować je w formacie których oczekuje loader. Za długo nie myśląc, gdy tylko znalazłem chwilę wolnego czasu zacząłem analizować zawartość obrazu dyskietki z grą. Zastanawiałem się czy gra używa jakichś wyrafinowanych struktur jeżeli chodzi przechowywanie danych poszczególnych poziomów gry.

Jakież było moje zdziwienie gdy przeglądając hex-edytorem zawartość pliku .ATR z obrazem gry natrafiłem na prawie normalne wpisy w miejscu gdzie powinien się znajdować katalog dysku w formacie DOS 2.0:

xxd -g1 -seek 0xb410 -l 0x280 "Eidolon, The v1.1 (1985)(Epyx)(US).atr"
0000b410: 60 01 00 01 00 20 20 20 20 54 68 65 20 20 20 20  `....    The    
0000b420: 60 02 00 02 00 20 20 45 69 64 6f 6c 6f 6e 20 20  `....  Eidolon  
0000b430: 60 03 00 03 00 76 65 72 73 69 6f 6e 20 31 2e 31  `....version 1.1
0000b440: 60 04 00 04 00 20 43 6f 70 79 72 69 67 68 74 20  `.... Copyright
0000b450: 60 05 00 05 00 20 20 20 31 39 38 35 20 20 20 20  `....   1985    
0000b460: 60 06 00 06 00 20 4c 75 63 61 73 66 69 6c 6d 20  `.... Lucasfilm
0000b470: 60 07 00 07 00 20 4c 74 64 2e 20 35 30 39 31 39  `.... Ltd. 50919
0000b480: 00 43 61 76 65 61 74 20 50 65 69 72 61 6e 21 21  .Caveat Peiran!!
0000b490: 42 0b 00 d7 00 50 41 4e 45 4c 20 20 20 53 43 52  B....PANEL   SCR
0000b4a0: 42 09 00 e2 00 54 49 54 4c 45 20 20 20 53 43 52  B....TITLE   SCR
0000b4b0: 42 03 00 eb 00 4c 45 56 45 4c 31 20 20 4d 41 50  B....LEVEL1  MAP
0000b4c0: 42 03 00 ee 00 4c 45 56 45 4c 32 20 20 4d 41 50  B....LEVEL2  MAP
0000b4d0: 42 03 00 f1 00 4c 45 56 45 4c 33 20 20 4d 41 50  B....LEVEL3  MAP
0000b4e0: 42 03 00 f4 00 4c 45 56 45 4c 34 20 20 4d 41 50  B....LEVEL4  MAP
0000b4f0: 42 03 00 f7 00 4c 45 56 45 4c 35 20 20 4d 41 50  B....LEVEL5  MAP
0000b500: 42 03 00 fa 00 4c 45 56 45 4c 36 20 20 4d 41 50  B....LEVEL6  MAP
0000b510: 42 03 00 fd 00 4c 45 56 45 4c 37 20 20 4d 41 50  B....LEVEL7  MAP
0000b520: 42 03 00 00 01 4c 45 56 45 4c 38 20 20 4d 41 50  B....LEVEL8  MAP
0000b530: 42 11 00 03 01 44 52 41 47 4f 4e 31 20 43 45 4c  B....DRAGON1 CEL
0000b540: 42 1a 00 14 01 44 52 41 47 4f 4e 32 20 43 45 4c  B....DRAGON2 CEL
0000b550: 42 14 00 2e 01 44 52 41 47 4f 4e 33 20 43 45 4c  B....DRAGON3 CEL
0000b560: 42 1c 00 42 01 44 52 41 47 4f 4e 34 20 43 45 4c  B..B.DRAGON4 CEL
0000b570: 42 1b 00 5e 01 44 52 41 47 4f 4e 35 20 43 45 4c  B..^.DRAGON5 CEL
0000b580: 42 19 00 82 01 44 52 41 47 4f 4e 36 20 43 45 4c  B....DRAGON6 CEL
0000b590: 42 14 00 9b 01 44 52 41 47 4f 4e 37 20 43 45 4c  B....DRAGON7 CEL
0000b5a0: 42 1e 00 af 01 44 52 41 47 4f 4e 38 20 43 45 4c  B....DRAGON8 CEL
0000b5b0: 42 0f 00 cd 01 44 52 41 47 4f 4e 38 41 43 45 4c  B....DRAGON8ACEL
0000b5c0: 42 10 00 dc 01 44 52 41 47 4f 4e 38 42 43 45 4c  B....DRAGON8BCEL
0000b5d0: 42 10 00 ec 01 44 52 41 47 4f 4e 38 43 43 45 4c  B....DRAGON8CCEL
0000b5e0: 42 1c 00 fc 01 42 49 46 46 20 20 20 20 43 45 4c  B....BIFF    CEL
0000b5f0: 42 1c 00 18 02 42 4e 45 43 4b 20 20 20 43 45 4c  B....BNECK   CEL
0000b600: 42 1d 00 34 02 47 52 45 50 20 20 20 20 43 45 4c  B..4.GREP    CEL
0000b610: 42 18 00 51 02 4d 41 4c 4c 4f 43 20 20 43 45 4c  B..Q.MALLOC  CEL
0000b620: 42 1b 00 69 02 50 4f 4c 59 50 53 20 20 43 45 4c  B..i.POLYPS  CEL
0000b630: 42 10 00 84 02 50 55 46 46 20 20 20 20 43 45 4c  B....PUFF    CEL
0000b640: 42 08 00 94 02 52 4f 54 4f 46 4c 59 20 43 45 4c  B....ROTOFLY CEL
0000b650: 42 17 00 9c 02 54 52 4f 4c 4c 20 20 20 43 45 4c  B....TROLL   CEL
0000b660: 42 0f 00 b3 02 42 42 49 52 44 20 20 20 43 45 4c  B....BBIRD   CEL
0000b670: 80 0e 00 c2 02 4d 49 53 20 20 20 20 20 43 45 4c  .....MIS     CEL
0000b680: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

… gdy ujrzałem tę strukturę katalogu przyznam że pojawił się w mojej głowie pewien promyk nadziei. Sprawdziłem na szybko czy aby na pewno wpisy znajdujące się w katalogu mają odzwierciedlenie w rzeczywistości i czy na pewno wskazują na poprawne pliki umieszczone na dysku. Okazało się że faktycznie da się te pliki bezproblemowo odczytać za pomocą DOS-a czy też dowolnego narzędzia do ekstrakcji plików umieszczonych w obrazie ATR, aby jednak taka operacja była możliwa i aby “DOS” czy inne narzędzie widziały całą strukturę wpisów należy podmienić bajt znajdujący się pod offsetem 0xb480 na wartość np. 0x60, tak aby DOS czy inne narzędzie nie uznawały że to ostatni wpis w katalogu dysku. Po tej operacji możemy listować już zawartość dysku a także skopiować wybrane pliki.

Teraz przyszedł czas na zastanowienie się jak wygląda wczytywanie przez grę poszczególnych plików, tzn. jak wygląda struktura danego poziomu i gdzie w kodzie gry określone jest jakich plików potrzebuje dany poziom do poprawnego działania. Oczywiście patrząc na strukturę katalogów można domyśleć się iż do każdego poziomu przypisany jest jeden ze smoków (pliki od “dragon1.cel” do “dragon8.cel”), przy czym widać że ostatni smok przeciwnik składa się wielu segmentów (dragon8.cel, dragon8a.cel, dragon8b.cel, dragon8b.cel). Można się domyśleć że pliki: “biff.cel”, “bneck.cel”, “grep.cel” … “rotofly.cel”, opisują wygląd poszczególnych przeciwników spotykanych podczas eksploracji jaskiń na kolejnych poziomach gry, jasne również staje się co reprezentują pliki z końcówką “.scr” oraz pliki “level1.map”. Przyszło mi do głowy że każdy z plików opisujących poziom (*.map_ powinien mieć w informację również o przeciwnikach i ich wyglądzie zawartą w sobie, zatem moja uwaga skierowała się na plik “LEVEL8.MAP”, i patrząc na wpis w katalogu dotyczący pliku “LEVEL8.MAP” widzimy:

0000b520: 42 03 00 00 01 4c 45 56 45 4c 38 20 20 4d 41 50  B....LEVEL8  MAP

Analizując ten wpis widzimy że plik zaczyna się od sektora 256 i ma długość 3 sektorów, zatem zaglądamy we wskazane sektory:

xxd -g1 -seek 0x8010 -l 0x180 "Eidolon, The v1.1 (1985)(Epyx)(US).atr"
00008010: 00 80 00 00 00 e3 00 e2 80 e0 80 80 80 e0 80 e2  ................
00008020: 00 e3 00 00 00 80 00 40 00 40 00 40 00 40 00 80  .......@.@.@.@..
00008030: 00 80 00 00 00 e3 00 e2 80 e0 80 80 80 e0 80 e2  ................
00008040: 00 e3 00 00 00 80 00 80 00 00 00 40 00 00 00 80  ...........@....
00008050: 00 80 00 00 00 80 80 80 80 f3 00 80 00 f3 80 80  ................
00008060: 80 80 00 00 00 00 00 00 00 00 00 80 00 00 00 00  ................
00008070: 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00  ................
00008080: 00 00 00 00 00 00 00 00 00 00 00 80 00 45 02 7d  .............E.}
00008090: 00 00 00 00 00 00 44 52 41 47 4f 4e 38 20 43 45  ......DRAGON8 CE
000080a0: 4c 44 52 41 47 4f 4e 38 41 43 45 4c 44 52 41 47  LDRAGON8ACELDRAG
000080b0: 4f 4e 38 42 43 45 4c 44 52 41 47 4f 4e 38 43 43  ON8BCELDRAGON8CC
000080c0: 45 4c 18 c8 c8 c8 c8 08 0a 00 00 08 00 0c 00 00  EL..............
000080d0: a0 ff 54 c6 c6 c6 c6 88 84 03 00 00 b8 08 04 04  ..T.............
000080e0: 04 04 04 06 08 0a 40 40 40 40 00 00 00 00 00 00  ......@@@@......
000080f0: 00 00 00 00 00 ff 00 00 ff 80 e0 80 e2 00 e3 00  ................
00008100: 00 00 80 00 80 00 40 00 40 00 40 00 40 44 00 69  ......@.@.@.@D.i
00008110: 38 08 2b 0f 7f 0d 1b 7f 0d fa 00 02 4d 52 57 fa  8.+.........MRW.
00008120: c9 17 59 92 bc fa dd f8 f4 f0 f2 fa f4 ba 38 8c  ..Y...........8.
00008130: 09 60 06 ff fa ea fa 07 00 01 02 02 03 04 00 04  .`..............
00008140: e3 05 0d 00 05 05 06 07 08 00 09 0a 0b 0b 0c 0c  ................
00008150: 0d 5f 4a 06 9a 9a aa ba ca da ea 46 e0 01 4e e0  ._J........F..N.
00008160: 13 4e 02 03 0e 10 4c 02 04 0f 11 4c 0a 14 16 19  .N....L....L....
00008170: 18 05 02 08 09 0a 0b 0d 44 02 07 15 17 52 03 07  ........D....R..
00008180: 24 fe 1f 41 c1 e2 fd a3 e4 f1 ea c5 e9 49 04 7d  $..A.........I.}

… no i wszystko stało się jasne! Plik .MAP opisujący poziom zawiera w środku informacje o plikach które są konieczne do wczytania przed uruchomieniem danego poziomu. Szybka analiza rekordów danych nagranych na taśmie pozwoliła mi ustalić że na taśmie brakuje ostatniego pliku “DRAGON8C.CEL”.

Teraz pozostało tylko skopiować z obrazu dyskietki plik “DRAGON8C.CEL” i spróbować zakodować go w taki sposób aby loader wczytujące poszczególne bloki gry poprawnie wczytał ów plik, a przy odrobinie szczęścia mogło się okazać że jeżeli ta operacja skończy się sukcesem to będziemy dysponowali kompletnym odtworzonym obrazem gry. Szanse na powodzenie niewielkie, jednak warto było spróbować.

Jak się do tego zabrać? Ponieważ pracujemy na plikach .HEX opisujących strukturę nagrania w sposób czytelny dla człowieka, a nagrane na taśmę bloki są zgodne ze standardem AST to wystarczyło napisać prosty skrypt kodujący dany plik jako ciąg liczb hex, dodać to tego segment “PWMD” zawierające odpowiednie długości impulsów, na końcu tego całego ciągu danych dodać sumę kontrolną XOR i jeżeli wszystko będzie się zgadzało to loader gry powinien wczytać brakujący plik bez błędu.

Klepiąc parę skryptów w Pythonie (do konwersji danych, liczenia sumy kontrolnej, etc.) udało mi się tę operację przeprowadzić w miarę bezproblemowo. Brakujące segmenty danych dodałem do pliku .hex zawierającego AJKOWĄ wersję gry… i podczas przejścia na ósmy poziom gry okazało się że loader poprawnie wczytał brakujący plik! :) Poziom ósmy wystartował bez problemu! Jakaż była moja radość gdy okazało się że te wszystkie operacje wykonane wcześniej przyniosły oczekiwany skutek.

Postanowiłem również poprawić zatem wcześniejszą wersję przeznaczoną dla turbo AST/UM. Na początku myślałem że loader ładujące poszczególne segmenty danych znajduje się w segmencie danych który pokazuje czołówkę informującą że tę wersję gry opracował “Unerring Masters”, podmieniłem więc tylko początkowe segmenty, tak aby zostały tylko jak mi się wydawało rekordy zawierające loadery dla systemu AST/UM, jednak moja radość nie trwała długo, ponieważ okazało się że loader danych został umieszczony w głównym segmencie danych zawierającego kod gry (blok danych o długości 24705 bajtów), zatem należało przenieść również ten długi blok z wersji dla AST/UM.

W tym jednak momencie zacząłem się zastanawiać czy aby na pewno skonwertowany wtedy przeze mnie plik był na pewno dobrze przetworzony, miałem wątpliwości ponieważ nagranie było dość wiekowe i miejscami trudno było poprawnie przetworzyć niektóre bloki danych, jednak teraz pojawiła się możliwość porównania obu plików, tzn. wersji AJKOWEJ i wersji UM, postanowiłem dokonać takiego porównania, w różnice powinny były tylko występować w obrębie loadera, gdyż wersja dla “KSO Turbo 2000”, dokonywała odczytu używając odwołań do PORTA ($D300) a wersja AST/UM będzie oczekiwać danych z portu SIO, a dokładniej rzecz biorąc z rejestru $D20F (bit #4 który to odwzorowuje stan wejścia SIO_DATA_IN).

Problem w tym że pierwsze dwa główne bloki gry (czołówka “Lucasfilm” oraz główny kod gry) były zakodowane inaczej niż pozostałe bloki gry odczytywane przez loader. Bloki ładowane w trakcie gry zapisano w standardzie AST, natomiast dwa pierwsze bloki posiadały inny początkowy ton synchronizujący, a długości impulsów były zgodne z Turbo 2000, z tym że kolejność bitów w bajcie była kodowana odwrotnie (LSB first) niż w przypadku KSO Turbo 2000 (MSB first). Moja wcześniejsza próba konwersji nie była doskonała, ponieważ mając świadomość iż użycie a8cas-util.pl z wymuszeniem formatu Turbo 2000 i sumą kontrolą XOR, pozostawiła w strukturze bloku PWMD bajty z odwróconymi bitami, a jako że nie przeszkadzało we wczytywaniu danych, to ten blok zostawiłem w takim stanie. Chcąc jednak porównać teraz zawartość obu plików należało doprowadzić ten segment danych do porządku. Kolejny skrypt w python i szybko udało się przetworzyć wcześniej skonwertowany segment danych, niestety okazało się że przy poprzedniej konwersji oprócz odwrócenia bitów w bajtach całość danych została przesunięta o jeden bit w lewo (konwersja i dekodowanie przez a8cas-util.pl było przeprowadzone nie na tym zboczu sygnału które trzeba) … blah… a więc kolejny skrypt i dane zostały przesunięte o jeden bit w prawo. Można było więc porównać zawartość obu segmentów danych (AJEK vs AST/UM). Kolejny skrypt to porównania danych, XOR aby zobaczyć ew. różnice w bitach i okazało się że mam dużo przekłamań na najstarszych bitach niektórych bajtów… ehhh.

Okazało się że przesunięcie nie przeszkadzało procedurom ładującym dane pod emulatorem, gdyż procedury ładujące dane pod emulatorem miały inne zależności czasowe i one dekodowały sygnał generowany ze strumienia PWMD nieco później, przez co dekodowanie następowało nieco później i to się nawet poprawnie wczytywało.

Co należało więc zrobić… ponownie dokonać konwersji tego bloku, niestety u mnie źródłowy plik .FLAC/.WAV się nie zachował, na szczęście Piguła pozostawiał ten plik w  udostępnionych przez siebie zasobach. Pobrałem plik źródłowy jeszcze raz, wysłuskałem blok który mnie interesował i spróbowałem innego podejścia… początkowo chciałem napisać własny dekoder do tego typu danych jednak po paru eksperymentach z “a8cas-util.pl” udalo się poprawnie zdekodować ten blok danych używając następujących parametrów:

./a8cas-util.pl conv -t lowsil2000 --cksum xor eidolon.blk2.um.wav eidolon.blk2.um.hex

Okazało się że długości impulsów używane w przypadku “Wrocławskiego Turbo 2000” są w miarę zgodne z blokami danych zapisanych w formacie UM, jedynie sposób liczenia sumy kontrolnej się zmienia na XOR. Oczywiście po takiej konwersji kolejność bitów w bajcie jest odwrócona, ale tę sprawę można załatwić dodatkowym skryptem.

Tutaj jeszcze jedna uwaga, Piguła udostępnił zgraną taśmę z próbkowaniem 48KHz (to bardzo dobrze), jednak z jakiegoś powodu a8cas-util, nie radził sobie z tym nagraniem próbkowanym z tą częstotliwością, w tym wypadku konwersja z 48kHz do 44.1kHz pomogła a8cas-util uporać się z dekodowaniem bez najmniejszego problemu.

Pewnie niektórzy z was zastanawiają się po co ja to wszystko opisuje, robię to po to aby opisując swoje doświadczenia zostawić coś w rodzaju poradnika i sposobów postępowania, gdyby ktoś kiedyś zechciał odzyskiwać jakieś nagrania odnaleziona na taśmach.

Wracając do moich zewnętrznych prymitywnych "skrypcików" w python, to ja zdaje sobie sprawę że te wszystkie operacje pewnie dałoby się dopisać do a8cas-util.pl, ale ja kompletnie nie znam się na PERL-u w którym to “a8cas-util.pl” jest napisany. Prościej i szybciej jest mi posługiwać się narzędziami czy językami które znam. A pisanie jednorazowych prymitywnych skryptów przy użyciu chociażby Pythona jest po prostu dla mnie szybsze i efektywniejsze, niźli dłubanie w PERL czy też pisanie tony kodu w C.

Także wracając do głównego wątku, po konwersji tego bloku i porównaniu z AJKOWĄ wersją różnice w plikach występowały tylko i wyłącznie w kodzie loadera, który to czytał z innego portu, w tym momencie mogłem być pewien że blok główny blok danych jest poprawnie zdekodowany. Koniec końców można było przygotować finalne wersje plików .HEX oraz .CAS. Przygotowane pliki sprawdziłem pod zmodyfikowaną przez FUJI-ego wersją atari800 (wsparcie dla systemów turbo). Wszystkie poziomy się wczytują poprawnie zarówno w wersji AST/UM jak i tej przygotowanej przez AJKA. Wspomniane pliki dodaję jako załącznik tego posta i kończę ten jak zwykle przydługi swój wywód.

Miałem napisać jeszcze o dwóch rzeczach… gdy loader gry wykryje błąd to na ekranie pokaże się typowa "atarowska tęcza", po cofnięciu taśmy i wciśnięciu START odczyt zostanie ponowiony. Jeżeli zakończymy grę (ostatni ósmy poziom) to gra będzie chciał wczytać ponownie pierwszy poziom, w tym wypadku należy przewinąć taśmę do tego miejsca, albo przesunąć się w obrazie taśmy w emulatorze do 23 bloku (dane poziomu pierwszego zaczynają się właśnie od tego bloku danych).

Drugą sprawą jest to że zastanawiało mnie dlaczego dwa pierwsze bloki nagrano w formacie UM a resztę niejako w formacie zgodnym AST? (różnica w początkowych tonach sync) … początkowo wydało mi się że zabieg ten był celowy i miał za zadnie chronić przed wczytaniem bloku z grą zamiast danych poziomu (np. gdy użytkownik przewinie taśmę zbyt daleko w tył) … ale nie wiem czy to był rzeczywisty powód zastosowania rekordów w różnych formatach. Być może powodem było coś innego.

W sumie to nie sądziłem że zabawa z tym “The Eidolon” zajmie mi tyle czasu, a po drugie nie sądziłem że mnie to wciągnie na tyle że dociągnę ten temat do końca, sam nie wiem czemu się tak zawziąłem, ale każda kolejna przeszkoda która się pojawiała powodowała że bardziej chciałem sprawę doprowadzić do szczęśliwego finału, tym razem się udało, ale nie wiem czy będę miał jeszcze kiedykolwiek tyle cierpliwości ;)