c64scene.pl

Kilkukrotnie spotkałem się że w stacji przestawał działać loader AR - działało load w normalu, ale dużo fastloadrów nie działało.
Przyczyną takiego stanu rzeczy okazywał się zdegradowany trymer 50pF, który jest umieszczony koło głównego kwarcu 16MHZ. sygnał z tego kwarcu końcowo jest dzielony przez 16, aby napędzać 6502 prędkością 1MHZ.
Trymer z czasem zwiększał swoją pojemność, spowalniając taktowanie do tego stopnia, że złożone (skomplikowane) fastloadery jak np. AR przestawały działać.

Do zdiagnozowania tego typu usterki napisałem program cycles, który porównywał równocześnie ilość cykli, które minęły w trakcie 1 ramki C64 PAL na owym C64PAL oraz w stacji dysków.
Z ustaleń empirycznych stwierdziłem że wszystko działa, jeżeli w stacji przeleci w okresie 1 ramki PAL więcej cykli w stacji. Ilość jaka nie sprawiała problemów to różnica w zakresie 273-303 cykle więcej w stacji.
Wielkością defaultową jest zakres około 286-296 cykli więcej.
Jeżeli cykli jest poniżej 270, wówczas należy wymienić ów trymer - ja wymieniałem go na kondensator stały 15pF i stacje wracały do życia (głównie loader AR).
Wspomniany program cycles zamieszczam w załączniku.

Drugą rzeczą jaką postanowiłem zrobić był program do pomiaru prędkości obrotowej dyskietki. Zrobiłem ten program, ponieważ oferowane usługi pomiaru prędkości obrotowej dysku bazują na błędnym założeniu, że CPU jest napędzany właściwą prędkością 1MHz, co jak widać powyżej nie zawsze musi być prawdą.
Jeżeli procesor ma błędne taktowanie, wówczas bazując na zliczaniu cykli w trakcie obrotu, również źle określamy spin dysku. W taki (może nie błędny, ale mogący zafałszowywać prawdziwe wyniki) sposób np. działa program do określania spinu dyskietki z cartridge 1541(cośtamdalej - nie pamiętam już).

Wobec tego napisałem program, który mierzy prędkość obrotową dysku przez 1 minutę, korzystając z przerwań rastra na C64. Po minucie program drukuje, ile udało mu się zliczyć obrotów dyskietki, w tym także ilość sektorów (obrazowo), które zostały odczytane w ostatnim, niepełnym obrocie dyskietki, który nie został zliczony.

Oba programy razem ze źródłami zamieszczam w załączniku.

Fajny sposób, aby zepsuć sobie stację dyskow.
Kolega zrobił dużo dobrej roboty, tyle że niepotrzebnej.
Prędkość obrotowa napędu nie ma nic wspólnego z częstotliwością zegara, a ta zależność, którą kolega zauważył, jest pozorna. Zresztą napędy dyskowe, szczególnie te tanie, których charakterystyczną cechą wspólną jest to, że były wykonane z plastiku, miały zawsze spore rozrzuty jeśli chodzi o prędkość obrotową, i nic dziwnego, bo miały być tanie, a to oznaczało nie tylko tańsze materiały, ale też, a może przede wszystkim, mało regulacji i brak potrzeby stosowania drogich urządzeń diagnostycznych na etapie produkcji oraz niestosowanie silników krokowych do napędzania dyskietki tylko tanszych gdzie regolacja obrotow dokonywana byla na tej samej zasadzie co np. w pralkach.
Jeśli prędkość obrotowa się rozjeżdża z zegarem, to w 99,99% przypadków winę ponosi rozregulowanie tampera prędkości obrotowej, a nie różnice w częstotliwości zegara CPU stacji.
Sam kolega zauwazyl ze 10proc. nie robi roznicy
Jest to częsta bolączka użytkowników ATARI przez zastosowane tam kodowanie zapisu na dyskietce wzięte wprost z maszyn IBM gdzie predkosc obrotowa byla naprawde precyzyjna ale wysokim kosztem napedow. W przeciwieństwie do tego, w Commodore i Apple zastosowano kodowanie GCR, które Motorola stworzyła dla napędów taśmowych. Dzięki temu stacje dyskowe Commodore i Apple rzadziej wymagają regulacji, a ich użytkownicy czésto nawet nie zdają sobie sprawy z tego, że są zwyczajnie rozregulowane.
Dodatkowo te roznice nominalne w zegarze gdzie CPU stacji to 1MHz a CPU c64 to 0.98 MHz.
No ale jesli CPU w stacja mimo szybszego zegara dziala wolniej niz w c64 to naprawde jest problem

