Modul-"Chaos" unter CAOS
von Ralf Kästner
Mit dem "Modularmonster" (scherzhafte Bezeichnung von Nicht-KC-Nutzern für den KC 85 - ich will ja keine Namen nennen) lassen sich durch das integrierte Modulkonzept immer wieder neue Anwendungsbereiche erschließen - andere Heimcomputer können von diesen Möglichkeiten nur träumen. Das Betriebssystem stellt dafür auch passende Unterprogramme zur Verfügung, welche für kleinere Projekte auch vollkommen ausreichen.
Die Probleme beginnen erst dann, wenn man mehrere Module des gleichen Typs gleichzeitig betreiben will oder wenn speziell in RAM-Modulen zur Laufzeit von Vordergrundprogrammen bereits andere Programme laufen, die nicht gestört oder gar überschrieben werden dürfen. Hier wären z.B. anwenderspezifische Systemerweiterungen zu nennen, welche mittels pfiffiger Interruptroutinen fast autonom ihren Dienst verrichten oder auch Module, wo man zeitweise Daten oder Programme ablegt, um später wieder darauf zurückzugreifen.
Problembeispiel
Frank Dachselt zeigte zum Treffen 1995 eine Systemuhr, welche mit Hilfe eines M001 arbeitet. Die zugehörigen Programme laufen dort in einem M011 und beanspruchen im Prinzip fast keinen Speicher im direkten Adressbereich der CPU. Tritt ein Interrupt auf, wird eine wenige Bytes umfassende Interruptserviceroutine aufgerufen, welche das M011 einblendet und das dort enthaltene Uhrprogramm aufruft. Nachdem dieses abgearbeitet ist, wird das M011 wieder ausgeblendet und fertig.
Es wäre nun äußerst ungünstig, wenn ein anderes Programm den Inhalt dieses M011 einfach überschreibt, in der Regel dürfte ein Systemabsturz die Folge sein. Gleiches trifft auf das genutzte M001 zu, was bei Uminitialisierung z.B. zur CENTRONICS-Druckausgabe auch nicht mehr, wie beabsichtigt, die Uhr bedient.
Ich wurde mit diesem Problem bei der Weiterentwicklung von "UNIPIC" konfrontiert und habe mir dort erst mal eine einfache Lösung ausgedacht. Zum Treffen habe ich mit Mario Leubner und Frank Dachselt darüber diskutiert und wir sind zu der Meinung gelangt, es zum Standard zu deklarieren. Die nachfolgend beschriebene Variante läßt sich bei allen Modulen anwenden, egal ob es sich um RAM- oder I/O-Module handelt.
Zunächst stellt dies eine einfache Lösung dar, um beim Start von eigenen Programmen abzutesten, ob das Modul bereits anderweitig benutzt wird, nicht mehr und nicht weniger. Ein richtiges RAM-Managment erreicht man dadurch nicht, dort müßten die Programme u.a. den belegten Speicher nach Beendigung auch wieder freigeben, außerdem müßte der Zugriff auf ein bestimmtes RAM-Segment bzw. eine bestimmte I/O-Adresse am besten über ein universelles Unterprogramm erfolgen, was sich beispielsweise um das eventuelle Ausschalten von höherpriorisierten Modulen in niedrigeren Modulschächten beim Zugriff (im DI!) kümmert. Hier ist noch einiges an Entwicklungsarbeit notwendig.
Lösungsvorschlag
Zum Funktionsprinzip, grundsätzlich wird der Normzustand von CAOS vorausgesetzt, welcher bestimmte Zustände des Modulsteuerbytes kk festlegt. Dieser sieht so aus, daß die internen RAM-Bereiche, RAM 0, RAM 4, RAM 8, eingeschaltet sind (Bit 0=1) und der Schreibschutz ausgeschaltet ist (Bit 1=1). Alle externen Module, bis auf das erste gefundene M003 (Bit 0=1), sind aus (Bit 0=0) und der Schreibschutz ist ein (Bit 1=0), CAOS schaltet also alle Module in den externen Schächten immer mit 00! aus.
Ist ein externes Modul offline (Bit 0=0) spielt der Zustand von Bit 1 durch die niedrigere Priorität innerhalb von kk an sich keine Rolle, kann aber dann gezielt über das Lesen des entsprechenden Steuerbytes ausgewertet werden. An dieser Stelle wird angesetzt, bevor man ein beliebiges Modul für das eigene Programm nutzt, wird Bit 1 von kk (z.B. Lesen über UP 26H) getestet. Ist es 0, kann das Modul genutzt werden, ist es 1, wird das Modul bereits von vorher geladenen Programmen verwendet und darf nicht in Beschlag genommen werden. Beim RAM 8 testet man dagegen Bit 0, ist es 0 ist der RAM reserviert, ist es 1, kann man ihn verwenden.
In "DIASHOW 1.1" ist diese Variante bereits realisiert und soll auch in "UNIPIC 2.0" so integriert werden. Für den reinen Anwender ändert sich gar nichts, nach Einschalten des KC und Kaltstart von CAOS erkennt und nutzt das Programm den gesamten zur Verfügung stehenden internen und externen RAM. Alle "POWER-User" können sich eigene RAM-Module reservieren, indem in vorher gestarteten Programmen diese Module mit 02! (Bit 1=1) ausgeschaltet werden. Die internen RAM-Bereiche sollten zweckmäßigerweise den Anwenderprogrammen zur Verfügung stehen, so daß keine Reservierung sinnvoll erscheint und damit auch nicht getestet werden müßte. Zumindest für den RAM 8 besteht vor dem Laden von "DIASHOW 1.1" durch vorheriges Ausschalten dennoch diese Möglichkeit.
Besonderheiten
Um das o. g. Problem der höheren Priorität niedrigerer Modulschächte auszuschließen, wird eine Modulnutzung nach dem Prinzip der RAM-Floppy von MikroDOS vorausgesetzt! D. h. alle Module, welche von Fremdprogrammen genutzt werden, sind im ausgeschalteten Zustand zu betreiben, nur im DI dürfen z. B. während der Abarbeitung von Interruptserviceroutinen Bereiche beliebig online geschaltet werden, sind aber nach Benutzung auch wieder offline zu schalten! Das laufende Vordergrundprogramm geht hier also vor. Die Int-Routine muß selbst prüfen, ob vielleicht ein anderes Modul einen Zugriff auf das reservierte Modul blockiert.
Im Beispiel "DIASHOW 1.1" schaltet das Programm beim Start den RAM8 und alle RAM-Module offline, unabhängig davon, ob sie reserviert sind oder selbst verwendet werden. Der Zustand des Bit 1 (und Bit 2 bis 7!) von kk wird bei den reservierten Modulen nicht verändert, das Programm reserviert sich aber die gefundenen freien RAM-Module selbst, indem Bit 1 von kk dann gesetzt wird.
Die Konsequenz - hat man jetzt beispielsweise eine Störung und das im RAM befindliche Programm arbeitet nicht mehr, kann man das Programm nicht einfach von Diskette nachladen, da es keinen freien RAM finden kann! Entweder man schaltet den KC aus und wieder ein (dann ist der CAOS-Normalzustand wiederhergestellt) oder, was besser ist, man schaltet mit dem SWITCH-Kommando die benutzten Module mit 00 aus, dann kann man "DIASHOW 1.1" nachladen und die RAM-Module werden wieder korrekt als frei erkannt. Zur Kontrolle des Schaltzustandes der Module oder Speicherbereiche lassen sich an dieser Stelle die CAOS-Kommandos %MODUL bzw. %SYSTEM vorteilhaft nutzen.