imported>Atariki recovery: Reconstructed from archived HTML; see provenance manifest

2026-10-01T08:51:48Z

Reconstructed from archived HTML; see provenance manifest

Nowa strona

CIO - Central Input/Output - rezydujący w pamięci [[ROM]] komputera podsystem [[Atari OS|Atari OS-u]] odpowiedzialny za obsługę plików.

== 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 [[Kody błędów|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:
* $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.
|-
| 3
| ICSTAT
| Status operacji ustawiany automatycznie po jej wykonaniu, czyli wartość 1 gdy sukces lub ujemny [[Kody błędów|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.<br />
Po zamknięciu kanału ustawiany jest tu adres procedury CIONOPN 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ż [[Lista handlerów CIO|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. [[Programowanie: Jak wyszukać pierwszy wolny IOCB|Jak wyszukać pierwszy wolny IOCB]].

== Zobacz też ==

* [[Dostęp do plików]]
* [[Biblioteczka kodera Atari XL/XE#CIO|Korzystanie z wywołań CIO]]

[[Kategoria:Menu Główne]]
[[Kategoria:Programowanie Atari 8-bit]]

CIO - Historia wersji

imported>Atariki recovery: Reconstructed from archived HTML; see provenance manifest