Albo ja czegoś nie rozumiem, albo ty czegoś nie zrozumiałeś:

hobocti77x_ pisze: ↑

28 wrz 2023, 18:37

Fajny sposób, aby zepsuć sobie stację dyskow.

W jaki sposób?

hobocti77x_ pisze: ↑

28 wrz 2023, 18:37

Prędkość obrotowa napędu nie ma nic wspólnego z częstotliwością zegara, a ta zależność, którą kolega zauważył, jest pozorna.

Prędkość obrotowa owszem nie ma nic wspólnego z częstotliwością zegara - nigdzie nie napisałem że ma. Chodziło o to, że błędem jest używać zegara (ściślej timera zliczającego zegarowe cykle) do pomiaru prędkości obrotowej dyskietki, jeżeli sygnał taktujący zwolnił, ponieważ to wówczas właśnie daje nam zafałszowany wynik prędkości obrotowej. Taki pomiar polega np. Na:
1. odnalezieniu sektora 0
2. odczytaniu timera
3. ponownym odnalezieniu sektora 0
4. ponownym odczytaniu timera

pomiar jest niedokładny z 2 powodów:
- Sprawdza tylko 1 obrót dyskietki
- Może fałszować pomiar, jeżeli prędkość sygnału taktującego się zmieniła

hobocti77x_ pisze: ↑

28 wrz 2023, 18:37

Jeśli prędkość obrotowa się rozjeżdża z zegarem, to w 99,99% przypadków winę ponosi rozregulowanie tampera prędkości obrotowej, a nie różnice w częstotliwości zegara CPU stacji.
Sam kolega zauwazyl ze 10proc. nie robi roznicy

Nie stwierdziłem co ponosi winę, tylko zmieniłem sposób pomiaru czasu i okres pomiaru - w miejsce odliczania przez 1 obrót dyskietki i zliczania czasu (za pomocą timera czyli cykli 6502) użyłem przerwań rastra z C64 a pomiar trwa całą minutę - co daje znacznie lepszą rozdzielczość i dokładność pomiaru. To tak jak byś usiłował mierzyć częstotliwość sygnału za pomocą pomiaru czasu pomiędzy dwoma zboczami, lub zliczał wszystkie impulsy przez sekundę. Zmieniłem sposób pomiaru z 2 powodów:

1. Mogący występować błąd w taktowaniu procesora, wpływa proporcjonalnie na dokładność pomiaru
2. Rozdzielczość pomiaru - czyli pomiar przez całą minutę i zliczanie impulsów w miejsce odliczenia czasu pomiędzy dwoma zboczami - w pierwszym przypadku dokładność pomiaru jest nieporównywalnie większa.

Prędkość obrotowa j.w. do pomiaru prędkości użyłem przerwań rastra w C64, które co 0.02 sec odmierzają czas
Nigdzie nie zauważyłem że 10% nie zrobi różnicy !!! - ZROBI CHOLERNĄ RÓŻNICĘ

Znalazłem kolejną wersję programu:
Pomiar polega na jednoczesnym zliczaniu cykli w C64 i stacji:

Ramka w C64PAL = 312 * 63 cykle = 19656 cykli

