26

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

Powtarzalność błędu może świadczyć o jego wspólnym źródle. To, że coś na PC jest zrobione źle, nie byłoby akurat niczym szczególnie zaskakującym.

Ceterum censeo Unionem Europaeam delendam esse.

27

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

Ok, macie rację, na szczęście te drajwery są w postaci źródłowej (przynajmniej dla Linuxa i BSD), można sprawdzić wzory.

KMK
? HEX$(6670358)

28

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

Udało nam się wykluczyć sterowniki USB i w ogóle całe USB jako przyczynę problemu:

1) w obliczeniach przeprowadzanych przez sterownik uftdi na FreeBSD i przez odpowiednik na Linuxie nie widać niczego podejrzanego

2) źródła w necie twierdzą, że zegary 48 MHz dla USB są "very accurate" (to a propos podejrzeń, że 48 MHz w rzeczywistości równa się 49,2 albo 49,4 MHz)

3) najważniejsze: kod AtariSIO Hiasa (wersja z 28 maja 2011) zawiera dokładnie te same kombinacje z wysokimi wartościami bitrate, mimo że w grę nie wchodzi USB, ale zwykły UART 16C950.

Ma ktoś jakiś pomysł, o co tu chodzi?

Ostatnio edytowany przez drac030 (2011-08-22 00:46:02)

KMK
? HEX$(6670358)

29

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

zmierz fizycznie co masz na wyjsciu z konwertera (bitrate) i w ten sposob zweryfikuj wzorek podany przez producenta z realiami

przechodze na tumiwisizm

30

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

Pytaliście autorów AspeQT i AtariSIO, czy swoje cyferki znaleźli eksperymentalnie, czy też stoi za nimi jakaś teoria?

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

31

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

Po mojemu problem leży w pojemnościach obciążających linie transmisyjne. Przy prędkości 126kbit/s różnica czasu propagacji stanu niskiego i wysokiego, mierzona na poziomie 2,5V, jest bliska połowie bitu a wówczas próbkowanie wypada na zboczu, co wystarczy, żeby skutecznie popsuć transmisję. Niewielkie obniżenie prędkości odbiornika poprawia sytuację, bo próbkowanie odjeżdża od zbocza. Sugeruję zmianę kondensatorów na wejściu i wyjściu danych z 1nF do 330pF i rezystorów podciągających z 4,7k do 2,2k.

Ceterum censeo Unionem Europaeam delendam esse.

32

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

Do listy hipotez dodałbym, że POKEY przy odbieraniu asynchronicznym może mieć opóźnienie w resetowaniu licznika po pojawieniu się bitu startu, rzędu kilku cykli. Niższa prędkość transmisji pozwala dobrze chwycić wszystkie bity mimo tego opóźnienia. Być może innym sposobem jest wydłużenie bitu stopu. Podobnie może być w drugą stronę (Atari->PC).

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

33

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

po co mierzyć na 2.5V skoro układ ma vih=2.2V?
kondensatory w zależności od płyty są, albo ich nie ma

przechodze na tumiwisizm

34

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

Candle napisał/a:

kondensatory w zależności od płyty są, albo ich nie

Słuszna uwaga. To tak, jak i POKEY-e. W zależności od płyty są, albo ich nie ma.

Ceterum censeo Unionem Europaeam delendam esse.

35

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

A jak to wygląda w firmware SIO2SD, skąd Jakub wziął wartości? Tam chyba też są dostępne te niskie wartości HSIndex?

36

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

Chwilowo dalsze prace są spowolnione, bo obowiązki zawodowe itp. Ale zdaje się, że problem da się zawęzić do HS Indexu 0, już HS Index 1 chodzi (u mnie przynajmniej) perfekcyjnie wg wzoru podanego przez Atari.

Niezbyt wierzę, że wina jest po stronie peceta; konwerter USB natomiast, jak to opiewa ulocia producenta, ma obsługiwać transfery do 3 Mbit/s, trudno zatem przypuszczać, żeby miał kłopot ze 126 kbit/s.

Problem musi leżeć gdzieś po stronie Atari: albo chodzi o zniekształcenia sygnału powodowane przez elementy na płycie (jak sugeruje Simius), albo - ale to czysta spekulacja z mojej strony - POKEY ma błąd (ewentualnie jakieś ograniczenie, jak sugeruje Fox), w wyniku którego SIO w jakiś sposób wariuje przy indeksie 0. To też trzeba byłoby może obejrzeć pod oscyloskopem, jak wyglądają ramki wypuszczane z Atari w stronę peceta. Bo błędy - i ogólnie kłopoty z komunikacją - wyskakują też przy zapisie.

Poczyniliśmy z mono jeszcze jedną obserwację: mianowicie on peceta podpina w nieco mniej skomplikowany sposób niż ja, bo przez IO-Board, u mnie natomiast konwerter COM2USB jest ten sam, co w IO-Board, ale jeszcze mam SIO2PC. To może wyjaśniać, dlaczego po obliczeniu szybkości transmisji z odchyłką (7,18 zamiast 7) u mono HS Index 0 działa superstabilnie, u mnie natomiast jednak nieco kapryśnie (wyżej pisałem o "większej restrykcyjności" mojego zestawu, acz wtedy zwalając na peceta). Tzn. jednego dnia godzinami działa dobrze, a drugiego, po zmianie kierunku wiatru, już pojawiają się okazjonalne wywałki.

Ostatnio edytowany przez drac030 (2011-08-22 21:52:27)

KMK
? HEX$(6670358)

37

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

a to nie ten problem wyjasnil i rozwiazal JkZ?
http://sio2sd.gucio.pl/wiki/HighSpeed_pl

Ostatnio edytowany przez xxl (2011-08-22 22:17:50)

http://atari.pl/hsc/ad.php?i=1.

38

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

Trudno powiedzieć, czy to rozwiązuje problem opisywany w wątku (który chyba czytałeś, skoro piszesz posta?), czy też tylko stabilizuje transmisję.

Ostatnio edytowany przez drac030 (2011-08-22 22:26:05)

KMK
? HEX$(6670358)

39

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

Wystarczy poprosic Simiusa zeby zrobil pomiary ale nie na nozkach pokeya i wszystko stanie sie jasne.

http://atari.pl/hsc/ad.php?i=1.

40

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

No, jak napisałem w poście 36.

KMK
? HEX$(6670358)

41

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

Hias w dyskusji odnośnie AtariSIO z Toms Turbo na AAge napisał, że to on podał te wartości autorowi AspeQT.

42

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

Tak myślałem, bo źródło AtariSIO zawiera całą listę szybkości z dopiskiem "działa"/"nie działa", więc widać, że eksperymentalnie to ustalał.

Jedyne nowe ustalenia są takie, że przyjęcie stałej 7.18 potrzebne jest tylko przy indeksie 0, reszta działa przy 7. Do dalszych badań potrzebny jest ktoś kumaty z oscyloskopem i wolnym czasem.

KMK
? HEX$(6670358)

43

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

Aby nie uciekło:

HiassofT napisał/a:

There's no magic behind the settings :)

I had already determined the working baudrates (up to divisor 0) for AtariSIO before, most important thing here is that you stay BELOW the value calculated from the well known POKEY divisor formula. Ah, well, and for divisor 0 it also helps to know that you have to stay somewhat below the calculated value.

In AtariSIO I currently use 125494 / 110765 / 97010 baud for divisor 0/1/2 (the divisor-2 setting just for testing, see tools/MiscUtils.cpp for other values, and driver/atarisio.c for the exact 16C950 UART configurations), in AspeQt we use 125494 / 110765 / 98797 baud for divisor 0/1/2.

The FT232BM has a baud_base of 24000000 (24MHz, check with "setserial -a"), so we are actually using 125654 / 110599 / 98765 baud (FTDI divisors 191, 217, 243).

The only thing left was a method to set those unusual baudrates in Linux, which can be done quite easily with the TIOCSSERIAL ioctl: include ASYNC_SPD_CUST in serial_struct.flags and set serial_struct.custom_divisor (see StandardSerialPortBackend::setSpeed method in serialport-unix.cpp of AspeQt source). That's it :)

44

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

Ale tyle to wiemy od pierwszego postu. I raczej nikt nie przypuszcza, że w grę tu wchodzi jakaś magia.

KMK
? HEX$(6670358)

45

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

Some more explanation:

Back in 2009 I did some tests and discovered 2 important things:

Bit sampling in pokey is shifted by 5 PHI2 cycles, at divisor 0 sampling takes place in cycle 12 of 14, not in cycle 7 or 8 (the center of the bit) as one would expect. This explains the asymmetric tolerance against baud-rate deviations, you don't have some +/- 3% as usual but something like -6% .. +0% (i.e. lower speeds working fine, but higher speeds result in failures).

At divisor 0 it's even worse, one byte would usually be 14*10 = 140 PHI2 cycles, but POKEY isn't able to detect a new start-bit at cycle 140. Detection works fine at cycle 141 and later, so you need to lower transmission speed (I guess this was your main question). If the start bit begins at cycle 140, pokey synchronizes on the next high-to-low transition in the bit stream and uses this as the start-bit (which isn't correct, of course...).

In my patched SDrive firmware I disabled the transmitter UART and used bitbanging to work around the problems: I stretched the start-bit by 5 cycles, to compensate for late-sampling, and also stretched each bit by one atmel cycle so that the baudrate matches approximately the PAL Atari rate (SDrives uses a 14.318MHz "NTSC" crystal).

Other solutions can also just use a lower baudrate or, within several limitations, add a second stop-bit (but the latter doesn't help you with the late-sampling issue, so using a lower baudrate is preferable).

In the "real world" you also have to pay attention to 2 other things, but I guess you all know them very well already:

One thing is the speed difference between PAL and NTSC Ataris, you have to set your baudrates so that they work with both systems. It's fine to choose the lower speed PAL baudrates, due to late-bit-sampling.

The other thing is signal rise/fall time on the SIO bus, especially if you have a lot of devices connected. The edges are then far from being steep (looking more like a sine than a square wave), so detection of the start-bit (high-to-low transistion) can be somewhat skewed, by a few PHI2 cycles (let's say 1 or 2).

As for the baudrate values in atarisio: I wrote a small program to calculate all possible baudrates my 16950 UART could generate (you have fine-grained control over baudrates by using the times-clock and clock-prescaler registers) which matched somewhat the calculated NTSC/PAL pokey baudrates. At this time I didn't know about late-sampling and min. 141 cycles so I just experimented with different baudrates/stopbits. Later I started to investigate things, then knew that I had to keep the baudrates somewhat lower (at least with divisor 0 and 1), and kept the old testing-parameters as a reference in the source.

BTW: I wrote a short summary about this POKEY behaviour at the end of the README of my highspeed patch. Back in 2009 I was discussing the research in a thread on AtariAge: http://www.atariage.com/forums/topic/13 … try1696180. In 2010 I did some more tests, now also covering pokey IRQ timing, and also hooked up my logic analyzer. The discussion was also on AtariAge: http://www.atariage.com/forums/topic/16 … ng-details, the test-programs included in this thread also contain the logic-analyzer captures in VCD format (use gtkwave to view them), in case you are curious :)

so long,

Hias

46

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

HiassofT napisał/a:

Bit sampling in pokey is shifted by 5 PHI2 cycles, at divisor 0 sampling takes place in cycle 12 of 14, not in cycle 7 or 8 (the center of the bit) as one would expect. This explains the asymmetric tolerance against baud-rate deviations, you don't have some +/- 3% as usual but something like -6% .. +0% (i.e. lower speeds working fine, but higher speeds result in failures).

At divisor 0 it's even worse, one byte would usually be 14*10 = 140 PHI2 cycles, but POKEY isn't able to detect a new start-bit at cycle 140. Detection works fine at cycle 141 and later, so you need to lower transmission speed (I guess this was your main question). If the start bit begins at cycle 140, pokey synchronizes on the next high-to-low transition in the bit stream and uses this as the start-bit (which isn't correct, of course...).

So there's a consistent theory which fits the observations. Excellent. Thank you.

KMK
? HEX$(6670358)