SIO

• $4E (N) drukowanie normalne
• $53 (S) druk obrócony o 90 stopni
• $44 (D) druk normalny z podwójną szerokością znaków

Komendę tę system operacyjny wysyła na port szeregowy przy każdym zimnym starcie. Jej znaczenie jest nieznane, przypuszczalnie nie jest ona w ogóle przeznaczona dla urządzenia szeregowego, lecz dla urządzenia szyny równoległej (może modułu Atari 1090). Ale nic nie stoi na przeszkodzie ku wykorzystaniu również przez urządzenia szeregowe.

Na początku komenda przesyłana jest z DAUX1 = $4F i DAUX2 = $4F ("OO" - jak "open"?). Następnie - i to bez sprawdzenia statusu wykonania się tej operacji - przesyłane jest drugi raz to samo, tym razem z DAUX1 = 0 i DAUX2 = 0. Dopiero po tym sprawdzany jest status - co wskazuje, że przesłana para poleceń ma w istocie stanowić jedną komendę, albo że protokół przewiduje przesyłanie wielu komend na raz, a "00" jest klauzulą, sygnałem końca bloku poleceń.

Pozytywna odpowiedź oznacza, że urządzenie nadesłało 4 bajty, z czego dwa pierwsze to ilość pamięci potrzebna do przeprowadzenia całości transmisji. Jeśli jest to więcej niż dostępna ilość pamięci pomiędzy MEMLO a MEMTOP, system ponownie wysyła tę samą komendę, ale DAUX1 i DAUX2 są tym razem ustawione na $4E ("NN" - jak "negative"?). I znów, bez sprawdzenia statusu, jako klauzula wysyłana jest ta sama komenda po raz czwarty z DAUX1 i DAUX2 ustawionymi na zero, a po pozytywnej odpowiedzi na tę sekwencję cała procedura zaczyna się od początku. W przypadku braku pamięci byłaby to pętla nieskończona, ale po wysłaniu przez komputer odpowiedzi "NN", na następną komendę urządzenie zapewne już nie odpowiada tak samo - być może jakoś zmienia ofertę, albo zgłasza błąd.

Trzeci przysłany bajt to identyfikator urządzenia (dla DDEVIC), które odpowiedziało na komendę i z którym będzie prowadzona dalsza komunikacja.

Po stwierdzeniu poprawności odpowiedzi komputer dokonuje rezerwacji pamięci nad wartością MEMLO zaokrągloną w górę do najbliższej granicy słowa i próbuje dokonać odczytu z urządzenia, które się zgłosiło, 128 bajtów pod adres $03FD, przy użyciu innej "nietypowej" komendy, a mianowicie $26 - SEND HANDLER.

Trzeba nadmienić, że "handler", którego komputer domaga się przy zimnym starcie, ma mieć raczej charakter ogólnego handlera wszystkiego, czyli innymi słowy ma grać rolę co najmniej części, o ile nie całości, systemu operacyjnego. Procedura ładowania handlera wywoływana jest po procedurze bootowania DOS-u, ale niezależnie od jej wyniku; z czego wniosek, że "handler" może spełniać funkcję zarówno dodatku do DOS-u, jak i zostać załadowany zamiast DOS-u.

Że chodzi o handler "ogólny", wiadomo stąd, że tą samą drogą można już po całkowitym uruchomieniu systemu, podczas pracy, załadować handler urządzenia konkretnie wskazanego. Robi to CIO przy każdorazowej próbie otwarcia pliku na urządzeniu, którego system nie zna (nie ma takiego wpisu w tablicy handlerów).

Odpytanie urządzenia $4F (za którym to identyfikatorem stoi zapewne jakiś moduł rozszerzeń zarządzający podłączonymi do siebie kartami) na okoliczność dysponowania takowym handlerem odbywa się tak samo, jak przy zimnym starcie, z tą jedynie różnicą, że DAUX1/2 nie są wyzerowane. W DAUX1 ma się znajdować identyfikator urządzenia CIO, dla którego to urządzenia potrzebujemy handlera (np. dla magnetofonu $43, czyli "C"), w DAUX2 natomiast przesyła się numer wywoływanego urządzenia (np. dla "C1:" będzie to $01).

