hobocti77x_ pisze: ↑28 wrz 2023, 12:25
Moim zdaniem problemem mogłaby być wymiana nagrań pod różnymi systemami, ale programy nagrane i odtwarzane pod NTSC powinny raczej działać tak samo jak i pod PAL.
Słusznie!
ABC load/save - może działać pod warunkiem że będzie wykorzystane w 2 strony na tym samym komputerze (NTSC)
Na C64 NTSC nie da się odczytać gier/programów zapisanych przez C64 PAL
.
Należy pomyśleć o akumulacji błędu:
Z pewnością zauważysz, że ABC turbo wyłącza ekran - nie dlatego żeby ładnie "mrugać" rastrami, ale po prostu żeby VIC nie kradł 40 cykli co 8mą linię. Wieki temu (dosłownie! - lata 90's) reversowałem ABC turbo i nie mogę dokładnie przytoczyć całości, ale ogólną zasadę tak:
Problem polega na zmianie prędkości nadawanych bitów - w 2 strony - przy zapisie i odczycie - w porównaniu do standardowego zapisu C64. Robi się to co raz bardziej napięte i dokładne - tak jak nieraz widzisz w demach że powinieneś używać stacji dysków "cycle exact" - maksymalnie zsynchronizowej z:
1. 1MHZ taktowanie CPU (często jest trymer 50pf koło kwarcu 16MHZ)
2. Idealną, niezakłóconą prędkością obrotową dysku 300rpm
Nota bene ten trymer staje się później źródłem problemów i zaprzestania odczytywania loaderów like AR, ponieważ jak się degraduje, to wzrasta jego pojemność. Mam takie doświadczenie (i napisane programy), które to sprawdzają w taki sposób, że synchronicznie zaczynają mierzyć różnicę "przecyklowanych" (hehe) cykli w trakcie 1 ramki na C64PAL w stosunku do tego, ile w tym czasie upłynęło cykli w drivie - z moich doświadczeń wynika, że wszystko działa prawidłowo, kiedy w stacji minie w okresie 1 ramki PAL
więcej cykli niż w C64PAL . Poprawną wartość empirycznie ustaliłem na ilość
273-303 cykli. A wartość bezpieczną i najczęściej spotykaną to
296 cykli więcej w drivie jak w C64PAL.
Chodzi o to samo... Np. loader Final3 ma opcję odczytu dyskietki z C64 PAL, jak i NTSC, ale jest to zamierzone i rozpoznaje na jakim C64 działa loader. Np. AR 7.3 (Atrax) już w NTSC nie zadziała - można sprawdzić choćby na emulatorze)
Po tak długim wstępie mogę przejść do sedna:
Teraz pomyślmy że dajmy na to (
ZAŁÓŻMY DLA ZOBRAZOWANIA) co 63 cykle zegara odbierany jest 1 bit z taśmy w C64 PAL. Problem w tym, pomiędzy C64 PAL i NTSC te 63 cykle trwają różny okres - niewiele się różnią,
ale różnią się!!!
I jeżeli PRZYKŁADOWO (bo nie pamiętam dokładnie) C64NTSC w 63 cykle "PALOWE" zrobi swoich cykli NTSC 64. Niby niewiele, jeżeli odebraliśmy 1 bit za szybko o okres 1/63 długości generowania się bitu - i tutaj właśnie do gry wkracza
AKUMULACJA BŁĘDU - czyli w przypadku 1 bitu odebranie danej "za wcześnie o 1 cykl" nie powinno stanowić najmniejszego problemu, o tyle po odebraniu bitów np 128 (8 bajtów) nasz 1 cykl rozbieżności
ZSUMUJE SIĘ do 128 cykli błędnego timingu odbierania danych, co już nieuchronnie musi zakończyć się katastrofą.
Gdyby ktoś chciał "oszukać system" i przyspieszyć prędkość przesuwu taśmy, wówczas jeżeli udałoby mu się dopasować do NTSC, wszystkie inne poprzednio nagrane pliki w NTSC przestaną być odczytywane.
Z tych samych powodów nie zadziałają turbo loadery dla driva - z wyjątkiem takich najprostszych jak np. loader z Final2. (FC3 zadziała, bo tak jest zaprogramowany) Szczerze mówiąc nie mam pojęcia czy BB9 obsługuje jakiś dopał dla driva.
