CIO
From Atariki
| Wersja z dnia 20:10, 14 wrz 2006 KMK (Dyskusja | wkład) (→Struktura IOCB) ← Previous diff |
Aktualna wersja KMK (Dyskusja | wkład) (→Struktura IOCB) |
||
| 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 zamknięciu kanału ustawiany jest tu adres procedury CIONOPN 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> | ||
| Linia 76: | Linia 76: | ||
| </table> | </table> | ||
| - | ===Wykaz urządzeń=== | + | ==Wykaz urządzeń== |
| System operacyjny standardowo instaluje pięć urządzeń. Są to: | System operacyjny standardowo instaluje pięć urządzeń. Są to: | ||
| Linia 86: | Linia 86: | ||
| * "K:" - klawiatura | * "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). | + | Zob. też [[Lista handlerów CIO|zestawienie znanych handlerów CIO]]. |
| - | Dodatkowo, gdy używana jest stacja dysków, instalowane jest także - po załadowaniu handlera ([[DOS|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: | + | == Funkcje specjalne ([[XIO]]) == |
| - | * 32 - RENAME - zmiana nazwy pliku | + | * [[Lista funkcji specjalnych CIO według urządzeń]] |
| - | * 33 - DELETE - skasowanie pliku | + | * [[Lista funkcji specjalnych CIO według kodów operacyjnych]] |
| - | * 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ż [[Lista handlerów CIO|zestawienie znanych handlerów CIO]]. | + | |
| ==Organizacja wewnętrzna== | ==Organizacja wewnętrzna== | ||
| Linia 117: | 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". | ||
| Linia 123: | Linia 103: | ||
| Dwa następne bajty to wskaźnik do tablicy adresowej zdefiniowanej przez handler. | 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. Służy ona do dodawania nowych wpisów oraz modyfikacji istniejących. | + | 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=== | ||
| - | Tablica adresowa sterownika ma 16 bajtów. Pierwsze 12 zajmuje sześć wektorów do procedur handlera implementujących kolenje operacje CIO: | + | Tablica adresowa sterownika ma 16 bajtów. Pierwsze 12 zajmuje sześć wektorów do procedur handlera implementujących kolejne operacje CIO: |
| <table border=1 cellpadding=5> | <table border=1 cellpadding=5> | ||
| Linia 148: | Linia 128: | ||
| Trzeba nadmienić, że CIO przepisuje tylko pierwszych 12 bajtów IOCB, pozostałe 4 bajty ZIOCB wykorzystując do swoich celów. | 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== | ==Mankamenty CIO== | ||
| Linia 158: | Linia 140: | ||
| To ostatnie ograniczenie można ominąć, zob. [[Programowanie: Jak wyszukać pierwszy wolny IOCB|Jak wyszukać pierwszy wolny IOCB]]. | 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:Menu Główne]] | ||
| [[Kategoria:Programowanie Atari 8-bit]] | [[Kategoria:Programowanie Atari 8-bit]] | ||
Aktualna wersja
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 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ż 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.