co oznacza że w stacji w tym okresie powinno być około 290 cykli więcej (przy prawie 20000 cykli!!!) - ma to swoje przełożenie do zegarów C64 i stacji, ale trzeba to faktycznie stwierdzić. Co więcej - stacje ożywały (loadery AR zaczynały działac na powrót), czyli diagnoza i naprawa była słuszna - wymiana zdegradowanego trymera na kondensator stały 10-15pF

hobocti77x_ pisze: ↑

28 wrz 2023, 18:37

Jeśli prędkość obrotowa się rozjeżdża z zegarem, to w 99,99% przypadków winę ponosi rozregulowanie tampera prędkości obrotowej, a nie różnice w częstotliwości zegara CPU stacji.

Jeszcze raz dla jasności - jeżeli masz złą podstawę czasową, wówczas źle mierzysz czas - nawiązuję do zdegradowanego trymera i spowolnionego przez to sygnału zegarowego.

wegi pisze: ↑

28 wrz 2023, 20:32

Albo ja czegoś nie rozumiem, albo ty czegoś nie zrozumiałeś:

hobocti77x_ pisze: ↑

28 wrz 2023, 18:37

Fajny sposób, aby zepsuć sobie stację dyskow.

W jaki sposób?

To moze odpowiem stopniowo
Na poczatek cytat z VICE manual .d64 file format
"At first, the defined track size value of 7928 bytes may seem to be arbitrary, but it is not. It is determined by the fastest write speed possible (speed zone 0), coupled with the average rotation speed of the disk (300 rpm). After some math, the answer that actually comes up is 7692 bytes. Why the discrepency between the actual size of 7692 and the defined size of 7928? Simply put, not all drives rotate at 300 rpm. Some can be faster or slower, so a upper safety margin of +3% was built added, in case some disks rotate slower and can write more data. After applying this safety factor, and some rounding-up, 7928 bytes per track was arrived at.
Also note that this upper limit of 7928 bytes per track really only applies to 1541 and compatible disks. If this format were applied to another disk type like the SFD1001, this value would be higher. "
Czyli juz na etapie produkcji rozjazd wielkosci 3% byl normalny.
A jak zepsuc ? A no tak ze dzis 99.99proc stacji dyskow jesli chodzi o predkosc obrotowa jest rozjechana.
Zrobmy test ilu uzytkownikow regolowalo swoj naped ( dodam ze jest to czynnosc bardzo prosta i nie wymaga wcale wiedzy elektronicznej ) ?
I jesli jeszcze zaczniemy majstrowac przy taktowaniu 6502 (ktore w 99.99 proc. maszyn jest zgodne z norma) to problemow zamiast ubyc moze przybyc
Dla zainteresowanych dodam ze i zegar CPU w c64 tez nie jest ustawiany precyzyjnie i sa roznice w poszczegolnych egzemplazach wieksze niz wynika to ze stabilnosci kwarcu.
Kiedys moze wyjasnie dlaczego niektore MAX machine byly szybsze i dlaczego c64 nie ma 1MHz choc poczatkowa tak wlasnie mialo byc. Zreszta z c64 zwiazana jest jeszcze jedna ciekawostaka bo jest to chyba jedyny przypadek w historii kiedy szybszy komputer VIC20 zostal zastapiony wolniejszym c64

Nie za bardzo rozumiem do czego te teoretyczne wywody prowadzą - skoryguję do praktyki.

Ne masz stacji - ja miałem ich z 10, także testowałem u kumpla, ale liczmy 10.

NIGDY nie regulowałem obrotów w moich stacjach, i jak pamiętam NIGDY ŻADNA z moich stacji nie przekroczyła, ba NAWET SIĘ NIE ZBLIŻYŁA do plus-minus 1% błędu - być może pierwsze stacje jakie wypuszczano były takie złomalne - ja posiadałem kilka 1541II/ jedną 1570/ jedną 1571/ jedną Oceanic9900. ŻADNA z tych stacji nie przekroczyła 1% błędu - ŻADNA.

