Im Handbuch wird fast beiläufig erwähnt, daß es außer der "normalen" Art von Programmen auch noch welche vom Typ-1, Typ-2, Typ-3 und Typ-4 gibt.
Allerdings werden kaum Hintergrundinformationen zu diesen speziellen Programmtypen geliefert, dabei haben sie doch einige interessante Eigenschaften. Für den Anwender bleibt beim Aufruf einer COM-Datei der Programmtyp verborgen, es sei denn das Programm selbst weist an irgendeiner Stelle darauf hin, wie z. B. ZPATCH es tut.
Programme vom Typ-3 oder Typ-4 werden zur Ausführung nicht ab Adresse 0100 hex geladen, sondern in höhere Speicherbereiche. Dadurch bleibt normalerweise das zuvor geladene Programm (ab 0100 hex) im Speicher erhalten und kann mittels GO-Befehl wieder gestartet werden, ohne daß es zuvor vom Datenträger geladen werden muß.
Die 5 Programmtypen sollen nun eingehender betrachtet werden. Zunächst einmal die reinen CP/M Programme, die selbstverständlich auch unter dem Z-System laufen. Da sie von der neuen Systemumgebung keine "Ahnung" haben, benutzen sie sie auch nicht. Normale CP/M Programme werden in den Arbeitsspeicher ab Adresse 0100 hex geladen. Bis auf wenige (systemnah programmierte) Ausnahmen bereiten sie keine Probleme.
Das Z-spezifische Pendant zu den normalen CP/M Programmen sind jene vom Typ-1. Bis auf einen wenige Bytes großen Header, der dem eigentlichen Programmcode vorangstellt ist, unterscheiden sie sich auf den ersten Blick nicht von standardmäßigen CP/M Programmen. Man kann sich auch unter einem solchen System starten, erhält aber meist eine Fehlermeldung und das Programm wird abgebrochen.
Dies hat natürlich einen Sinn. Im Verlaufe der Programmausführung wird von den speziellen Eigenschaften des Z-Systems Gebrauch gemacht. Weil dies unter einem standardmäßigen CP/M System unweigerlich zu Problemen führen würde, blockt das Programm die Benutzung in einem solchen Fall ab.
Da für alle Zugriffe auf die Eigenschaften des Z-Systems die Adresse des jeweiligen Elementes (z. B. TCAP für Terminalsteuerzeichen) aus dem Environment Descriptor benötigt wird, muß dieser zuerst gesucht werden. Dazu kann sich der Programmierer einer Routine aus der Z3LIB bedienen. Für die anschließende Initialisierung steht ebenfalls eine Routine zur Verfügung. Diese setzt eine globale Variable auf das Environment und ermöglicht so den anderen Z3LIB-Routinen einen schnellen und unkomplizierten Zugriff auf das Z-System.
Leider konnte ich bislang kein Programm vom Typ-2 auftreiben, der im Handbuch ebenfalls erwähnt wird. Offenbar handelt es sich dabei um eine ausgestorbene Art. Den Ausführungen von Jay Sage in der Z-System Corner des TCJ (Ausgaben #32 und #34) folgend, wird der Environment Descriptor in diese Programme eingebettet. Somit wäre ein Programm vom Typ-2 an ein bestimmtes System angepaßt und nur auf diesem lauffähig -- ziemlich unflexibel für ein dynamisches Betriebssystem.
Hingegen trifft man gelegentlich noch auf Programme vom Typ-3. Diese besitzen einen ähnlichen Header wie die Typ-1 Programme, mit dem sie sich gegenüber dem Kommandoprozessor identifizieren. Im Gegensatz zu diesen hat der Programmierer als Basisadresse jedoch eine andere als 0100 hex festgelegt (meist 8000 hex oder höher). Diese Basis- oder Startadresse ist im Header enthalten und wird vom CPR zum Laden und Starten des Programmes benutzt. Sinn und Zweck von Typ-3 Programmen ist es, den unteren Speicher zur Wiederausführung eines geladenen Programmes "freizuhalten".
Bei Programmen vom Typ-3 kann jedoch folgendes Problem auftreten: Der Programmierer hat, ausgehend von seinem System, eine sehr hohe Basisadresse festgelegt. Beim Start auf einem System mit weniger TPA kann es dazu führen, daß Teile des Systems überschrieben würden. Um einem Absturz vorzubeugen, lädt der CPR in diesem Fall das Programm nicht -- es kann also nicht ausgeführt werden.
Dieses Problem wird von den Typ-4 Programmen elegant gelöst. Bei ihnen wird die Basisadresse nicht vom Programmierer festgelegt, sondern erst zur Laufzeit bestimmt. Dazu sind jedoch zwei besondere Voraussetzungen notwendig. Der Programmcode darf nicht auf eine bestimmte Adresse gelinkt werden, sondern muß als PRL- oder SPR-Datei erzeugt werden. In die ersten beiden Records, die bei PRL-/SPR-Dateien standardmäßig nur die Länge des Codes enthalten, wird ein spezieller Header eingebettet. Darin sind Routinen zur Berechnung der Ladeadresse und zum Linken des Programmcodes enthalten.
Wird vom Kommandoprozessor der Typ-4 erkannt, so lädt er den ersten Record des Programms in den standardmäßigen DMA-Puffer (Adresse 0080 h). Anschließend wird ein CALL dorthin ausgeführt, um die Ladeadresse berechnen zu lassen. Danach lädt der CPR den zweiten Record in den DMA-Puffer und die restliche Datei (also den Programmcode inklusive Bitstream) ab berechneter Ladeadresse in die TPA. Ist dies geschehen, wird durch einen weiteren CALL die Routine im DMA-Puffer aufgerufen. Diese linkt den Programmcode und kehrt anschließend zum Kommandoprozessor zurück, der dann das Programm startet.
Auf diese Weise werden Programm vom Typ-4 stets auf die höchstmögliche Adresse geladen, wobei der untere TPA-Bereich unverändert bleibt. Ein vorher geladenes Programm kann einfach mittels GO-Befehl wieder gestartet werden. Ein Überschreiten der oberen TPA-Grenze während des Ladevorgangs kann nicht auftreten.
An dieser Stelle möchte ich alle Programmierer ermutigen, es einmal mit Typ-4 zu versuchen. Grundsätzlich kann jedes Programm dafür eingerichtet werden. Für den speziellen Typ-4-Lader stehen Quelltexte (auch in deutsch) und ein einfach zu handhabendes Overlay zur Verfügung. Mit Hilfe des originalen LINK von Digital Research ist es möglich, anstelle einer COM-Datei das PRL- oder das SPR-Format auszugeben. Es mangelt also nicht an Werkzeugen!
