Wysłałem e-mail via forum! Dzięki za chęć wypożyczenia magnetofonu. Będzie druga sztuka z turbo UM do porównania!

No Lost niestety nie będę... w tym roku niestety nie będzie to możliwe. Miałem magnet z UM turbo od ucr0Bee-iego, ale jak go testowałem mi wszystko działało ;/ Odesłałem go po przeglądzie i rozrysowaniu schematu, więc w razie czego mogę bez problemu ten interface odtworzyć i zamontować w jednym ze swoich trupków :D

Wybacz pytanie głupiego... i uproczywe drążenie tematu, ale próbuję zrozumieć gdzie tkwi problem piszesz że "... nie rozpoznaje nawet tytułu." Nawet jak odwrócisz fazę sygnału? A ten soft mini/pack daje radę to wczytać?

Czekaj, czekaj... abym dobrze zrozumiał... kiedy dokładnie pojawia się problem? Czy udaje się wczytać loader Speedy 2700 i potem dopiero nie idzie? Czy już się nie udaje wczytać samego loadera? Pytam o to bo loader dla Speedy 2700, ma niby procedurę detekcji ale ona jest nieco spaprana i może nie wykrywać dobrze źródła sygnału (loader do Speedy 2700 próbuje wykryć czy sygnał pojawi się na drugim porcie Joy-a (KSO2000) czy też na DATA_IN w porcie SIO.

Co do odpalania tego z AVG to nie wiem co może być problemem, może loader AVG zmienia coś na stronie zerowej czy gdzieś w lokacjach systemowych tak że potem pojawia się przy ładowaniu danych z Turbo. Zmienię sposób startu tej wersji z patch-em, tam aby robiła sobie sama "ciepły start" przed uruchomieniem, to rozwiąże problem z kolizją z istniejącym urządzeniem "D:", dodam także możliwość wyboru pomiędzy "D:" a "T:"

Jeszcze raz dziękuję za testy! Wyjaśnia się wiele spraw.

I jeszcze jeden szybki test, procedura odczytu bajtu z "mini/pack":

    F65D: A0 08             LDY #$08
    F65F: AD 1F D0          LDA CONSOL
    F662: F0 D8             BEQ $F63C
    F664: 20 25 F7          JSR $F725              ;[contract]
      F725: A9 10             LDA #$10
      F727: 2C 0F D2          BIT SKSTAT
      F72A: 60                RTS
    F667: D0 F6             BNE $F65F
    F669: A2 00             LDX #$00
    F66B: 8E 1A D0          STX COLBK
    F66E: E8                INX
    F66F: 30 1C             BMI $F68D
    F671: 2C 0F D2          BIT SKSTAT
    F674: F0 F8             BEQ $F66E
    F676: A9 08             LDA #$08
    F678: 8D 1A D0          STA COLBK
    F67B: E0 36             CPX #$36
    F67D: B0 0A             BCS $F689
    F67F: 66 49             ROR $49
    F681: E0 1B             CPX #$1B
    F683: 26 30             ROL STATUS
    F685: 88                DEY
    F686: D0 D7             BNE $F65F
    F688: 60                RTS

i tej wersji która patchowałem;

    0758: A0 08             LDY #$08
    075A: EA                NOP
    075B: AD 1F D0          LDA CONSOL
    075E: F0 D6             BEQ $0736
    0760: 20 5E 08          JSR $085E              ;[contract]
      085E: A9 10             LDA #$10
      0860: 2C 0F D2          BIT SKSTAT
      0863: 60                RTS
    0763: D0 F6             BNE $075B
    0765: A2 00             LDX #$00
    0767: 8E 1A D0          STX COLBK
    076A: E8                INX
    076B: 30 1E             BMI $078B
    076D: 2C 0F D2          BIT SKSTAT
    0770: F0 F8             BEQ $076A
    0772: A9 08             LDA #$08
    0774: 8D 1A D0          STA COLBK
    0777: EC 0A 07          CPX $070A
    077A: B0 0B             BCS $0787
    077C: 66 49             ROR $49
    077E: EC 0B 07          CPX $070B
    0781: 26 30             ROL STATUS
    0783: 88                DEY
    0784: D0 D5             BNE $075B
    0786: 60                RTS

compare_table:

070A: 36 1B

Różnice są kosmetyczne! Właściwie nie powinno to mieć żadnego znaczenia. Wersja "patched" ma właściwe kod tożsamy z tym co się znajdzie w "KSO 2000", tzn. wartości do porównań długości zmierzonych impulsów pobiera z tabeli, wersja "mini&pack" ma te długości zaszyte bezpośrednio w kodzie. Różnica jest taka że CPX $xxxx od CPX #$xx wykonuje się o dwa cykle dłużej.

U mnie działają wszystkie z tych wersji. Naprawdę nie wiem co może być przyczyną tego że u Ciebie nie działa. Próbowałeś ładować jakoś inaczej niż z AVG? SIO2PC? (np. używając RespeQT i Boot Atari Executable)? Ew. czy możesz sprawdzić jeszcze czy jeżeli wykonasz po załadowaniu tej mojej wersji "patched" warm-start (RESET) to czy to cokolwiek zmienia?

Przejrzałem kod "mini" i "pack"... procedury odczytu faktycznie zmieniają także stan linii COMMAND...  czyli wychodzi dokładnie na to samo co zrobiłem robiąc "patch" w tej wersji turbo 2000F którą wrzucałem na forum. Nie wiem czemu wersja którą udostępniłem u Ciebie nie działa... stan linii jest dokładnie taki sam:

Altirra> .pia
Port A control:   34 (IOR, motor line: low / on, proceed line: -edge)
Port A direction: 00
Port A output:    00
Port A edge:      pending
Port B control:   34 (IOR, command line: low / on, interrupt line: -edge)
Port B direction: ff
Port B output:    ff
Port B edge:      none

tyle że w przypadku mini/pack OS-ROM jest odłączony bo procedury odczytu są pod OS-ROM:

Altirra> .pia
Port A control:   34 (IOR, motor line: low / on, proceed line: -edge)
Port A direction: 00
Port A output:    00
Port A edge:      pending
Port B control:   34 (IOR, command line: low / on, interrupt line: -edge)
Port B direction: ff
Port B output:    fe
Port B edge:      none

Jest to dla mnie kompletne zaskoczenie! Do tej pory sądziłem że poza lokacją w pamięci wersje systemów Turbo 2000F/2001, etc. nie różnią się procedurami odczytu! A jednak jest jakaś różnica skoro wersje "mini" i "pack" u Ciebie działają, a mój "patch" nie działa (oczywiście wszystko działa niezależnie od wersji, etc. na magnecie wyposażonym w Turb 2000F lub ten klon czeskiego Turbo 2000 - u mnie działają wszystkie trzy wersje).

Po pierwsze będę musiał zgłębić temat nieco bliżej, po drugie zaskoczyło mnie to że owe wersje "mini" i "pack" sterują linią COMMAND, do tej pory wersje Turbo 2000F/2001 które widziałem nie dotykały PBCTL. Kolejny temat do wyjaśnienia zatem! Ale to niech się trochę chłodniej zrobi! ;-)