Szczerze przyznam, że taka precyzja obrotów wprawiała mnie nawet do dzisiaj w osłupienie, ale tak naprawdę było. Zresztą łatwo to sprawdzić - wystarczy wziąć stację, podłączyć do C64 i uruchomić na C64 mój program do pomiaru spina.

Z tego co pamiętam to liczba 299 i 300 - nie pamiętam żeby jakakolwiek stacja miała np 301 czy 302 rpm, albo poniżej 299 ... No może RAZ 298 , ale naprawdę bardziej zgaduję niż jestem pewien.

Gwarantuję że wiele nowych dem nie ruszy ze stacją, która miałaby 309 rpm (+3%) np demo z GCR on the fly, ale nie tylko.

Tak samo gwarantuję że jeżeli spadnie taktowanie 6502 w stacji do różnicy poniżej 270 cykli więcej niż w C64PAL (na ramkę) - przestanie działać loader AR - z prostej przyczyny: Loader to 2 programy - jeden w stacji, drugi w C64. Te programy podczas przesyłania bloku najpierw się synchronizują, a potem przesyłają po 4 bajty 2bitowo BEZ POTWIERDZENIA bazując na zsynchronizowaniu i prędkości obu procków (C64 i 1541). Potem jest szybkie dosynchronizowanie (JEDNO kliknięcie jedną linią serial portu) i kolejne 4 bajty bez potwierdzenia. aż osiągnie wielkość bloku.

Potwierdzam kolejny raz - naprawiłem kilka takich stacji, które miały za wolne taktowanie i nie działał na nich loader AR. Po usunięciu trymera i zastąpieniu go stałym kondensatorem wszystko wracało do normy. O ile pamiętam najbardziej zdegradowany trymer obniżał prędkość taktowania driva tylko do 100 cykli więcej na ramkę, niż w C64. Nie dawało się już trymera podkręcić i wyregulować.

Program do sprawdzania cykli na C64NTSC

Hornet pisze: ↑

28 wrz 2023, 15:12

Najpierw pozwoliłbym się pobić mojej dziewczynie po prawej, a potem pozwoliłbym żeby pocieszała mnie laska w czerwonym

pzdr

wegi pisze: ↑

28 wrz 2023, 23:07

Nie za bardzo rozumiem do czego te teoretyczne wywody prowadzą - skoryguję do praktyki.

Ne masz stacji - ja miałem ich z 10, także testowałem u kumpla, ale liczmy 10.

NIGDY nie regulowałem obrotów w moich stacjach, i jak pamiętam NIGDY ŻADNA z moich stacji nie przekroczyła, ba NAWET SIĘ NIE ZBLIŻYŁA do plus-minus 1% błędu - być może pierwsze stacje jakie wypuszczano były takie złomalne - ja posiadałem kilka 1541II/ jedną 1570/ jedną 1571/ jedną Oceanic9900. ŻADNA z tych stacji nie przekroczyła 1% błędu - ŻADNA.

Szczerze przyznam, że taka precyzja obrotów wprawiała mnie nawet do dzisiaj w osłupienie, ale tak naprawdę było. Zresztą łatwo to sprawdzić - wystarczy wziąć stację, podłączyć do C64 i uruchomić na C64 mój program do pomiaru spina.

Z tego co pamiętam to liczba 299 i 300 - nie pamiętam żeby jakakolwiek stacja miała np 301 czy 302 rpm, albo poniżej 299 ... No może RAZ 298 , ale naprawdę bardziej zgaduję niż jestem pewien.

Nie mam teraz , co nie znaczy ze nigdy nie mialem. Za to mam teraz 2 przy AppleII+
Nie ja pisalem ten dokument , ale wydaje mi sie ze osoba ktora go tworzyla wiedziala co pisze
Dobra, napisz mi moze w jaki sposob twoj program rozpoznaje ze nastapil pelny obrot dyskietki.

