Jak powstają DOS-y ?Komputery Atari serii XE/XL są starymi wytworami światowej myśli informatycznej, jego systemowe oprogramowanie powstawało dawno i obecnie uważane jest za mało elastyczne. Można by nawet zaryzykować opinię, że programy takie zawierąją błędy, a ich obsługa jest czasochłonna i męcząca. Do takich należą niestety DOS-y. Wady i zalety dwóch najpopularniejszych DOS-ów (SpartaDOS-u oraz DOS-u 2.5) opisałem w poprzednim numerze Tajemnic, więc wiadomo na czym polega problem. Moim ideałem jest DOS o następujących parametrach: możliwość obsługiwania dyskietek sformatowanych we wszystkich podstawowych gęstościach (pojedynczej, rozszerzonej i podwójnej), najmniejsza długość kodu maszynowego programu, stale obecny w pamięci Command Processor, zgodność z innymi DOS-ami. Jest sprawą oczywistą, że powinien się oznaczać poprawnym oraz szybkim działaniem (przesianie sektora danych do lub z bufora musi odbyć się na tyle sprawnie, aby dyskietka nie robiła w stacji dysków jałowego obrotu zanim głowica odczyta lub zapisze właściwy sektor). Problem szybkości działania jest prawdopodobnie najtrudniejszym do rozwiązania. Dzieje się to ze względu na stosunkowo krótki czas pomiędzy odczytem lub zapisem dwóch kolejnych sektorów. Dodatkowo komplikują sprawę popularne obecnie rozszerzenia typu "Turbo", które ten czas jeszcze dodatkowo skracają. W przerwie tej DOS musi obsłużyć bufor sektora oraz zajmująca gro czasu CIO. Krótka dygresja na temat komunikacji komputera z urządzeniami peryferyjnymi z punktu widzenia użytkownika. System operacyjny ATARI posiada własne procedury wejścia/wyjścia, którymi zarządza Central Input/Output (CIO) czyli centrala operacji WE/WY. Programista może skorzystać z tych procedur poprzez umiejętną obsługę IOCB-ÓW (Input-Output Control Block) czyli bloków sterowania wejścia/wyjścia. CIO poprzez tablicę HATABS, która zawiera spis obecnych urządzeń zewnętrznych uaktywnia sterownik danego urządzenia (tzw. handler), który najczęściej z kolei uruchamia Serial Input/Output (SIO). SIO bezpośrednio wpływa na "obudzenie się" urządzenia zewnętrznego. W ten prosty sposób większość programów obsługuje urządzenia peryferyjne. Praktycznie gdyby DOS-y korzystały z procedur systemowych, to wyglądałoby to tak: operacja na sektorze, przerwa spowodowana niepotrzebnym obrotem dyskietki w stacji dysków, operacja na sektorze. Jak nietrudno się domyślić czas odczytu czy zapisu zwiększyłby się kilkakrotnie. Używając np. DOS-u 2.5 słyszymy jednak, że operacje na dyskietce odbywają się płynnie, dłuższa przerwa następuje tylko podczas przejścia głowicy stacji dysków z jednej ścieżki sektorowej na inną. Budowa dyskietki (sektory, ścieżki) została opisana w TA 4/91, więc wszyscy, którzy dokładnie zapoznali się z treścią artykułu o Dyskowych Systemach Operacyjnych powinni zrozumieć sedno problemu. Istnieją zatem sposoby na zwiększenie szybkości transmisji danych. Przytoczę tutaj dwa z nich. Pierwszym, wykorzystywanym przez DOS 2.5 firmy Atari Corporation, jest napisanie własnych procedur obsługi przerwania wywoływanego przez port szeregowy podczas przesyłania danych. Jest to rozwiązanie bardzo skuteczne, ale stosunkowo trudne w praktycznej realizacji, bo wymaga bardzo dobrej znąjomości nie tylko obsługi przerwań, ale również SIO, a w szczególności transmisji przez szeregowy port wejścia/wyjścia. Drugi sposób uzyskania wystarczającej prędkości wykonywania operacji WE/WY jest równie skuteczny, lecz, moim zdaniem, łatwiejszy w praktycznym wykonaniu. Polega on na "oszukaniu" CIO, a właściwie na symulacji jego działania. W skrócie opiszę postępowanie systemu operacyjnego po próbie dokonania przez użytkownika operacji na pliku. Zasadniczo proces ten został opisany w numerze 5/91 Tajemnic Atari, więc przypuśćmy, że mamy do czynienia z odczytem lub zapisem pliku. Operacje te składają się najogólniej z trzech faz: otwarcia pliku, przesłania danych oraz zamknięcia pliku. Szczegółowo zajmę się fazą drugą ze względu na jej czasowo krytyczny charakter. To właśnie ta część operacji decyduje o prędkości transmisji danych. Załóżmy, że dany plik został otwarty (faza otwarcia zbioru zakończyła się sukcesem). Użytkownik ustawia odpowiednio do własnych potrzeb IOCB i uaktywnia CIO. Co się dzieje od tej chwili aż do czasu powrotu do programu wywołującego? CIO po sprawdzeniu poprawności wywołania przepisuje aktywny blok kontroli WE/WY na stronę zerową, szuka w tablicy HATABS adresu sterownika urządzenia D:, a następnie na jego podstawie uaktywnia Dyskowy System Operacyjny. DOS przesyła jeden bajt danych (w zależności od rodzaju operacji dana jest pobierana z bufora sektora i zwracana do CIO w rejestrze A mikroprocesora (LOAD) lub pobierana z rejestru A i zapisywana w buforze sektora (SAVE)). Po przesłaniu tej danej sterowanie programu jest przekazywane przez DOS do CIO, które zmniejsza licznik bajtów przeznaczonych do transmisji, zwiększa adres przesyłanej danej i jeśli długość bufora jest różna od zera uaktywnia DOS, cały proces powtarza się. Jak łatwo się domyślić jest to proces niezwykle czasochłonny, zwalniający operacje wykonywane przez stację dysków. Tutaj właśnie tkwi sedno rozwiązania problemu szybkiego przesyłania danych. Należy zasymulować działanie CIO. Zamiast więc przesyłać jeden bajt danych, przesyłamy żądany blok danych, umieszczając go bezpośrednio w pamięci (bo pomijamy CIO, które między innymi tym się zajmuje), uaktualniamy ZIOCB czyli blok kontroli WE/WY strony zerowej (patrz mapa pamięci) i dopiero wtedy DOS powinien oddać sterowanie do CIO. Cała ta operacja będzie niezauważalna przez CIO, ponieważ jej systemowe procedury bazują na bloku I/O, który umiejętnie został uaktualniony. Takie rozwiązanie problemu skutecznie zapewnia operacjom WE/WY płynność działania. "Podrobienie" działania CIO powoduje wydłużenie kodu maszynowego DOS-u, lecz ze względu na działania przede wszystkim na komórkach pamięci umieszczonych na stronie zerowej ta obsługa jest stosunkowo krótka, z pewnością zastosowanie pierwszego sposobu czyli napisanie własnych procedur obsługi portu szeregowego jest dłuższe i bardziej skomplikowane. Leon
|