************************* 
* KIO's Erfahrungen mit * 
* RTOS-Pearl/UH  2.3.87 * 
************************* 

Hey Fans, also, damit sich andere mal an meinem Beispiel ein Vorbild 
nehmen, und vielleicht auch, damit anderen der Mund so waessrig wird, 
dass es im Erlanger Raum bald mehr als nur einen RTOS-Anwender gibt, 
lass' ich hier mal meine gesammelten Erfahrungen mit RTOS vom Stapel: 

Nachdem so mein erster Maeuse-Rausch verflogen und mir langsam klar 
geworden war, dass es sich beim TOS des Atari ST keinesfalls um ein 
multi-tasking-faehiges Betriebssystem handelt (obwohl Atari und einige 
andere Freaks das im Bezug auf GEM immer wieder behaupten), war die 
Frage, was nun, Du mein lieber KIO ?? Da bot ja selbst der Schneider CPC 
mit seinem Event-Mechanismus schon besseres, na ja. 

Als fleissiger Leser der c't schien das Raetsel denn auch bald geloest, als 
dort das 'neue' Multitasking-Multiuser-Realtime-Betriebssystem RTOS fuer 
den Atari angeboten wurde. Ich erstand es dann auch fuer knappe 200 DM. 

Zur Zeit wird jedoch eine neue Version angeboten. Das Update habe ich 
bereits seit mehr als 2 Wochen bestellt (weitere 60 DM), es laesst aber 
noch auf sich warten. Aber soviel muesste man als potentieller Interessent 
jetzt hinblaettern: 

reine Disk-Version: 248,-- DM 
die Haelfte im ROM: 268,-- DM 
komplett in 4 ROMs: 288,-- DM jeweils plus 3 DM Versand. 

Das ist erstaunlich billig, bekommt man hier doch nicht nur den Compiler 
fuer eine Programmiersprache, sondern ein komplettes Betriebssystem. 

Aber hier liegt dann auch schon der erste Hase im Pfeffer: 

Unter TOS geschriebene Programme sind keinesfalls unter RTOS ablauffaehig 
und umgekehrt natuerlich auch nicht. 
Aber noch schlimmer: RTOS benutzt ein anderes Diskettenformat, so dass 
der Datenaustausch zwischen den beiden Systemen auf ein und dem selben 
Computer fast unmoeglich erscheint! 
Das waren die ersten beiden Kroeten, die ich schlucken musste. 

Aber es geht noch weiter: Da RTOS nicht speziell fuer den Atari ST 
entwickelt wurde, sondern eigentlich mehr fuer Grossrechenanlagen und 
Fertigungsstrassen in der Industrie (aha, realtime!) werden auch keine 
der besonderen Faehigkeiten des Atari ST unterstuetzt, die Maus kann man 
zunaechst einmal wieder einmotten. 
Auch was sonst auf unter GEM so an Benutzerfreundlichem geboten wurde, 
muss man sich hier erst in muehsamen Nachschichten erkaempfen: Der gesamte 
Dialog mit dem Betriebssystem geht natuerlich wieder komplett per Text, 
Diskettenkataloge sind ab sofort ueberhaupt nicht mehr informativ, weil 
jeder Dateiname maximal 8 Zeichen lang sein darf. Positiv faellt nur auf, 
dass mit jedem Katalog ausgegeben wird, wieviel Platz noch auf der 
Diskette frei ist. Loeschen von Files etc. geht nur mit expliziter Namens- 
nennung, Joker und Wildcards sind nicht moeglich. Umbenennen ist nur 
mittels umkopieren moeglich (oder habe ich da bis heute was nicht entdeckt?) 
und Back-Ups sind fuer RTOS ueberhaupt was total ueberfluessiges. Fuer mich 
allerdings nicht, wie ich leidvoll schon mehrere Male feststellen musste. 

Ausserdem ist RTOS manchmal unheimlich arbeitsfaul, wenn es auf die 
Diskette zugreifen soll, um beispielsweise das Directory zu lesen oder auch 
zurueckzuschreiben: So lange auf einer Diskette noch eine Datei in Arbeit 
ist, wird nur das hin und hergeschippelt, was im Disc-I/O-Buffer keinen 
Platz mehr findet. Da kann es schon leicht mal passieren, dass man nachts 
um 1 Uhr sein 'Tages'werk auf Diskette rettet, und es am naechsten Tag 
dort nicht mehr vorfindet: Irgendeine verunglueckte Task hinterliess 
irgendwann mal eine offene Datei auf der Diskette, und RTOS nahm den 
exakten Medium-Abgleich nicht vor .... 
Zwar gibt es dafuer ein paar Funktionen, u.a. sollte (muss!!) man vor dem 
Wechsel einer Diskette mal nachfragen, ob eben noch eine Datei offen ist, 
aber immer denkt man halt nicht dran. Und wer erst frisch vom GEM-Desktop 
auf RTOS umgestiegen ist, dem ist das sehr wahrscheinlich ueberhaupt nicht 
bewusst, dass er hierdurch staendig Datenverluste produziert. Bei mir 
dauerte es auf jeden Fall ein Weilchen. 



