• Skąd: Okolice okolic ...
  • Zarejestrowany: 2009-11-07
  • Posty: 19

Witam,

Mam pytanie odnośnie protokołu SIO. Przeczytałem artykuł SIO w atariki, lecz parę rzeczy nie jest dla mnie jasne. Mianowicie
jak konkretnie wygląda nadawanie komendy? Rozumiem że komputer ustawia linie COMMAND w stan niski, po czym peryferia
rozpoznają że to co za chwilę odbiorą będzie blokiem komendy. Interesuje mnie kiedy COMMAND wraca w stan wysoki. Domyślałem się że
po nadaniu komendy, lecz pomiar napięcia na gniezdzie wskazuje że nie zawsze tak się dzieje. Co sie dzieje z linią COMMAND w wypadku Frame error,
lub Checksum Error? Czy peryferia mają obowiązek powiadomić komputer w jakiś sposób o tym że juz odebrały blok komendy, i wtedy komputer zresetuje linie COMMAND, czy do momentu kiedy nie zostanie ona zresetowana peryferium ma obowiazek odbierać to co im sie nadaje? (bez względu na to co to jest)

Drugie pytanie dotyczy samej transmisji, a konkretnie zegara. W jaki sposób komputer uzgadnia z peryferium prędkość? O ile stacja dysków wiadomo używa różnych metod turbo, o tyle interesuje mnie skąd Pokey wie z jaką prędkością nadawać komendy do urządzenia w niestandardowej prędkości. (np do drukarki - no chyba że drukarki atari gadają w standardowym 19200)

Z góry dzięki za rzeczowe odpowiedzi.

Pozdrawiam

Nice shoes...

2 Odpowiedź przez Pecus

  • Pecus
  • Pecus
  • Atarowiec
  • Nieaktywny
  • Skąd: Dokąd: Dlaczego: Co?
  • Zarejestrowany: 2002-03-09
  • Posty: 1,654

Command powinna być stanie niskim podczas nadawania całej komendy. Peryferia po odebraniu bloku odpowiadjaja nadajac ACK (czyli kod Ascii "A") i w zasadzie to jest sygnałem prawidłowego odebrania.
A co do drugiego pytania, to nie ma uzgadniania prędkości :), przynajmniej ja się z nim nie spotkałem.
Stacja rozpoznająca kilka prędkości po prostu stara się odebrać komendę ustawiając jedną z dostępnych prędkości, jeśli wystąpi błąd, to komputer i tak ponawia wysłanie komendy, a w tym czasie stacja zmienia prędkość na kolejną dostępna. Z tego, co pamiętam to prób nadania komendy przez komputer jest 12, i za którąś znich, stacja będzie miała ustawioną prędkość zgodną z komputerem. Co do innych urządzeń to prędkości są ustalone wstępnie (czyli 19200 a magnetofon 300 ;) )

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

Pecus's Strona

3 Odpowiedź przez mono Ostatnio edytowany przez mono (2009-11-08 17:25:31)

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,947

Czy przypadkiem w protokole XF551 nie było tak, że komendy z najwyższym bitem ustawionym nie przełączały stacji w tryb turbo (38400? 57600? pamiętam, że w audf ustawiało się 6)?
O ile pamiętam wyglądało to tak:
1. atari wysyła polecenie w 19200 (pbctl=$34)
2. xf odpowiada ack/nack w 19200 (pbctl=$3c)
3. atari wysyła blok w turbo
4. xf odpowiada ack/nack
W przypadku odbioru bloku przez atari nie ma p4 - nie jestem też pewny czy p4 idzie w 19200 czy w turbo.
Nie wiem, jak jest w przypadku innych stacji i systemów turbo.

@pecus: magnetofon - 600 :D, ale ta prędkość jest w pewnym zakresie zdaje się korygowana podczas odczytu dwóch pierwszych bajtów rekordu zawierających naprzemiennie zera i jedynki ($5555).

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

mono's Strona

4 Odpowiedź przez Pecus Ostatnio edytowany przez Pecus (2009-11-08 17:30:24)

  • Pecus
  • Pecus
  • Atarowiec
  • Nieaktywny
  • Skąd: Dokąd: Dlaczego: Co?
  • Zarejestrowany: 2002-03-09
  • Posty: 1,654

Tak jest w turbo XF551 i Top-Drive (tyle ze tutaj juz ACK po komendzie leci w turbo), ale w przypadku przyspieszaczy "cywilizowanych" takich jak Happy Warp czy US-Doubler, ze o Toms Multi nie wspomnę, prędkość turbo jest stosowana już przy nadawaniu komendy, więc stacja nie wie z jaką szybkością ma tę komendę odbierać, musi próbować :)
W Atariki napisane jest, że stacje te używają sygnału "CLK" do ustalenia prędkości, analizując kod Toms Multi, i US-Doublera nie zauważyłem by to robiły. Po prostu starają sie przełączać na różne prędkości, aż w końcu odbiorą komendę. A że trwa to ułamki sekund - nikt tego nie zauważa.

