1

Temat: POKEY, SIO i BaudRate

Witam!

Panowie, potrzebuje waszej pomocy poniewaz moje obliczenia nie bardzo zgadzaja sie z rzeczywistoscia :-(  Chodzi i o wzor na dokladne okreslenie predkosci transmisji (bps) na podstawie wartosci wpisanej do rejestrow AUDF. Wedlug "tajnego" wzoru opublikowanego w ATARI HARDWARE MANUAL mozemy policzyc to tak:

Fout=1773447Hz/(2*(AUDUF+7))

Zakladajac iz transmisja kazdego bitu jest realizowana przy kazdej narastajacej krawiedzi zbocza zegarowego (a zegar jest generowany przez polaczone w tym momecie kanalu 3 i 4) mozemy przyjac ze predkosc transmisji jest rowna czestotliwosci wpisanej do rejestrow AUDF3,AUDF4. Jak wiadomo dla standardowej predkosci transmisji system operacyjny ATARI laczy kanaly 3,4 w celu uzyskania 16 bitowej precyzji, oraz wpisuje do rejestrow AUDF3,AUDF4 wartosc $0028.

Po podstawieniu tejze wartosci do wzoru mamy:

Fout=1773447/(2*(40+7))=18866.45745

...wiec obliczona predkosc transmisji oscyluje na poziomie 18866bps. Jednak zakladajac poprawnosc wzoru wydaje mi sie iz wartosc 39 byla by na tym miejscu bardziej odpowiednia, poniewaz wtedy predkosc transmisji wynosilaby:  19276 bitow/sek. (co jest juz blizsze wartosci 19200 :-)

Tu sie rodza moje watpliwosci... czy podany przez dokumentacje wzor jest nie poprawny, czy ja sie gdzies mijam z prawda w moim toku myslenia :-) Jezeli ktos wie jak to policzyc lub jest w stanie udzielic jakichs wskazowek prosze o informacje.

Zastanawia mnie jeszcze jedna rzecz... co sie dzieje w przypadku NTSC. Z tego co pamietam systemowe procedury transmisji szerwgowej nie sprawdzaja czy maja doczynienia z systemem PAL czy NTSC. Wiec w przypadku NTSC predkosc transmisji wynosila by:

Fout=1789772/(2*40+7))=19040

W tym wypadku jest to wartosc najbardziej zblizona do wartosci 19200 jaka da sie uzyskac przy taktowaniu POKEY'a zegarem 1.789722MHz. Wiec po prostu wyadje mi sie iz tworcy systemu operacyjnego nie brali pod uwage/nie przejmowali sie roznica zegarow dla systemow PAL i NTSC.

A moze jest ktos w stanie wytlumaczyc mi skad sie bierza magiczna liczba 7 we wzorze na Fout. Prawde mowiac nie mialem zbyt duzo czasu aby przyjrzec sie dokladnie dokumentacji POKEY'a. Moze ktos jest mi to w stanie wyjasnic i zaoszczedzi mi troche cennego czasu :-)

serdecznie pozdrawiam
Seban/SLIGHT

2

Odp: POKEY, SIO i BaudRate

O stary, ale czarna magia ....   ciekawe co tam knujesz ;) ...

Im dłużej czekamy, tym wzorek jest większy" (c) by Sikor

3

Odp: POKEY, SIO i BaudRate

Seban: te dane niekoniecznie musza byc bledne - przy transmisji szeregowej dopuszcza sie przeciez pewne przesuniecia czasowe - przeciez to bit startu daje znac kiedy zaczyna sie przeslanie bajtu i dokonuje on pewnego rodzaju synchronizacji miedzy odbiornikiem i nadajnikiem. ZTCP COM-y w PC tez nie maja dokladnie docyklowanych licznikow transmisyjnych i ich wartosci z lekka "odstaja" od okraglych wartosci typu: 600,1200,...9600 etc.