ps1) Wersja Turbo 2001 którą sprawdziłeś nie działa bo nie dotyka linii COMMAND, chciałem się upewnić czy aby na pewno UM ma tak samo aktywowany tryb pracy turbo interfejsu. Już się bałem że coś na schemacie mam źle, albo że u Ciebie jest jakoś inaczej. Dzięki za test!

ps2) zauważyłem na filmiku że wpisujesz "D:*.*", nie wiem czy nie wygodniej pisać "D***", ja tak czynię bo szybciej, a efekt ten sam :) Tak zresztą było w instrukcji do KSO 2000 którą kiedyś dostałem jak mi je zamontowano.

eee.... Turbo2000F_minisoft.xex oraz Turbo2000_pack.xex w ogóle nie powinny Ci działać na magnecie z UM turbo! :) UM włącza się linią command... nie wydaje mi się aby *.minisoft czy *.pack sterowały linią COMMAND w odpowiedni sposób (ale mogę to sprawdzić). Sądziłem że używałeś softu z tego postu: Turbo 2000F CMD & Phase Select Patch v.1.2

Do kompletu wersje "minisoft" i "pack" lokują się pod ROM, dużo z tych gier które tu wrzucałem nie pójdzie. Tzn. wszystko co się będzie pakowało pod OS-ROM zniszczy procedury Turbo. Ten "... CMD & Phase ..." siedzi w pamięci nisko od $700 jak DOS i większość tych zestawów oczekuje właśnie takiej lokacji systemu turbo (pewnie dlatego KULT wysypuje Ci się na emulatorze). Ja każdy z tych CAS-ów sprawdziłem i każdy z nich ładował mi się na emulatorze. Używałem co prawda carta od KSO Turbo 2000 (sygnał na drugim porcie JOY-a)... ale robiłem tak dlatego że jeżeli były dołączone loadery L1, L2 to one były zazwyczaj w wersji dla KSO również, założyłem zatem iż te zestawy sa po prostu przeznaczone dla KSO.