Na ja, aber nur meckern wollte ich eigentlich auch nicht, also berichte ich 
mal von den auch faszinierenden Seiten des RTOS: 

Also, da ist es nun gebootet (woher auch immer) und man sitzt davor, die 
Maus ist vorsichtshalber komplett abgenabelt und man will dem lieben RTOS 
einen klitzekleinen Befehl zum abarbeiten geben: Also nichts wie hinein- 
gehackt in die Tastatur und .... na was ist denn das? RTOS mag mich nicht, 
es ignoriert einfach mein Begehren und ruehrt sich mit keinem Bit im 
Bildschirm, wenn ich ein Taestlein druecke ... 

Tscha, das ist natuerlich schon unheimlich professionell, wenn man jetzt 
weiss, dass RTOS eigentlich nichts lieber tut als eine total sinnlose, 
unnuetze Task abzuarbeiten, die sinnigerweise den Namen IDLE traegt ... 

Um RTOS dazu zu bewegen, eine Task zu starten, die dann von mir die 
Eingabe entgegen nimmt, muss man ihm mit ctrl-A oder UNDO das erst 
einmal klarmachen. 

Also, UNDO, und schon erscheint mit geringer Verzoegerung ein '*', der 
Eingabeprompt des Kommando-Interpreters. Aber nicht dass man jetzt denkt, 
dass sich RTOS jetzt zeitweise von seiner lieben IDLE-Task getrennt haette, 
um die Eingabe-Task am Laufen zu halten. Nein ueberhaupt nicht. Man muesste 
schon verdammt exakte Messungen anstellen, um festzustellen, dass durch 
die jetzt gleichzeitig laufende Eingabetask, IDLE auch nur ein kleines 
bischen gebremst wuerde. Wir als menschliche Anwender sind ja sooooo was 
von laaaangsam ... Da koennen in der Zwischenzeit Telefonbuecher im Inneren 
des Atari bewegt werden ... 

Was koennte man jetzt alles machen? Ich schlage mal vor: 

An der RS232 haengt gerade ein User, der sich ueber Telefon in meine 
Mailbox eingeloggt hat. Ich habe derweil auf Laufwerk F0. = A: das 
Formatieren einer Diskette angeleiert, editiere im Moment aber mein 
hinterletztes Assemblerlisting, waehrend ich die Dialogdatei der Mailbox 
zu Dokumentationszwecken auf dem Drucker ausdrucken lasse. Da Hierdurch 
die Rechenzeit der CPU natuerlich noch in keiner Weise ausgelastet ist, 
kommt eigentlich die meiste Zeit IDLE zum Zug, wenn ich nicht vielleicht 
noch gleichzeitig Apfelmaennchen berechnen lasse ... 

Na ? 

Aktuell haette ich mit dieser vorgeschlagenen Arbeitskonfiguration aber 
noch etwas Probleme. Zum ersten wuerde ich mich zur Zeit noch nicht trauen, 
jemanden ueber Telefon in meine Mailbox reinzulassen, weil der jederzeit 
selbst den Komando-Interpreter aufrufen koennte (mit ctrl-A zum Beispiel) 
Und wenn das erst mal raus ist (oder, noch viel wahrscheinlicher, sobald 
raus ist, dass das auch mit ctrl-C geht, was man ja oft fuer Skip-Text 
benutzt) wuerden mir sicher irgendwelche Idioten hinterruecks die Disketten 
formatieren. 