Komenda ta nie jest nigdzie opisana, ale na szczęście w dokumentacji SIO znajduje się wzmianka o niej pozwalająca ustalić oficjalną nazwę (SEND HANDLER właśnie). Reszta została wywnioskowana z kodu systemu operacyjnego.

Procedura ładowania handlera zaczyna się zawsze od wysłania komendy POLL BUS ($40). Po otrzymaniu pozytywnej odpowiedzi komputer rozpoczyna ładowanie kolejnych, 128-bajtowych rekordów binarnych, w liczbie do 256 (czyli "handler" może mieć maksimum 32k) oraz interpretację ich zawartości w sposób nie do końca jeszcze dla mnie jasny, jako że formatu danych nie zdołałem jeszcze rozgryźć. Wiadomo, że przesyłany strumień danych zawiera podany explicite znacznik końca pliku - wystąpienie błędu przed napotkaniem tego znacznika powoduje przerwanie procedury z kodem błędu INCOMPLETE EXECUTION.

Ustawienia zmiennych DCB dla komendy SEND HANDLER wyglądają następująco:

• DDEVIC - kod urządzenia przesłany przez urządzenie $4F na komendę POLL BUS.
• DUNIT - zawsze $01
• DCMND - $26 - SEND HANDLER
• DSTATS - $40 - odczyt
• DTIMLO - 30 sekund
• DBYT - 128 bajtów
• DAUX1 - numer kolejny rekordu danych
• DAUX2 - zawsze 0

Komendy te występują jako komendy dyskowe na liście rozkazów SIO w dokumentacji sporządzonej przez Atari. Nie znam jednak stacji, która by na nie reagowała. Mogą to być komendy stacji 810, jakieś komendy diagnostyczne jej prototypu, albo komendy planowane, lecz nie zaimplementowane. Dostępna dokumentacja nie zawiera ich opisu.

• bit 0 = 1 - wydana ostatnio komenda nie została rozpoznana
• bit 1 = 1 - przesłany ostatnio blok danych był błędny
• bit 7 = 1 - drukarka jest programowalna (w drukarkach Atari ten bit jest skasowany)

• bit 0 = 1 - wydana ostatnio komenda nie została rozpoznana
• bit 1 = 1 - przesłany ostatnio blok danych był błędny (błąd sumy kontrolnej)
• bit 2 = 1 - ostatnia operacja nie powiodła się (np. próbowano odczytać wadliwy sektor)
• bit 3 = 1 - dyskietka jest zabezpieczona przed zapisem
• bit 4 = 1 - kręci się silnik obracający dyskietkę
• bit 5 = 1 - sektory 256-bajtowe (128-bajtowe w przeciwnym wypadku)
• bit 6 = 0 - zarezerwowany
• bit 7 = 1 - praca w średniej gęstości

• 0 - 30 ms
• 1 - 20 ms
• 2 - 12 ms
• 3 - 6 ms

W praktyce stacje przeważnie ignorują przesłaną wartość. W przypadku twardego dysku jest ona bez znaczenia (kontroler KMK/JŻ zwraca w tym bajcie numer wersji wewnętrznego oprogramowania)

Gęstość zapisu:

</table> W praktyce większość stacji nie ustawia tych bitów zgodnie z powyższym opisem.

</table>

Protokół transmisji

Protokół transmisji urządzeń podłączanych do szyny równoległej jest zależny od programu obsługi urządzenia zawartego w jego pamięci ROM. System operacyjny tego nie definiuje.

Protokół transmisji urządzeń podłączonych do szyny szeregowej jest zdefiniowany następująco:

• 1 bit startu
• osiem bitów danych
• brak kontroli parzystości
• 1 bit stopu
• 19200 bitów na sekundę

Dane transmitowane są w kolejności od najmłodszego bitu. Szybkość transmisji 19200 bitów na sekundę nie dotyczy magnetofonu kasetowego, gdzie określona jest na 600 bitów na sekundę.