Nie wiem czy ide wlasciwym tokiem myslenia, ale biorac wartosci: 18866 Hz i 19200 Hz daje nam to roznice na poziomie 1,8 %, co w wypadku 8 bitow powoduje, ze teoretycznie ramka przy przesylaniu ostatniego bita danych bedzie przesunieta czasowo na poziomie 15% co raczej nie powinno wplynac na przeklamania w transmisji, tymbardziej ze po przeslaniu tej paczki nastepuje ponownie synchronizacja przez bity stop/start.

4

Odp: POKEY, SIO i BaudRate

A ja mam 2 pytania:
-Czemu w tym wzorze jest +7 a nie +1. To bez sensu. Liczniki audf przecież zliczają w dół do zera i generują IRQ po jego przekroczeniu (bcc?). Więc przerwanie jest generowane po AUDF+1 cyklach. Błąd w druku? (7 jest podobne do 1, a w starych maszynach do pisania cyfry 1 nawet nie było i używało się np. T).
-Czy te 19200 to ilość bitów danych przesłanych w ciągu sekundy razem z bitem stopu czy bez?

I Seban: jakie przesunięcie 15% po ostatnim bicie??? Dlaczego ty te procenty dodajesz? Głodnemu chleb na myśli?

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

5

Odp: POKEY, SIO i BaudRate

Nie jestem pewien, ale POKEY przy wysyłaniu (SKCTLS = $23) wyrzuca na linię zegarową szybkość transmisji - może wystarczyłoby zmierzyć tutaj częstotliwość ?

Swoją drogą PDF od POKEY'a jest w zakresie transmisji nieco zakręcony i nie bardzo można (ja nie mogę) do końca zrozumieć różnic pomiędzy niektórymi trybami transmisji wybieranymi przez SKCTLS...

Jaskier: mac ma rację.... 15 %.... ale długości bitu a nie całej ramki danych :) . Jest to powiedzmy do przyjęcia.

Seban: W domu sprawdzę dokumentację... może z tym Twoim wzorem coś nie tak ?

pomidor

6

Odp: POKEY, SIO i BaudRate

Jaskier: mac ma rację.... 15 %.... ale długości bitu a nie całej ramki danych :) . Jest to powiedzmy do przyjęcia.

Musisz mi to rozrysować. Jeżeli różnica prędkości wynosi 1.8%, to różnica czasu wysyłania też będzie na tym poziomie. Bez względu na ilość danych. (Albo ja wracam na studia.)

Aby odpackować teksty trzeba najpierw odpackować  program do ich odpackowywania - Energy #1

7

Odp: POKEY, SIO i BaudRate

Do MacGyver'a:

Ufff.... Doszedlem do podobnych wnioskow... Ciesze sie ze ktos mysli tak jak ja :-) Potrzebowalem poparcia moich chorych teori przez osobe trzecia :-) Dzieki! 

I Seban: jakie przesunięcie 15% po ostatnim bicie??? Dlaczego ty te procenty dodajesz? Głodnemu chleb na myśli?"

ale o dodawaniu procentow pisal chyba MacGyver :-) A pozatym to bym sie chyba z nim zgodzil, ale przy zalozeniu poprawek Electrona :-) (co do bledu 15% wartosci bitu dla calej ramki  :-)

Czemu w tym wzorze jest +7 a nie +1. To bez sensu. Liczniki audf przecież zliczają w dół do zera i generują IRQ po jego przekroczeniu (bcc?). Więc przerwanie jest generowane po AUDF+1 cyklach. Błąd w druku? (7 jest podobne do 1, a w starych maszynach do pisania cyfry 1 nawet nie było i używało się np. T).

Pozwolisz ze zacytuje pare fragmentow dokumentacji, to chyba najwazniejszy fragment:

The frequencies given above are approximate. The Exact Frequency (Fin) that clocks the divide by N counters is given below (NTSC only, PAL different).

    FIN Approximate     FIN Exact
    1.79 MHz     1.78979 MHz           ? Use modified formula for Fout
    64 kHz     63.9210 kHz           ? Use normal formula for Fout
    15 kHz     15.6999 kHz            