Ausserdem gibt es noch klitzekleine Probleme mit dem XON-XOFF-Protokoll, 
die ich aber nicht weiter ausbreiten will (koennte laenger dauern). 
Eine automatische Anruf-Erkennung ist aber sehr einfach moeglich, weil 
RTOS das Signal vom Pin 22 der RS232 (Ring Indicator) in einen 
systemkonformen Interrupt umwandelt. Andererseits bereitet das 
automatische Abheben Probleme, weil am entsprechenden Port des PSG 
nicht nur die RTS-Leitung sondern auch Strobe, Side select, 
Drive 0/1-select etc erzeugt werden, und deshalb beim Ansprechen des 
Druckers oder der Floppies immer wieder aufgelegt wird ... Aber das soll 
mit dem Update alles besser werden! 
Ausserdem hat man fuer die ACIAs (und die RS232 faellt darunter, auch wenn 
sie de facto nicht ueber einen ACIA laeuft) jeweils nur eine Treibertask 
vorgesehen, sowohl fuer Eingabe, als auch fuer Ausgabe. Das hat z.Z. zur 
unangenehmen Folge, dass keine Ausgabe mehr moeglich ist, sobald eine Eingabe 
haengt und umgekehrt. Na ja, auch hier wie so oft: Ich hoffe auf das Update! 

Sehr angenehm ist, dass bei einem Diskettenzugriff die CPU nicht wie unter 
TOS Daeumchen dreht. Waehrend der Lesekopf hin und herroedelt und wahrend 
per DMA die Bytes hin und herflutschen macht die CPU halt was anderes (und 
wenn sie sich wieder mal mit ihrer geliebten IDLE verlustiert). 

Ausserdem hat RTOS standard-maessig eine RAM-Disk eingebaut: Die belegt, 
wenn sie leer ist, 0 Bytes und unterscheidet sich dadurch auf's angenehmste 
von anderen Vertretern ihrer Art. 
Leider habe ich mit ihr z.Z. auch einige Probleme. So kann man unter RTOS 
den Schreib/Lese-Zeiger in einer Datei voellig frei positionieren, was 
z.B. in einer Dateiverwaltung ja unabdingbar ist. Nur in der RAM-Disk 
funktioniert das nicht. Der Grund ist, dass die Dateien hier komprimiert 
werden (lt. Handbuch: einfache Redundanzen). Bei einem Megabyte RAM 
wuerde ich aber lieber auf ein paar herausgequetschte Bytes verzichten, 
und auch und gerade in der RAM-Disk frei innerhalb einer Datei lesen und 
schreiben koennen. Ich hoffe aber, dass auch das mit dem Update bereinigt 
ist. 

Wie laeuft nun das Arbeiten unter RTOS so ab? 

Zum Einen quatscht man hier staendig mit dem Kommando-Interpreter. So muss 
man ueber diesen zunaechst mal anleiern, dass man ueberhaupt eine arbeits- 
faehige Umgebung erhaelt: Ich habe zur Zeit nur das eigentliche RTOS in ROMs, 
den Pearl-Compiler und den Assembler muss ich erst von Diskette nachladen. 
Das geschieht recht einfach, indem ich nach jedem Kaltstart so beginne: 

[ctrl-A] LOAD F0.I--I [enter] 

Erkennt man doch gleich, was RTOS da macht. 
Du nicht?, na ja dann: 
ctrl-A ruft das Bedieninterface auf den Plan. Dadurch kann ich (s.o.) RTOS 
einen Befehl erteilen. In diesem fall gleich zwei: 

'LOAD F0.I' laedt die linkfertige Datei 'I' vom Laufwerk 'F0.' (das ist A:) 
in den Speicher. Wenn das abgeschlossen ist, erkennbar am Separator '--', 
wird der Befehl 'I' aufgerufen. Dieser Befehl ist kein RTOS-Befehl, sondern 
der Name einer Task, die durch Laden der Datei 'F0.I' entstanden ist. 
Ich haette frei jeden beliebigen Namen mit bis zu 6 Buchstaben (demnaechst 
24) benutzen koennen, aber solche immer wieder kehrenden Taetigkeiten 
versucht man ja auf den kuezestmoeglichen Nenner zu bringen. 

Diese Task nun ihrerseits mach all das, was ich so gerne haette: Sie laedt 
den Pearl-Compiler, den Assembler, eine Hilfstext-Datei, belegt die 
Funktionstasten und, in der augenmblicklichen Version, laedt den Quelltext, 
an dem ich gerade arbeite und ein Assembler-Moduelchen, das auch gleich 
noch assembliert wird (aeh ja, da wurde natuerlich der Assembler-Quelltext 
geladen). 

Sprachlich ungenau ist das 'Laden' von Textdateien. Die werden nicht geladen, 
weil man ueberhaupt nur die linkfertigen Dateien 'Laden' kann, sondern in 
die Ram-Disk (Geraet ED.) 'Copy'iert. 