Ale ja mówiłem o tym konkretnym przypadku. Muszę zajrzeć do procki instalującej handler. Być może ta wersja softu korzystna z systemowej procki i jej uruchomienie z poziomu np. DOS-a który to już instaluje wcześniej urządzenie "D:" powoduje jakiś problem. Sprawdzę to, może od razu dodam opcję wyboru urządzenia D/T. Ale tak czy inaczej ten soft z DOS-em współpracować nie będzie, ponieważ lokuje się w pamięci od adresu $700 a więc tak czy inaczej będzie kolidować z DOS-em. Ja tego .xex ładowałem używając SIO2PC ale używałem opcji "BOOT Atari Executable" z RespetQT. Nie ładowałem tego z poziomu DOS-a, więc nawet nie byłem świadomy istnienia takiego problemu.

Dzięki QTZ za wrzucenie tego! Niezła kolekcja! Nie byłem świadom że tyle tego było! W sensie miejsc w których się takie zestawy sprzedawało, a co za tym idzie sporo wzorów i etykiet jest! Fajnie to zobaczyć po latach. Ja to widziałem na własne oczy tylko kilka sztuk z tych które zaprezentowałeś!

Hej!

Dzięki za materiały do obróbki. Tak na szybko rzuciłem na to okiem! Jeden z cartów (Blizzard) udało Ci się poprawnie zrzucić! Podpowiedz proszę czy ten cart da się łatwo rozebrać? Pytam aby potwierdzić rozmiar pamięci która jest w cartridge. Powinno być coś wielkości 2764 lub mniejsze (z analizy dumpa wygląda że to będzie 2732). Dlaczego pytam? Bo mój dumper jest naprawdę sample i zrzuca tylko 8K blok pamięci znajdujący się w obszarze $A000-$BFFF. 

I właśnie dlatego drugi z dumpów (ten drugi cart z grami) nie  będzie kompletny, ponieważ ma on o wiele większą pamięć zapewne i zupełnie inną konstrukcję niż carty do Turbo... zapewne ma też jakiś mechanizm przełączania banków, którego "simple dumper" nie wspiera. Więc wykonany nim dump, dał tylko kawałek pamięci która jest w tym carcie z grami.

Jeżeli chodzi o taśmy, to szybki rzut okiem pokazuje że nie dość że są one w stanie dość kiepskim, to niestety są one wielokrotnie napisane innymi programami, są tam głównie niekompletne jakieś dłuższe nagrania, zastąpione krótszymi programami... niewiele chyba z tego da sie odzyskać... z pierwszej strony udalo mi się na szybko wczytać co ciekawe jakiś inicjalizer dla dyskietek oraz "Rythmizer AT1":