The Normal Formula for output frequency is:

    Fout = Fin / 2N

Where N The binary number in the frequency register (AUDF), plus 1 (N=AUDF+1). The MODIFIED FORMULA should be used when Fin = 1.79 MHZ and a more exact result is desired:

    Fout = Fin / 2(AUDF + M)

Where:     M = 4 if 8 bit counter (AUDCTL bit 3 or 4 = 0)
      M = 7 if 16 bit counter (AUDCTL bit 3 or 4 = 1)

Tez nie mam pojecia skad sie biora wartosci 4 i 7, nie mam czasu na tak dokladne wnikanie w malo-czytelna dokumentacje POKEY'a :-( Dlatego prosilem was o wyjasnienie tego faktu.

Co ciekawe dopiero po zastosowaniu tego wzoru udaje sie osiagnac odpowiednie wyniki :-?

Czy te 19200 to ilość bitów danych przesłanych w ciągu sekundy razem z bitem stopu czy bez?

wydaje mi sie ze jest predkosc transmisji wszystkiego co pojawia sie na szynie, a wiec bity start i stop, niejeko naleza do calosci transmisji. Przytocze fragment Atari Hardware Manual (AHM):

The serial output data always changes when the serial output clock goes true. The clock then returns to zero in the centre of the output data bit time.
...
...
The baud (bit) rate of the data and clock is determined by audio channel 4 audio channel 2, or by the input clock, depending on the serial mode selected by bits 4, 5, and 6 of SKCTL. (See chart at end of this section.)

A jak wiadomo zegar (CLOCK) jest generowany przez polaczone kanaly 3 i 4.  Tak wiec wszystko co jest wystawiane na szyne danych jest synchronizowane przez sygnal zegarowy generowany poprzez polaczone kanaly 3 i 4, tak wiec  mysle ze bity start i stop takze nalezy liczyc :-)

Nie jestem pewien, ale POKEY przy wysyłaniu (SKCTLS = $23) wyrzuca na linię zegarową szybkość transmisji - może wystarczyłoby zmierzyć tutaj częstotliwość ?

Na poczatek parametry szyny:

# 1 start bit
# 1 stop bit
# 8 data bits
# no parity control
# 19200 bits per second

A i owszem, wyrzuca, ale tylko podczas transmisji bajtu danych,  a wyglada to tak:

                          One byte of SIO data
     
     
                    +-+ +-+ +-+ +-+ +-+ +-+ +-+ +-+
                    | | | | | | | | | | | | | | | |        clock
       -------------+ +-+ +-+ +-+ +-+ +-+ +-+ +-+ +------
     
     
       ---------+       +---+   +-------+       +--------
                |     0 | 1 | 0 | 1   1 | 0   0 | 1        data
                +-------+   +---+       +-------+
     
                  |                                    |
     
              start bit                            stop bit

