Abs. : KIO
Datum:  5.12.90 um 20:01 Uhr
Betr.: A:RTOS

Hallo Hardy,

nun ja, zu RTOS läßt sich vielleicht folgendes kurz (?) sagen:

Es handelt sich um ein Multitasking, Multiuser, Realtime Betriebssystem. Goile
Sache, newa ? naja ...

Es hat keine grafische Benutzeroberfläche.
Es hat mit TOS nichts zu tun.

Es gibt (bisher) als Programmiersprachen nur PEARL und ASSEMBLER.

Immerhin unterstützt es mittlerweile auch normale TOS-formatierte Disketten und
HD-Partitions. Die unter RTOS formatierten Disketten ließen sich interessanter-
weise aber von einem AT-Rechner nicht lesen ....

ad Multitasking:

RTOS ist ein ausgesucht sicheres Multitasking-BS. Eine Abstürzende Task hat
i.A. nicht mehr zur Folge als eine Fehlermeldung und eine Suspendierung der
Task. Selbst für Prozeßinterrupts gibt es einen Fail-Safe-Mechanismus. Eine
amoklaufende Task, die das RAM plättet oder auch nur gezielt eine Verkettung in
einer der vielenn Listen RTOS' zerstört, kann natürlich auch RTOS zum
endgültigen Untergang verhelfen.

RTOS unterstützt ein echtes, Ereignis- und Zeitgesteuertes Multitasking.
CPU-Zeit wird an lauffähige Tasks per Priorität vergeben. (Keine Zeitscheiben,
kein 'kooperatives' Multitasking wie am MAC). Wahrscheinlich das beste Konzept,
sicher jedoch nicht das einfachste.

Da RTOS keine Fensteroberfläche hat, kommen alle Ausgaben aller laufenden Tasks
normalerweise bunt gemischt auf den Bildschirm. Hier muß man dann selbst den
Überblick behalten, was gerade läuft und wohl welche Meldung erzeugt haben
könnte .... naja, aber normalerweise läuft ja nur ein Programm, das auf den
Bildschirm zugreift.

ad Multiuser:

RTOS für den Atari ST unterstützt drei Benutzerkonsolen: Bildschirm, RS232 und
Midi. Naja, RS232 gebrauche ich schon mal öfters. Es ist recht interessant,
wenn man etwas schreibt, was Ausgaben auf den Bildschirm macht, das ganze von
der seriellen her zu managen, weil dann die eigenen Ein/Ausgaben auf dem
Bildschirm nichts wegschieben.

ad Realtime:

Wie schon erwähnt, ist es ein Ereignis- und Zeitgesteuertes Multitasking. Man
kann Tasks auf Zeitpunkte oder Prozeßinterrupts einplanen, wobei man eigene
Interrupts auch selbst programmieren/auslösen kann. z.B. startet für die
Mailbox die Task PORT1, wenn ein standardmäßig von RTOS unterstützter
Interrupt ausgelöst wird, wenn nämlich das Telefon klingelt (RI-Leitung vom
RS232-Port).

ad PEARL:

PEARL ist eine Hochsicherheitstraktsprache nach DIN ... das deutsche Pendant zu
ADA. Es ist sehr Pascal-ähnlich, hat aber ein crudes I/O-Verhalten, was
teilweise auch von dem Betriebssystem RTOS herrührt. PEARL enthält vom
Sprachstandard her Elemente zur Echtzeitsteuerung verschiedener Tasks. Die
Implementierung umfaßt mittlerweile auch Zeigervariablen, ansonsten wird so
ziemlich alles unterstützt. Etwas nervig ist die Unterscheidung der Variablen
bis in's kleinste Detail (so gibt es z.B. einen CLOCK und ein DURATION
Datentyp, die dar nicht so einfach umzurechnen sind). Konvertierungen zwischen
Datentypen müssen zumeist explizit ausgeschrieben werden.

z.B.

PROC TEST (zpt CLOCK, tim DURATION);
  DCL L LONG, F FIXED;

  L = 300;     /* Unfein. 300 ist FIXED. Wird als L = 300 FIT L compiliert. */
  L = 300(31); /* schon besser */

  F = L-30;    /* geht nicht. L-30 gibt ein LONG, und das paßt in F nicht rein

  zpt = NOW;   /* Einbaufunktion. Funktioniert nicht 100% .. naja */
  tim = zpt-0:0:0;
               /* Soviel Zeit ist's her sein 0 Uhr ... */
  L = ROUND(tim/1 sec);
  F            /* Das sind etwa soviele Sekunden.
                  man beachte: DURATION/DURATION = FLOAT !
                  ROUND macht daraus ein FIXED ... 2^15-1 langt nicht für
                        alle Sekunden eines Tages ... ach, was soll's ...  */
END;

Ganz nett ist, daß man eine Zeilennummer- und eine Indextest-Option wahlweise
beim Compilieren zuschalten kann. Dann erhält man z.B. bei einem Indexfehler
auch gleich die Zeilennummer, wo das passiert ist. Die Aussagekraft leidet nur
etwas, wenn man mehrere Module linkt, weil jedes Modul beim Compilieren ab
Zeile 1 nummeriert wurde ....

Nervig ist eine Besonderheit des RTOS-PEARL-Compilers, der bei
Funktionsaufrufen übergebene Paarmeter erst zur Runtime überprüft. Ich kenne
sonst keinen Compiler, wo das compilierte Programm plötzlich und unerwartet
noch einen Parameter-Fehler melden kann ...

ad ASSEMBLER:

Der Assembler ist etwas unkomfortabel. Wie der Compiler ist auch der Assembler
in seiner Arbeitsweise etwas langsam. Man kann in Assembler zum Glück mit etwas
Übung auch PEARL-Unterprogramme schreiben.

ad RTOS:

Das System ist soweit dokumentiert, daß man es mit etwas mehr Übung sogar
selbst erweitern kann. Die Implementierung von eigenen Datenschnittstellen ist
mit einem Beispiel-Handler für eine Standard-Interruptgetriebene Schnittstelle
(z.B. weitere RS232 ...) erklärt, Shellkommandos können auch in PEARL selbst
geschrieben werden, Standardfunktionen können zum Bestandteil des RTOS-Boot-
Systems gemacht werden. Soweit ganz flexibel.

ad Massenspeicher:

RTOS unterstützt mittlerweile DOS-Disketten. Die normalen vier Partitions der
ersten HD. (Weitere HD am ST noch nicht getestet, aber unwahrscheinlich.) Der
standardmäßig mitgelieferte Editor ist eine Zumutung und die darauf
zugeschnittene RAM-Disk eine Unmöglichkeit. Zum Glück gibt es Public Domain
Disketten ...

Und zu guter Letzt:

Ich bin glücklicher Besitzer zweier RTOS-Lizenzen, eine davon jedoch für die
nicht mehr ganz aktuelle Version 2.0. Die müßte sich eigentlich updaten lassen
auf 2.2, aber auch so ist sie vielleicht zum Reinschnuppern schon mal ganz
interessant. Abgabe gegen VB ...

                bye bye .... KIO !