Bardzo prosto - już pisałem - odnajduje występujący jeden raz na ścieżce ciąg bitów - to jest np nagłówek sektora 0 - nie ma takiego drugiego nagłówka na ścieżce. Poza tym odnajduje kolejne nagłówki na ścieżce i w realtime wysyła o tym info do C64

Jeżeli znajdzie kolejny raz nagłówek sektora 0, to znaczy że nastąpił kolejny pełny obrót dyskietki. Można spojrzeć w źródło...

Pamiętajmy że pierwsze C64 to był totalny złom bardzo często uszkodzony już w samym sklepie - to wykupili bogaci Niemcy i Amerykanie. Więc myślę że pierwsze drivy mogły być tak ciulowe jak piszą, ale żadnych szans, żeby jakieś new age demo na tym chciało się ładować...

Rozumiem, że synchronizujesz się z sektorem 0.
No dobra, a czy korzystasz z jakichś swoich specjalnych procedur w napędzie, czy po prostu wykorzystujesz procedury systemowe?
W programie jest blad :
jest ";NTSC 65 CYCLES PER LINE 262 SCANLINES
a powinno byc "NTSC 64 CYCLES PER LINE 262 SCANLINES " jesli idzie o starsza wersje.

Systemowe procedury to przy memory-write do stacji i takie tam.

Korzystam z procedury ładowania/wysyłania 2 bitowego - to nie są systemowe procedury.

Między kolejnymi nagłówkami jest cały sektor przerwy - nawet tym zwykłym 2 bit proc zdążę wysłać kilkadziesiąt bajtów, a co dopiero jeden czy 2 żeby wysłać info, który aktualnie nagłówek jest odczytywany.
Informacja o każdym "nadjeżdżającym" sektorze idzie w realtime do C64 - co jest szczególnie widoczne po minucie, kiedy pokazuje ile zdążył przeczytać nagłówków z ostatniego "niezaliczonego" obrotu dyskietki - wtedy widzisz np 299 i "pół".

Błąd to nie wiem, już nie pamiętam ale chyba to miało być na 65 cykli...

Problem z tym programem jest taki, że tak naprawdę nie pokazuje on nam jaką jest rzeczywista częstotliwość zegara CPU, ani ile dokładnie obrotów dyskietki jest w czasie sekundy, a jedynie jakie jest różnica między częstotliwością a obrotami. A i tego nie jestem pewien.
Moim zdaniem urzycie go to jak gra w rosyjska ruletke.
Dodatkowo pomiar jest podlany sosem ciągłych synchronizacji głowicy i stacji dyskow z komputerem, które z zasady muszą wprowadzać błąd do pomiaru. A przy okazji opieramy sie na czastotliwosci CPU ktora to podejrzewamy ze jest zla (czyli za mala albo za duza)
Wszystko po to, aby pokręcić trymerem przy CPU w zależności od mało precyzyjnie ustalonej prędkości obrotowej za pomoca niepewnie dzialajacego CPU ,a która to z założenia jest już mało precyzyjna.
A przecież można to zrobić dużo łatwiej, a efekt będzie dużo bardziej dokładny, no i od razu będzie widać przyczynę problemu.
Wystarczy napisać procedurę dla stacji dyskow, która wykona pętlę trwającą ileś tam cykli, dajmy na to 1 milion. Na starcie ustawi linię np DATA np. na 0, a po wykonaniu pętli zmieni ją na 1.
Teraz wystarczy w C64 kontrolować stan linii DATA i policzyć w pętli przez ile cykli trwał stan 0. Błąd pomiaru będzie o rząd wielkości mniejszy, co najwyżej kilka cykli CPU potrzebnych na synchronizację (dokładnie 1 na starcie i 1 na końcu), a który to maksymalny błąd będzie przynajmniej znany i nie ulegal ciaglej kumulacji.
A jak juz bedzimy miec prawidlowa czestotliwosc zegara w stacji to ustalenie faktycznej predkosci obrotowej bedzie dziecinnie latwe.

