26

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

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:

http://seban.pigwa.net/aa/gtia_digitizer/gtia_digitizer_1.jpg

http://seban.pigwa.net/aa/gtia_digitizer/gtia_digitizer_2.jpg

http://seban.pigwa.net/aa/gtia_digitizer/rgb2hdmi_1.jpg

http://seban.pigwa.net/aa/gtia_digitizer/rgb2hdmi_2.jpg

27

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

Cześć!

Dzięki za poświęcony czas i wykrycie błędu na schemacie, już wiem gdzie zrobiłem błąd, tzn. jaki był powód powstanie tego błędu, zamysł miałem dobry tylko coś musiało mi przerwać pracę i po powrocie do rysowania schematu zapomniałem co robiłem i stąd błąd który zauważyłeś. Poprawię niebawem i zaktualizuję pliki. Dodane do listy "to do".

Generalnie linia idąca do pinów 4,5 bramki powinna być opisana etykietą ~RST (NOT RST) i podpięta do pinu 13 bramki NAND przerzutnika RS stworzonego z bramek NAND, a sygnał RST powinien iść tylko do wejść resetujących licznik 7490. I taki był zamysł, tzn. aby etykieta przy pinie 13 bramki miała symbol ~RST.

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

Hej!

Jeżeli brałbyś pod uwagę możliwość wysyłki (np. paczkomat Inpost) to byłbym zainteresowany dyskami Caviar 2540 oraz Caviar 31600. Mogę zaoferować 100zł za oba dyski, jeżeli to dla Ciebie uczciwa cena daj znać.

pozdrawiam
Seban

Hej!

Piguła/Shpoon napisał/a:

Natomiast mnie po zgrywaniu kilkunastu kaset w Turbo2000 w oparciu o magnetofon z T2001 lub T2000f - ten system turbo mocno rozczarował mała kompatybilnością. Masa softu do małego Atari (szczególnie tego, który powstał na finiszu 8bitowego Atari w latach 90 z tym systemem działa słabo. Są problemy, aby go uruchomić z poziomu jakiegokolwiek loadera.

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

W archiwum są dwie wersje. Jedna dla magnetofonów z turbo UM/AST/Turbo2000F (odczyt danych przez port SIO) ... druga wersja przerobiona przez AJKA tak aby czytała z portu JOY-a. Myślę że jeżeli chodzi o wersję sygnowaną przez UM to raczej nie pytanie do galtrona a raczej to Piotra Janiszowskiego, który był założycielem firmy UM. Galtron specjalizował się montażu/serwisie czyli bardziej tematy sprzętowe niźli software.

A co do niepełnej wersji gry to pewnie tak została ona nagrana na kasecie firmy Empex... wersja AJKA też pewnie była pełna, zapewne pośrednicy podczas kopiowania tychże nagrań doprowadzili do braku kilku plików. Nie mamy dostępu do oryginalnych wersji więc składamy i odzyskujemy z tego co mamy. Ale skoro w obecnych czasach trudno o kasety z tamtych czasów to należy robić co się da aby odzyskać takie perełki.

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 ;)

rzuciłem okiem na twój eidolon hex... no to na pewno nie jest poprawna konwersja niestety, normalnie jest tam 37 albo 38 bloków danych, w Twojej wersji tych bloków występuje chyba 421... tzn. a8cas-util.pl nie bardzo radzi z konwersją nagrań o mizernej jakości, w dodatku bardzo chętnie konwertuje takie pliki pisząc ze wszystko jest OK, tak jak wspominałem wcześniej sprzyja ku temu sposób wyznaczania sumy kontrolnej bloku (XOR) a w dodatku chyba konwerter nie oczekuje tonu synchronizującego o minimalnej długośći przed rozpoczęciem danego bloku danych i ochoczo dzieli wszystko na bloki o mniejszej długości (co jest zachowaniem niepoprawnym).

ace.hex wygląda lepiej a nie przyglądałem mu się zbyt długo, zostawię sobie to na później. Spróbuje też ponownie siąść do tego "the eidolon", ale przydał by się lepszej jakości dump (w sensie zgrany z lepszym ustawieniem głowicy). Ja do takich akcji używam starego prymitywnego decka w którym nie szkoda mi kręcić głowicą jeżeli wiem że źródłowa taśma była nagrana z innym skosem niż "fabryczny".

Coś mi się chyba przypomina że gdzieś wcześniej wrzucałeś pliki tego "the eidolon" w formacie UM? czy się mylę i pamięć płata mi figle?