Jetzt kann ich mich in den Editor einloggen, und Quelltexte, die sich im 
Geraet ED. (die Ramdisk) befinden muessen, editieren. 

Bin ich soweit fertig, nix wie raus aus dem Editor, und den Quelltext 
assembliert oder compiliert (je nach dem). Ich erhalte so die linkfaehigen 
Dateien. 

Die lann ich nun mit 'LOAD' laden. Bei Bedarf kann ich auch mehrere Dateien 
dabei zusammenbinden. 

Danach stehen mir (hoffentlich) die Tasks, die in den Quelltexten gebastelt 
wurden, zum Aufruf mit ihrem Namen bereit, so wie oben die Task 'I'. 

In einem Link-Durchgang koennen mehrere Tasks erzeugt werden, fuer eine 
Mailbox z.B. die Betreuungstask plus eine Task, die das Carrier-Signal 
ueberwacht plus eine Task, die den Anrufer nach Ablauf des Time Out 
abwuergt plus ... na ja, was man so braucht. 

Funktioniert der Kram nicht so, wie man will, muss man die alten Tasks 
wieder entladen mit 'UNLOAD'. Dabei kann man meist alle Tasks eines Moduls 
auf einmal rausschmeissen, indem man 'UNLOAD modnam*' eingibt. 'modnam' ist 
dabei der Name des Moduls. Vergisst man den Stern, hat man danach etwas mehr 
Arbeit. Jetzt (oder auch vorher schon) kann man den Quelltext aendern, neu 
uebersetzen, neu laden und neu staerten. Also das uebliche ECLG: edit - 
compile - link and go. 

Interessant sind dabei die 'Turn around'-Zeiten. Wie lange brauche ich 
fuer einen ECLG-Zyklus? Da alles im RAM stattfindet (meistens zumindest) 
geht es relativ flott. Nur der Assembler ist ein ausgesprochener Lahmarsch 
udn uebermaessig schnell ist der Compiler auch nicht: Die Angabe '500 Zeilen 
pro Minute' kommt hin, gilt allerdings inclusive reichlicher Remarks. 

Der Linker ist ueberaus flott, und braucht nur bei wirklich langen Modulen 
nennenswerte (bzw. erkennbare) Zeiten. 

Bei kurzen Problemen liegen die Turnaround-Zeiten oft unter einer Minute. 
Da koennen TOS-C-Programmierer nur von traeumen. 



Wie funktioniert das Multitasking? 

RTOS vergibt keine 'Zeitscheiben'. (In der neuen Version kann man das aber 
erzwingen. Ich frag' mich aber wofuer, denn das ging auch in der alten 
Version mit einem klitzekleinen Trick schon.) Alle Tasks haben eine 
Prioritaet und immer die hoechstpriorisierte, lauffaehige Task laeuft. Da 
bei vielen Arbeiten zwangsweise Wartezeiten anfallen (Diskettenzugriff, 
Drucker, RS232) ist die hoechstpriorisierte Task eben sehr oft nicht 
lauffaehig und in den Luecken kommt der Rest meist ausreichend oft zum zug. 

Man muss halt verhindern, dass Dauerbrenner zu hoch priorisiert werden. 
Ich habe z.B. keine Probleme, die Mailbox stellenweise mit der allerhoechsten 
Prioritaet laufen zu lassen, weil die RS232 ja nur mit 300 Baud die Zeichen 
ruebertuckert. Dadurch verbleibt mit (z.B. im Editor) fast immer komfortabel 
viel Rechenzeit. Allenfalls das Blaettern im Text ist etwas ruckhaft, und 
manchmal springt der Cursor etwas geck. Was soll's. 

Zum Schluss noch was zu Pearl: Diese Sprache kennt wohl nur, wer an 
entsprechenden Rechnern in der Industrie oder an Universitaeten arbeitet, 
oder es sich fuer irgendeinen Rechner ueber die c't zugelegt hat. Diese 
bezieht ihre Versionen anscheins ausschliesslich aus irgendwelchen 
Denkschmieden der Universitaet Hannover (da sitzt der Verlag ja auch). 

Pearl merkt man es an, dass es ein deutsches Produkt ist. Nicht, dass man 
hier deutsche Schluesselworte benutzen wuerde ... (remember LOGO!!) 
Aber hier ist alles 'gruendlich'. Soviel wie in dieser Sprache muss man 
wohl in keiner anderen Deklarieren. Ein 'Programm', dass ganz einfach 
'Hello world' ausdruckt (bei C-Programmierern ja als ausserordentlich 
sinnvoll eingestuft) sieht mindestens so aus: 

