K-202, MERA-400 i CROOK - Krótka historia pewnego projektu
W 1972 r. w Zespole Badawczym Automatyki Okrętowej Instytutu Okrętowego Politechniki Gdańskiej pojawił się pierwszy polski minikomputer K-202, który jako jedyny (import nie był brany pod uwagę) wydawał się być nadający do automatyzacji i sterowania w okrętownictwie. K-202 miał bardzo nowoczesną jak na owe czasy architekturę, wielopoziomowy system przerwań, możliwość pracy w trybach użytkowym i systemowym, podział pamięci operacyjnej na bloki. Cechy te predysponowały minikomputer do pracy wieloprocesowej i wieloprogramowej koniecznej w przewidywanych zastosowaniach.
Pierwszy egzemplarz K-202 składał się z procesora i 88 kB ferrytowej pamięci operacyjnej (z czego 64 kB w osobnej obudowie). Jako konsola operatora służył dalekopis, a z urządzeń wejścia-wyjścia był tylko perforator i czytnik taśmy papierowej. Dostarczone oprogramowanie składało się z systemu operacyjnego SOK-1, kompilatora języka maszynowego (asemblera) ASSK, oraz interpretera języka BASIC.
SOK-1 był systemem operacyjnym tylko z nazwy. Zapewniał wykonywanie tylko jednego procesu, stosunkowo szybki procesor po zleceniu operacji wejścia- wyjścia był wstrzymywany do czasu zakończenia tej operacji.
Stało się rzeczą oczywistą, że K-202 w tej konfiguracji nie nadawał się do sterowania systemami okrętowymi. W opracowaniu był, co prawda blok sprzężenia K-202 CAMAC, który mógł zapewnić połączenie komputera z obiektem sterowania, ale nic nie wskazywało, że w rozsądnym czasie pojawi się system operacyjny pozwalający na jednoczesne wykonywanie wielu programów (procesów). Postanowiono więc stworzyć taki system samodzielnie. Dostawca udostępnił źródłowy SOK-1 w asemblerze, więc pierwsze próby polegały na jego modyfikacji.
Jedną z najczęściej wykonywanych czynności była translacja programów zapisanych w asemblerze na taśmie papierowej. Praca odbywała się sekwencyjnie, wczytanie wiersza programu, przetwarzanie, wczytanie następnego. Czytnik był dość szybki 1kB/sek, i w przerwach między wierszami zatrzymywał się. Powodowało to hałas, szarpanie taśmą, co czasami doprowadzało do jej uszkodzenia. Pierwszą modyfikacją było, więc softwareowe buforowanie urządzeń wejścia-wyjścia. Bufory po kilkadziesiąt znaków załatwiły elegancko sprawę. Czytnik podczas kompilacji już się nie zatrzymywał, a podczas edycji (poprawiania programów) oba urządzenia pracowały równocześnie.
Kolejnym palącym problemem był wielodostęp. Komputer był jeden, z jednym dalekopisem, a chętnych do pracy kilku. Drugi dalekopis szybko się znalazł, ale co z tego. Przerobienie SOK-1 na system wielodostępny nie było już rzeczą trywialną. Jądro systemu odpowiedzialne za zarządzanie wieloma procesami równocześnie, trzeba było zaprojektować od podstaw. Z SOK-1 pozostał tylko interpreter komend systemowych.
Zestaw instrukcji maszynowych K-202, nie zachęcał do pisania tzw. czystych procedur, w których kod programu nie ulega zmianom w czasie wykonywania, wskutek czego znakomita większość programów nie nadawała się do pracy wielowejściowej. Interpreter komend systemowych trzeba więc było napisać od nowa. Tymczasowo jednak, aby uzyskać szybki efekt interpreter z SOK-1 został po prostu powielony. Tą drobną sztuczką osiągnięto pożądany efekt. Dwie osoby mogły pracować jednocześnie i dla każdej komputer zachowywał się tak jak dotychczas. No może nie dokładnie tak samo, bo dostępną pamięć operacyjną trzeba było na sztywno podzielić na dwie części. Każdy z użytkowników miał do dyspozycji 32kB, co wystarczało na przygotowywanie i kompilację programów w asemblerze.
Nowa jakość wymagała też zmiany nazwy systemu. W tym czasie ktoś w Polsce ogłosił sukces uruchamiając na którejś wersji ODRY system pozwalający wykonywać dwa procesy jednocześnie i nazwał go SODA (System Operacyjny Dwu Aktywny). Nasz w założeniach maił być wielo aktywny. I tak postała SOWA.
Inni użytkownicy K-202 stanęli przed tym samym problemem, braku wielodostępu i wieloprogramowości. Gdy dowiedzieli się o pierwszych sukcesach zaproponowali finansowanie dalszych prac polegających na dostosowaniu SOWY do ich potrzeb. Powstały wersje wykorzystane w Biurze Projektów i Studiów Typowych BISTYP w Warszawie (wielodostęp), w Wyższej Szkole Marynarki Wojennej w Gdyni (sterowanie w czasie rzeczywistym systemami kutra torpedowego), w Ministerstwie Spraw Wewnętrznych w Warszawie (do bliżej nie ujawnionych tajnych celów).
Autorów systemu zaproszono do Instytutu Maszyn Matematycznych w Warszawie na seminarium, na którym przedstawili gronu naukowców zasady budowy systemu. No i grono to orzekło, że w o oparciu o te zasady system nie ma prawa działać. System jednak działał, więc musiało być w tym jakieś oszustwo. I tak SOWA stała się CROOK-iem.
CROOK-1 miał już własny język zleceń systemowych zupełnie inny niż SOK-1. Umożliwiał jednoczesną pracę kilku użytkownikom przy sztywnym podziale pamięci operacyjnej. Obsługiwał urządzenia znakowe, dalekopisy, drukarrki, czytniki i perforatory taśmy papierowej. Pozwalał na łączenie strumieni wejścia-wyjścia różnych programów (np. edytora i asemblera), co umożliwiało nanoszenie poprawek w tekstach źródłowych programów bez konieczności perforacji nowej taśmy. Zastosowano prosty algorytm szeregowania procesów typu LIFO, w którym w wyniku obsługi przerwania reaktywowany był proces oczekujący na to przerwanie. Algorytm ten zapewniał szybką reakcję systemu na zdarzenia zewnętrzne. System działał zupełnie poprawnie na komputerach bez generatora przerwań zegarowych.
CROOK-2 mógł sterować obiektem w czasie rzeczywistym (poprzez kasetę CAMAC) jednocześnie obsługując kilku użytkowników wprowadzających i wykonujących swoje programy. Użytkownik zgłaszając się do systemu rezerwował blok pamięci operacyjnej o żądanym wymiarze i w nim już sam musiał rozmieścić używane przez siebie programy. Algorytm szeregowania został rozbudowany przez wprowadzenie priorytetów procesów i cykliczną rotację w oparciu o przerwania z generatora zegarowego. CROOK-2 został zastosowany miedzy innymi w Centrum Medycyny Doświadczalnej i Klinicznej PAN w Warszawie, gdzie był podstawą systemu intensywnego nadzoru chorych po operacjach neurochirurgicznych.
Prace rozwojowe i dalszą produkcje K-202 przerwano i Instytut Okrętowy odkupił od producenta dyski magnetyczne i napędy taśmowe. Urządzenia były nowe, ale bezużyteczne, bo kanał pamięciowy do K-202 nigdy nie powstał. Był jednak blok sprzężenia K-202-CAMAC który pozwalał na przeprowadzenie transmisji blokowej z pamięci operacyjnej K-202 do modułu CAMAC. Potrzebne sterowniki dysków i pamięci taśmowych jako moduły CAMAC zaprojektowali i wykonali w ramach prac dyplomowych studenci Wydziału Elektroniki. Pojawiła się nowa jakość.
CROOK-3 był już pełnym dyskowym, wielodostępnym systemem operacyjnym. Użytkownik przystępując do pracy musiał podać swoją nazwę i hasło otwierające dostęp do własnego skorowidza zbiorów (plików) dyskowych. Ponadto mógł korzystać ze zbiorów umieszczonych w ogólnodostępnej bibliotece. Użytkownik mógł wprowadzić i uruchomić jednocześnie kilka programów, z których każdy mógł składać się z kilku współbieżnych procesów. System zapewniał pełną ochronę zbiorów i programów przed przypadkową lub celową ingerencją innych użytkowników. Pamięć taśmowa była wykorzystywana głównie do archiwizacji zbiorów dyskowych.
Gdy CROOK-3 był już gotowy, pojawił się następca K-202, minikomputer MERA-400. Chociaż wykonana w nieco nowszej technologii, MERA-400 zachowała prawie dokładnie architekturę i listę rozkazów K-202. Zmiany były na tyle drobne, że pozwalały na automatyczne przetłumaczenie programów w asemblerze K-202 na MERĘ-400. W kilka tygodni po zainstalowaniu w Instytucie Okrętowym P.G. MERY-400 przeniesiono na nią system CROOK-3 wraz z całym działającym pod nim oprogramowaniem.
Minikomputer MERA-400 posiadał w standardowej konfiguracji 64 kB ferrytowej pamięci operacyjnej i jeden dysk 5 MB. CROOK-3 potrafił przy tej konfiguracji obsłużyć czterech użytkowników, przy czym sam system zajmował na stałe tylko 16 kB, a każdy z użytkowników miał pozostałe 48 kB do dyspozycji.
Oczywiście MERA-400 była dostarczana z oprogramowaniem producenta. Systemy operacyjne były dwa, SOM-1 (czyli przetłumaczony SOK-1) i SOM-3. Ten ostatni był systemem dyskowym, ale wydawał się być przeniesiony z jakiejś dużej maszyny, która pracowała wyłącznie z taśmami magnetycznymi. SOM-3 był trudny w użyciu, nie miał systemu zbiorów, a dysk traktował jak taśmę. W standardowej konfiguracji MERY-400 mógł obsłużyć tylko jednego użytkownika.
Użytkownicy MERY-400 którzy mieli do czynienia z SOM-3 nie mogli uwierzyć, że na tej samej maszynie pod CROOK-iem może pracować jednocześnie kilka osób, a system zbiorów dyskowych czyni tą pracę łatwą i przyjemną. Powtórzyła się historia z K-202. Zespół z Instytutu Okrętowego otrzymywał kolejne zlecenia dalszego rozwoju CROOK-a.
CROOK-4 miał już hierarchiczną strukturę zbiorów dyskowych i hierarchiczną strukturę procesów. Zapewniał obsługę wszystkich urządzeń, z którymi mogła współpracować MERA-400. Umożliwiał definiowanie własnych języków komunikacji z systemem i symulację działania innych systemów operacyjnych. Powstał symulator SOM-3, który umożliwiał bezpośrednie wykonywanie programów działających pod tym systemem.
Do pracy przyłączyły się inne zespoły. Zespół z Politechniki Poznańskiej wykonał translatory języków FORTRAN, LISP, CSL, ALGOL i MODULA-2. W Instytucie Maszyn Matematycznych zespół osób, które uczestniczyły w powstawaniu K-202 i MERY-400, zajął się koordynacją prac i dystrybucją systemu. W latach 1982-1985 CROOK-4 został uruchomiony na około siedemdziesięciu instalacjach MERY-400 w bardzo różnych warunkach – wyższych uczelniach, biurach projektów, przedsiębiorstwach przemysłowych. Stosunkowo najmniej było zastosowań do pracy w czasie rzeczywistym, czyli celu dla którego pierwotnie powstał. Niemniej w kilku polskich miastach MERA-400 pod CROOK-iem sterowała synchronizacją sygnalizacji świetlnej.
W 1985 roku zaprzestano ostatecznie produkcji MERY-400 a Instytut Maszyn Matematycznych zrezygnował z dalszej dystrybucji CROOKa-4. W tej sytuacji Przedsiębiorstwo Zagraniczne AMEPOL – producent pamięci operacyjnych, procesorów komunikacyjnych umożliwiających podłączanie większej ilości końcówek oraz sterowników pamięci dyskowych, przejęło funkcje dystrybutora systemu. Urządzenia produkowane przez AMEPOL uczyniły z starej MERY-400 sprzęt nowej jakości. Sprzęt ten wymagał też adaptacji systemu operacyjnego.
CROOK-5 współpracował z procesorem komunikacyjnym, pamięciami operacyjnymi o pojemności 2MB, z dyskami o pojemnościach do 40 MB, z zegarem czasu rzeczywistego. Biblioteka kompilatorów została wzbogacona o język C. Minikomputery MERA-400 pracujące pod CROOK-iem można było łączyć z sobą za pomocą łącza pracującego z szybkością 2 MB/sek. W Instytucie Okrętowym uruchomiono instalację, w której dwie sprzężone z sobą MERY-400 obsługiwały pracujących jednoczenie 24 użytkowników (12 stanowisk w laboratorium i 12 końcówek w pokojach pracowników) Podobne instalacje złożone z sprzężonych MER-400 uruchomiono w kilku innych ośrodkach: Politechnice Poznańskiej, Zakładach Elektronicznych UNIMOR, Stoczni Remontowej RADUNIA, Hucie Szkła Szczakowa, WSK Gorzyce k/Sandomierza.
Wbrew obiegowym opiniom system operacyjny CROOK nie był wzorowany na systemie UNIX. Powstawał w sposób ewolucyjny dostosowując się do zmieniającego się środowiska i aktualnych potrzeb, aż w końcu stał się trochę podobny do UNIX-a. Główne podobieństwo dotyczyło hierarchicznego systemu zbiorów. Natomiast już samo rozmieszczenie zawartości zbioru na powierzchni dysku było zupełnie inne. W wszystkich systemach CROOK każdy zbiór zajmował zawsze spójny fragment obszaru dyskowego, natomiast w UNIX-ie zastosowano rozrzuconą strukturę zbiorów. Można by tak wskazywać wiele innych różnic i podobieństw.
Pozostaje jeszcze wyjaśnienie, kto był autorem systemu. Inicjatorem przedsięwzięcia był niewątpliwie Włodzimierz Martin. To dzięki jego działaniom egzemplarze K-202 i MERY-400 znalazły się w Instytucie Okrętowym P.G. On też wciągał do współpracy przy tworzeniu systemu młodszych kolegów i organizował studentom informatyki prace dyplomowe. Pierwszym i przez jakiś czas jedynym „wciągniętym” był autor niniejszego tekstu. Tak więc CROOK-1 i 2 były w całości dziełami jednego autora. CROOK-3 miał już drugiego autora. System zbiorów dyskowych był dziełem Marka Nikodemskiego. Jednak nie mógłby on powstać bez sterownika dysków, który jako pracę dyplomową wykonał Roman Lutowski, oraz sterownika pamięci taśmowej – pracy dyplomowej Wiesława Bojarskiego.
CROOK-4 i 5 miał już wielu autorów: Zbigniew Czerniak – warstwa systemu najbliższa sprzętu, obsługa urządzeń peryferyjnych, zarządzanie procesami i pamięcią operacyjną, kompilator języka maszynowego ASSM; Marek Nikodemski – hierarchiczny system zbiorów dyskowych, interpreter języka komunikacji z systemem; Zenon Kapała – interpreter języka BASIC, symulator systemu SOM-3, kompilator języka C; Wiesław Bojarski – szybkie łącze międzykomputerowe; August Rams – symulator maszyny analogowej CEMMA; Andrzej Bobcow – edytor kontekstowy EDIT; Janusz Gocałek i Jacek Klauziński (Politechnika Poznańska) – kompilatory języków FORTRAN, LISP, CSL, ALGOL, MODULA-2;.
Zbigniew Czerniak