3030
edycji
Nie podano opisu zmian |
Nie podano opisu zmian |
||
(Nie pokazano 6 pośrednich wersji utworzonych przez tego samego użytkownika) | |||
Linia 1: | Linia 1: | ||
[[File:Mera400 pg.jpg| | [[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, | 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 | 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'' |