Przebieg komunikacji pomiędzy komputerem i urządzeniem jest następujący:

1) komputer ustawia linię COMMAND portu SIO;

2) komputer formuje czterobajtowy blok komendy, tzw. Command Frame. Command Frame składa się kolejno z (bajt 1) dodanych do siebie wartości DDEVIC i DUNIT, odjąć 1; (bajt 2) wartości DCMND; (bajt 3) wartości DAUX1; (bajt 4) wartości DAUX2;

3) komenda jest wysyłana do urządzenia razem z dołączoną na końcu sumą kontrolną; czas pomiędzy ustawieniem linii COMMAND a wysłaniem komendy musi być nie mniejszy niż 750 usec i nie większy niż 1600 usec.

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ź;

5) urządzenie przyjmuje komendę; jeśli urządzenie stwierdziło w komendzie błąd sumy kontrolnej, nie reaguje; jeśli komenda jest nierozpoznana, albo nieprawidłowe są jej parametry (np. nie istnieje sektor o podanym numere), odpowiedzią jest $4E ("N", jak Negative Acknowledge) i na tym transmisja się kończy; jeśli komenda jest urządzeniu znana a parametry prawidłowe, odpowiedzią jest $41 ("A", jak Acknowledge). Odpowiedź urządzenia musi nastąpić w czasie od 0 do 16 msec. od skasowania linii COMMAND przez komputer;

6) jeśli komenda jest wykonalna i jest to odczyt danych, urządzenie podejmuje próbę wykonania operacji; jeśli się to nie uda (np. nie można odczytać sektora z powodu uszkodzenia nośnika), wysyła kod $45 ("E", jak Error) i na tym transmisja się kończy; w przeciwnym wypadku przesyłany jest kod $43 ("C", jak Complete), a następnie blok danych zakończony sumą kontrolną i na tym transmisja się kończy; po przesłaniu potwierdzenia ("C") blok danych po musi nadejść nie wcześniej niż w ciągu 1000 usec. i nie później niż w ciągu 1800 usec.;

7) jeśli to jest zapis danych, komputer przesyła blok danych plus sumę kontrolną do urządzenia. Po jego przyjęciu i stwierdzeniu poprawności urządzenie odpowiada kodem $41 ("A") i przystępuje do np. zapisania danych na nośnik. Po zapisie urządzenie informuje komputer kodem "C" lub "E" o znaczeniu jak powyżej, i na tym transmisja się kończy. Przesłanie danych po potwierdzeniu ("A") musi nastąpić nie wcześniej niż w ciągu 1000 usec. i nie później niż w ciągu 1800 usec. Przesłanie potwierdzenia końcowego ("C" lub "E") musi nastąpić w czasie od 850 usec. do 16 msec. po przesłaniu bloku danych.

Ogólnie potwierdzenie końcowe ("C" lub "E") musi nadejść z urządzenia nie wcześniej niż po 250 usec. i nie później niż po 255 sekundach - czyli po 4 minutach i 15 sekundach - od nadesłania potwierdzenia komendy ("A").

Ogólnie schemat wymiany danych przy odczycie jest następujący:

• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• komputer <-- blok danych + CRC <-- urządzenie
• koniec.

Natomiast zapis wygląda tak:

• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• komputer --> blok danych + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• koniec

W fazie oznaczonej jako wykonanie urządzenie dokonuje niezbędnych czynności (np. stacja dysków wyszukuje żądany sektor na dyskietce i odczytuje go, albo zapisuje), a komputer czeka.

Potwierdzenia przesyłane są bez sum kontrolnych (CRC).

Układ Pokey a transmisja szeregowa

