Temat: Wzór do obliczania baudrate POKEY-a - błędny?

Cześć

Pisał o tym już mono w tym miejscu http://atariarea.krap.pl/forum/viewtopi … 81#p132381 - ale jakoś przeszło to bez echa. Otóż w dokumentacji POKEY-a jest podany wzór do obliczenia szybkości transmisji szeregowej z wartości licznika, czyli inaczej mówiąc z HS_INDEX. Ten wzór (dla PAL-u) to:

baudrate = 1773446/(2*(HS_INDEX+7))

Wszelako, z eksperymentów dokonywanych programem SIO2BSD (przy czym mono uruchamia go na pececie z Linuxem, a ja z FreeBSD) wychodzi, że ten wzór jest błędny, obliczona w ten sposób na pececie i tamże ustawiona prędkość transmisji nie zgadza się z prędkością wybraną na POKEY-u przez wartość HS_INDEX, i to na tyle, że przy niskich wartościach HS_INDEX (typu 0) nie ma pomiędzy komputerami łączności.

Eksperymentalnie ustaliliśmy (tj. mono ustalił, a ja się przyglądałem ;) ), że we wzorze zamiast "plus 7" powinno być "plus 7 z czymś", przy czym to "coś", to ułamek w rodzaju 0.13-0.25.

Pytania:

1) czy ktoś coś wie na ten temat? :) Domyślam się, że częstotliwości generowane przez POKEY są mierzalne, wobec tego może już je ktoś dokładnie pomierzył.

2) z czego może wynikać niecałkowita wartość współczynnika? Jakieś opóźnienia na bramkach wewnątrz POKEY-a? Błąd w naszym rozumowaniu albo w obliczeniach? Niekompatybilność RS-232 i SIO?

Ostatnio edytowany przez drac030 (2011-08-20 15:38:55)

KMK
? HEX$(6670358)

2

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

drac030 napisał/a:

Eksperymentalnie ustaliliśmy (tj. mono ustalił, a ja się przyglądałem ;) ), że we wzorze zamiast "plus 7" powinno być "plus 7 z czymś", przy czym to "coś", to ułamek w rodzaju 0.13-0.25.

Tzw. stała mono-draco. ;)

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

3

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Od czego w ogóle wyszedłem? Od analizy kodu AspeQt, bo tam komunikacja przy niskich indeksach szła pięknie. No i okazało się, że tam w pliku serialport.h jest taki kwiatek:

    static inline int divisorToBaud(int divisor)
    {
        switch (divisor) {
        case 0:
            return 125494;
            break;
        case 1:
            return 110765;
            break;
        case 2:
            return 98797;
            break;
        default:
            return (int)(1781610.0 / (2*(divisor+7)));
        }
    }

1.781610 okazała się przybliżoną średnią między kwarcami PAL i NTSC z FREDDIEm (dokładna wychodzi 1781609.75). Ale poza tym to prędkości dla najwyższych indeksów są jakieś od czapy, bo w żaden sposób nie wychodzą ze znanych wzorów. ALE DZIAŁAJĄ!
Policzyłem w którą stronę jest więc odchylenie no i zacząłem eksperymentować z dobieraniem części ułamkowej do 7 wychodząc z założenia, że dla niskich prędkości błąd będzie nieznaczny i POKEY da sobie radę, a dla wysokich da się ustalić wzór liczący precyzyjnie działającą prędkość. No i metodą kolejnych przybliżeń (kiedy jeszcze działa, a kiedy już nie) wyszło mi 7.13.
Sprawdziłem czy wszystko działa na Atari z PAL, ale nie wiem czy będzie to jeszcze działać dla NTSC. Dla PAL z poziomu PC transmisja działa zarówno kiedy liczę zakładając zegar bazowy PAL, NTSC, NTSC z Freddie, jak i średnią wartość taką jak w AspeQt (PAL - NTSC-Freddie), jak i między dwoma skrajnymi częstotliwościami PAL i NTSC.
Niestety Dracowi już nie zadziałało - dla niego współczynnik wychodzi 7.25.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

4

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

trzba zlapac kogos z oscyloskopem i po prostu te czestotliwosci pomierzyc...
lepiej miec "stale", ale pewne wartosci (tj. pewnie plywajace nieco miedzy egzemplarzami), niz wyliczane z wzoru "na oko" przyblizajacego wartosc...

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

5

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Nie z oscyloskopem, a z częstościomierzem raczej. Oscyloskop za mało precyzyjny. Jak nie zapomnę, to w poniedziałek zmierzę.

Ceterum censeo Unionem Europaeam delendam esse.

6

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

mono napisał/a:

Niestety Dracowi już nie zadziałało - dla niego współczynnik wychodzi 7.25.

Korekta: raczej coś pomiędzy 7.15 a 7.20.

PS. Poza tym mój pecet jest jakiś bardziej restrykcyjny, żeby w ogóle transmisja z indeksem 0 szła jako tako, muszę przyjąć zegar bazowy PAL, bo przy zegarze NTSC albo NTSC-F albo średniej PAL/NTSC - niezależnie od współczynnika - od razu lecą błędy transmisji (gł. sumy kontrolnej).

Ostatnio edytowany przez drac030 (2011-08-20 18:21:52)

KMK
? HEX$(6670358)

7

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Chciałbym tylko zauważyć, że dane z Atariki nie przedstawiają się liniowo.

Post's attachments

Wykres Baudrate PAL.jpg 112.59 kb, nikt jeszcze nie pobierał tego pliku. 

Tylko zalogowani mogą pobierać załączniki.

8

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

nie liniowo tylko 1/f...

9

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

pajero napisał/a:

Chciałbym tylko zauważyć, że dane z Atariki nie przedstawiają się liniowo.

Chyba trudno, żeby przedstawiały się liniowo, skoro HS_INDEX jest dzielnikiem częstotliwości?

KMK
? HEX$(6670358)

10

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Może problemy wynikają raczej z braku możliwości ustawienia dokładnej prędkości transmisji po stronie PC lub z zakłóceń?

https://www.youtube.com/watch?v=jofNR_WkoCE

11

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Myślę, że zakłócenia spokojnie można wyeliminować. Ale jest tu jeszcze jedna rzecz, o której zapomniałem napisać, mianowicie obaj korzystamy nie z rzeczywistego portu RS-232, ale z konwertera COM2USB. Być może on tu coś miesza.

Co do tej drugiej możliwości, sam jestem ciekaw, dlatego z niecierpliwością czekam na potwierdzenie (zaprzeczenie), że częstotliwość wypuszczana przez POKEY (przy indeksie 0 na przykład) to ta sama, która wychodzi z wzoru widocznego w docach Atari.

KMK
? HEX$(6670358)

12

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

hint, spróbuj podzielić 48MHz tak, aby dało wartości wynikające ze wzoru

przechodze na tumiwisizm

13

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Niech będzie 24 MHz, żebym miał trudniej. Proszę:

1773446 / 14 = 126674,71428571428571428571428571..., niech będzie 126675.

24000000 / 126675 = 189,46121965660153937240970988751... niech będzie 189.

24000000 / 189 = 126984,12698412698412698412698413... niech będzie 126984.

Różnica:

(126984 / 126675) * 100 - 100 = 0,24393132030787448194197750148017... niech będzie równo ćwierć procenta.

Tymczasem RS-232 powinien tolerować odchylenia do 5%.

Ostatnio edytowany przez drac030 (2011-08-21 18:52:40)

KMK
? HEX$(6670358)

14

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Mnie linux raportuje 24MHz. Dzielniki działające (na brzegach względnie stabilnie) są w zakresie:

divider baud(PC)            dev(pal)            dev(ntsc)
190     126315,789473684    0,0028339991939     0,01192969909216
191     125654,45026178     0,00805476359602    0,01710284202885
192     125000              0,01322114503563    0,02222209805995
193     124352,331606218    0,01833398884373    0,02728830480575
194     123711,340206186    0,02339412292186    0,03230228261603
195     123076,923076923    0,02840235818893    0,03726483501287
196     122448,979591837    0,03335948901449    0,04217674911995
197     121827,411167513    0,03826629363878    0,04703879607873
198     121212,121212121    0,04312353458       0,05185173145207
199     120603,015075377    0,04793195902935    0,05661629561563

Odchylenia liczyłem dla baud=126674,785714286 PAL i 127840,892857143 NTSC wyliczone ze wzoru Atari.
No to teraz jeśli przyjąć że tolerancja POKEYa jest symetryczna, to prawdziwa prędkość transmisji to 123.35kbaud? Skoro tak, to może współczynnik jednak powinien wynosić 7,18610754177378?

Edit: divider w tabelce a nie hsidx; hsidx to oczywiście 0

Ostatnio edytowany przez mono (2011-08-21 18:58:44)

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

15

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Próbowaliście porównać odebrane dane z wysyłanymi? Czy np. uszkodzone są pojedyncze bajty a w nich zgubiony lub zbyt długi jeden bit (chociaż często to pewnie i tak skończy się problemem z bitem stopu lub startu następnego bajtu)? Albo zgubione dłuższe bloki? Albo jeszcze coś innego?

Ostatnio edytowany przez epi (2011-08-21 19:19:37)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

16

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Tobie chodzi o porównywanie danych przy nieudanych transmisjach czy w ogóle? Bo w ogóle to wczoraj przewaliłem 32 MB w dwie strony (tj. Atari->PC-Atari), blokami po 32985 bajtów, i nie było różnic między źródłem a celem.

Natomiast przy nieudanych, to są dwa rodzaje:

1) dane odbierane przez peceta w ogóle nie przypominają niczego, co Atari mogłoby wysłać - to przy ogólnym braku komunikacji

2) błędy u mnie to na ogół błędy sumy kontrolnej, wtedy suma różni się różnie, czasem o 1 bit, czasem zupełnie

Jeśli on coś w ogóle zgubi, to właśnie nie dłuższe bloki, ale raczej krótsze (potwierdzenia).

KMK
? HEX$(6670358)

17

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Z ciekawości pomierzyłem częstotliwości swoim oscyloskopem. Nie mam 100% pewności, czy mierzy poprawnie, bo nigdy tego nie sprawdzałem. Wszystko, co w tym zakresie podaje specyfikacja, to dokładność bazy czasu +/- 50ppm.
Komputer 800XE, bez rozszerzeń.
Wyniki pomiarów:
Częstotliwość sygnału OSC na nóżce 37 FREDDIE-go: 3,5468001MHz
Częstotliwość sygnału ACLK na nóżce 27 POKEY-a przy zawartości rejestru AUDF3/AUDF4:
0 - 126,67200kHz / 126,67000kHz
1 - 110,83800kHz / 110,83599kHz
2 - 98,522003kHz / 98,524002kHz
3 - 88,670005kHz
4 - 80,610000kHz / 80,608001kHz
5 - 73,892000kHz / 73,889999kHz
6 - 68,208000kHz / 68,206001kHz
8 - 59,114002kHz / 59,111999kHz
9 - 55,418000kHz / 55,417999kHz
10 - 52,158000kHz / 52,15999kHz
16 - 38,552001kHz / 38,55400kHz
40 - 18,866001kHz

Wskazania nie są całkowicie stabilne, bo z reguły pojawiają się na przemian dwie (podane)  wartości, z których jedna (pierwsza) jest czasowo wyraźnie dominująca. Wystarcza to jednak do stwierdzenia, że podany wzór na baudrate wygląda na poprawny.

Ostatnio edytowany przez Simius (2011-08-21 21:20:33)

Ceterum censeo Unionem Europaeam delendam esse.

18

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Hmm wiem ze sie nie znam ale od dawna mam do atarki zrobiona transmisje PC- USB - Apeqt indeks zero bez problemow, zapis i odczyt ?

Dwa korce ziemniaków, gęsich jajek kopa, żeby móc to połknąć, tęgiego trza chłopa. GG3456993

19

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Nienaganny synchronizm sygnałów O2 i ACLK (z lekkim tylko przesunięciem fazy) świadczy o tym, że współczynnik podziału jest z absolutną pewnością liczbą całkowitą.

Ostatnio edytowany przez Simius (2011-08-21 21:52:58)

Ceterum censeo Unionem Europaeam delendam esse.

20

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Hmm, no to ja nie wiem. Wynika z tego, że wzór jest OK, a na pececie wyliczony divisor 189 jest akurat o 1 poza zakresem tych, które działają. I ja bym jeszcze pojął, gdyby to był jednostkowy przypadek błędu w programie, błędu w driverach (na dwóch różnych OS-ach?), ale w aspeqt mamy poniekąd to samo (post nr 3, zaxon).

KMK
? HEX$(6670358)

21

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

@zaxon: Chodzi nam o to, wg jakiego wzoru należałoby liczyć prędkość transmisji w PC tak, żeby komunikacja z Atari działała bezproblemowo. Ponieważ prędkość liczona wg wzoru z Atariki nie działa dla niskich indeksów (w AspeQt 3 najwyższe prędkości mają _predefiniowane_ wartości i bynajmniej nie są to wartości wynikające ze wzoru - są niższe; AspeQt liczy też prędkość transmisji zakładając uśredniony między PAL a NTSC z Freddym zegar taktujący POKEY).

@Simius: Wielkie dzięki za pomiary. Przynajmniej wiadomo, że wzór w Atariki jest jednak poprawny, a przyczyna rozbieżności musi leżeć gdzieś indziej.

hex, code and ror'n'rol
niewiedza buduje, wiedza rujnuje

22

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Skoro poprawny jest wzór na Atari, to prawdopodobnie błędny jest wzór na PC, bo co innego?

Ceterum censeo Unionem Europaeam delendam esse.

23

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

To może te 24 MHz to nie jest 24 MHz. Tylko jeszcze nie wiem co mogłoby być tego przyczyną. Np. dla FT232R producent podaje, że częstotliwość wewnętrznego oscylatora jest 11.98 .. 12.02 MHz, co przy 120 kbit/s daje różnicę na czwartej cyfrze znaczącej, a u mono zakres poprawnego działania jest większy. A kwarc powinien być jeszcze dokładniejszy.

Edit: no tak, przyczyną może być zły wzór. ;)

Ostatnio edytowany przez epi (2011-08-21 22:12:48)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.

24

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

simius, rzecz w tym, że jedyny "wzór na PC", który może tu wchodzić w rachubę, to ten właśnie, o którym tu mowa. Chyba, że mówisz o wzorach, którymi systemy operacyjne w pecetach (licząc z Windowsami - trzy różne) wyliczają clock divisor dla podanej wartości baud rate. Ale na to nie mamy wpływu i wydaje mi się dziwne, żeby w trzech różnych OS-ach było to zrobione tak samo źle.

Epi, różnica jest rzędu 2,5%, przy 24 MHz daje to 600 kHz, wtedy przyjmowanie zegara 24,0 MHz byłoby sporym nadużyciem.

Ostatnio edytowany przez drac030 (2011-08-21 22:15:09)

KMK
? HEX$(6670358)

25

Odp: Wzór do obliczania baudrate POKEY-a - błędny?

Jeśli wszystkie te drivery w różnych OSach pochodzą np. z FTDI, to w sumie dlaczego nie miałyby być tak samo zepsute?

Ostatnio edytowany przez epi (2011-08-21 22:16:24)

Hitler, Stalin, totalniak, SSman, NKWDzista, kaczor dyktator, za długo byłem w ChRL, wypowiadam się afektywnie.