MODULE HELLO; 

SYSTEM;  A1; 
PROBLEM; 
SPC A1 DATION INOUT ALPHIC CONTROL(ALL); 

HELLO:TASK; 
PUT 'Hello world' TO A1 BY A,SKIP; 
END; 

MODEND; 

Zunaechst muss man den gabzen Krampf in ein Modul packen, das mit MODULE name 
beginnt und mit MODEND aufhoert. 

Dann muss man im SYSTEM-abhaengigen Teil die Datenstation A1 deklarieren. 
Die benutzte Form 'A1' ohne alle weiteren Zusaetze ist schon eine recht 
verkuerzte Form von: 

A1: A1. <-> 

oder gar: 

A1: A1. (TFU 1 ) <-> 

Dabei wird eine Zuordnung der Systembezeichnung A1. fuer das normale 
Terminal zum Programm-internen Namen (hier der Einfachheit halber auch A1) 
vorgenommen, die Station als ein- und ausgabefaehig deklariert (der Pfeil <->) 
und evtl. noch zusaetzlich festgelegt, dass jedes einzelne Zeichen sofort 
an das Pearl-Programm uebergeben werden soll (TFU=1). Letzteres ist vor 
allem bei Dialogen zwischen Anwender und Programm sehr oft notwendig. 

Dann muss man den ganzen Krampf im System-unabhaengigen Teil (ab PROBLEM) 
in geschraubter Schreibweise wiederholen: SPC A1 DATION etc. pp. 

Hat man mehrere Datenstationen, z.B. auch Diskettendateien, hat man alleine 
hiermit schon die ersten 50 Zeilen weg. Interrupt-Quellen ergeht es genauso. 

Dann muss man noch alle Vorwaerts-referenzen befriedigen (Der Compiler macht 
nur einen Durchgang), Variablentypen (auch Structs) deklarieren, alle 
globalen Variablen deklarieren, externe Prozeduren und Tasks spezifizieren 
usw usf. 

Danach darf man endlich loslegen. Faustformel: Bis hierhin hat man schon 
ein Zehntel der notwendigen Tiparbeit geleistet ... 

Bei den Datentypen hat man sich regelrecht ueberschlagen: 
So hat man sich fuer Zeiten nicht nur damit begnuegt, hierfuer einen eigenen 
Variablentyp zu deklarieren, sondern gleich deren zwei: 

1. Typ CLOCK    --> Uhrzeiten 
2. Typ DURATION --> Zeitdiferenzen. 

Zwischen den einzelnen Datentypen muss sehr oft explizit konvertiert werden: 

Verlangt eine Funktion einen Eingabetyp FLOAT, z.B. auch die bereits fest 
implementierten trigonometrischen Funktionen!!, und man schreibt: 

A = SIN(3) 

so geht das schief: 3 ist Integer. Dabei zeigt der Compiler hierbei eine 
denkwuerdige Eigenart, Parameter-Anzahl und Typ nicht beim compilieren zu 
ueberpruefen, sondern erst in Run-Time! Dadurch werden hier in Zukunft 
auch lang fehlerfrei gewaehnte, compilierte Programme sich wie sonst nur 
bei Interpretern ueblich mit einem Syntax-Error verabschieden ... 
(heist hier dann nur anders). 

Pearl bietet die Moeglichkeit, recht komfortable Fehlersuche zu betreiben. 
Uebersetzt man sein Programm mit der Option +M, so werden die gerade 
bearbeiteten Pearl-Zeilennummern festgehalten. Diese wird dann im Fehlerfall 
ausgegeben oder laesst sich (z.B. zum Lokalisieren einer dead loop) auch 
explizit vom Kommando-Interpreter aus anzeigen. 

+I erzeugt einen modifizierten Code, bei dem die Einhaltung von Feldgrenzen 
ueberprueft wird. Dadurch kann man sich hier nicht mehr selbst den Code 
zerschiessen. 

************************ 

Ende Teil 1.  Der liebe KIO hat jetzt keine Lust mehr, dafuer aber Blasen 
an den Fingern. Wer Lust hat, selbst mal mit RTOS rumzuspielen, der kann 
mich mal anrufen: (09131) 20 7996. 

Er kann dann auch mal per Modem selbst mit RTOS arbeiten !! 
(Nur der Editor bleibt ihm wohl verwehrt, dafuer sind 300 Baud eher weniger 
geeignet) 

so long ... KIO