K-202, MERA-400 i CROOK - Krótka historia pewnego projektu: Różnice pomiędzy wersjami

Przejdź do nawigacji Przejdź do wyszukiwania

K-202, MERA-400 i CROOK - Krótka historia pewnego projektu (tekst źródłowy)

Wersja z 11:09, 12 wrz 2016

Dodane 10 bajtów ,  12 wrz 2016
brak opisu edycji
Nie podano opisu zmian
Nie podano opisu zmian
 
(Nie pokazano 3 pośrednich wersji utworzonych przez tego samego użytkownika)
Linia 1: Linia 1:
[[File:Mera400 pg.jpg|thumb|500px|K-202, MERA-400 i peryferia - Politechnika Gdańska]]
[[File:Mera400 pg.jpg|thumb|500px|K-202, MERA-400 i peryferia - Politechnika Gdańska]]
W 1972 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.
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.
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.
Linia 12: Linia 12:
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.
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, do wystarczało na przygotowywanie i kompilację programów w asemblerze.
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.
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.
Linia 18: Linia 18:
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).
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 przestawili 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.
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-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.
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.
Linia 50: Linia 50:
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;.
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
 
''Zbigniew Czerniak''
Źródło: „http://mera400.pl/Specjalna:Różnica_mobilna/2364...2369”

Menu nawigacyjne