Poza tym zastanawiam sie dlaczego kolega uwziol sie na trymera od CPU ze ten zawsze jest uszkodzony a nie bierze pod uwage pyrka w tachometrze ktory wlasnie jest po to aby serwisant mogl sobie pokrecic i ustawic i to doslownie na oko

hobocti77x_ pisze: ↑

29 wrz 2023, 12:24

Moim zdaniem urzycie go to jak gra w rosyjska ruletke.

bzdura

hobocti77x_ pisze: ↑

29 wrz 2023, 12:24

Dodatkowo pomiar jest podlany sosem ciągłych synchronizacji głowicy i stacji dyskow z komputerem, które z zasady muszą wprowadzać błąd do pomiaru.

kolejna bzdura (nie ty jeden nie potrafisz sobie wyobrazić co się dzieje jednocześnie w stacji i C64, poza tym nagłówki sektorów pozostają w tym samym miejscu dyskietki przez cały czas do momentu kolejnego formatowania ścieżki)
Gdyby twoje założenia były prawidłowe nie byłoby po co pisać loadera AR czy innych fastloaderów, bo nie miałyby prawa działać - a jednak są i działają.

hobocti77x_ pisze: ↑

29 wrz 2023, 12:24

Problem z tym programem jest taki, że tak naprawdę nie pokazuje on nam jaką jest rzeczywista częstotliwość zegara CPU, ani ile dokładnie obrotów dyskietki jest w czasie sekundy, a jedynie jakie jest różnica między częstotliwością a obrotami. A i tego nie jestem pewien.

Kolejny raz nie rozumiem logiki twojego wywodu i nie jestem pewien do którego programu się czepiasz (spin/cycles), Nie potrafisz zrozumieć rozwiązywania problemu od strony programowej - np zamiast rozkręcać staję i podłączać oscyloskop, czy miernik częstotliwości lub pojemności - wystarczy uruchomić program i po sekundzie wiedzieć czy jest "rozcyklowanie".

Określenia "różnica między częstotliwością a obrotami" nie rozumiem ponownie. Pomiędzy którą częstotliwością C64 czy 1541?

O czym już pisałem sztuczki stosowane w pomiarze spinu 1541 za pomocą timera będą błędne jeżeli zmieniła się podstawa czasowa - to chyba łatwo zrozumieć, że jeżeli masz błędną podstawę czasową, to źle mierzysz czas?
Z tego powodu mierzę za pomocą przerwań rastra C64 ilość zliczonych pełnych obrotów przez minutę - to dokładnie oddaje jakość pomiaru, jeżeli spojrzysz na idiotów próbujących określać częstotliwość sygnału mierząc czas pomiędzy dwoma zboczami. O wiele dekad dokładniejszy jest pomiar zliczenia cykli w okresie jednej sekundy - tu masz analogię do pomiaru spinu.

Program cycles pokazuje różnice w cyklach pomiędzy C64 i 1541 w określonym czasie (ramki na C64) - nie trzeba geniusza matematycznego, wystarczy kalkulator albo arkusz excela, żeby przenieść to na częstotliwość jeżeli nie wystarcza ci informacja że jest OK jeżeli masz różnicę w zakresie 273-303 cykli.

hobocti77x_ pisze: ↑

29 wrz 2023, 12:24

Poza tym zastanawiam sie dlaczego kolega uwziol sie na trymera od CPU ze ten zawsze jest uszkodzony a nie bierze pod uwage pyrka w tachometrze ktory wlasnie jest po to aby serwisant mogl sobie pokrecic i ustawic i to doslownie na oko

