CIO
From Atariki
CIO - Central Input/Output - rezydujący w pamięci ROM komputera podsystem Atari OS-u odpowiedzialny za obsługę plików.
Spis treści |
Sposób użycia
Żądaną operację definiuje się ustawiwszy przedtem odpowiednie zmienne w wybranym bloku IOCB (Input/Output Control Block, $0340-$03BF), załadowawszy do rejestru X jego pomnożony przez 16 numer oraz - przy zapisie bajt po bajcie - ewentualną daną do akumulatora, a nastepnie wywołuje skokiem JSR pod JCIOMAIN $E456, co jest punktem wejściowym podsystemu zarządznia plikami. Przy powrocie rejestr Y zawiera wartość 1 w przypadku powodzenia, bądź ujemny kod błędu, rejestr X numer kanału pomnożony przez 16, akumulator zaś - przy odczycie bajt po bajcie - ewentualną daną.
Bloki kontroli wejścia/wyjścia IOCB
Pod adresem $0340 znajduje się zajmujący 128 bajtów pamięci obszar bloków kontroli wejścia/wyjścia (IOCB). Bloków tych jest osiem, każdy z nich definiuje jeden niezależny "kanał" transmisji danych z wybranym urządzeniem. Blok numer 0 jest zajęty przez standardowy edytor ekranowy (urządzenie "E:", konsola systemowa). Reszta jest do wykorzystania przez programy, np. BASIC używa kanału nr 7 do wysyłania danych na drukarkę instrukcją LPRINT, a kanału nr 6 jako ekranu graficznego (otwieranego instrukcją GRAPHICS).
Struktura IOCB
| Bajt | Etykieta | Opis |
| 0 | ICCHID | Tzw. numer identyfikacyjny. Tak naprawdę jest to indeks wpisu w tablicy handlerów wskazującego dane urządzenie. Ustawiany jest automatycznie przez system. Wartość $FF oznacza, że kanał jest zamknięty, każda inna - że jest w użyciu. |
| 1 | ICDNO | Numer urządzenia podanego przez użytkownika (np. 3 dla "D3:NAZWA") albo 1, gdy numer nie został podany. Ustawiane automatycznie przez system. |
| 2 | ICCMD | Kod żądanej operacji (rozkaz); ustawiany przez program. Dozwolone kody:
Wszystkie pozostałe kody o wartościach powyżej 13 ($0D) są traktowane jako kody operacji specjalnych i przekazywane bezpośrednio do handlera urządzenia, bez interpretacji przez system. |
| 3 | ICSTAT | Status operacji ustawiany automatycznie po jej wykonaniu, czyli wartość 1 gdy sukces lub ujemny kod błędu. Czyli to samo, co jest przekazywane w rejestrze Y przy powrocie z CIO. |
| 4-5 | ICBUFA | Adres bufora dla operacji, ustawiany przez użytkownika. Dla OPEN, STATUS i operacji specjalnych powinien wskazywać nazwę pliku. |
| 6-7 | ICPUTB | Zmniejszony o 1 adres procedury wysyłania 1 bajtu do urządzenia. Ustawiany automatycznie przez system w czasie otwierania pliku. |
| 8-9 | ICBUFL | Wielkość bufora dla danej operacji, ustawiany przez program użytkownika. Po operacji zawiera liczbę bajtów odczytanych lub zapisanych. Jeśli 0, to bajt przekazywany jest w akumulatorze. |
| 10 | ICAX1 | Pierwszy bajt pomocniczy, przy otwieraniu pliku oznacza rodzaj dostępu ($04 - odczyt, $08 - zapis, $09 - dopisywanie, $0C - zapis i odczyt). W BASIC-u jest to drugi parametr instrukcji OPEN. |
| 11 | ICAX2 | Drugi bajt pomocniczy. Jego znaczenie jest zależne od handlera, np. przy otwieraniu ekranu w trybie graficznym będzie to numer trybu graficznego. |
| 12 | ICAX3 | Trzeci bajt pomocniczy. Jego znaczenie jest zależne od handlera. |
| 13 | ICAX4 | Czwarty bajt pomocniczy. Jego znaczenie jest zależne od handlera. |
| 14 | ICAX5 | Piąty bajt pomocniczy. Jego znaczenie jest zależne od handlera. |
| 15 | ICAX6 | Szósty bajt pomocniczy. Jego znaczenie jest zależne od handlera. |
Wykaz urządzeń
System operacyjny standardowo instaluje pięć urządzeń. Są to:
- "P:" - drukarka
- "C:" - magnetofon kasetowy
- "E:" - edytor ekranowy (konsola)
- "S:" - ekran graficzny
- "K:" - klawiatura
Jedynym urządzeniem z tej listy, którego handler obsługuje jakieś "operacje specjalne", jest ekran graficzny; jako operacje specjalne zaimplementowane jest rysowanie linii (17) oraz osobliwe połączenie rysowania linii z wypełnianiem (18).
Dodatkowo, gdy używana jest stacja dysków, instalowane jest także - po załadowaniu handlera (DOS-u) z dyskietki bądź kartridża - urządzenie "D:". Oprócz zwykłych operacji odczytu i zapisu danych dysponuje ono też pewnym wachlarzem operacji specjalnych:
- 32 - RENAME - zmiana nazwy pliku
- 33 - DELETE - skasowanie pliku
- 34 - LOCK DISK - ustawienie software'owego zabezpieczenia dyskietki przed zapisem (SpartaDOS)
- 35 - PROTECT - zabezpieczenie przed zapisem
- 36 - UNPROTECT - odbezpieczenie pliku
- 37 - POINT (SEEK) - ustawienie pozycji w pliku do odczytu/zapisu
- 38 - NOTE (TELL) - odczytanie bieżącej pozycji w pliku
- 39 - LEN - odczyt długości pliku
- 40 - LOAD - załadowanie i uruchomienie pliku binarnego
- 41 - SET DEFAULT DIRECTORY - ustawianie domyślnego katalogu, widzianego jako D: (MyDOS)
- 41 - BINARY SAVE - zapis danych z pamięci do pliku binarnego typu COM (SpartaDOS)
- 42 - MKDIR - utworzenie katalogu
- 43 - RMDIR - skasowanie katalogu
- 44 - CHDIR - zmiana bieżącego katalogu
- 45 - SET BOOT FILE - w SpartaDOS wskazanie pliku, który zostanie załadowany z dyskietki przy zimnym starcie
- 46 - UNLOCK DISK - skasowanie software'owego zabezpieczenia dyskietki przed zapisem (SpartaDOS)
- 47 - CHKDSK - odczyt informacji o dyskietce
- 48 - CWD - odczyt bieżącego katalogu
- 49 - ATTR - ustawianie atrybutów pliku
- 254 - FORMAT - formatowanie dyskietki
Zob. też zestawienie znanych handlerów CIO.
Organizacja wewnętrzna
HATABS
Podstawą ogranizacji CIO jest HATABS - tablica handlerów. Znajduje się ona pod adresem $031A i liczy 33 bajty. Ponieważ jeden wpis zajmuje trzy bajty, to w HATABS jest miejsce na jedenaście wpisów. Pięć - lub sześć, gdy DOS jest załadowany - z nich jest zajęte przez urządzenia systemowe, reszta jest przeznaczona na handlery użytkownika.
Wpis w HATABS, jako się rzekło, zajmuje trzy bajty. Pierwszy z nich to kod ASCII stanowiący identyfikator urządzenia, np. dla stacji dysków, czyli urządzenia "D:", jest to $44, czyli "D".
Dwa następne bajty to wskaźnik do tablicy adresowej zdefiniowanej przez handler.
Tablicę HATABS obsługuje znajdująca się w ROM-ie procedura NEWDEV $E486 (zob. Tablica skoków). Służy ona do dodawania nowych wpisów oraz modyfikacji istniejących.
Tablica adresowa sterownika
Tablica adresowa sterownika ma 16 bajtów. Pierwsze 12 zajmuje sześć wektorów do procedur handlera implementujących kolenje operacje CIO:
| Bajt | Wpis | Funkcja |
| 0 | 1 | Wektor do procedury otwarcia pliku (OPEN) |
| 2 | 2 | Wektor do procedury zamknięcia pliku (CLOSE) |
| 4 | 3 | Wektor do procedury odczytu danych (GET) |
| 6 | 4 | Wektor do procedury zapisu danych (PUT) |
| 8 | 5 | Wektor do procedury odczytu statusu (STATUS) |
| 10 | 6 | Wektor do procedury operacji specjalnych (SPECIAL) |
Wartości wszystkich tych wektorów są pomniejszone o 1.
Następne trzy bajty zajmuje instrukcja skoku JMP do procedury inicjowania handlera. Ostatni bajt jest niewykorzystany.
ZIOCB
W chwili wejścia do CIO system kopiuje zawartość wskazanego IOCB na stronę zerową, konkretnie do obszaru zwanego ZIOCB, a zaczynającego się od adresu $20. Handler urządzenia wykonując operację I/O powinien wszystkie przekazane informacje pobierać stąd właśnie, a nie z głównych bloków kontroli urządzeń znajdujących się na stronie trzeciej ($0340-$03BF); tu też powinien dokonywać wszystkich modyfikacji, jakich chce dokonać w danych zapisanych z IOCB. Po zakończeniu kodu handlera procedury CIO dokonują przekopiowania danych ze ZIOCB z powrotem do wskazanego przez program bloku IOCB.
Trzeba nadmienić, że CIO przepisuje tylko pierwszych 12 bajtów IOCB, pozostałe 4 bajty ZIOCB wykorzystując do swoich celów.
Mankamenty CIO
Trudno orzec, jaka była moda jeśli chodzi o projektowanie tego typu podsystemów pod koniec lat siedemdziesiątych, jednak z dzisiejszego punktu widzenia sposób organizacji CIO wykazuje pewne mankamenty. Za najważniejsze z nich można uznać:
- przypisanie kanałom I/O z góry znanego i ograniczonego pod względem wielkości obszaru w pamięci; skutecznie ogranicza to liczbę równocześnie otwartych plików do ośmiu i jest to bariera nie do przeskoczenia bez zduplikowania przez DOS podsystemu I/O - co czyni np. SpartaDOS X.
- fakt, że numer kanału jest parametrem wejściowym, a nie daną wyjściową CIO. W efekcie, jeśli jeden program - np. w wyniku jakiejś pomyłki - zostawi otwarty konkretny kanał CIO, drugi program nie może go użyć. Z kolei praktyka zamykania kanałów przed ich użyciem może spowodować kłopoty jeśli program został wywołany z innego, który danego kanału używa do własnych celów.
To ostatnie ograniczenie można ominąć, zob. Jak wyszukać pierwszy wolny IOCB.
