Hej!
Długo mnie nie było, ale cóż... życie. Wracam do tematu detekcji typu turbo w przypadku loader-a speedy 2700 wersji którą zaprezentował baktraaa, wszystko stało się jasne... w sumie to nie wiem czemu tego wcześniej nie zauważyłem ;-/ Aby dokładnie wyjaśnić o co chodzi muszę zaprezentować zachowanie realnego hardware i opisać to co będzie widać. Wybaczcie marną jakość filmu, ale kręciłem to "z ręki" próbując drugą ręką pisać na klawiaturze i ogarniać jednocześnie sprzęt, wyszło jak wyszło... ale jakbym się z tym "pieścił" to zajęło by mi to kolejne tygodnie :P także wybaczcie, jest jak jest...
https://www.youtube.com/watch?v=Yh4L62yiKVE
Co właściwie widać na filmie? Do Atari podłączony jest magnetofon XCA12 z K.S.O. Turbo 2000 oraz z Turbo 2000F (ale przełącznik od Turbo 2000F jest w stanie "normal"). Zatem loader Speedy 2700 powinien poprawnie wykrywać K.S.O. 2000.
Wykrywanie jest dokonywane przez monitorowanie stanu bitu #7 w porta A, a więc wtyczka od interface turbo jest podpięta zgodnie ze sztuką pod drugi port JOY-a. Na filmie klepię kawałek kodu który ma na celu odczytanie PORTA, przesunięcie jego bitów tak aby zmiany w górnej połowie bitów PORTA było odwzorowane jako zmiany kolorów ramki.
Należy dodać że domyślnym stanem wszystkich bitów PORTA w chwili gdy nic do portów nie jest podłączone (lub gdy joystick nie jest wychylony w żadnym kierunku) jest stan "1". Natomiast po podpięciu kabla od interface do portu joysticka #2, jak pisałem przed chwilą bit #7 reprezentuje aktualny stan na wyjściu dyskryminatora danych tegoż interface, co znaczy tylko tyle że to co interface analizując sygnał na jego wejściu (z taśmy) decyduje czy to co obserwuje na wejściu będzie "1" lub "0" logicznym? A co się dzieje kiedy nie ma żadnego użytecznego sygnału na wejściu interface?
To właśnie pokazuje początek filmu... jak się okazuje w większości czasu na wyjściu interface będzie panowało logiczne "0", i ten fakt wykorzystuje *AJEK aby zdecydować czy ma do czynienia z interface K.S.O. Turbo 2000... tzn. dokonuje odczytu PORTA a i sprawdza czy tam znajduje się "0", jeżeli tak to zakłada że interface K.S.O. musi być podłączony (bo przecież w normalnych warunkach powinno tam być zawsze "1").
Ale jak pokazuje filmik, taka metoda detekcji jest tylko pozornie dobra, bo zdarzyło mi się że loader Speedy 2700 trafił akurat na "1" i przełączył się na Turbo 2000F (które miałem wyłączone) zatem z odczytu nagrania wyszło "wielkie nic" :) Przez większość czasu to działa (jak ktoś chce można liczyć prawdopodobieństwo)... Ale jak widać na filmie nawet interface z wyłączonym silnikiem potrafi wystawiać "1" logiczne mimo braku obecności sygnału z kasety na wejściu.
Od 0:30 - 0:42 widać właśnie ten stan, potem na filmie uruchamiam silnik magnetofonu ($D302=$34) i pokazuje zachowanie gdy silnik pracuje (kasety w kieszeni brak, ale na początku PLAY jest wyłączony [0:56], a potem zostaje wciśnięty [1:02]).
Jak więc widać metoda detekcji u *AJKA jest również niezbyt pewna i daje błędne rezultaty. *AJEK włącza niby od razu silnik, ale na szczęście detekcji dokonuje bardzo szybko po tym fakcie i silnik nie zdąży ruszyć i cały magnetofon przez chwile znajduje się jeszcze w stanie nazwijmy to "IDLE", to zwiększa prawdopodobieństwo że u *AJKA są szanse aby loader poprawnie pracował z K.S.O. 2000.
Pytanie czemu to nie działa w loaderze od Baktraaa? Nie wiem jak na to wcześniej patrzyłem, ale jest to tak oczywiste że sam się dziwię że tego wcześniej nie dojrzałem. Sądzę że Baktraaa disassemblował kod loader już po tym gdy ten dokonał detekcji systemu turbo (nie wykrył KSO) i w kod loadera procedura detekcji wpisała wartości które odpowiadają pracy loadera z Turbo 2000F/AST, etc.
Domyślnym stanem (startowym) loadera jest stan w którym ma on wpisane w procedury odczytu wartości odpowiadające odczytowi danych z K.S.O. 2000. Potem następuje detekcja i ew. korekta loadera tak aby czytał z Turbo 2000F, w przypadku disassemblacji kodu po detekcji efekt będzie taki że loader już nigdy nie będzie miał możliwości przełączenia się na K.S.O. 2000, bo śladu po tych instrukcjach odczytujących z PORTA bit #7 już nie ma. Pojawić się nie mogą, bo procedura detekcji tylko przełącza na Turbo 2000F, więc przełączanie z Turbo 2000F na Turbo 2000F niewiele zmienia ;-)
procedury odczytu przed detekcją w oryginale wyglądają tak:
W tych procedurach powyżej widać sekwencje:
tymczasem u Ciebie baktraaa jest na starcie:
LDA #$10
BIT SKSTAT ; $D20F
zatem procedura detekcji przełączenia znajdująca się od linii 296, czyli:
lda PORTA ;Check signal at joystick port
bpl L085E ;If no signal, then skip
lda #$0F ;Modify the decoding routine so
sta L0708 ;it reads from the joystick port
sta L0715
sta L072E
sta L0739
lda #$D2
sta L0709
sta L0716
sta L072F
sta L073A
lda #$10
sta L0706
sta L072C
nie ma prawa działać.
Można to poprawić w procedurach odczytu na odwołania do KSO, albo zmienić procedurę detekcji tak aby wykonywała się zawsze gdy zostanie wykryte KSO, czyli:
lda PORTA ;Check signal at joystick port
bmi L085E ;If no signal, then skip
lda #$00 ;Modify the decoding routine so
sta L0708 ;it reads from the joystick port
sta L0715
sta L072E
sta L0739
lda #$D3
sta L0709
sta L0716
sta L072F
sta L073A
lda #$80
sta L0706
sta L072C
jednak tak jak pisałem przydałoby się sprawdzić więcej niż raz czy w PORTA bit #7 nie zmienia stanu na "0", lub że przez jakiś okres czasu bit #7 w PORTA ma zawsze stan "1", można to zrobić jakoś tak:
; wait for scanline #0
lda $d40b
bne *-3
dt_loop lda PORTA
bmi dt_wait
; KSO detected ...
lda #$00
sta ...
sta ...
lda #$d3
sta ...
sta ...
lda #$80
sta ...
sta ...
jmp dt_end
dt_wait lda $d40b
bpl dt_loop
dt_end
... lub oczywiście w dowolny inny sposób który Ci przyjdzie do głowy i który będziesz uważał za słuszny.
Gdybym coś za ostro zamotał i napisał zbyt niejasno to oczywiście nie wahaj się pytać.
ps) przepraszam że tyle czasu to trwało, ale naprawdę nie miałem się do tego kiedy zabrać ;/
Edited on 2025.08.18: Updated HTTP links to HTTPS to avoid mixed content issues.