ehhh.... zrobił się double post.... to dopiszę w tym drugim jeszcze kilka słów o strukturze tego nagrania.

Pierwszym blokiem danych nagranym w standardowym formacie Turbo 2000 jest loader zawierający procedury ładowania dla turbo UM przerobione tak aby czytały dane z portu JOY-a, a po drugie zmienione tak aby reagowały na długości impulsów adekwatne dla Turbo 2000/KSO. Nie wiem co to miało na celu... bo dwa następne bloki są blokami nagranymi w formacie Turbo UM, tyle że długości impulsów kodujących 1 i 0 są zmienione tak aby pasowały tym które występują w Turbo 2000/KSO. W dodatku turbo UM w przeciwieństwie do KSO koduje bity w bajcie w odwrotnej kolejności, tzn. LSB first. Tak więc blok nazwy i blok zawierający loader w pliku hex, mają odwrócone bity w bajtach bo a8cas-util.pl nie daje możlwiości wymuszenia kodowania lsb_first czy msb_first i dokonuje wyboru na podstawie formatu określonego w parametrach, tzn. opcja "-t turbo2000" wymusza kodowanie msb_first. Można oczywiście sobie odwrócić wartości tych bajtów jakimś prostym skryptem.

Pierwszym blokiem jest blok nazwy, drugi blok to blok zawierający główny loader ładujący pozostałą część nagrania, ten blok jest ładowany od adres $400.

Pozostałe bloki danych są już nagrane w formacie AST tak jak wspominał wcześniej Piguła.

Wracam na chwilę do "The Eidolon"...  loader udało mi się wyłuskać z tego nagrania poprawnie, przynajmniej tak mi się wydaje (w załączniku do tego następnego posta plik .hex zawierający ów loader).

Natomiast z konwersją części AST mam problem... tzn. udaje niby mi się dokonać konwersji... ale mimo że a8cas-util.pl mówi że wszystko jest OK, to w/g mnie wcale tak nie jest (np. zmieniając parametry konwersji uzyskuję różną liczbę bloków wyjściowych) ... powodem takiego zachowania jest to że AST ma prymitywny mechanizm obliczania sumy kontrolnej bazujący na XOR ;-/ tak naprawdę przy tak długich blokach danych trudno mieć pewność dane są poprawne.

Przy moich próbach konwersji bloków AST udaje się maksymalnie wczytać 2-3 poziomy, potem mam błąd odczytu sygnalizowany poprzez cało ekranowe kolor-bary. Piguła, pisałeś że Tobie się udaje konwertować te bloki AST bez problemu... może jak połączysz mojego hex-a zawierającego loader z Twoją konwersją bloków AST to wyjdzie z tego coś sensownego.

Niestety jakość nagrania jest dość kiepska, tzn. wysokie częstotliwości dość słabo się zachowały na kasecie, albo kaseta była nagrywana na magnetofonie ze źle ustawionym skosem głowicy, stąd problem z wyższymi częstotliwościami:

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

Hej!

Piguła/Shpoon napisał/a:

Za wyjątkiem 3 pierwszych pozycji ze strony A. Jest tam rozwiązanie mieszane Turbo2000 + AST. gra The Eidolon, Ace of Aces oraz MULE.

Rzuciłem "na szybko" okiem na pierwszą pozycję, wygląda na to że loader obsługuje tylko turbo podpinane do drugiego portu JOY-a... w weekend postaram się znaleźć trochę wolnego czasu i spróbuję się temu przyjrzeć dokładniej i dokonać konwersji do CAS (mam nadzieję że się da).

Piguła/Shpoon napisał/a:

Obrobiłem zestaw 18 Studia Spark w T2000

Dzięki WIELKIE! :) Już pobieram i wrzucam do swojego domowego archiwum!

Hejka!

Czyli mam rozumieć że już nie muszę szukać? :D

38

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

Ja również bardzo dziękuję! Sprzęt super!

39

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

OK, czyli wychodzi na to że w pełni "padło na mnie" ;-) ... odezwę się na priv.

40

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

podbijam do 200 za PC.

41

(11 odpowiedzi, napisanych Kupię / Sprzedam / Zamienię pozostałe)

Hej!

To ja może zacznę

1) compaq - 100 zł
2) składak - 100 zł

42

(114 odpowiedzi, napisanych Software, Gry - 8bit)