@mono: Hm.... to gdzie bylo 300??  :) w C64 chyba - w stacji dysków ;)

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

Pecus's Strona

5 Odpowiedź przez mono

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,947

Może w modemie?

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

mono's Strona

6 Odpowiedź przez deadcode

  • Skąd: Okolice okolic ...
  • Zarejestrowany: 2009-11-07
  • Posty: 19

Czyli dopóki urządzenie nie odpowie ACK na komendę, linia COMMAND trzymana jest w stanie niskim, a komputer ponawia wysyłanie komendy.?
Nie wiedziałem że drukarki atari pracują ze standardową prędkością, dzięki.

Nice shoes...

7 Odpowiedź przez mono Ostatnio edytowany przez mono (2009-11-08 19:11:19)

  • mono
  • Starszy Atarowiec
  • Nieaktywny
  • Skąd: inąd
  • Zarejestrowany: 2007-08-20
  • Posty: 2,947

Bit 3 pbctl odpowiada za przełączanie stanu linii command. Wydaje mi się, że już w momencie kiedy atari czeka na odbiór bajtu statusu jest ona puszczana (stan wysoki). Ponieważ podczas wysyłania nie zdarzy się żaden błąd to po wysłaniu 4 bajtów + crc o ile procedura nie zostanie przerwana klawiszem break, to powina zainicjalizować odczyt statusu a więc ustawić stan linii command w stan wysoki (na odebranie statusu ustawiany jest timeout 2 ramek - 2/50 s w pal). Obsługa klawisza break również powoduje natychmiastowe ustawienie linii w stan wysoki.

Edit:
Warto może jeszcze dodać, że od chwili ściągnięcia command na 0 wykonywany jest kod:

     LDX #$01
LOOP1 LDY #$FF
LOOP2 DEY
     BNE LOOP2
     DEX
     BNE LOOP1

co daje ok 1285 cykli procesora (726 us?). Ale po wysłaniu komendy raczej nie powinno być wielkich opóźnień (co nie pokrywałoby się z Twoimi spostrzeżeniami).

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

mono's Strona

8 Odpowiedź przez deadcode

  • Skąd: Okolice okolic ...
  • Zarejestrowany: 2009-11-07
  • Posty: 19

Hm, mogę się zgodzić, ale - w źródle OS atari widać (o ile się nie pomyliłem) że te wspomniane przez Pecusia powtarzanie nadawania komendy dzieje sie przy opuszczonym COMMAND, tak więc COMMAND jest opuszczona aż urządzenie odbierze 4bajty + crc. Czyli w wypadku błędu transmisji COMMAND nadal jest niska.  Dobrze myślę?

Pozdrawiam

Nice shoes...

9 Odpowiedź przez drac030 Ostatnio edytowany przez drac030 (2009-11-09 14:07:32)

  • drac030
  • drac030
  • Swołocz z Atari Area
  • Nieaktywny
  • Skąd: Warszawa
  • Zarejestrowany: 2004-09-12
  • Posty: 4,611
Pecus napisał/a:

W Atariki napisane jest, że stacje te używają sygnału "CLK" do ustalenia prędkości, analizując kod Toms Multi, i US-Doublera nie zauważyłem by to robiły.

No bo nie robią, jeśli jest tak napisane, to trzeba poprawić, tylko powiedz, gdzie to jest. Nb. sygnał zegara jednak *można* wykorzystać do negocjacji prędkości tak że stacja nie ma potrzeby ustawiać tego na ślepo.

@deadcode: cytat z Atariki (za oficjalną dokumentacją SIO): "4) komputer kasuje linię COMMAND portu SIO (nie wcześniej niż po 650 usec i nie później niż 950 usec po wysłaniu komendy) i czeka na odpowiedź;"

KMK
? HEX$(6670358)

drac030's Strona

10 Odpowiedź przez deadcode

  • Skąd: Okolice okolic ...
  • Zarejestrowany: 2009-11-07
  • Posty: 19

Dzięki. Czyli protokół wygląda tak?:

- command = 0
- komputer->peryferium -> cmd, (dunit+ddevic-1), daux1,daux2,crc.
- pauza >650 usec
- command = 1
- komputer czeka na ACK.

Nice shoes...

11 Odpowiedź przez drac030

  • drac030
  • drac030
  • Swołocz z Atari Area
  • Nieaktywny
  • Skąd: Warszawa
  • Zarejestrowany: 2004-09-12
  • Posty: 4,611
mono napisał/a:
     LDX #$01
LOOP1 LDY #$FF
LOOP2 DEY
     BNE LOOP2
     DEX
     BNE LOOP1

co daje ok 1285 cykli procesora

... pod warunkiem, że nie wetnie się w to VBL.

@deadcode: tak jakby.

KMK
? HEX$(6670358)

drac030's Strona