CIO

From Atariki

(Różnice między wersjami)
Jump to: navigation, search
Wersja z dnia 10:09, 21 wrz 2017
KMK (Dyskusja | wkład)
(Tablica adresowa sterownika)
← Previous diff
Wersja z dnia 10:26, 21 wrz 2017
Mono (Dyskusja | wkład)
(HATABS - styl)
Next diff →
Linia 97: Linia 97:
===HATABS=== ===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.+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". 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".

Wersja z dnia 10:26, 21 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

BajtEtykietaOpis
0ICCHID 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.
1ICDNO Numer urządzenia podanego przez użytkownika (np. 3 dla "D3:NAZWA") albo 1, gdy numer nie został podany. Ustawiane automatycznie przez system.
2ICCMD Kod żądanej operacji (rozkaz); ustawiany przez program. Dozwolone kody:
  • $03 - OPEN - otwarcie pliku
  • $05 - GET RECORD - odczyt danych w trybie tekstowym
  • $07 - GET BYTES - odczyt danych w trybie binarnym
  • $09 - PUT RECORD - zapis danych w trybie tekstowym
  • $0B - PUT BYTES - zapis danych w trybie binarnym
  • $0C - CLOSE - zamknięcie pliku
  • $0D - STATUS - odczyt statusu handlera

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.

3ICSTAT 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-5ICBUFA Adres bufora dla operacji, ustawiany przez użytkownika. Dla OPEN, STATUS i operacji specjalnych powinien wskazywać nazwę pliku.
6-7ICPUTB Zmniejszony o 1 adres procedury wysyłania 1 bajtu do urządzenia. Ustawiany automatycznie przez system w czasie otwierania pliku.
8-9ICBUFL 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.
10ICAX1 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.
11ICAX2 Drugi bajt pomocniczy. Jego znaczenie jest zależne od handlera, np. przy otwieraniu ekranu w trybie graficznym będzie to numer trybu graficznego.
12ICAX3 Trzeci bajt pomocniczy. Jego znaczenie jest zależne od handlera.
13ICAX4 Czwarty bajt pomocniczy. Jego znaczenie jest zależne od handlera.
14ICAX5 Piąty bajt pomocniczy. Jego znaczenie jest zależne od handlera.
15ICAX6 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)

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:

BajtWpisFunkcja
01Wektor do procedury otwarcia pliku (OPEN)
22Wektor do procedury zamknięcia pliku (CLOSE)
43Wektor do procedury odczytu danych (GET)
64Wektor do procedury zapisu danych (PUT)
85Wektor do procedury odczytu statusu (STATUS)
106Wektor 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.

Zobacz też

Personal tools