Umbruch im System: OS-9/68000 reizt den ST endlich aus

Für industrielle Anwendungen auf dem MC68000 konzipiert, erfüllt das multitasking-, multiuser und echtzeitfähige OS-9/68000 alle Ansprüche an ein modernes professionelles Betriebssystem.

TOS gibt Ihnen einen Einblick in das Konzept von OS-9/68000 und erklärt, warum es gleichermaßen bei Anwendern und Programmierern beliebt ist.

Die Wurzeln von OS-9/68000 liegen im Betriebssystem OS-9 für den legendären 6809-Prozessor. Ende der 70er Jahre entwickelten Motorola und Microware für diesen Prozessor ein modernes multiuser-, multitasking- und echtzeitfähiges Betriebssystem mit einem außergewöhnlich modularen Konzept. Das System sollte im ROM Platz finden und dazu kompakt, schnell und sehr flexibel sein, da es für Anwendungen im industriellen Bereich entwickelt wurde. Außerdem konnte man auf ein breites Erfahrungsspektrum mit dem Betriebssystem UNIX zurückgreifen. So ist es nicht weiter verwunderlich, daß große konzeptionelle Ähnlichkeiten zwischen den beiden Betriebssystemen bestehen.

Anfang der 80er Jahre übertrug Microware - Motorola hatte sich inzwischen aus dem OS-9-Geschäft zurückgezogen - OS-9 auf den mittlerweile in großen Stückzahlen verfügbaren und im industriellen Bereich sehr beliebten 68000-Prozessor. Wegen der erheblich größeren Leistungsfähigkeit dieses Prozessors im Vergleich zum 6809 war diese Version stark verbessert und erweitert. Mittlerweile gibt es Versionen für die anderen Prozessoren aus der 680x0-Serie (68010, 68020, 68030). Der jüngste Spross der OS-9-Familie ist OS-9000, ein Betriebssystem für 68030, 80386/ 80486 und diverse RISC-Prozessoren.

Der ST: Idealer OS-9/68000-Computer

Die Anpassung von OS-9/68000 auf den Atari ST war nicht einfach. Wegen der teilweise komplexen Hardware und besonders wegen der mangelhaften Dokumentation - das war 1987, heute ist sie schon erheblich besser - ergaben sich viele Probleme. Dennoch erweist sich der ST als eine leistungsfähige OS-9/68000-Maschine: Der extrem schnelle DMA-Kanal, der direkte Zugriff auf das Video-Memory und die zahlreichen Schnittstellen ergeben eine komfortable Entwicklungs- und Anwenderumgebung für OS-9/68000-Software.

Grundsätzlich verzichteten die Entwickler bei dieser Implementation auf die Verwendung jeglicher im ROM-TOS vorhandenen Routinen, d. h. nach dem Start von OS-9/68000 könnten die TOS-ROMs aus ihren Sockeln gezogen werden. Außerdem gibt es für alle Standard-Schnittstellen des STs (Monitor, Tastatur, Maus, Diskettenlaufwerke, Festplatte, RS-232, Centronics und MIDI) geeignete Treiber.

Eine Besonderheit stellt der Treiber für virtuelle Terminals dar: Durch einfaches Umschalten mit den Funktionstasten emuliert er auf dem Bildschirm bis zu acht Terminals. Diese Terminals sind voneinander völlig unabhängig. Eine Statuszeile am unteren Rand des Bildschirms gibt Aufschluß über den Zustand jedes, auch gerade nicht sichtbaren Terminals. Dabei erfahren Sie die Programmnamen, ob seit dem letzten Umschalten eine Ausgabe erfolgt ist, ob das Terminal eine Eingabe erwartet usw.

Bild 1. Unter OS-9/68000 besitzen Module eine genau definierte Struktur. Eine Modultabelle hält ihre Lage im Speicher fest.

Durch Module flexibel

Wie bereits erwähnt, besitzt OS-9/68000 ein modulares Konzept. Jede Funktionsgruppe des Betriebssystems und jedes Anwenderprogramm ist in einem eigenen Modul »verpackt«. Module besitzen einen eindeutigen Namen, z. B. »kernel« für den Betriebssystemkern, »stclock« für den Uhrtreiber oder »c68« für den C-Compiler. Der Betriebssystemkern verwaltet die Module über eine Tabelle (siehe Bild 1).

Sie enthalt die Anfangsadressen der Module im Speicher sowie einen Zähler, der angibt, wie oft das Modul verwendet wird. Ist dieser Zähler Null, kann das Betriebssystem das entsprechende Modul bei Speicherbedarf entfernen. Module beginnen mit einem Kopf (Header), der Informationen wie Größe des Moduls in Bytes, Modultyp (z. B. Programm, Treiber, Daten), Zugriffsberechtigungen, Einsprungsadresse sowie einen Verweis auf den Namen des Moduls enthält. Danach folgt der Modulrumpf (Body), der aus dem ausführbaren Programm oder Daten besteht. Vom gesamten Modul gibt es eine Prüfsumme, die hinter dem Rumpf abgelegt ist. Module werden in Dateien gespeichert.

Beim Aufruf eines Programms durch den Benutzer sucht das Betriebssystem eine Datei mit dem angegebenen Namen (z. B. »c68«), reserviert Speicherplatz und lädt die Datei zusammenhängend an diese Stelle. Danach erfolgt der Eintrag in die Modultabelle, und das Programm startet an der im Header enthaltenen Einsprungsadresse.

Das Treiberkonzept von OS-9/68000

Dieses modulare Konzept erlaubt die dynamische Konfiguration des Systems. Im Gegensatz zu anderen Gerätetreiber haben die Aufgabe, die Peripherie des Computers zu steuern. Der Festplattentreiber muß Sektoren von der Festplatte lesen oder auf sie schreiben. Der RS-232-Treiber empfängt oder sendet Zeichen über die serielle Schnittstelle. Diese Funktionen hängen sehr von den verwendeten Hardwarebausteinen ab und müssen bei der Implementation eines Betriebssystems für einen Computer in der Regel neu programmiert werden.

Höhergeordnete Funktionen, wie z. B. die Verwaltung von Inhaltsverzeichnissen und Dateien auf einer Festplatte sind hardwareunabhängig und laufen auf jedem Computer. OS-9/68000 unterscheidet strikt zwischen diesen Funktionsbereichen. Die logische Verwaltung von gleichartigen Geräten, wie etwa Festplatte und Diskettenlaufwerk oder serieller und paralleler Schnittstelle, erledigen sog. Filemanagermodule.

Die hardwareabhängigen Aufgaben bleiben dagegen Treibermodulen überlassen. Den Zusammenhang zwischen Filemanagern und dazugehörigen Treibern stellen die Device-Descriptor-Module her (siehe Bild 2). Für jedes Gerät existiert im System ein derartiger Descriptor, der neben gerätespezifischen Informationen, wie etwa die Anzahl Sektoren auf der Spur bei einem Diskettenlaufwerk oder die Baudrate bei einer seriellen Schnittstelle, auch den Namen des zugehörigen Filemanager- und des Treibermoduls enthält. So kann der Betriebssystemkern für den Zugriff auf ein Peripheriegerät die passenden Routinen aufrufen.

Für gängige Gerätetypen gibt es Standard-Filemanager, so z. B. für Festplatten und Diskettenlaufwerke, für serielle Schnittstellen, für Bandlaufwerke und für Netzwerke. Auch der Benutzer kann (z. B. in C) neue Filemanager und Treiber schreiben und dem System hinzufügen.

Programme und Prozesse

Bei Multitasking-Betriebssystemen wie OS-9/68000 ist zwischen Programmen und Prozessen zu unterscheiden. Korrekterweise müßte man sagen, man startet nicht ein Programm, sondern einen Prozeß, der ein bestimmtes Programm abarbeitet. Ein Prozeß kann zu einem bestimmten Zeitpunkt nur ein Programm abarbeiten, das selbe Programm kann aber von verschiedenen Prozessen abgearbeitet werden.

Jeder laufende Prozeß hat einen Eintrag in einer speziellen Tabelle, der Prozeßtabelle. In ihr sind u. a. ein Zeiger auf das Programmodul, eine Liste der vom Prozeß geöffneten Dateien sowie Platz für eine Kopie der CPU-Register enthalten. Dieser Platz ist notwendig, da Prozesse nicht gleichzeitig, sondern »scheibchenweise« abgearbeitet werden. Der Betriebssystemkern schaltet dauernd zwischen den aktiven Prozessen um und muß deren Register immer retten bzw. wiederherstellen. Dieses Verfahren der Rechenzeitzuteilung für Prozesse heißt Time-Sharing. Durch die Zuweisung einer hohen Priorität für einen Prozeß erreicht der Benutzer, daß dieser Prozeß mehr Zeitscheiben erhält als die anderen und so schneller als die anderen abläuft.

Das Modul-Konzept von OS-9/68000 bietet in diesem Zusammenhang noch einen weiteren Vorteil. Wenn mehrere Prozesse das selbe Programmodul abarbeiten, mußesnureinmal im Speichervorhanden sein. Nur die Datenbereiche werden für jeden Prozeß separat benötigt.

Bild 3. Mehrere Prozesse tauschen über ein Datenmodul Informationen aus. Jeder Prozeß kann mit einem Systemaufruf und Angabe des Modulnamens die Startadresse der Daten feststellen.

Prozeßkommunikation

Für viele Anwendungen müssen Prozesse in der Lage sein, miteinander zu kommunizieren. OS-9/68000 stellt dazu vier verschiedene Arten zur Verfügung:

Datenmodule (siehe Bild 3) sind Speicherbereiche, auf die beliebig viele Prozesse zugreifen können. Da auch Datenmodule mit einem eindeutigen Namen bezeichnet sind, erreicht sie jeder Prozeß mit Hilfe eines Betriebssystemaufrufs.
Signale (siehe Bild 4) sind Nummern, die ein Prozeß an einen anderen schickt. Wenn ein Prozeß Signale empfangen will, muß er mit einem Betriebssystemaufruf eine Signalroutine installieren. Diese ruft er bei jedem ankommenden Signal mit der Signalnummer als Parameter auf. Dazu unterbricht er kurz den Programmablauf. So kann ein Prozeß einen anderen z. B. darüber benachrichtigen, daß für ihn Daten in einem Datenmodul verfügbar sind.
Eine Pipe (siehe Bild 5) ist ein Puffer, in dem ein Prozeß Daten schreibt und aus dem ein anderer Prozeß diese Daten in der gleichen Reihenfolge wieder ausliest (FIFG-Prinzip). Wenn der Puffer voll ist, hält das Betriebssystem den schreibenden Prozeß automatisch an, bis der lesende Daten abgeholt hat und im Puffer wieder Platz ist. Das gleiche passiert, wenn der Puffer leer ist: Der lesende Prozeß stoppt, bis der schreibende wieder Daten im Puffer abgelegt hat. Pipes werden wie normale Dateien - mit den üblichen Ein-/Ausgabefunktionen (wie open(), read() und write()) - angesprochen.
Semaphore erlauben den koordinierten Zugriff von zwei oder mehreren Prozessen auf gemeinsame Datenbereiche (z, B. ein Datenmodul).

Breite Softwarepalette

Für OS-9/68000 gibt es zahlreiche Compiler. Am wichtigsten ist der C-Compiler, der dem K&R Standard entspricht. Die C-Library enthält viele UNIX-kompatible Funktionen, welche die Übertragung von UNIX-Programmen auf OS-9/68000 erheblich erleichtern. Das make-Programm kompiliert selbst größere Programmpakete einfach und automatisch. Zeitkritische Programmteile, die in Assembler geschrieben sind, lassen sich mit dem Makro-Assembler nach Motorola-Standard übersetzen. Der Linker erzeugt sowohl OS-9/68000 Programmodule als auch absoluten Code für Einplatinencomputer auf ROM-Basis. Mit dem symbolischen Debugger verfolgt der Benutzer den Programmablauf Schritt für Schritt. Der Debugger beherrscht u. a. Breakpoints, Disassemblierung und Memorydumps. SCULPTOR ist ein mehrplatzfähiges Datenbanksystem mit maskengesteuerter Online-Bearbeitung und Report-Generator. Beide Teile lassen sich in einer mächtigen Datenbanksprache einfach programmieren. Die Tabellenkalkulation DYNACALC stellt ein riesiges Arbeitsfeld zur Verfügung und bietet zahlreiche Funktionen und Bearbeitungsmöglichkeiten. Mit der Textverarbeitung STYLOGRAPH lassen sich Dokumente schnell anfertigen. Ein Mail merge-Programm erlaubt den Ausdruck von Serienbriefen.

Bild 4. Signale erlauben die asynchrone Kommunikation zwischen Prozessen. Das Betriebssystem unterbricht den empfangenen Prozeß und führt eine von ihm vorher installierte Signal-Behandlungsroutine aus. Anschließend setzt es den Prozeß fort.

Bild 5. Pipes erlauben einen gepufferten und automatisch synchronisierten Datenfluß zwischen zwei Prozessen. So dient z. B. die Ausgabe eines Prozesses als Eingabe eines anderen.

Der MGR (ManaGeR) ist eine kompakte, multitaskingfähige grafische Benutzeroberfläche, die an zahlreiche VME-Bus-Grafikkarten und den Atari ST angepaßt ist. Sie erlaubt es, in nahezu beliebig vielen Fenstern Anwendungen parallel ablaufen zu lassen. MGR ähnelt vom Erscheinungsbild dem X-Windows-System für UNIX. Die Programme, die unter MGR arbeiten, bedienen Sie dabei bequem mit der Maus. (ba)

Über den Autor: Wolfgang Ocker, Jahrgang 1962, ist Gründer und Inhaber der Firma reccoware systems, die sich hauptsächlich mit der Entwicklung von Systemsoftware für OS-9/ 68000 befaßt. Die Portierung von OS-9/68000 auf den Atari ST im Jahre 1987 war eines der ersten größeren Projekte.

Literatur: »The OS-9 Catalog, Second Edition«, 1989, microware: Technisch orientierte, detaillierte Übersicht über OS-9/68000 und Zusatzprodukte von microware.

»OS-9 Insights, An Advanced Programmers Guide to OS-9/68000«, 1988, microware, ISBN 0-918035-01-5 (auch in deutscher Sprache): Genaue Beschreibung von OS-9/68000 für Systemprogrammierer. Vollständigen Beispiele erleichtern die Entwicklung von Gerätetreibern und Filemanager.

Wolfgang Ocker

Aus: TOS 09 / 1990, Seite 72

Links