Jest tam też jakiś program zapisany w Turbo Blizzard, ale jeszcze tego nie analizowałem. Druga strona też nie wygląda lepiej, tzn. z tego co przesłuchałem na szybko, to część dłuższych nagrań jest niekompletna i podkasowa, w dodatku są też zaniki sygnału ta taśmie (pewnie zagniecenia). No ale temu się jeszcze przyjrzę...

Tera wrócę jeszcze do carta z blizzardem który udostępniłeś! Tego carta jeszcze nie mieliśmy tutaj w kolekcji! Za dump bardzo Ci dziękuję! Niebawem obrobię pliki i wystawię komplet, teraz tylko screen-shot:

Dobra, wracam na chwilę do carta KSO2000 z którego dump zrobił Dely... obiecałem przetworzyć ten 8KB dump, tak aby był dostępny w różnych postaciach. Udało mi się znaleźć chwilę czasu aby to uczynić, ale tym razem wrzucam całe archwium z masą plików, może się komuś przyda. W archwimum oprócz wersji XEX, BOOT, BIN (oryginalnej i zawierającej patch) dodałem również skrypt i makefile przetwarzający to wszystko od początku do końca. Dodaję cały ten śmietnik w celach poznawczych, może ktoś będzie chciał sobie kiedyś samemu spróbować dokonać takich eksperymentów, może to być dobry materiał do startu. I proszę nie protestować że Linux potrzebny, etc. W dobie maszyn wirtualnych każdy może mieć Linuxa pod "windą", czy to będzie jakiś darmowy VirtualBox czy też WSL to już pozostawiam zainteresowanym tematem.

Dla nie zainteresowanych w archiwum są również gotowe i przetworzone pliki wynikowe czyli:

• KSO2000_2k.bin - wyłuskana 2KB oryginalna zawartość pamięci EPROM

• KSO2000_2k_cctl_patch.bin - oryginalny obraz + patch umożliwiający automatyczne (nie czasowe) wyłączenie carta

• KSO2000_4k_cctl_patch.bin  - "powdojony" oryginalny obraz (do rozmiaru 4kB) + patch umożliwiający automatyczne (nie czasowe) wyłączenie carta - ten obraz bez problemu obsługuja emulatory, wystarczy wybrać Blizzard 4K pod emu i cart samoczynnie wystartuje.

• kso2000.xex - obraz przetworzony do formatu XEX, można sobie go uruchomić z dowolnego urządzenia typu SIO2SD, SIO2PC, etc.

• kso2000.boot - obraz przetworzony do formatu BOOT, można sobie nagrać na kasetę za pomocą jakiegoś programu kopiującego a potem wczytywać przez START+OPTION

• kso2000.cas - obraz przetworzony do formatu CAS, można użyć np. Turgen aby nagrać sobie to na kasetę i wczytywać z magnetofonu w standardowej prędkości :P

suma SHA256 2kB obrazu EPROM:

03d1c0d28f7dd2fc71a19bff17fc8d0638fdefbcec51813476a5637453c2d0aa

W archiwum są też inne pliki, np. makefile, a8cas-util od FUJI-ego (potrzebny do wygenerowania pliku CAS), pliki .XSM (cart2boot.xsm oraz cart2xex.xsm) to kod kompilowany za pomocą Fox-owego XASM, extract.sh to BASH-owy sktypt umożliwiający wyciągnięcie początkowych 2KB z 8KB pliku generowanego przez "simple cart dumper", skrypt ten również aplikuje "patch" za pomocą narzędzia "bbe" dostępnego dla systemu Linux (taki SED tylko dla plików binarnych). Ale jak mówię te wszystkie dodatki, to tylko dla zainteresowanych "how it was done".

