CIO
From Atariki
| Wersja z dnia 00:13, 26 wrz 2017 Mono (Dyskusja | wkład) (→ZIOCB - moze to nie bylo intuicyjne) ← Previous diff |
Wersja z dnia 10:18, 26 wrz 2017 Mono (Dyskusja | wkład) (→Struktura IOCB - icputb po zamknieciu #) Next diff → |
||
| Linia 43: | Linia 43: | ||
| <tr><td>6-7</td><td>ICPUTB</td> | <tr><td>6-7</td><td>ICPUTB</td> | ||
| - | <td>Zmniejszony o 1 adres procedury wysyłania 1 bajtu do urządzenia. Ustawiany automatycznie przez system w czasie otwierania pliku. | + | <td>Zmniejszony o 1 adres procedury wysyłania 1 bajtu do urządzenia. Ustawiany automatycznie przez system w czasie otwierania pliku.<br> |
| - | </td></tr> | + | Po zakmnięciu kanału ustawiany jest tu adres procedury zwracającej kod 133 (DEVICE OR FILE NOT OPEN).</td></tr> |
| <tr><td>8-9</td><td>ICBUFL</td> | <tr><td>8-9</td><td>ICBUFL</td> | ||
Wersja z dnia 10:18, 26 wrz 2017
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. Po zakmnięciu kanału ustawiany jest tu adres procedury zwracającej kod 133 (DEVICE OR FILE NOT OPEN). |
| 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
Zob. też zestawienie znanych handlerów CIO.
Funkcje specjalne (XIO)
- Lista funkcji specjalnych CIO według urządzeń
- Lista funkcji specjalnych CIO według kodów operacyjnych
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ęć z nich - lub sześć, gdy DOS jest załadowany - 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 kolejne 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.
ICAX3Z i ICAX4Z są wykorzystywane do przechowywania adresu handlera CIO oraz adresu wykonywanej procedury, w ICAX5Z i ICAX6Z zaś zachowane są wartości rejestrów X i A procesora przekazanych przy wejściu do JCIOMAIN. Korzystając z tych komórek można w procedurze obsługi rozkazu zarówno odczytywać, jak i zapisywać wartości ICAX3..6 z IOCB. Procedura CIO tych komórek nie dotyka. Nic więc nie stoi na przeszkodzie, aby w każdym wywołaniu CIO przekazywać parametry oraz zwracać wynik za pomocą wszystkich rejestrów ICAX.
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.