Bo to zdało egzamin i naprawiało stację - gdyby stacja miała właściwą różnicę w cyklach w porównaniu do C64 - wówczas podejrzanym jest mechanizm obrotowy (I jak widać drugi program ma jak najdokładniej określać SPIN!). Nie twierdzę że można go wykluczyć, czy że nigdy nie nie rozkalibrowywuje - po prostu jak widać częściej psuje się trymer.

edit:
I jak widać drugi program ma jak najdokładniej określać SPIN!

wegi pisze: ↑

28 wrz 2023, 14:35

Z ustaleń empirycznych stwierdziłem, że wszystko działa, jeżeli w stacji przeleci w okresie 1 ramki PAL więcej cykli w stacji. Ilość, jaka nie sprawiała problemów, to różnica w zakresie 273-303 cykli więcej w stacji.
Wielkością domyślną jest zakres około 286-296 cykli więcej.

Nie zamierzam się z nikim kłócić. Po prostu pewne informacje mi nie pasują do teorii.
Pierwsza to ilość obrotów Commodore twierdzi, że dopuszczalna różnica to +-3% od 300 obr. czyli zakres 291-309. 273- to już jest prawie -10%.
Druga kwestia:
Według tego i nie tylko tego wiadomo, że pojemność ma niewielki wpływ na zmianę częstotliwości kwarcu, po prostu jak będzie za mała, to kwarc nie będzie pracował, a jak za duża, to efekt będzie podobny.
Co prawda producenci podają parametry pojemności, przy której częstotliwość kwarcu jest najbliższa częstotliwości, do jakiej został przycięty, ale zmiana pojemności tak naprawdę wynosi maksymalnie ok. 0.005 proc przy zmianie pojemnosci w pelnym zakresie i jest podana w jednostkach ppm, czyli ilość taktów odchylki na milion (500, -300 dla przykladowego kwarcu) , zreszta jest porownywalna z wplywem temperatury.
https://ep.com.pl/i/2022/01/31/85405-dd ... asu-r2.jpg
https://ep.com.pl/rynek/temat-miesiaca/ ... ci-i-czasu.
W końcu problem numer 3.
Tu ktoś twierdzi https://www-baltissen-org.translate.goo ... _tr_tl=en&, że napęd 1541 powinien przynajmniej w teorii prawidłowo czytać przy zmianach prędkości w zakresie 225-375
"IMHO this would mean speed of a drive could drop as low as 225 RPM before an error will occur.
A 1, that shows up shortly after the second 0 has been clocked in, will be noted as well. This would mean that a drive can be too fast for up to 375 RPM" oczywiście o ile mówimy o torze odczytu z dyskietki, a nie możliwych Turbo do transmisji pomiedzy 1541 a c64

hobocti77x_ pisze: ↑

03 paź 2023, 16:29

Pierwsza to ilość obrotów Commodore twierdzi, że dopuszczalna różnica to +-3% od 300 obr. czyli zakres 291-309. 273- to już jest prawie -10%.

Cały czas błędnie obliczasz procenta przyjacielu.
Mówimy o:

19656 cykli w C64 PAL
19946 cykli w stacji [stacja w NTSC ]

czyli 1% odchyłki to 199.46 obrota
sytuacja optymalna - różnica 290 cykli

290 / 199.46 = 1,453925599117618 %

Powiedzmy około półtora procenta.
I teraz od tego półtora procenta 10% to będzie około 0.15%

Przy okazji te półtora procenta to jak spojrzymy na C64PAL = 0.985 versus stacja 1MHz - widać zbieżność ???

Program potwierdza że C64PAL działa wolniej i w dodatku 1.5% wolniej - teoria zgodna z praktyką.
Rozlajrowany trymer zjechał do granic 100 cykli różnicy jak pamiętam.

Dobra teraz te nieszczęsne obroty:

Ze schematu widać, że DS działa tak, że bajt GCR w $1c01 jest generowany dla odpowiednich grup ścieżek
co 24, 26, 28 i 30 cykli jak pamiętam.

I teraz co może sprawiać problemy, to przede wszystkim stacja z przyspieszonymi obrotami. Dlaczego?

Weźmy odczyt sektora w normalu:
Teraz dla porównania odczyt sektora GCR z AR:
Pamiętajmy że nie można przekroczyć magicznej wartości 24 cykli pomiędzy odczytem $1c01, bo będzie katastrofa. Trzeba też za każdym razem robić
Teraz proste wyobrażenie - przede wszystkim stacja musi działać jak najdokładniej te 300rpm, bo inaczej jak z taśmą magnetofonową - bity będą przyjeżdżać za wcześnie, albo za późno!!!

Problemy są 2:

Pierwszy, że co 24 (i odpowiednio dla grupy ścieżek 26,28,30) cykle generuje się bajt, jakkolwiek nie zakręcisz dyskiem - czyli jak nim zakręcisz za szybko, czy za wolno - to z odczytu NICI.

Po drugie przy przyspieszonych obrotach loadery typu AR mają problem bo mogą nie zdążyć odczytywać danych - jeżeli odczyt ma napięty do granic czasowych generowania się bajtu w rejestrze przesuwnym.

Więc przede wszystkim jest problem że z dużym prawdopodobieństwem nie odczytasz dyskietki ode mnie, jeżeli ja nagrałem dla ciebie pliki w 300 rpm, a ty masz 309 - po prostu nierealne.
Swoje pliki samemu sobie możesz nagrywać i odtwarzać, jeżeli stacja chociaż odbiega od 300 rpm, to tak jak z ABC turbo - będzie działać w obrębie tej konkretnej stacji.
Czyli nie możesz odczytać dysku ode mnie, ani wysłać mi swojego dysku, żebym ja go odczytał.
I chyba dlatego te drivy tak składnie utrzymują 300 rpm

ufff...

Idąc dalej - te same zależności jak z prędkością obrotową są dla zmieniającego się taktowania procesora.
uff2

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?
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.
I z tego, co wiem, wszystkie napędy dysków tak naprawdę były robione na system FM, czy to zastosowany w PC, Atari, Commodore czy Apple.
W systemie FM okienko na bit wynosi 4 us. (stąd to magiczne 250 kHz). Co ciekawe, kontroler aby zorientować się o wartości bitu nie potrzebuje aż 4 us, a w przypadku FM tylko 2/3 tego czasu, a w GCR nawet mniej.
Dlatego zmiana prędkości wywoła błąd, jeśli bit będzie trwał dłużej niż magiczne 4 us, lub krócej niż 2/3 z 4 us.
A jedna 1/3 to tak ok. 33%.
Co ciekawe, w stacjach Commodore i nie tylko jest magiczny układ 9602, który tak naprawdę jest układem 74ls123, tyle że o innych wyprowadzeniach, i to on generuje cykl odczytu, a jego stała czasowa jest zawsze taka sama, i to on generuje cykl zegara potrzebny do wysterowania rejestru kontrolera.
To, że wystarczy 2/3 a nie całe 4 us, wykorzystał Commodore do przycięcia nieco czasu na bit, i dzięki temu uzyskał więcej danych na dyskietce. Ale coś za coś, Commodore, co prawda, mógł przechować więcej danych na dyskietce, ale stracił bardzo ważną możliwość dla komputerów profesjonalnych, którą z klei zachowal Wozniak projektując kontroler dla Apple. A mianowicie możliwość zapisu/odczytu nie tylko w GCR, ale także i FM, który to system był najbardziej powszechny wśród komputerów.
I to moim zdaniem oprócz znacznie wyzszej ceny zestawu ze stacja dyskow niz podobny zestaw AppleII bylo gwozdziem do trumny projektu PET jako komputera profesjonalnego

Zresztą pozostał w PC do końca czasu stosowania dyskietek.

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: I oto co równolegle na to robi 1541: