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.

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

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?

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.

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%.

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?

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.

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ą.

@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.

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. ;)