hobocti77x_ pisze: ↑04 paź 2023, 10:53
Czyli twój program pokazujący liczbę obrotów wcale nie pokazuje liczby obrotów, tylko ile obrotów przypada na tę samą liczbę cykli w stacji i komputerze, które to w sekundzie mają z definicji różną liczbę cykli. Dobrze zrozumiałem?
Oprócz tego że z pierwszego zdania wychodzi masło-maślane to źle zrozumiałeś.
Program cycles
1. Synchronizuje się programowo C64 ze stają
2. Daje sygnał do stacji kiedy zaczyna się ramka w C64
3. Stacja odczytuje timer
4. C64 daje sygnał zakończenia ramki
5. Stacja odczytuje timer i zlicza różnicę pomiędzy pierwszym odczytem
W C64 wiemy od razu ile cykli upłynęło bez sprawdzania - tyle co trwa ramka 312*63 cykle
W stacji różnica pomiędzy odczytem początkowym i końcowym timera daje liczbę cykli, jaki upłynęły w trakcie ramki na C64
Z reguły tych cykli w stacji jest 1.5% więcej jak w C64 PAL i jeżeli jest większa odchyłka w różnicy cykli w stacji względem C64 to zdegradował się trymer najprawdopodobniej. Ten program nie ma nic do obrotów w tej chwili i w tym konkretnym przypadku.
Program spin:
zlicza czas na C64 w ramkach (0.02 sec co ramkę) przez minutę - aby trwało to minutę tych ramek musi minąć 50 * 60
1 stacja daje sygnał że C64 ma zacząć odliczanie (napotkała PIERWSZY RAZ sektor 0)
2. C 64 zaczyna odliczać czas a stacja w uproszczeniu co kolejny raz daje sygnał że napotyka sektor zero, co oznacza
kolejny pełny obrót dyskietki"
- punkt drugi w uproszczeniu, bo tak naprawdę procesor w stacji nie ma co do roboty przez pełen obrót dysku, dlatego też odczytuje wszystkie nadjeżdżające po kolei nagłówki i również informuje o tym C64. Ale to ma znaczenie drugorzędne.
3. C 64 po minucie sprawdza ile pełnych (i niepełnego) obrotów zaliczył driv według informacji przesłanych od driva i wypluwa dalej na ekran freez tego zliczania - po kolejnej minucie wypluje kolejne dane, ale to już nieważne...
Tak więc C64 odmierza tą minutę a stacja informuje go co nadjeżdża.
Dalsze dywagacje że coś się rozjeżdża bo są znaki synchronizacji są kompletnie bez sensu. Nagłówek zostaje odczytane i przez cały czas ten nagłówek pojawia się dokładnie co pełen obrót dysku - czas generowania bajtu to 24-30 cykli - po znaku synchronizacji zostaje odczytanych np 5 bajtów, zdekodowanych i wysyłana jest informacja do C64. Odczyt nagłówka po znaku synchronizacji i jego dekodowanie zawsze trwa TYLE SAMO CYKLI, czyli cały czas jest takie samo opóźnienie i interwały są idealnie pokazujące czas obrotu dyskietki.
Więc program spin nie dość że bardzo dokładnie mierzy rpm, to C64 sam zajmuje się odmierzaniem czasu (aby uniknąć problemów w przypadku "zepsuty trymer") - to pierwszy powód dlaczego tak jest mierzony czas przez C64. Drugi powód - pełna minuta - aby zwiększyć dokładność pomiaru -
analogia pomiędzy pomiarem dwóch zboczy dla określenia częstotliwości oraz pomiaru ilości impulsów przez pełną sekundę.
==============================================================================================================
Dopiero teraz występuje trzeci przypadek o którym wspominałem - to właśnie pomiar spinu za pomocą timera w stacji i pomiaru czasu obrotu dysku. - JA TAK NIE ROBIĘ, TYLKO INNE PROGRAMY...
Głównym powodem dla którego MOŻE BYĆ ON NIEDOKŁADNY, to właśnie zmieniona podstawa czasowa poprzez ... oczywiście ... zepsuty trymer... Drugi powód, to programy te nie mierzą pełnej minuty czyli słaba rozdzielczość pomiaru - o ile powód drugi można zmienić w swoim własnym programie, o tyle zmieniona podstawa czasowa (mogąca występować) cały czas fałszuje pomiar
==============================================================================================================
hobocti77x_ pisze: ↑04 paź 2023, 10:53
W takim razie co jest przyczyna błędów w AR? Bo według mojej wiedzy zapis fizyczny na dyskietce Commodore jest wykonywany przez hardware i nie da się praktycznie zmienić sposobu zapisu, nie tylko bitu, ale i bajtu.
Np jak zapis robiłeś hardwarem taktowanym 1.000 MHz, a chcesz odczytywać go w hardwarze, w którym taktowanie spadło do 0.99 MHz
Jeżeli obroty przyspieszają w małych granicach (bo więcej to wiadomo że będzie trainwreck) wówczas loader AR dekodujący częściowo GCR w locie da zbyt duże opóźnienia i zgubi co któryś "nadlatujący" bajt. Tego bajtu by nie zgubił loader z BB9, bo on nie dekoduje GCR w locie w trakcie odczytu - ma wystarczająco czasu, żeby oczekiwać na "nadjeżdżający" bajt i go odebrać.
Dokładnie tak samo się stanie gdy spowolni się taktowanie DRIVA (chyba nie muszę wspominać dlaczego miałoby się spowolnić...) ,
a dysk nie spowolni, wówczas procesor staje się zbyt wolny do "przybywających" bajtów, które ze stałą prędkością obrotową "nadlatują" - szczególnie właśnie przestanie się wyrabiać loader typu AR, a normal będzie działał, albo loader z BB9 też zadziała.
Prosta rzecz - mając swoją dyskietkę pokręć trymerem w stacji i zobaczy czy "rozjedzie" się loader z AR
Teraz przykład synchronizacji C64 ze stacją - wyjęty z loadera BB9:
Oto co robi C64:
Kod: Zaznacz cały
;-------------
LP_BLK_S
;---
LDY #$00
NOP
NOP
LDA #$23
STA $DD00
;---
NOP
NOP
LDA #$03
STA $DD00
;---
BIT $93
LDA #$23
STA $DD00
;---
NOP
LDA #$03
STA $DD00
Kod: Zaznacz cały
SERIAL = $1800
;---
GETBLOCK001
LDX SERIAL
BEQ *-3
;-
LDX SERIAL
BEQ +
BIT $80
NOP
;-
+ LDX SERIAL
BNE +
BIT $C2
+ LDX SERIAL
BNE +
+ NOP
BIT $80
GETLOOP001
NOP
NOP
NOP
2021.06.16 "U mnie w okolicy też nikt nie umarł - ale nie będę na tej podstawie twierdził, że Covid nie istnieje ani że nie jest żadnym zagrożeniem"
2023.09.09 U mnie też nikt nie umarł włącznie z ciotką chorą na białaczkę. Dwukrotnie zaszczepiona dostała covida w szpitalu - żyje. Ta plandemia to już jak Bóg - wszędzie jest i nikt go nie widział.