Transmisja szeregowa jest wspomagana przez układ Pokey. Działa on jako UART, przejmując na siebie podział przesłanych przez komputer bajtów na pojedyncze bity i wyemitowanie ich na złącze szeregowe z zaprogramowaną częstotliwością. Szybkość transmisji programowana jest przy użyciu połączonych w parę dzielników 3 i 4 (AUDF3 i AUDF4), do których doprowadza się sygnał o częstotliwości głównego zegara systemu, czyli 1773446,25 Hz w systemie PAL albo 1789772,5 Hz w systemie NTSC. Szybkość tę możemy obliczyć według następującego wzoru:

baud = (FI/2)/(R+7)

gdzie FI to wspomniana wyżej częstotliwość bazowa, a R - wartość wstawiana do rejestru układu Pokey.

Normalnie ustawianą przez system operacyjny wartością R jest 40. Teoretycznie ma to odpowiadać szybkości 19200 bitów na sekundę, z podanego wzoru wynika jednak, że w rzeczywistości jest to 18866,45 bps w systemie PAL oraz 19040 bps w systemie NTSC. W praktyce szybkość transmisji nieprzyspieszanej może wahać się w zakresie od 17734,46 bps do 20152,8 bps (19200 bps +/- 5%; odpowiada to wartościom dzielnika Pokeya z zakresu od 43 do 37, w systemie PAL).

Możliwości układu Pokey nie kończą się jednak na szybkości 20 kbps. Niektóre możliwe do wygenerowania szybkości transmisji przedstawia poniższa tabela:

Oczywiście wartość dzielnika częstotliwości może mieć i wyższe wartości, do 65535 włącznie (co daje 13,6 bps).

Magnetofon

Dla magnetofonu domyślną wartością rejestru jest 1484, co odpowiada szybkości 594,7 bps. Szybkość tę podczas transmisji komputer dostosowuje w pewnym zakresie do bieżących potrzeb wynikłych np. z nierównomiernego przesuwu taśmy bądź jej rozciągnięcia itd.

W odróżnieniu od innych urządzeń szeregowych, które używają modulacji częstotliwościowej, dla magnetofonu stosowany jest tryb dwutonowy.

Rozszerzenia SIO

Systemy turbo do stacji dysków

Standardowa szybkość wymiany danych ze stacją dysków - 19200 bps - szybko okazała się dalece niewystarczająca. Ponieważ, jak napisano powyżej, możliwości układu Pokey pozwalają uzyskać znacznie więcej, wkrótce powstało kilka, różnych niestety, systemów "turbo".

US Doubler / Happy Warp

Protokół transmisji US Doublera (i zgodnego z nim Happy Warp) jest identyczny jak w standardzie, z tą różnicą, że układ Pokey programowany jest do pracy z prędkością 52 kbps. Praca w standardowym 19,2 kbps także jest możliwa. Stacja przełącza się automatycznie pomiędzy tymi dwoma trybami pracy, a do pomiaru żądanej przez komputer prędkości wykorzystuje pojawiający się na złączu szeregowym Atari synchronizujący sygnał zegarowy (CLOCK OUT).

Stacje z rozszerzeniem US Doubler implementują dodatkową komendę POLL ('?'). Wysłanie - w standardzie - tej komendy do stacji dysków powoduje, że zwraca ona 1 bajt stanowiący wartość, jaką należy wstawić do licznika układu Pokey celem uzyskania szybkiej transmisji. W standardowych stacjach US Doubler wartością tą jest $0A, ale stacje innych producentów dzięki temu mechanizmowi mogą implementować wyższe prędkości i wciąż pozostają zgodne z US Doublerem.

Atari XF-551 / CA-2001

Stacje Atari XF-551 oraz California Access 2001 mogą pracować z prędkością 38400 bps. Dla zasygnalizowania stacji, że komputer żąda pracy w turbo, przy prędkości 38400 bps używany jest inny protokół transmisji będący - oczywiście - zmodyfikowaną wersją standardowego (patrz wyżej).

Blok komendy (Command Frame) dla stacji, tak samo jak w standardzie, wysyłany jest z prędkością 19200 bps. Jednakże drugi bajt tego bloku, zawierający wartość bajtu DCMND bloku DCB, jest zwiększony o 128 (ORA #$80). Po wysłaniu komendy komputer, identycznie jak w standardzie, czeka - cały czas mając układ Pokey zaprogramowany na 19200 bps - na potwierdzenie jej przyjęcia. Negatywna odpowiedź urządzenia na taką komendę oznacza, że nie zna ono tego protokołu transmisji i nie może pracować w turbo zgodnym z XF-551.

Odpowiedź pozytywna ('A') jest sygnałem do przeprogramowania układu Pokey na większą prędkość. Komputer wstawia do licznika AUDF3/4 wartość $10; analogicznej operacji ze swojej strony dokonuje stacja dysków. Dalsza wymiana danych wywołana przez tę jedną komendę odbywa się w przyspieszonej transmisji. Po wykonaniu komendy następuje powrót do prędkości standardowej.

Ogólnie schemat wymiany danych przy odczycie jest następujący:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• przełączenie na 38400 bps
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• komputer <-- blok danych + CRC <-- urządzenie
• przełączenie na 19200 bps
• koniec.

Natomiast zapis wygląda tak:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• przełączenie na 38400 bps
• komputer --> blok danych + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• przełączenie na 19200 bps
• koniec

Budzącym zakłopotanie niedopatrzeniem jest w tym wszystkim niemożność odpytania stacji na okoliczność wartości, jaką ma mieć licznik Pokeya w czasie przyspieszonej transmisji. Dodatkowym kłopotem posiadaczy CA-2001 jest to, że stację trzeba specjalnie zaprogramować (programem o nazwie Synchromesh dostarczonym przez producenta na dyskietce), żeby w ogóle działała w turbo. XF-551 jest tej ostatniej wady na szczęście pozbawiona.

Indus GT / LDW 2000 Super

Protokół przyspieszonej transmisji używany przez stacje Indus GT oraz LDW Super 2000 jest identyczny z tym opisanym powyżej dla Atari XF-551 oraz California Access 2001. Jedyną różnicą jest szybkość transmisji: dla LDW wynosi ona 68,2 kbps (wartość licznika Pokeya - $06). Dla uzyskania tej prędkości konieczne jest uprzednie zaprogramowanie stacji programem Synchromesh dostarczonym przez producenta na dyskietce. Stacja pozostaje zaprogramowana aż do wyłączenia zasilania.

Ogólnie schemat wymiany danych przy odczycie jest następujący:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• przełączenie na 68,2 kbps
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• komputer <-- blok danych + CRC <-- urządzenie
• przełączenie na 19200 bps
• koniec.

Natomiast zapis wygląda tak:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• przełączenie na 68,2 kbps
• komputer --> blok danych + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• przełączenie na 19200 bps
• koniec

Top Drive / TOMS Turbo

Stacje z rozszerzeniem Top Drive 1050, TOMS Turbo oraz TOMS Multi mogą pracować z prędkością 68,2 kbps. Dla zasygnalizowania stacji, że komputer żąda pracy w turbo, przy prędkości 68,2 kbps używany jest inny protokół transmisji będący zmodyfikowaną wersją standardowego. Protokół ten jest odmienny niż w wypadku stacji XF-551.

Blok komendy (Command Frame) dla stacji, tak samo jak w standardzie, wysyłany jest z prędkością 19200 bps. Czwarty bajt tego bloku, niosący wartość bajtu DAUX2 bloku DCB, jest zwiększony o 128 (ORA #$80). Po wysłaniu komendy komputer - nie czekając na odpowiedź - przeprogramowuje układ Pokey na 68,2 kbps (wartość licznika - $06) założywszy w ciemno, że stacja ze swej strony również przełącza się na szybką transmisję. Odbiór ewentualnej negatywnej odpowiedzi oczywiście nie jest w takim układzie możliwy.

Dalsza wymiana danych wywołana przez tę jedną komendę odbywa się w przyspieszonej transmisji. Po wykonaniu komendy następuje powrót do prędkości standardowej.

Ogólnie schemat wymiany danych przy odczycie jest następujący:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• przełączenie na 68,2 kbps
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• komputer <-- blok danych + CRC <-- urządzenie
• przełączenie na 19200 bps
• koniec.

Natomiast zapis wygląda tak:

• prędkość 19200 bps
• komputer --> komenda 4 B + CRC --> urządzenie
• przełączenie na 68,2 kbps
• komputer <-- potwierdzenie 'A' <-- urządzenie
• komputer --> blok danych + CRC --> urządzenie
• komputer <-- potwierdzenie 'A' <-- urządzenie
• wykonanie
• komputer <-- potwierdzenie 'C' <-- urządzenie
• przełączenie na 19200 bps
• koniec

Jest to zdecydowanie najpodlejsze turbo z omawianej tu czwórki; Top Drive nie dość, że ma wszystkie wady protokołu XF-551, to jeszcze dorzuca do nich jedną własną (którą jest wspomniana wyżej niemożność odrzucenia przez stację w cywilizowany sposób żądanego przez komputer trybu pracy), nie mając przy tym żadnych równoważących to zalet (jeden bajt więcej przesłany w szybkiej transmisji zwiększa prędkość wymiany danych o niecałe 8 promili).

Rozszerzone adresowanie sektorów (KMK/JŻ IDE)

Kontroler KMK/JŻ IDE wykorzystuje bajt DUNUSE ($0307) bloku DCB jako najstarszy bajt numeru sektora. Pozwala to na zaadresowanie do 16777215 sektorów na jednej partycji.

Rozszerzone adresowanie pamięci (65C816)

DracOS (odmiana XL OS przygotowana dla procesora 65C816) zawiera rozszerzenie SIO pozwalające na transfery danych bezpośrednio do i z dodatkowej pamięci adresowalnej liniowo (tj. znajdującej się pod adresami wyższymi niż $FFFF).

Blok DCB

Block DCB w tej wersji systemu jest rozszerzony do 16 bajtów i wygląda następująco:

Sposób użycia

Dla utrzymania zgodności z dotychczasowym oprogramowaniem, a już zwłaszcza z dotychczasowymi sterownikami urządzeń podłączanych do szyny równoległej, wpisanie pod $000304/5/E 24-bitowego adresu nie da pożądanego wyniku; jeśliby bowiem urządzenie brało pod uwagę tylko 16 najmłodszych bitów adresu ignorując najstarszy bajt wpisany pod $00030E, wtedy - przy odczycie - dane zostałyby umieszczone nie tam, gdzie trzeba. Musi więc istnieć mechanizm, który zapobiega tego typu nieporozumieniom.

W tym celu SIO definiuje trzy nowe urządzenia wirtualne, o kodach jak następuje:

• $B1 (= $31 + $80) - stacja dysków
• $C0 (= $40 + $80) - drukarka
• $D0 (= $50 + $80) - RS-232C

Wywołanie urządzenia z takim kodem w DDEVIC powiadamia sterownik SIO, że adres bufora w DCB jest 24-bitowy i że najstarszy bajt adresu jest pod $00030E (w przeciwnym wypadku SIO zakłada, że najstarszy bajt adresu to 0); oraz że numer sektora jest 32-bitowy i jest umieszczony w DAUX1-DAUX4 (UWAGA: w przypadku szeregowych stacji dysków, SIO2IDE, SIO2PC itp. dwa najstarsze bajty tego numeru są ignorowane, ale powinny być wyzerowane dla kompatybilności). Poza tym działanie urządzeń wirtualnych jest identyczne, jak tradycyjnych (odpowiednio $31, $40 i $50), a kod urządzenia jest przed wysłaniem na port szeregowy przekładany na kod rzeczywisty.

Przyjmując komendę do wykonania SIO w żaden sposób nie sprawdza, czy dodatkowa pamięć w ogóle istnieje - zakłada się, że program sam stwierdzi jej istnienie (choćby za pomocą funkcji alokacji pamięci) przed próbą odczytu do niej danych.

Bibliografia

• Atari Home Computer System: Serial Input Output Interface, User's Handbook
• Harry B. Stewart, Z800/Sweet 16 Operating System, External Reference Specification