To ja teraz na szybko... bo udało mi się to ogarnąć... rekordy #3 i #4 to faktycznie rekordy w formacie długich bloków danych Turbo 2000 (KSO/2001/F) tyle że liczenie sumy kontrolnej zmieniono z modulo256 na XOR ... nie wiem kto wymyślił używanie XOR jako "sumy kontrolnej", to jest tak podatne na przekłamania że nie rozumiem tego sposobu... no chyba że chodziło o to aby się "pewniej" wczytało... gdzie "pewniej" znaczy z błędami! A nóż tak wczytana gra się uruchomi? może błędy będą na grafice, etc. takie podejście to czyste dziadostwo :( szczególnie że liczenie sumy kontrolnej modulo256 nie jest jakoś specjalnie bardziej czasochłonne!

Udało mi się rekordy #3 i #4 skonwertować poprawnie... mimo że wiele razy dzięki temu wspaniałemu XOR-owi miałem błędne dane po konwersji mimo że XOR się zgadzał! szczególnie w tym długim bloku #4 ... no ale koniec końców się udało...

Pozostała walka z rekordem #41... który to został specjalne uszkodzony! Nie to że nagranie jest błędne... nagrano rekord o złej długości!!! Sądzę że zrobiono to celowo... po prostu wczytywanie miało się wysypać podczas siódmego poziomu... a dlaczego??? ponieważ brakuje dalszej części danych! Nie ma bloków z danymi dla poziomu #8  ... widać w UM założyli że nikt nie przejdzie i tak tej gry do końca ... i nie chciało im się wykonać poprawnej wersji tejże gry.

Dane z brakującego rekordu #41 odzyskałem (posiłkując się wersją na 130XE dostępną na AoL). Rekord na taśmie zawiera tylko 3375 bajtów, podczas gdy loader oczekuje 3484 bajtów danych (wraz z sumą XOR). Dodałem brakujące bajty (poszukując brakującej sekwencji w wersji dla 130XE) i spreparowałem poprawną sumę dla tak przygotowanego rekordu.

Tyle że wyszła z tego lipa bowiem okazało się że próba wczytania poziomu #8 powoduje że loader oczekuje na więcej danych... a dalszych rekordów już w nagraniu nie ma :(

W dodatku aby możliwe było przechodzenie z poziomu na poziom, należy robić to bezbłędnie i bez śmierci... "ponieważ gdyż" ta wersja nie wypisuje jakie segmenty danych ją interesują do wczytania i wciąga z taśmy co jej tam podejdzie co prędzej czy później kończy się błędem wczytywania lub "zwiechą".

Aby to wszystko przetestować musiałem pogrzebać w kodzie gry... bo nie wyobrażałem sobie abym za każdym razem przechodził te wszystkie poziomy od nowa :( zatem gdyby kogoś interesowało to aby przejść do następnego poziomu to pod emulatorem należy:

1. wejść do debuggera/monitora

2. pod adresem $CDB4 umieścić kolejny numer poziomu (jeżeli jesteśmy na pierwszym poziomie wpisujemy tam wartość 2)

3. pod adresem $CDB7 umieścić zero

4. wrócić do gry

pod atari800 robimy to tak (przejście z poziomu #1 to poziomu #2), wciskamy F8 (wejście do monitora/debuggera), a potem na konsoli piszemy:

c CDB7 0
c CDB4 2
cont

aby przejść z poziomu #2 do #3 piszemy:

c CDB7 0
c CDB4 3
cont

itd.

Dla chętnych w załączniku plik HEX, nie porządkowałem go zbytnio, bo i tak ta wersja gry jest totalnie spartolona przez tego kto ją wykonał. Zrobił to na odwal się, licząc że nikt z graczy nie zabrnie tak daleko. Cóż za podejście :D Autorowi takiego hacka można "pogratulować" ... ale chyba braku cierpliwości... wygląda na to że rzeźbił, rzeźbił i mu się znudziło! :)

Ale numer z blokiem #41 jest wręcz żenujący! :D No chyba że faktycznie na tej kasecie nagrano jakąś uszkodzoną lub niedorobioną wersję i gdzieś może istnieje wersja poprawna?