@VLX: przyjrzałem się trochę temu dyskowemu wydaniu Crumbles Crisis, akurat miałem do przećwiczenia parę koncepcji i pomysłów, toteż dzięki temu dało dodać trainer w miarę niewielkim nakładem pracy (w załączniku tego posta wersja dyskietkowa z trainerem). Robiłem ją z obrazu .ATX zawierającego grę oryginalnie wydaną w UK przez Red Rat Software.

Przy okazji przyjrzałem się plikom i dochodzę do wniosku że z użyciem kompresji dało by się zrobić wersję file mieszczącą się w 64kB ze wszystkimi poziomami, i gdyby nie kompilowany BASIC to już bym działał... ale przy kompilowanym BASIC-u to trzeba by zastosować inne podejście i napisać sobie taki handler I/O który dane by zasysał z ram i dekompresował w locie wszystko. Trochę więcej upierdliwej roboty... ale to może kiedyś, bo teraz nie mam ani czasu, ani cierpliwości aby z tym walczyć ;) Zresztą gdy pograłem w inne poziomy tejże gry to mnie to tylko bardziej zniechęciło... do tej pory sądziłem że pierwszy poziom jest upierdliwie trudny, ale porównując go do następnych, to ten pierwszy to bardzo prosty jest ;P

43

(114 odpowiedzi, napisanych Software, Gry - 8bit)

małe info: postanowiłem się przyjrzeć "Crumble's Crisis", wiedziałem że to kompilowany BASIC, ale nie z takimi rzeczami człowiek walczył jak był młody :P grzebiąc w tym "skompilowanym chaosie", udało mi się zrobić "unlimited energy", więc zacząłem sobie grać w wersję plikową (zrobioną przez Tomasza Rolewskiego) ... ale po przejściu pierwszego poziomu okazało się że gra jest owszem w postaci plikowej, jednak zawiera tylko pierwszy poziom i po jego zakończeniu wracamy ponownie do poziomu pierwszego.

W sumie to się kiedyś zastanawiałem jak te wszystkie poziomy udało się T.R. upchnąć w pamięci i własnie poznałem odpowiedź :D Nie udało się, wersja plikowa jest okrojona... w sumie T.R. uznał chyba że gra jest na tyle trudna/nudna/monotonna że nikt i tak nie przejdzie pierwszego poziomu i taka okrojona wersja plikowa w zupełności wystarczy, a nawet jak ktoś zakończy poziom pierwszy to się jedyne wnerwi na autora gry że to jakaś porażka że po przejściu całego labiryntu i pozbieraniu wszystkich "fuzzies" zaczynamy od nowa ;-)

T.R. robiąc wersję plikową "Crumble's Crisis" poszedł drogą stworzenia w pamięci takiego nazwijmy to "mini" ram-dysku, w którym trzyma pliki doczytywane przez grę, jednak nie zrobił on jednego urządzenia powiedzmy "R:" z którego gra czyta pliki, a zastosował nieco odmienne podejście, mianowicie stworzył on listę urządzeń "A, B, G, H, I, J". Każdy z tych handlerów udostępnia jeden plik gry (obrazek, fonty, mapę, etc.). W kodzie gry podmieniono nazwę urządzenia "D:" z której gra oryginalnie czytała pliki (używając nazwy pliku), na inne urządzenia (A-J), więc gra odwołując się do G: zawsze dostanie plik "CRUMBLE.PIC", niestety gra wczytując dany poziom, również dostanie zawsze ten sam plik, niezależnie od nazwy poziomu jaką poprosi.

Myślę że ten zabieg T.R. wykonał celowo aby stworzyć wersję plikową gry mieszczącą się w 64kB pamięci RAM. Założenie pewnie było takie że nikt i tak nie będzie miał tyle cierpliwości aby przechodzić całą grę przy poziomie trudności zaoferowanym przez autorów gry. Czasy  były takie że to mogła być kolejna pozycja do handlu na giełdzie (dla posiadaczy magnetofonów) i pewnie nikt się nie przejmował że gra jest de-facto niepełna.

