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 1090). Ale nic nie stoi na przeszkodzie ku wykorzystaniu również przez urządzenia szeregowe.

Na początku komenda przesyłana jest z DAUX1 = 0 i DAUX2 = 0. W odpowiedzi urządzenie ma przysłać 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, DAUX1 i DAUX2 są ustawiane na $4E ("N", jak Negative Acknowledge) i po wysłaniu tej samej komendy ponownie - procedura zaczyna się od początku; i tak dalej w pętli aż do wystąpienia błędu transmisji. 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 QUERY 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 BOOT ERROR.

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

• DDEVIC - kod urządzenia przesłany przez urządzenie $4F na komendę QUERY 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 - praca w gęstości MFM (FM 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: