Polskie Towarzystwo Informatyczne
NUMER ARCHIWALNY:     1-2 / 43 -44 rok V | styczeń-luty 1986
Archiwum
Menu chronologiczne Menu tematyczne


Polskie Towarzystwo Informatyczne

Kilka uwag do artykułu o systemie CP/M

                Artykuł kol. Andrzeja J. Majewskiego z Gdańska pt. “Dyskowy ,system operacyjny CP/M” (część pierwsza) zamieszczony w Biuletynie PTI 1985, nr 9 zawiera (niestety) sporo nieścisłości, których sprostowanie wydaje mi się niezbędne. Uwagi moje dotyczą wersji CP/M 2.2 pochodzącej z roku 1979. Jest zatem możliwe, że w późniejszych mutacjach tej wersji sprawy, o których piszę, potraktowano nieco inaczej. Będę wdzięczny za ewentualne informacje na ten temat. A teraz do rzeczy:

1.     Nie podzielam poglądu kol. A. J. M., że wersja 2.2 systemu CP/M stanowi “produkt w pełni dojrzały”. Dla uzasadnienia przypomnę:
(a)   bardzo uproszczone (wręcz nieporadne) reagowanie na błędy przesyłań dyskowych;
(b) mało sensowne potraktowanie programów realizujących dyrektywy nierezydentne CP/M w niezerowych obszarach użytkownika (n.b. jest to bardzo łatwe do skorygowania!);
(c)   automatyczne blokowanie zapisu po wymianie dyskietki w pojemniku, które bywa tyleż pożyteczne, co kłopotliwe.
Sprawy powyższe nie umniejszają oczywistych walorów systemu CP/M 2.2, ale produktem “w pełni dojrzałym” to on jednak nie jest.
2.     System CP/M 2.2 może pracować poprawnie w pamięci RAM mniejszej niż 20 KB. Osobiście zainstalowałem go w pamięci ok. 10 KB i pracuje tam bez zarzutu. Ograniczenie do 20 KB zalecane przez producenta systemu wynika, jak sądzę, z chęci zapewnienia dostatecznie dużego obszaru TPA dla przeciętnych warunków eksploatacyjnych. Nie jest ono jednak obligatoryjne.
3.     Bufor komunikacji z konsolą znajduje się w obszarze CCP, a nie na stronicy zerowej. Podczas stanu systemu BIOS zapełnia jedynie początkowe osiem bajtów stronicy zerowej. Pozostały obszar stronicy zerowej, używany przez system, jest zapełniany przez CCP.
4.     CCP nie jest “programem”, a BDOS nie jest “zestawem programów” (!). Obydwa stanowią jedynie moduły systemu CP/M.
5.     Znakowe strumienie wejścia i wyjścia oraz zarządzanie pamięcią obsługuje nie tylko BDOS, lecz także (w większym nawet stopniu) CCP.
6.     Żaden z modułów CP/M nie może być niszczony przez programy użytkowe (chyba że w sposób ściśle kontrolowany, tzn. w pełnej zgodności z ich budową i funkcjami). CP/M nie pozwoli na “przykrycie” żadnej ze swych części programem ładowanym do TPA. Ma też wbudowane specjalne procedury, badające wzajemną koegzystencję CCP i BDOS, oraz blokujący pracę mikrokomputera, gdy stwierdzi, że któryś z nich został “uszkodzony”.
7.     CCP nie powinien być nakładkowany bez absolutnej potrzeby. Nie należy pochopnie uogólniać rozwiązania zastosowanego w debuggerze. Szczegóły — vide p. 6.
8.     Nie podzielam entuzjazmu kol. A. J. M. związanego z pojemnością zbiorów dyskowych, które może obsłużyć system CP/M. Podstawową jednostką pojemności zbioru rejestrowaną przez CP/M w pojedynczym zapisie w katalogu dysku jest tzw. extend mogący opisać maksimum 16 KB pamięci. Zbiór o pojemności 8 MB musiałby zatem być zarejestrowany w 512 zapisach katalogowych. A system CP/M przegląda katalog sekwencyjnie. Bezpośredni dostęp do danych (wynikający z sugerowanej przez kol. A. J. M. organizacji zbioru w bazę danych) znacznie zwiększa ilość odwołań do katalogu. Wątpię, aby przetwarzanie tak dużego zbioru było w tej sytuacji efektywne.
9.     Nie jest prawdą, że “w obrębie jednego dysku nie mogą istnieć dwa pliki o identycznych nazwach i typach należące do tego samego użytkownika”. Mogą istnieć i mogą być poprawnie przetwarzane. CP/M dostarcza niezbędne do tego narzędzia (np. ekstrakody przeglądania katalogu dysku). Jest natomiast prawdą, że sensowność tego typu sytuacji jest ograniczona do kilku bardzo specyficznych przypadków.
10. Dysk może być dzielony pomiędzy 32 użytkowników, z czego jedynie pierwszych 16 ma dostęp do swoich obszarów z konsoli monitora (n.b. obszaru 32 nie należy raczej używać bez dokładnego rozeznania problemu).
11. Zbiór “tymczasowy” typu $$$ nie jest automatycznie niszczony przy końcu sesji. Dotyczy to tylko zbioru o nazwie SUB.$$$ tworzonego w trakcie realizacji dyrektywy SUBMIT.
                Powyżej wypunktowałem jedynie najważniejsze nieścisłości zawarte w artykule. Ponadto artykuł razi nieco niekonsekwencją i niedokładnością stosowanej terminologii (“moduł”, “program”, “zestaw programów”, ,.sesja" itp.).
                Mam nadzieję, że kol. A. J. M. nie weźmie mi za złe tych paru uwag krytycznych. O ile się orientuję, PTI za jeden ze swych “punktów honoru” uważa dobrą jakość merytoryczną. A to zobowiązuje, prawda?
Mariusz Klapper

Kraków

Archiwum PTI Ewa Łukasik ( elukasik@cs.put.poznan.pl) Grzegorz Przybył ( grzegorz.przybyl@wp.pl ) www.pti.org.pl Kontakt PTI ( pti@pti.org.pl )
Tutorial


Tutorial

Wyszukiwanie

Całość
tylko prodialog
tylko biuletyny
tylko konferencje
tylko multimedia
tylko sprawozdania
tylko uchwały
tylko zawody
tylko zjazdy
pozostałe treści

Rodzaj przeszukiwania
Słowa kluczowe
Pełen tekst

pelen zakres dat
ograniczony zakres
od:

do:




Kontakty

Instytut Informatyki

Polskie Towarzystwo Informatyczne

Nasz Skrzynka Pocztowa

+ - D A