Przyznaję otwarcie że wcześniej (bez zrobienia nieśmiertelności) nie miałem cierpliwości grać w tę grę, jednak teraz się okazało że mając tę grę nagraną na kasetę to dużo bym sobie nie pograł :P ... ale "do brzegu"... robienie nieśmiertelności do wersji niepełnej mija się z celem, a przerabianie wersji dyskietkowej również chyba nie ma sensu, ponieważ rozumiem że Jaro124 chciał mieć wersję plikową tejże gry. Zastanawiałem się czy spróbować zrobić wersji plikowej zawierającej wszystkie poziomy, np. używając wydajnej metody kompresji poziomów, ale po pierwsze trzeba by oszacować czy aby na pewno dałoby się to skompresować aby to się zmieściło w wolnej przestrzeni RAM którą gra pozostawia nietkniętą, a po drugie to chyba nie mam na to aż tyle chęci i czasu ;-) Zatem "Crumbles Crisis" w wersji plikowej skreślam z listy "TO DO". Zastanowię się nad modyfikacją wersji dyskietkowej, ale to już kiedyś.

Jeżeli ktoś chce sobie zrobić "unlimited energy" z ręki za pomocą monitora w używanym emulatorze to proszę oto przepis; należy zmienić zawartość dwóch komórek pamięci na $20 (rozkaz JSR) na $2C (rozkaz BIT), owe adresy to:

  • $532B - zmiana na $2C spowoduje że nie ubywa energii po zderzeniu z murem czy też nieruchomymi obiektami pola gry

  • $3305 - zmiana na $2C spowoduje że nie będzie ubywać energii przy kontakcie z ruchomymi obiektami w grze (tzw. "przeszkadzajkami")

... i to chyba tyle co miałem do powiedzenia na temat "Crumbles Crisis". Musze przyznać że gdy pograłem trochę bez ubywającej energii gra wydała mi się bardziej przyjazna i bardziej grywalna ;-) Ale ja nie jestem jakimś graczem, dla mnie gry to głównie rozrywka i relaks, ale "przesadzony" poziom trudności mnie wręcz zniechęca. Pewnie stąd zrodziło się kiedyś moje "zamiłowanie" przerabiania gier ;)

44

(114 odpowiedzi, napisanych Software, Gry - 8bit)

i przysłowiowym "rzutem na taśmę", wrzucam również "Super Cobra".

45

(114 odpowiedzi, napisanych Software, Gry - 8bit)

Hej!

Po długiej przerwie wrzucam kolejny tytuł z listy, tym razem to "Batty Builders". W załączniku .xex do pobrania.

@piguła: no to rewelacja! Cieszy mnie że udało podnieść ten magnet i przywrócić go do sprawności! Kolejny kaseciak uratowany! Niech służy dobrze! :)

@Grzegorz_29_: fajnie że wynajdujesz i udostępniasz takie ciekawostki :) Dzięki temu poszerza się obraz dawnych czasów i rozwiązań stosowanych w konkretnych regionach polski... bez takich "akcji" to bym był przekonany że nie było tak wielu różnorodnych rozwiązań stosowanych nazwijmy to "lokalnie". A to turbo od Pana Sidora to też jest ciekawostka, nie porzuciłem jeszcze prac nad analizą tego systemu, jednak wymagają one więcej czasu niż mi się wydawało... zatem chwilę to potrwa.

Dzięki Panowie za wasz wkład i chęć dzielenia się waszymi zasobami, doświadczeniem i tym że opisujecie to na co napotykacie!

47

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

Cześć!

Ja chyba żyję (przynajmniej tak mi się wydaje :P) ... co do SlightSID to jestem na etapie w którym po pewnych przemyśleniach postanowiłem przyjąć  inną strategię... po protu wypuszczę ten projekt w obecnej formie. Pogodziłem się z tym że "dalekosiężne" plany rozwoju i modyfikacji tejże wersji mijają się celem. Zostawię więc mapowanie rejestrów tak jak jest, ponieważ istniejący soft to obsługuje, zmian w CPLD wprowadzać już nie będę, dokładać modułu zapewniającego self-upgrade również nie będę. Skoro tyle czasu przeleżało to bez większych postępów to myślę że dokładanie dodatkowej funkcjonalności której nikt albo prawie nikt nie wykorzysta nie ma najmniejszego sensu. Poza tym jeżeli ktokolwiek będzie zainteresowany jeszcze tym produktem/projektem no wypuszczenie go w obecnej formie pozwoli albo na spokojną śmierć albo dalszy rozwój produktu.

@piguła: jasne. ale to jak ogarnę to co mam w kolejce. dam znać na priv.

@pigłuła: jak zwykle dzięki za kawał dobrze wykonanej roboty!

@Grzegorz_29_: przyjrzałem się plikom które udostępniłeś z programami ze "studia komputerowego" z Ząbkowic Śląskich:

http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/loader_speeder_zabkowice.png

Część pozycji udało się odtworzyć i przekonwertować do plików CAS, niestety fragmenty nagrań na kasecie wydają się być  uszkodzone (zaniki sygnału na taśmie), np. "Pitstop" którego nie udało się odtworzyć wygląda w kilku miejscach tak:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/pitstop_signal_drop.png

Te pliki które udało się poprawnie przekonwertować do formatu CAS udostępniam dla zainteresowanych: Speeder 1400 - Ząbkowice Śląskie

Części nagrań właśnie z powodu wspominanych "zaników" sygnału (szczególnie tym problemem dotknięta jest strona "B" kasety z której robiłeś "zrzut", być może to zagniecenia lub uszkodzenia powierzchni taśmy) nie udało się odtworzyć jednak analizując fragmenty nagrania które to udało się wczytać do pamięci, udało się ustalić co to były za pozycje (używałem bazy AoL z grami do znalezienia ciągów które występowały w uszkodzonych nagraniach, w ten sposób udało się jednoznacznie określić jaki program był na taśmie zapisany), oto lista programów z udostępnionego przez ciebie "zrzutu" kasety:

strona A)

01) Gladiatior
02) HardHat Willy
03) Desmod's Dungeon
04) Pitsop [malformed]
05) Gunfight
06) Chimera

Strona B)

01) Diamond Mine (Roklan) [malformed]
02) Arcanoid III
03) Mr. Do!
04) Boulder Dash 8 (Iron Soft)
05) Electrician (Synapse Software, 1984) [malformed]
06) Joe (by Roy York) [malformed]

Na szczęście pozycje których nie udało się odtworzyć nie są białymi krukami ani unikalnymi pozycjami więc straty nie są duże :)

Przyjrzałem się także kodowi loadera, i jest on właściwie tożsamy ze "Speeder 1400", użwa on całej masy "nielegalnych" kodów procesora 6502, a jeżeli chodzi o ten formatu zapisu to przypomniały mi się dwa wątki. Rozmawialiśmy kiedyś o Speeder Tape w tym wtąku Speeder Tape. Potem jeszcze wypowiadałem się na temat programu Speeder 1400 autorstwa K.Polaka o w tym poście: Speeder 1400.

Kaseta która udostępniłeś jest zapisana w formacie Speeder 1400 autorstwa K. Polaka, jednak nie wiem którą dokładnie wersją Speeder-a były tworzone te nagrania, ale sądząc po tym co udostępnił Voy na pigwie, to K.Polak prawdopodobnie tworzył na zamówienie wersje swojego programu zawierające nagłówki reklamujące dane "studio komputerowe". Zapewne tak było i w tym wypadku, tzn. "Studio Komputerowe" z Ząbkowic Śląskich posługiwało się "spersonalizowaną" wersją programu która wyświetlała ich nagłówek podczas ładowania się programów.

A jeżeli chodzi o Ząbkowice Śląskie i adres 1-maja 17, to google maps (street view) dysponuje najstarszymi zdjęciami z lipca 2012:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/Studio_Komputerowe_1_maja_17_Z%c4%85bkowice_%c5%9al%c4%85skie_a.jpg

gdzieś w tej kamienicy znajdowało się owe studio komputerowe :) Może ktoś coś kojarzy i pamięta:
http://seban.pigwa.net/greg29/speeder_z%c4%85bkowice/Studio_Komputerowe_1_maja_17_Z%c4%85bkowice_%c5%9al%c4%85skie_b.jpg

Hej!

Piguła/Shpoon napisał/a:

Mimo wszystko są to dwie nietypowe pozycje w tym Turbo. Bo nie da się ich skopiować kopierem ATT-ATT. W oryginalnym zrzucie do WAV po powiększeniu widać przy obu tytułach 0.4sekundowe bloki ciszy w tych felernych miejscach.

Ja myślę że to nie jest nietypowe, tylko ktoś spierniczył zapis tych pozycji, może kopiował je "na raty" i "podkasował" kawałki tonów synchronizujących, być stąd problemy z kopiowaniem. A loadery do ATT praktycznie nie sprawdzają żadnych błędów, mówiąc brzydko "wczytują na pałę" i odpalają czy wczytało się poprawnie czy też nie. A przerwa pomaga bo szum z taśmy generuje jakieś tam krawędzie, które przez loader są "detektowane" jako kolejne zbocza sygnału, właściwie to pewnie loader czeka na jakąś zmianę która jest impulsem dłuższym niż "0" lub "1", nie wnika czy to jest synchro/stop, etc. Jeżeli kopier tego nie łyka to być może procedura łądująca jest nieco bardziej rozbudowana i oczekuje czegoś więcej niż minimalistyczna procedura w loaderze.