Czestotliwosciomierzem tego nie zmierze :-(, ATARI do pracy nie zaniose :-( A oscyloskopu cyfrowego z pamiecia w domu nie posiadam. Zmierze to wszytko jak tylko sobie POKEY'a do jakiegos mikro-kontrolera podlacze :-) i zaniose to do pracy gdzie mam odpowiedni sprzet :-)

Seban: W domu sprawdzę dokumentację... może z tym Twoim wzorem coś nie tak ?

to nie jest moj wzor, wziolem go z dokumentacji :-) Sam nie rozumiem tej magicznej liczby 7 ... hmmm... mam co prawda podejrzenie, ale musialbym miec bardziej czytelne dokumentacje POKEY'a... te maja za malo DPI :(

Zwroccie uwage prosze na opis rejestru $D208 (AUDCTL):

AUDCTL (Audio Control)(D208)

This address writes data into the Audio Mode Control Register. (Also see SKCTL two-tone bit 3 and notes).

D0 Change Normal 64 KHZ frequency, into 15 KHZ.
D1 Insert Hi Pass Pilter in Channel 2, clocked by Channel 4.
D2 Insert Hi Pass Filter in Channel 1, clocked by Channel 3. (See section II.)
D3 Clock Channel 4 with Channel 3, instead of 64 KHz (16 BIT).
D4 Clock Channel 2 with Channel 1, instead of 64 KHz (16 BIT).
D5 Clock Channel 3 with 1.79 MHz, instead of 64 KHz.
D6 Clock Channel 1 with 1.79 MHz, instead of 64 KHz.
D7 Change 17 bit poly into a 9 bit below poly.

Zwrocie prosze uwage na opis bitow D3,D4. W kazdej dostepnej literaturze bylo napisane ze dwa osmiobitowe liczniki sa laczone w jeden 16-bitowy. Jednak tu sugeruja iz na poczatku nastepuje podzial Fin przez kanal np. 3, a dopiero ta podzielona czestotliwosc jest dalej dzielona poprzez kanal 4. Z tego wynika ze nie jest to tak naprawde pelny 16-bitowy dzielnik, ale jakas dziwna hybryda.... albo ja juz nic nie rozumiem, albo oni tu cos sciemniaja :-) Moze to z tego wynikaja te magiczne liczby 4 i 7 we wzorach na Fout?

Dzieki Wszystkim za poswiecony czas! Ide walczyc... jezeli ktos bedzie mial jeszcze jakies pomysly lub nowe idee... prosze piszcze :-) Moze uda sie to wyjasnic :-)

A jeszcze jedno zdanie z dokumencacji dotyczace predkosci transmisji:

Input and output clocks are equal to the baud (bit) rate, not 16 times baud rate. Transmitted data changes when the output clock goes true. Received data is sampled when the input clock goes to zero.

Nie wiem dlaczego podkleslaja "not 16 times baud rate". hmmm. Ciekawostka.

pozdrawiam serdecznie
Seban/SLIGHT

8

Odp: POKEY, SIO i BaudRate

Teraz ja się tylko trochę wtrącę.

Prędkości transmisji zawsze podaje się dla całości tzn. dane+bity start/stop+parzystość.
Zresztą dotyczy wszystkich transmisji szeregowych (równoległych w zasadzie też) obojętnie czy dla RS232/422/485 czy i2c, CAN, Ethernet itp itd.

9

Odp: POKEY, SIO i BaudRate

Seban: może wartości 4 i 7 biorą się z pewnych opóźnień między wpisywaniem do POKEYA a zapisywaniem do liczników , i ich restartem  - w końcu POKEY też w jakiś ustalony sposób dzieli częstotliwość bazową , co powoduje również opóźnienia między sygnałęm Fi2 procesora a wewnętrznymi generatorami. (W końcu do wyboru mamy 64 , 15khz  i 1.79 Mhz)

To oczywiście jest czysta teoria.

10

Odp: POKEY, SIO i BaudRate

Male sprostowanie - byc moze zle dobralem terminologie (piszac ramka mialem na mysli paczke: bit startu, bity danych bit stopu). W kazdym razie wydaje mi sie, ze wszyscy zrozumieli co mialem na mysli ;) Chodzilo mi np. o sytuacje, ze jezeli odbiornik odczytuje dane z wzorcowa czestotliwoscia taktowania 19200 a nadajnik ma taktowanie o czestotliwosci rozniacej sie o 1,8% to przy odczycie kazdego kolejnego bitu bedzie coraz wieksze przesuniecie czasowe kazdego odczytywanego bitu - aby to bardziej zobrazowac polecam dokonac nastepujacego eksperymentu:

Wezmy 2 paski wyciete z papieru - na jednym z nich co 9 mm rysujcie poprzeczne linie a pola powstale w wyniku podzialu za pomoca owych linii ponumerujcie od 1 do 20, na drugim zrobcie dokladnie to samo z tym, ze rysujcie kreski co 10 mm. Nastepnie przylozcie owe paski do siebie tak, aby pola o numerze 1 rozpoczynaly sie w tym samym miejscu - wyraznie widac, ze im dalsze jest dane pole, tym wieksze jest przesuniecie wzgledem siebie pol o tych samych numerach na dwoch paskach.
Zamiast paskow mozna uzyc np. papieru milimetrowego ;)

11

Odp: POKEY, SIO i BaudRate

Mówcie dalej. Uwielbiam słuchać mądrzejszych od siebie.

12

Odp: POKEY, SIO i BaudRate

Chodzilo mi np. o sytuacje, ze jezeli odbiornik odczytuje dane z wzorcowa czestotliwoscia taktowania 19200 a nadajnik ma taktowanie o czestotliwosci rozniacej sie o 1,8% to przy odczycie kazdego kolejnego bitu bedzie coraz wieksze przesuniecie czasowe kazdego odczytywanego bitu

Tyle tylko ze synchronizacja odbiornika odbywa sie w chwili przeslania bitu startu (po to on wlasnie jest). Wiec nigdy sie nadajnik z odbiornikiem nie "rozjada" w czasie dluzszym niz transmisja jednego bajtu. Oczywiscie synchronizowac da sie tylko wtedy kiedy szybkosc transmisji jest wynikim podzialu jakiejs czestotliwosci wzorcowej (a tak jest w tym przypadku) - jesli nie ma podzialu - nie ma pola manewru.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

13

Odp: POKEY, SIO i BaudRate

Pecus: to co napisalem uwzglednialo synchronizacje bitem startu, jednak jezeli czestotliwosci zegarow taktujacych (pod warunkiem, ze nie beda one synchronizowane tym samym zegarem) odbiornika i nadajnika beda za bardzo sie roznily wzgledem siebie, to nawet przeslanie jednego bajtu moze pociagac za soba przeklamania -  oczywiscie, jezeli urzadzenie jest specjalizowane do szybkosci transmisji rzedu 19200 to z reguly ewentualne odstepstwa od wzorca nie sa zbyt duze, ale gdyby roznica wynosila np. ok 20%, to przeslanie pojedynczego bajtu w trybie 8 bit (zakladamy, ze przesylamy dane paczkami 8-bitowymi) byloby juz niemozliwe.

14

Odp: POKEY, SIO i BaudRate

to co napisalem uwzglednialo synchronizacje bitem startu, [...] gdyby roznica wynosila np. ok 20%, to przeslanie pojedynczego bajtu w trybie 8 bit

Hm... a ja tam widze 1,8% :) co sugeruje rozciagniecie sie tego przesuniecia na conajmniej 25 bitow.... I dlatego przypomnialem o tu ze operujemy tu na paczkach po 8 bitow, w tym przypadku niedokladnosci rzedu nawet 10% raczej nie wplyna na pojawienie sie przeklaman.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

15

Odp: POKEY, SIO i BaudRate

Pecus: nie kumam... skad wziales te 25 bitow ?

16

Odp: POKEY, SIO i BaudRate

Szybka operacja myslowa - sam zaczynam miec watpliwosci czy poprawna :)

1. bledy zaczynaja sie pojawiac gdy przesuniecie osiagnie ponad pol bitu.
2. oznacza to ze przy 1% roznicy zaczna pojawiac sie po 50tym bicie (proste rozumowanie - przy 100 bicie przesuniecie w takim wypadku osiagnie dlugosc pelnego bitu, to polowa bedzie przy 50tym)...
3. skoro tak to przy prawie 2% pojawia sie w okolicy 25 bitu (no przy 1,8% - pare bitow dalej).

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

17

Odp: POKEY, SIO i BaudRate

Pecus: no dokladnie, wszystko sie zgadza, stad byl moj pomysl z tymi paskami papieru ;)