ZAS beendet Speicherkriege im Grundgerät
von Ralf Kästner
Bitte entschuldigt, aber eine bessere Überschrift ist mir leider nicht eingefallen. In letzter Zeit ist durch Mario Leubner Bewegung in eine Sache gekommen, welche seit geraumer Zeit einer Lösung bedarf - die Verwaltung des freien Speichers im Grundgerät, während das KC-Floppy-System in der CP/M- bzw. PC-Betriebsart betrieben wird.
Nachdem Mario am 07. 06. dieses Jahres eine in dieser Richtung erweiterte Testversion von ZAS an die Programmierer verschickt hatte, gab es heiße ON- und OFFLINE-Diskussionen hinter den Kulissen, wo sich um die genaue Spezifikation der ZAS-Funktionen und den Aufbau der Programmteile, welche im Grundgerät laufen sollen, förmlich gestritten wurde. Da auch ich zu dieser illustren Runde gehörte und die anderen momentan andere wichtige Dinge, wie Erstellung der nächsten KC-News, Hochwasserbekämpfung usw. zu bewältigen haben, wurde ich dazu verdonnert, etwas zum momentanen Stand zu schreiben, damit dieser zukünftige Standard bekannt wird und man sich ggf. darauf vorbereiten kann, wenn derartige Projekte in Arbeit sind bzw. geplant sind.
Die ZAS-Funktionen der Version 1.1 wurden von Mario in den News 4/96 S. 2 ff. ausführlich vorgestellt. In der gleichen Ausgabe kann man ab S. 10 den Artikel von Jörg Linder lesen, wo ausführlich Sinn und Zweck aber vor allem die Notwendigkeit einer derartigen Speicherverwaltung angedacht wurde. Genau wie dort vorgeschlagen, hat Mario damit begonnen, ZAS um entsprechende Funktionen zu erweitern. Der momentane Stand ist bereits vielversprechend aber noch nicht soweit, daß ich hier genaue Aussagen machen kann bzw. will, das macht Mario sicher selbst in einer der nächsten Ausgaben.
ZAS verwaltet in der neuen Version den freien Speicher des Grundgerätes im RAM0 von 1C00H-3AFFH und im RAM4 von 4000H-7FFFH, wobei den nutzenden Programmen immer ganze Pages (Speicherbereiche) zu je 256 Byte zugeteilt werden. Der Programmbeginn entspricht dabei einem Pagebeginn - Adresse xx00H, mehrere zusammenhängende Pages pro Programm sind natürlich auch möglich, man kann auch festlegen, ob ein Programm in den RAM0 oder RAM4 geladen werden soll/muß.
Wahrscheinlich werden auch temporäre Speicherbereiche für eine Zwischenablage von Daten u.ä. unterstützt, dort ist die Form noch nicht endgültig geklärt. Programme, welche ausführbaren Code enthalten, müssen frei verschieblich sein oder im PRL-Format vorliegen. Jedes Programm, welches im Grundgerät laufen soll, erhält einen Identifizierungscode (ID), welchen der Programmierer momentan bei Mario beantragt und den er dann für sein Programm verwenden muß. Der Beginn jedes Programmes (Header) hat einen einheitlichen Aufbau, welcher unbedingt eingehalten werden muß, da dort ZAS und das Ladeprogramm, welches das Grundgeräteprogramm vom D004 in das Grundgerät schreibt (s.u.), wichtige Informationen entnimmt - hier steht der Inhalt auch noch nicht ganz fest.
ZAS enthält eine neue ESC-Sequenz, mit der man Funktionen des Grundgeräteprogrammes direkt aufrufen kann, wobei eine Übergabe von Parametern über die CPU-Register möglich ist. Für umfangreichere Datentransporte muß/kann dann der Koppel-RAM benutzt werden, wobei man vor einem Aufruf die Daten dort hineinschreibt und nach einem Aufruf Daten von dort lesen kann, quittiert wird das von ZAS, wie bisher auch schon, in MEMANF.
ZAS übernimmt also in Zukunft die gesamte Speicherverwaltung im Grundgerät und kann anhand der ID Funktionsaufrufe an dort vorhandene aktivierte Programme weiterleiten. Das Konzept, welches hier verfolgt wird, sieht so aus, daß benötigte (möglichst universell nutzbare) Programme bereits beim Systemstart in das Grundgerät übertragen werden und sich nicht länger gegenseitig behindern bzw. sogar adressmäßig überschneiden.
Dies soll zukünftig ein Ladeprogramm erledigen, welches noch zu schreiben ist und sowohl verschiebliche Programme laden als auch Programme im PRL-Format lesen und reloziert auf eine freie Adresse im Grundgerät schreiben kann. ZAS enthält hierfür entsprechende ESC-Sequenzen, um den Speicher aufzuteilen.
Die Lage des Programmes im Grundgerät ist anschließend für das nutzende Programm im D004 uninteressant, da alle Funktionsaufrufe über den ID-Code automatisch an das richtige Programm im Grundgerät weitergeleitet werden. Damit werden die eigentlichen Programme von der gesamten administrativen Arbeit befreit, welche bisher notwendig war, um Programme im Grundgerät ablaufen zu lassen. Da ZAS den Speicher zuteilt, sind Adresskonflikte ausgeschlossen und der gesamte verfügbare freie RAM kann auch problemlos ausgenutzt werden Grundvoraussetzung ist natürlich, daß sich alle an den (wenigen) Vorgaben orientieren und die definierten Schnittstellen benutzen.
Wenn man es genau betrachtet, wird die Nutzung des Grundgerätes erheblich erleichtert. Man muß vorher lediglich eine Aufgabenverteilung vornehmen, was im Grundgerät gemacht werden soll und was im D004. Anschließend schreibt man das Programm für oben wie bisher und den Programmteil für das Grundgerät getrennt - ist er bereits verschieblich, war es das schon, ist er nicht verschieblich erzeugt man einfach mit dem Linker eine entsprechende PRL-Datei, welche dann genauso mit dem universellen Ladeprogramm geladen werden kann. Im D004 Programm fällt lediglich ein Test an, ob das zugehörige Programm im Grundgerät aufgerufen werden kann - es ist ja laut Konzept bereits zum Zeitpunkt des Systemstarts geladen worden.
Es soll natürlich auch nicht verschwiegen werden, daß es Probleme geben kann, wenn alte Programme benutzt werden, welche die neue Speicherverwaltung nicht kennen und mit den bereits vorhandenen ESC- Funktionen ins Grundgerät schreiben. Die sind nach wie vor alle verfügbar, da auch das neue ZAS abwärtskompatibel sein wird. Nun, da es nicht soviele sind, dürfte das nur in einer Übergangszeit stören. U.a. haben Frank Dachselt für DRUCK.COM bzw. HPKC.COM und Mario Leubner für ML.COM überarbeitete Versionen angekündigt, so daß diese Programme auch zukünftigt eingesetzt werden können, andere wichtige Programme, welche dies betrifft, fallen mir momentan auch nicht ein.
Der Gebrauch der alten Funktionen zum Schreiben in den Speicher des Grundgerätes ist dann auch nicht mehr so ohne Weiteres möglich, da sich in den o.g. Bereichen aktive Programme befinden können, welche dann zerstört werden - die Folge ist höchstwahrscheinlich ein Absturz im Grundgerät und damit auch der PC-Betriebsart! Hierzu wird Mario sicherlich etwas sagen, wenn er das neue ZAS vorstellt.
Soviel zum bisherigen Stand, abschließend noch einige Gedanken für eine sinnvolle Nutzung dieser ganzen Angelegenheit. Das KC-Floppy-System ist in der CP/M- bzw. PC-Betriebsart ein absoluter Exot unter den CP/M-kompatiblen Systemen, wie Jörg Linder schon einmal treffend schrieb, sind wir ja als KC-Nutzer Besonderes gewöhnt. Die Fähigkeiten unseres Grundgerätes stehen anderen CP/M-Programmierern nicht zur Verfügung, da dieses Betriebssystem von Hause aus z.B. weder vollgrafikfähig ist noch Musik erzeugen kann. Um dem Ganzen noch die Krone aufzusetzen, steht durch den RAM des Grundgerätes quasi eine kostenlose Vergrößerung des TPA zur Verfügung, indem man Programmteile einfach dorthin auslagert - dies wird durch die neue RAM-Verwaltung sogar noch gefördert, da es wesentlich einfacher und dann auch sicherer wird.
Genau dadurch entstehen allerdings auch Gefahren. Jedes CP/M-Programm, welches Programme im Grundgerät voraussetzt, ist zu anderen CP/M-Systemen inkompatibel und läuft dort nicht - die Lauffähigkeit von Programmen auf verschiedenen Plattformen war eigentlich mal ein Hauptgrund für den Erfolg dieses Betriebssystems. Alle Programme, welche auf die neue RAM-Verwaltung angewiesen sind, laufen nur noch auf dem KC 85/4..., da ZAS nicht auf dem 85/2,3 läuft. Wenn jeder Programmierer eigene Programme für das Grundgerät entwickelt, welche ähnliche Aufgaben erfüllen, wird es irgendwann wieder eng dort unten, da der Speicher begrenzt ist. Ziel muß also sein, daß man sich untereinander austauscht, um möglichst auf bereits vorhandene Programme für das Grundgerät zurückzugreifen. Man muß dann beim Systemstart weniger laden (warten) und erspart allen Anwendern Frust, dazu kommt, daß wir dann eine Speicherverwaltung gar nicht brauchen, da jedes D004-Programm seine Grundgeräteprogramme selbst laden und verwalten könnte.
Solange die Möglichkeiten von CP/M und beispielsweise NZCOM ausreichend sind, sollte man sich darauf beschränken, es erhöht die Bandbreite für die Nutzung auf anderen Systemen erheblich. Sinnvoll werden Programmteile im Grungerät erst, wenn es nicht anders machbar ist. Hierzu zählen u.a. direkte Zugriffe auf die Hardware von I/O-Modulen (Stichwort Modem an M003) und ähnliche Probleme. Weiterhin spezielle Programme, welche für grafisch orientierte Anwendungen notwendig sind, wenn diese mit den bisher vorhandenen ESC-Funktionen nicht auskommen, weil es sie nicht gibt oder diese u.U. zu langsam sind. In diesem Zusammenhang sind auch die o.g. temporären Speicherbereiche zu sehen, welche man für eine Zwischenspeicherung von vollgrafischen Daten (Dateien) benötigt, um sie anschließend über den IRM des Grundgerätes anzeigen lassen zu können. Ich will damit sagen, daß die Speicherverwaltung durch ZAS keine Aufforderung zum Auslagern von Programmcode in das Grundgerät ist oder ein ,,zweites`` ZAS parallel zum dort bereits laufenden geschrieben werden sollte, nur weil einem die vorhandenen ZAS-Funktionen nicht gefallen oder zu umständlich erscheinen - es sollte viel mehr als letztes Mittel verstanden werden, um besondere Anwendungen für den KC 85/4 überhaupt erst zu ermöglichen.
Soviel für heute von meiner Seite zu einem eher ungewohnten Thema, eigentlich bin ich ja eher CAOS-orientiert und habe für die CP/M-Betriebsart nicht so viel übrig, da die grafischen Möglichkeiten eher beschränkt sind bzw. offiziell gar nicht zur Verfügung stehen. Ich konnte mich hoffentlich einigermaßen verständlich ausdrücken und man kann diesen Zeilen brauchbare Informationen entnehmen.