@takron27: a widzisz ... nie byłem świadomy że walczycie w tym wątku jakimiś kasetami :) na AoL zdarza mi się zaglądać, ale ostatnio brak czasu powoduje że na forum nie zaglądałem zbyt często, a tam się widzę dzieje niezła walka :) ... fajnie że walczycie w temacie! Aż miło czytać że archiwizacja i zgrywanie napotkanych kaset idzie jak burza!

btw. w ostatnim poście tego wątku na AoL który podałeś pisałeś, że to co Ci się wczytuje z użyciem magnetofonu wyposażonego w Turbo2000F/2001 nie wczytuje Ci się użyciem softu do KSO Turbo 2000 ... wybacz głupie pytanie, pewnie jesteś tego świadom ... ale wolę się upewnić ... rozumiem że jak używasz softu od KSO Turbo 2000 to używasz także magnetofonu wyposażonego w ten interface bo KSO Turbo 2000 transmituje dane z wykorzystaniem drugiego portu joysticka i software te dane czyta używając PORTA z układu PIA.

W moim wypadku mam taki swój stary magnet XC12 który za wbudowane zarówno Turbo 2000F jak i KSO Turbo 2000 i problematyczne kasety udawało mi się raczej wczytywać pewniej używając interface KSO Turbo 2000 (drugi port JOY) niż minimalistycznego Turbo 2000F. Być może taki egzemplarz XC12 że KSO Turbo 2000 ma większe wzmocnienie czy też inną charakterystykę przenoszenia, która powoduje pewniejszy odczyt. KSO Turbo 2000 ma też chyba nieco inaczej "docyklowane" procedury odczytu, więc np. jeżeli prędkość obrotowa silnika jest inna to np. w Twoim wypadku powoduje to że KSO Turbo 2000 szybciej wywala Ci Error 140 (zła długość zmierzonego impulsu). KSO 2000 było wcześniej niż Turbo 2000F i bazowało na Turbo 2T06 pana W. Zabołotnego. Turbo 2000F/2001 było n-tą iteracją systemu, więc zmieniły się również nieco procedury odczytu (zostały uproszczone), ale nie wydaje mi się aby ktoś modyfikował tablice przechowujące długości impulsów, czy też zmieniał wartości liczników pętli które zliczają długości impulsów z taśmy. Może więc być tak że taśmy zapisane za pomocą softu dla KSO 2000 będą miały inny margines błędu przy odczycie softem dla Turbo 2000F/2001 i vice versa. A ja do tego dodać wiek taśmy i różnice prędkości obrotowych magnetofonów to mimo 100% zgodności formatu, odczyt za pomocą różnych wersji oprogramowania i różnych interfejsów może mieć wpływ na jakość/pewność odczytu.

Dla mnie KSO Turbo 2000 to system który posiadałem jako pierwszy więc jak to się mówi mam niezły "bias" i ten właśnie system jest dla mnie najwygodniejszy i najpewniejszy, do dziś moje stare kasety zapisane w KSO Turbo 2000 czytają się bez problemu :) A mają chyba już ze 30 lat ;D Przez moje ręce przewinęło się sporo innych starych kaset i to własnie z kasetami zapisanymi w innych systemach maiłem najwięcej "zabawy" (czytaj problemów) ... chyba najszybciej sobie radzę z obróbką standardowego formatu KSO Turbo 2000/Turbo 2000F/2001. Ale jak mówię w tym wypadku moja stronniczość (chociaż nie jest to za dobre tłumaczenie angielskiego "bias", być może lepszym słowem byłaby polaryzacja) może mieć kluczowe znaczenie. Nie jest to oczywiście system idealny, bo ma standardowo chociażby owe 3kB bloki przez które robi się problem z miejscem potrzebnym na bufor danych i MEMLO systemu jest dość wysokie, ale przyjdzie kiedyś czas kiedy wyciągnę moje skarby z szuflady i napiszę opowieść o tym jak sobie z tym radziłem :D

I doskonale rozumiem wszelakie starania wasze o zachowanie nagrań w innych systemach, bo są one dla was i dla mnie tak samo ważne ze względów zarówno sentymentalnych jak i historycznych.