Kapitel 6
6.1 Definition der Datei-Typen
Das NZ-COM-Betriebssystem identifiziert die Funktionen bestimmter Spezial-Dateien durch ihren Datei-Typ. Diese sind in der nachfolgenden Tabelle aufgeführt. ZRL-Dateien sind spezielle relozierbare Dateien, die an eine beliebige NZ-COM-Systemkonfiguration angepaßt werden können. Diese können sowohl im SLR- als auch im Microsoft M-80-Format vorliegen. Die Moduln müssen gemäß der folgenden Tabelle benannt werden, einschließlich einer Zeile im Quell-Code, die den NAME-Pseudo-op-Code enthält. Es gibt keinerlei Einschränkungen hinsichtlich der Namen, die für die Dateien selbt benutzt werden dürfen. Zum Zeitpunkt des Ladens bestimmt NZCOM die Art des Moduls durch Prüfung des im Code eingebetteten Modul-Namens.
DATEI-TYP INHALT Library Datei NZ-COM System-Deskriptor Z-System Environment und NZ-COM System-Deskriptor NZ-COM System Speicher Belegung Z3 Terminal Capability Deskriptor (TCAP) Register-Datei der benannten Directories Z-system ReLozierbare allgemeine Code-Datei Datei mit REL-Modul namens: NZ-COM Disk Operating System Modul NZ-COM Kommando Prozessor NZ-COM BIOS-Modul Resident Command Package (eingeb. Befehle) Flow Command Package Input/Output Package wobei "x" irgendein Zeichen ist Tabelle der Datei-Typen, die vom NZ-COM-System benutzt werden.
6.2 Bei NZ-COM mitgelieferte Dateien
Viele Dateien werden beim NZ-COM-System mitgeliefert. Die meisten sind in diesem Abschnitt aufgeführt, zusammen mit Erklärungen ihrer Funktionen. Siehe dazu auch die Datei RELEASE.NOT wegen Information über kurzfristige Änderungen.
6.2.1 NZ-COM System-Dateien
Die Dateien, die NZ-COM ausmachen, sind in der untenstehenden Tabelle aufgeführt. WIr möchten Sie erinnern, daß diese Dateien einem Copyright unterliegen und nur auf einen einzigen Anwender lizensiert sind. Es ist daher illegal, diese Dateien für andere Personen zu kopieren und an diese weiterzugeben. Einzelheiten dazu siehe Copyright-Notiz am Anfang des Handbuches.
Der alternative RCP ist kleiner als der Standard-RCP und bietet ein sehr verschiedenes Befehls-Set, die im Hinblick auf Arbeitsgeschwindigkeit zusammengestellt wurden. Mit Ausnahme des R-Befehls, der fast keinen Platz im RCP beansprucht, beinhaltet er lediglich Befehle, die völlig speicherbezogen arbeiten und ohne Bezug auf eine Diskettenfunktion. Hier kann die Geschwindigkeits-Optimierung eines residenten Befehls voll ausgeschöpft werden. Diskettenorientierte Befehle, wie SP, TYPE und ERA, werden transienten Befehlen überlassen.
Der alternative FCP kommt ohne IFQ-Befehl aus und ist daher einen Record kleiner. Wenn Sie den Gebrauch der Z-System-Ablaufsteuerung mit IF erst einmal gelernt haben, werden Sie vielleicht diese kleinere FCP-Version wählen. Wenn das der Fall sein sollte, können Sie einfach NZFCP1.ZRL in NZFCP.ZRL umbenennen (und den Standard- NZFCP.ZRL etwa in NZFCP2.ZRL) so daß dieser als Default geladen wird. Die gleiche Art der Umbenennung kann auch für den weiter unten beschriebenen RCP vorgenommen werden. Sie können die Library "Member"-Files umbenennen mit NULU oder VLU. Ist keins dieser Programme zur Hand, entpacken Sie alle Dateien aus der Library mit (LGET), nehmen die Umbenennung vor und erstellen eine neue Library mit (LPUT). Geübte können Dateien auch direkt in der LBR-Datei durch Patchen umbenennen.
Liste der NZ-COM System-Dateien.
NZCOM-Systemlader Library mit NZCOM-System-Moduln Default Kommando-Prozessor Default Disk Operating System Default virtuelles BIOS Default Resident Command Package Alternatives Resident Command Package Default Flow Command Package Alternatives Flow Command Package Default Definition benannter Directories NZ-COM System-Defininitions-Utility Alternative Kommando-Prozessor Moduln Z-System Package-Lader
6.2.2 Tools und Utilities
Viele Dateien, die nicht zum NZ-COM-System gehören, sind im Lieferumfang enthalten, als Zugeständnis an die Anwender. 1 Einige dieser Dateien sind Public Domain. Andere stehen unter Copyright ihrer Autoren oder der ZSIG, der Z-System Interest Group. Für alle gilt jedoch, daß die Autoren ihre Zustimmung gaben zum Kopieren und kostenlosen Weitergeben an dritte, für nicht-kommerzielle Zwecke wohlgemerkt.
1Daher können wir keine Verantwortung zur Unterstützung für diese Programme übernehmen.
Die folgenden Dateien unterstützen die Z-System TCAP Einrichtung:
Auswahl des Terminal Deskriptors Datenbank von Terminal Deskriptoren
Die folgenden Dateien unterstützen Z-System Aliase:
Alias Comdatei-Generator Alias Befehlsprozessor Alias Script Datei für ARUNZ
Die folgende Datei wird vom FCP benutzt, um erweiterte konditionelle Prüfungen durchzuführen:
Erweiterter Flußzustands-Tester
Die folgenden Utilities definieren oder zeigen Z-System-Environment Variablen und System-Eigenschaften:
zeigt/definiert CRT/PRT Charakteristika setzt/zeigt Befehls-Suchpfad
Name aus dem ursprünglichen SETPATH.COM abgeändert.zeigt Z-System Konfigurations-Information editiert Named Directory Register im Speicher
Name vom ursrpünglichen EDITND.COM geändert."Save Named Directory Register" in Datei
Die folgenden Programme sind Utilities von allgemeinem Interesse:
Datei-Sucher Datei-Komprimierer Datei-Dekomprimierer
Folgende Programme unterstützen Library-Dateien:
Library Directory Programm Library Member Extraktor Library Datei Inserter Video-orientiertes Library Utility Library Datei Executor
Die folgenden Dateien beziehen sich auf Shells und Error Handler:
ZFILER für Terminals mit Inversdarstellung ZFILER für Terminals mit Helligkeiststufen Makro Script Datei für ZFILER Kommando History-Shell und Error Handler erzeugt Datei mit EASE-Befehlstasten komprimiert EASE-History-Datei Log-Shell - alternative History-Shell
Folgende Dateien unterstützen die Z-System-Help-Einrichtung:
zeigt menügesteuert Help-Dateien diverse Help-Dateien
Folgende Programme sind type-4 transiente Programme (siehe Abschnitt 3.2.4), die am oberen Ende der verfügbaren TPA laufen und die so den Speicher darunter nicht stören. Sie sind besonders nützlich in einem "Minimum"-System, wo transiente Programme für Funktionen benutzt werden, die andernfalls von RCP Befehlen übernommen werden müßten. Zum Gebrauch ist es zweckmäßig, sie umzubenennen, um die vorangestellte TY4-Kennzeichnung zu eliminieren.
SPeicherplatz auf Diskette SAVE-Befehl wie bei CP/M REName ERAse
Es gibt verschiedene Arten, wie man an die Unmengen von ständig zunehmenden Z-System User-Group Dateien kommt. Die Telefonnummern der Z-Node Mailboxen sind aufgelistet in:
ZNODES .LST
Eine Reihe von einzelnen Leuten haben mitgeholfen, bei anderen das Z-System zu installieren und die Anwendung zu unterstützen. Ihre Namen, Adressen, und Telefonnummern sind aufgeführt in der Datei:
ZHELPERS.LST
6.3 NZCOM Befehlszeilen
Dieser Abschnitt beschreibt die verschiedenen Arten der Befehlszeile, die zum Aufruf von NZCOM.COM eingesetzt werden können.
6.3.1 Hilfe-Seiten
Eine eingebaute Hilfeseite zur Erinnerung an die Syntax der NZCOM Befehle wird dargestellt, wenn einer der folgenden Befehle eingegeben wird:
NZCOM //<cr> NZCOM ?<cr>
Diese Seite wird auch anzeigen, wie die momentane Version durch Patchen der Datei (siehe Abschnitt 6.4) konfiguriert wurde.
6.3.2 Laden des NZ-COM Systems
Die allgemeine Form der NZCOM Befehlszeile ist:
NZCOM [Library] [Deskriptor] [Dateiliste] [/Optionen] [;Befehle]<cr>
Alle Elemente auf der Befehlszeile sind optional. Wenn mehrere Eingaben gemacht werden, kann man diese trennen durch Leerzeichen (wie dargestellt), Kommata oder Kombinationen beider Formen. Für verschiedene Teile der Befehlszeile können verschiedene Separatoren benutzt werden.
Allgemeine Regeln
Bevor wir die einzelnen Bestandteile der Befehlszeile detailliert beschreiben, wollen wir zwei allgemeine Regeln definieren. Erstens: Ein Präfix namens "dir:" in einem Syntax-Ausdruck bedeutet eine geeignete Directory-Angabe. Wenn NZCOM von CP/M aus aufgerufen wird, kann der Directory-Präfix jede der folgenden Drive/User Formate haben: Doppelpunkt allein für das gegenwärtige Directory, D:, U: oder DU:. Ist das Z-System bereits aktiv, dann dürfen auch benannte Directories benutzt werden.
Zweitens: Dateien, die auf der NZCOM-Befehlszeile angegeben werden, werden nach folgender Prozedur gesucht. Hat die Datei einen spezifischen Directory-Präfix, wird nur dieses Directory durchsucht. Wurde kein expliziter Directory-Präfix verwendet, wird zuerst die momentan ausgewählte Library-Datei (mehr darüber gleich) durchsucht. Wird die Datei dort nicht gefunden, wird der "Suchpfad" abgesucht. Ist das Z-System bereits aktiv, dann steht der Ausdruck "Path" für den Z-System-Suchpfad, einschließlich des momentanen Directorys. Unter CP/M bedeutet "Path" einen internen Suchpfad, der in NZCOM.COM verankert wurde (siehe Abschnitt 6.4.1). Diesen Pfad kann man sehen, indem man NZCOM mit der Hilfe-Seite aufruft.
Der Ausdruck Library
Der erste Teil der Befehlszeile ist optional die Angabe einer eine Library-Datei. Er ist von der Form:
[dir:]lbrname.LBR
Der Datei-Typ LBR wurde angegeben. Wird dabei kein Library-Name explizit angegeben, wird der Ausdruck "NZCOM.LBR" für diesen Teil der Befehlszeile angenommen. Directory-Präfixe sind optional.
Libraries können ebenfalls als Teil einer Dateiliste angegeben werden, wie wir bald sehen werden. In allen Fällen sucht NZCOM nach Library Dateien wie nach jeder anderen Datei, außer daß es natürlich nicht als "Member" einer anderen Library gesucht wird. Der zuletzt angegebene (oder eingebaute) Library-Name wird in der Such-Hierarchie für andere Dateien benutzt. Eine Library, die am Beginn einer Parameterzeile steht, wird nach allen Deskriptor-Dateien durchsucht.
Der Ausdruck Deskriptor
Der zweite Teil ist eine optionale NZ-COM-System Deskriptor-Datei. Auch diese kann optional einen Directory-Präfix beinhalten. Sie wird dadurch identifiziert, daß sie entweder keinen Datei-Typ hat, oder einen der drei System Deskriptor-Datei Typen ZCI, ZCM oder ENV. Wurde kein Datei-Typ explizit genannt, dann findet die Such-Prozedur in der Reihenfolge, in der die drei Datei-Typen gerade aufgeführt wurden sequentiell Anwendung. Erscheint kein System-Deskriptor in der Befehlszeile, geht NZCOM in den "System-building mode" über. Andernfalls findet der Modul-Lade-Modus statt.
Wenn keine Dateiliste (siehe unten) angegeben wurde, dann wird dafür im allgemeinen der Ausdruck "NZCOM" als System-Deskriptor eingesetzt. Eine Ausnahme tritt dann ein, wenn gar keine Dateien als Parameter angegeben wurdem. Dann wird die Dateispezifikation als
NZCOM NZCOM.LBR NZCOM.ZCM
angenommen, wobei der ZCM-Datei-Typ statt ZCI benutzt wird, wie in der oben angegeben allgemeinen Regel.
Der Ausdruck Dateiliste
Der dritte Teil ist eine optionale Liste eines oder mehrerer Moduln oder Library-Dateien der Form:
Dateiname [Dateiname [...]]
Jeder Dateiname hat die Form:
[dir:]name.typ
wobei die erlaubten Dateitypen LBR, ZRL, REL, Z3T, NDR, FCP, RCP oder IOP sind.
Wurde eine Library-Datei benannt, wird sie zur aktiven Library und wird für die Suche nach Modul-Dateien in der Folge eingesetzt.
Die ZRL-Datei ist eine spezielle Form relozierbaren Codes, der für den Gebrauch im Z-System konfiguriert werden kann, wenn die Datei verwendet werden soll (im Gegensatz zum Enstehungszeitpunkt). Es ist die einzige Dateiart, die zum Laden von Kommando-Prozessor, Disk Operating System, oder virtuellen BIOS-Moduln verwendet werden kann. Die ZRL-Datei ist ein bequemer Weg, andere Code-Moduln, wie FCP- und RCP-Moduln zu versorgen, da eine einzelne ZRL-Datei in jedem Z-System verwendet werden kann, das dafür Speicher reserviert hat. Wir ermutigen Entwickler, Dateien des Typs ZRL die Endung ZRL zu geben. Es können jedoch Dateien des ZRL-Typs mit der Endung REL geladen werden.
NZCOM kann gleichwohl verschiedene Formen nicht-relozierbarer Dateien laden. Z3T Terminal Capability Deskriptor-Dateien und NDR Named Directory Register Dateien stellen nie ein Problem dar, da diese Moduln keinen Code enthalten; sie enthalten nur Daten. NZCOM kann auch absolute Speicher-Abbilder von FCP-, RCP-, und IOP-Code Moduln laden. Das ist eine bleibende, riskante Prozedur in einem dynamischen System wie NZ-COM, wo die Adressen von System-Komponenten sich ändern können. Aus diesem Grund empfehlen wir nachhaltig den Gebrauch von ZRL-Dateien. NZCOM unternimmt einige Anstrengungen, um diese absoluten Moduln auf Kompatibilität mit dem aktiven oder dem zu konstruierenden NZ-COM-System zu prüfen, aber kein Test kann diese Kompatibilität garantieren.
NZCOM bearbeitet die Dateiliste auf zwei verschiedene Arten, je nachdem, in welchem Modus es sich gerade befindet. Im Modul-Lade-Modus wird jede in der Liste genannte Datei direkt in das momentan aktive System geladen. Im "System-building"-Modus baut es daraus ein Abbild des neuen Systems.
Im System-building Modus, wenn ein NZ-COM-System bereits aktiv ist, werden Moduln aus der Liste nur geladen, wenn sich das neudefinierte NZ-COM-System vom aktiven NZ-COM-System auf eine Weise unterscheidet, die das Laden des neuen Moduls erforderlich macht, besonders, wenn dies Adresse des Puffers, an die das Modul geladen werden soll, sich geändert hat, oder wenn dieser Puffer kleiner geworden ist. Werden irgendwelche Moduln benötigt, die nicht angegeben wurden, benutzt NZCOM seine Standard-Default-Modulnamen, und sucht es diese Dateien, als ob sie explizit am Ende der Dateiliste angegeben wären. Diese Moduln sind wie folgt:
Wurde die Option "C" (siehe unten) angegeben, dann ist es NZCOM egal, ob gerade ein Z-System aktiv ist. Es verhält sich, als ob CP/M aktiv wäre und lädt alle Modul-Dateien in den Speicher.
Der Ausdruck Optionen
Der nächste Teil der NZCOM-Befehlszeile ist ein optionaler "Slash" (Vorwärts-Schrägstrich), gefolgt von einem oder mehreren Buchstaben. Die Schalter "Q" oder "V" setzen den "quiet" oder "verbose" Modus. Im Verbose-Modus (= wortreich), zeigt NZCOM Information über die Moduln, die geladen werden, einschließlich des Namens und, wo angebracht, der Zieladresse der verwendeten Datei. Im Quiet-Modus wird diese Anzeige unterdrückt und nur eine Reihe von Punkten wird dargestellt. Dies teilt Ihnen mit, daß etwas passiert und daß etwas vorangeht. Die NZCOM-Hilfs-Seite zeigt den Default-Modus für diesen Schalter. Der Quiet-Modus ist in der Vertriebsversion von NZCOM.COM Default, kann aber vom Anwender geändert werden (siehe Abschnitt 6.4.2).
Ein anderer Options-Schalter ist "C" (für "Clonen"). Wenn dieser Schalter angegeben wurde, verhält sich NZCOM als ob es aus der CP/M-Befehlszeile aufgerufen worden wäre und schafft ein komplettes System. Es lädt dieses System jedoch nicht. Statt dessen erstellt es eine Datei mit der Bezeichnung der auf der Befehlszeile angebenen NZ-COM-Deskriptor-Datei (oder per Default NZCOM). Diese Option kann natürlich nur im "System-building"-Modus benutzt werden.
Eine dritte Option ist eine der Kombination "Z" und "R". Damit wird festgelegt, ob NZCOM eine Datei-Extension ZRL oder REL für Dateien des Typs ZRL als Default-Dateien lädt (siehe obige Liste der Default-Dateien), wenn es ein Modul ist, das Sie nicht ausdrücklich angegeben haben. Wir empfehlen den Gebrauch dieser Option nicht sondern raten Ihnen, die Dateien umzubenennen, so daß die Extension ZRL wird und damit den Datei-Typ eindeutig als ZRL festlegen.
Der Ausdruck Befehlszeile
Die letzte Option in der NZCOM-Befehlszeile ist ein Strichpunkt (Semikolon), gefolgt von einem Ausdruck, der aus einer Multiplen Z-System Befehlszeile besteht. Da ein Semikolon unter dem Z-System eine Befehlszeile abschließt, ist diese Option bedeutungslos, wenn das Z-System bereits läuft. 2 Dies soll dazu dienen, dem Anwender den Gebrauch Multipler Befehlszeilen beim Aufruf von NZCOM aus CP/M direkt anzuhängen.
2Wann immer NZCOM eine neue Version des Z-Systems lädt, werden schwebende Befehle im Befehlszeilen-Puffer des laufenden Systems in den Befehlszeilen-Puffer des neuen Systems übergeben. Als Resultat scheint die hier beschriebene Option genauso unter einem laufenden Z-System zu funktionieren.
6.3.3 Das Entfernen von NZ-COM
Wenn NZCOM aus CP/M aufgerufen wird, wird die Existenz einer Datei namens NZCPM.COM im Root Directory des intern in NZCOM.COM (siehe Abschnitt 6.4.1) konfigurierten Pfads abgeprüft. Wurde keine solche gefunden, wird ein Speicherabbild des CP/M-Systems zusammen mit einem Lader in eine Datei gespeichert. Diese Datei heißt NZCPM.COM. Das NZ-COM Betriebssystem kann jederzeit aus dem Speicher entfernt und das CP/M Betriebssystem wiederhergestellt werden durch Eingabe von 3 :
NZCPM<cr>
3Hierbei wird davon ausgegangen, daß NZCPM sich in einem Directory entlang des Suchpfads befindet. Wenn nicht, müssen Sie eine Directory-Angabe davorstellen.
6.3.4 Beispiele und Tips
Wir wollen Ihnen jetzt einige Beispiele von NZCOM-Befehlszeilen geben, um Ihnen das Verständnis der Syntax zu erleichetern. Während wir diese Beispiele diskutieren, wollen wir einige Tricks zeigen, die das Arbeiten mit NZCOM vereinfachen oder beschleunigen.
Laden einer speziellen NZ-COM-Konfiguration
Die folgende Befehlszeile kann benutzt werden, um eine besondere, mit SMALL.ENV erstellte Konfiguration zu laden. Es wird angenommen, daß sich die Definition und die Moduln SMALLFCP.ZRL und SMALLRCP.ZRL, die es benutzt, in der Library SPECIAL.LBR befinden, die sich im Directory A15: befindet. Außer diesen speziellen Moduln, sind alle anderen Moduln die Default-Dateien, die sich wie gewohnt in der Datei NZCOM.LBR auf A0: befinden. Hier die Befehlszeile, um dieses System zu laden:
NZCOM A15:SPECIAL.LBR SMALL.ENV SMALLFCP.ZRL SMALLRCP.ZRL A0:NZCOM.LBR /V<cr>
Wir haben Laufwerksangaben für beide Libraries angegeben, damit NZCOM nicht Zeit verliert bei der Suche nach diesen entlang des Pfads.
Durch Angabe eines expliziten Datei-Typs im Ausdruck SMALL.ENV, erhalten wir zwei Vorteile. Zuerst versichern wir uns, daß Dateien mit den Namen SMALL.ZCI oder SMALL.ZCM nicht geladen werden (hier entgegen unserer Absicht). Zum Zweiten, für den Fall, daß die Datei unglücklicherweise nicht in der Library gefunden wird, hindern wir NZCOM daran, eine langwierige Suche nach Dateien mit allen drei Deskriptor-Datei-Typen über den gesamten Suchbereich durchzuführen, bevor der Fehler gefunden und gemeldet wird.
Das Hinzufügen des Ausdrucks A0:NZCOM.LBR am Ende der Dateiliste ist sehr wichtig. Ohne das, wäre die Library am Ende der Liste A15:SMALL.LBR gewesen. Die Default-Dateien für die verbleibenden Moduln würden nicht gefunden, da NZCOM nicht automatisch in NZCOM.LBR nachsehen würde.
Die Option "/V" am Ende stellt sicher, daß NZCOM eine detaillierte Lade-Anzeige ausgibt, die das generierte System zeigt.
Wenn man die System-Konfiguration, die durch diese Befehlszeile definiert wurde, mehr als nur ein-, zweimal benutzt, wäre es sinnvoll, diese Zeile in die Datei ALIAS.CMD einzubinden, etwa unter einem Alias-Namen wie SMALL. Das würde uns eine Menge Tipperei ersparen und eine Menge Fehler vermeiden helfen, wie etwa, zu vergessen, den Ausruck NZCOM.LBR anzugeben, oder einen Dateinamen falsch anzugeben.
Laden Spezieller Moduln
Der folgende Befehl wird benutzt, um eine neue Gruppe von Kommando-Moduln zu laden. Er setzt voraus, daß wir unsere RCPs in einem Directory namens RCP entwickeln und daß wir die fertig gestellten in einer Library namens RCPS.LBR ablegen. Er setzt voraus, daß wir nur ein paar Versionen von FCPs haben und daß wir es vorziehen, sie als einzelne Dateien in unserem Hauptverzeichnis A0: zu lagern.
NZCOM RCP:RCPS.LBR RCP-D.ZRL A0:FCP-1.ZRL<cr>
Durch gezielte Angabe von A0: vor dem Ausdruck FCP-1.ZRL erreichen wir einen Geschwindigkeitsvorteil. NZCOM würde normalerweise die Datei zuerst in RCPS.LBR suchen und nur dann entlang des Pfads suchen. Durch Angabe des korrekten Directory-Pfads bringen wir NZCOM dazu, die Datei sofort zu finden.
Laden eines neuen Kommando-Prozessors
Benutzer des Z-Systems sind an die Vorstellung gewöhnt, neue RCP und FCP Moduln zu laden. Es mag überraschen, daß NZCOM genauso einfach einen neuen Kommando-Prozessor laden kann. Das NZ-COM-Vertriebspaket beinhaltet eine Library namens ZCPR34.LBR, die diverse alternative Kommando-Prozessor Konfigurationen enthält. Einer davon unterstützt eine nicht standardisierte Form der SUBMIT-Bearbeitung, die willkürliche Längen von SUBMIT-Dateien erlaubt. 4 Um diese spezielle Datei namens Z34LONG.ZRL zu benutzen, geben wir die Befehlszeile ein:
NZCOM A0:ZCPR34.LBR Z34LONG.ZRL<cr>
4Normale CP/M SUBMIT-Dateien dürfen nicht mehr als 128 Befehlszeichen enthalten, die Anzahl, die man in einem einzigen Datei-"Extent" unterbringen kann.
Auf lange Sicht gesehen wäre es vielleicht nützlich, einen Alias in ALIAS.CMD unter einem Namen wie LSUBCPR zu definieren, der diese Befehlszeile für uns erzeugen könnte.
6.4 Patchen von NZCOM.COM
Es gibt verschiedene Optionen in NZCOM.COM, die von den Konfigurations-Bytes im Code kontrolliert werden. Man kann Änderungen auf vielerlei Arten installieren. Die bequemste Methode ist durch ein Patch-Utility wie ZPATCH. Man kann auch die zur Verfügung stehenden Gegebenheiten des Z-Systems verwenden. NZCOM kann mit dem GET Befehl in den Speicher laden, mit dem POKE-Befehl ändern und dann das modifizierte Speicherabbild mit SAVE speichern. Bevor Sie das tun, sollten Sie jedoch wissen, wie groß die Datei NZCOM.COM in Records ist. Das Directory-Programm SDZ mit der "/C" Option wird diese Information liefern.
Wir werden jetzt die momentanen Konfigurations-Bereiche en detail betrachten. Diese Information ist korrekt für die ursprünglich veröffentlichte Version von NZ-COM und es ist sehr leicht möglich, daß zukünftige Versionen neue oder zusätzliche Konfigurations-Optionen bieten. Sie sollten stets die Datei RELEASE.NOT, sofern vorhanden, auf aktuellere Information durchforsten.
6.4.1 Der Interne Suchpfad
Der "interne" Suchpfad, der dann benutzt wird, wenn NZCOM von CP/M aus operiert, der initiale Z-SystemSuchpfad, der entscheidet, wohin die CCP "Image Datei" NZCOM.CCP und der NZ-COM System-Rücklader NZCPM.COM gespeichert werden, werden an die Adresse 0680H geladen. 5 Jedes Element im Suchpfad wird durch ein Bytepaar ausgedrückt. Das erste Byte des Paars ist das Laufwerk, wobei der Wert 1 für Laufwerk A steht. Das zweite Byte ist die User-Nummer und muß einen Wert zwischen 00 und 1F (31 decimal) aufweisen. 6
5Alle Adressen sind in hexadezimaler Schreibweise und erwarten einen Programmbeginn bei 0100H.
6Bedenken Sie, daß Sie unter CP/M Plus nur 15 User ansprechen können. Userbereiche darüber sind daher nur in reinen CP/M 2.2 Systemen mit speziellen Utilities erreichbar.
Es gibt zwei besondere Symbole, die in einem Pfad Ausdruck Anwendung finden. Ein Dollar-Zeichen (24 Hex) für ein Laufwerk wird zum Zeitpunkt der Anwendung des Pfad-Ausdrucks ersetzt durch das momentan eingeloggte Laufwerk. Gleichermaßen repräsentiert ein Dollar-Zeichen an der Position des Usereintrags den momentan eingeloggten Userbereich.
Es können maximal fünf Elemente im Pfad enthalten sein. Er wird terminiert durch ein einzelnes Null-Bytes (value 00). Das Ende der ganzen Pfadsequenz im NZCOM-Code ist markiert durch FF. Der Suchpfad in der Vertriebsversion von NZCOM.COM enthält die Sequenz A0 $$ A0. Die verbleibenden zwei möglichen Pfad-Elemente werden mit Nullen aufgefüllt.
Sie werden sich fragen, warum das Directory A0 zweimal im Pfad enthalten ist. Das letzte Drive/User Paar heißt Root Directory. 7 Viele Z-System-Operationen beziehen sich automatisch auf dieses Directory. Der ZCPR34-Kommando-Prozessor ist gewöhnlich so konfiguriert, daß er im Root Directory nach dem Erweiterten Kommando-Prozessor sucht, und ARUNZ und ZFILER suchen dort nach ihren CMD-Dateien. 8 NZCOM benutzt den "Root" dieses internen Pfads um seine Dateien NZCOM.CCP und NZCPM.COM abzulegen.
7Bitte dieses Root Directory nicht mit einem Directory verwechseln, das zufällig ROOT heißt. Letzteres ist lediglich ein Name und hat keine besondere Bedeutung für das Directory.
8Die Lieferversionen von ARUNZ und ZFILER sind konfiguriert, ihre CMD-Dateien im Root Directory zu suchen. Diese Programme können, wenn gewünscht, konfiguriert werden, ein anderes Directory zu benutzen.
Auf der anderen Seite enthält das als Root eingestellte Directory oft die meistbenötigten Programme und im allgemeinen möchte man ein Programm dort zuerst suchen lassen. So ist NZCOM eingestellt, zuesrt auf A0 zu suchen und es als Root zu benutzen. Pfad-Ausdrücke mit Dollar-Zeichen kann auch Doppeleinträge im Pfad hervorrufen. In der Standardkonfiguration hat der Pfad drei Einträge von A0 wenn man auf A0 eingeloggt ist. Wird bei der ersten Suche nach einer Datei nichts gefunden, wird eine zweite Suche sicher nichts fruchten. Sowohl NZCOM, als auch der ZCPR34-Kommando-Prozessor sind clever genug, eine zweifache Suche zu unterbinden durch einen sogenannten "Minpath". Minpath ist der verbleibende Suchpfad, nachdem alle Doppeleinträge entfernt worden sind.
6.4.2 Die Default-Optionen
NZCOM kann eingestellt werden, entweder Q oder V und sowohl Z oder R als Default Option für die beiden Optionspaare anzunehmen. Der "Verbose"-Options-Schalter VOPT 9 wird an der Adresse 068D gespeichert. Der Wert 00 selektiert den "Quiet"-Modus als Default; FF selektiert den "Verbose"-Modus.
9verbose = geschwätzig
Die für ZRL-Dateien von NZCOM benutzte Datei-Extension wird von dem ZOPT Schalter an der Adresse 068E bestimmt. 00 selektiert die R Option; der Wert FF selektiert die Z Option.
6.4.3 Die Startup Befehlszeile
Die Default Startup Befehlszeile, die immer dann benutzt wird, wann immer das NZ-COM-System aus CP/M geladen wird, bleibt an der Adresse 0690 gespeichert. Sie besteht aus den Zeichen, die die Befehlszeile formen, gefolgt von einem Null-Byte (00), um den Kommando-String abzuschließen, und dann einem FF, um den gesamten String abzuschließen.
Diese Befehlszeile ist normalerweise so eingestellt, daß sie den String STARTZCM enthält. Dies wird dann ein ALIAS sein, der viele andere Befehle enthält. Das macht es leichter, die Startup-Befehle zu ändern, als wenn eine komplexe Befehlsfolge starr in NZCOM.COM verankert wäre. Es ist gerade genug Platz in NZCOM.COM -- ohne die Copyright Notiz zu überschreiben -- für einen Befehlsnamen mit acht Zeichen. Ein Teil der Copyright-Notiz kann durch die Befehlszeile überschrieben werden, sollten Sie darauf bestehen, einen längeren Befehl fest einzubinden (oder wenn Sie beim Verstümmeln von Copyright-Notizen perverse Lust verspüren sollten).
Patchen des Konfigurationsprogramms
NZCOM.COM hat einen speziellen Patchbereich zur Programmkonfiguration in den der fortgeschrittene Anwender Code einbinden kann, um besondere Abläufe auszuführen, zusätzlich zu denen von NZCOM. Dieser Patchbereich beginnt bei 0280H und erstreckt sich über 1KB bis zur Adresse 067FH. Unzweifelhaft werden sich viele kreative Anwendungen für diese Einrichtung finden.
Wir haben dabei an die Verwendung für spezielle Patches gedacht, wenn "above-BIOS" System-Erweiterungen, wie etwa DateStamper und/oder BYE, in einem NZ-COM-System laufen sollen. Bei diesen Programmen ist es nötig, in das laufende System Information zu extrahieren, wie sie "eingehängt" sind, um dann diese "Haken" zu restaurieren, nachdem ein neues System geladen wurde (aber noch bevor es zu laufen beginnt). Wir wollen nicht versuchen, Ihnen hier zu erklären, wie das gemacht wird; wir wollen versuchen, Ihnen genug Information über diesen Patchbereich zu geben, daß Sie mit der notwendigen Programmiererfahrung Gebrauch davon machen können.
NZCOM gibt während seines Laufs zu unterschiedlichen Zeitpunkten CALL-Anweisungen an den Code aus, der bei 0280H steht, indem es Z80-Register benutzt, um Information an die Konfigurationsroutine weiterzuleiten. Besonders der Wert im A-Register zeigt an, von welchem Punkt in der Sequenz der auszuführenden Anweisungen NZCOM den Call auslöste. Die folgenden Calls sind momentan definiert:
NZCOM ist gerade gestartet und hat festgestellt, daß kein NZ-COM-System momentan läuft. Keine Dateien wurden zum gegenwärtigen Zeitpunkt geladen. NZCOM ist gerade gestartet und hat festgestellt, daß ein NZ-COM System momentan läuft. Keine Dateien wurden zum gegenwärtigen Zeitpunkt geladen. Alle zugewiesenen oder erforderlichen Default Moduln wurden in einen Arbeitspuffer geladen und sind bereit für das Laden an ihre Run-Time Adressen. Keine Modifikationen wurden bisher vom laufenden Betriebssystem gemacht. Die Moduln wurden wie benötigt aus dem Arbeitspuffer an ihre Run-Time Adressen kopiert , und NZCOM ist bereit, einen Kaltstart des neuen Systems auszuführen. NZCOM hat festgestellt, daß kein neues System geladen werden muß. Dieser Call tritt ein, wenn das angegebene neue System sich vom gegenwärtigen in keiner Weise derart unterscheidet, daß etwas nachgeladen werden müßte. Er wird ebenfalls eintreten, wenn ein Fehler auftritt, der den Abbruch einer NZCOM-Operation erfordert.
Die ersten zwei Calls stehen zur Verfügung für den Fall, daß Code im Konfigurations-Patch initialisiert werden muß, bevor andere Calls auftreten oder wenn andere Operationen der Konfigurations-Routine wissen müssen, welche Art System momentan aktiv ist.
Zusätzliche Information steht durch andere Z80-Register zur Verfügung. Das HL-Registerpaar zeigt auf den Arbeitspuffer WRTBUF, wo NZCOM das neue System zusammenbaut. Der Environment Deskriptor für das neue System steht im Code-Block von 0100H bis 017FH. Die Information, die dort zusammen mit der Adresse des WRTBUF steht, kann benutzt werden, um die Position jedes Moduls im Arbeitspuffer zu berechnen.
Das DE-Registerpaar zeigt auf einen String von Bytes mit Information über den Ladestatus. Gegenwärtig enhält der String zwei Bytes. Das erste heißt MODLST (Modul-Liste). Jedes seiner acht Bits wird dazu verwendet, anzuzeigen, ob Veränderungen in der System Konfiguration das Laden eines korrespondierenden Moduls erforderlich machen. Die Funktion jedes Bits ist definiert in der folgenden Tabelle. Das zweite Byte heißt SEGLST (Segment-Liste). Jedes Bit indiziert, ob die Veränderung eines der in der unteren Tabelle verzeichneten System-Segmente den Einsatz des NZCOM-Laders erforderlich macht.
Außer wenn ein CALL mit dem Wert 3 im A-Register ausgeführt wird, bleibt das alte Betriebssystem an Ort und Stelle und funktional. Der Konfigurationscode kann sich daher auf Betriebssystem-Aufrufe stützen, um seine Aufgaben zu erledigen. Wenn er zum Beispiel entscheidet, daß die Ausführung des NZCOM-Befehls abgebrochen werden soll, kann er das tun durch einen Jump an die Adresse 0000H, um einen Warm Boot zu initiieren.
Man sollte sehr sorgfältig auf jeden Code achten, mit dem ein Call auf die Konfigurationsroutine mit dem Inhalt A = 3 ausgführt wird. An diesem Punkt wurde das neue System an seine Laufzeit-Adresse geladen, aber es wurde nicht nicht initialisiert und darf in keinster Weise verwendet werden. 10
10Mit Geschick, können Sie die Adresse des echten BIOS (im Gegensatz zum virtuellen BIOS) von NZ-COM herausfinden und können entsprechende Calls darauf ausführen. Wenn NZCOM unter einem existierenden NZ-COM-System läuft, ist das Wort an der Adresse 0101H die Adresse der CONST-Routine des echten BIOS.
0 CCP 1 DOS 2 BIOS 3 IOP 4 RCP 5 FCP 6 NDR 7 Z3T System-Segment, das zu jedem Bit im MODLST-Byte korrespondiert.
0 Shell Stack 1 Message Puffer 2 Externer FCB 3 Kommando Suchpfad 4 Wheel byte 5 Befehlszeilenpuffer-Adresse 6 reserviert 7 reserviert System-Segment, das zu jedem Bit im SEGLST-Byte korrespondiert.
6.5 Das Programm JetLDR
Im NZ-COM-Lieferumfang ist ein spezielles Programm namens JetLDR enthalten. Dieses Programm ist ein extrem mächtiger Allzweck-Modullader. All die herkömmlichen Modul-Ladefunktionen für das NZ-COM-System können von NZCOM.COM ausgeführt werden. JetLDR jedoch, ist erweiterbar durch Verwendung spezieller Konfigurations- oder auch CFG-Dateien. Das sind Moduln, die JetLDR in sich selbst lädt und die die Art kontrollieren, wie es andere Moduln lädt. Diese Eigenschaft kann JetLDR die Fähigkeit geben, speziellen Moduln zu laden, wie etwa residente System-Erweiterungen (RSXe).
JetLDR hat eine eingebaute Hilfs-Seite, die mit der Standardeingabe:
JETLDR //<cr>
aufgerufen werden kann.
6.6 Die MKZCM-Befehlszeile
Glücklicherweise muß über die MKZCM Befehlssyntax wenig gesagt werden, da sie so einfach ist. Das Format der Befehlszeile ist:
MKZCM [name]<cr>
Das optionale Token "name" -- dient als Name für die ZCM- und ENV-Deskriptor Dateien, die von MKZCM erzeugt werden sollen -- kann auf der Befehlszeile hinzugefügt werden, wenn man im Voraus weiß, wie der neue System-Deskriptor heißen soll. Es liegt jedoch nur ein geringer Vorteil in dieser Option. Wird kein Name auf der Befehlszeile angegeben, wird MKZCM einen Prompt dafür ausgeben, wenn es aufgefordert wird, die System-Deskriptoren zu speichern. Entschließen Sie sich dazu, den Systemdefinitionsprozeß abzubrechen und nicht zu speichern, haben Sie sich eine Menge Tipperei erspart! Viel wichtiger aber ist, daß Ihre Optionen immer noch offen sind, wenn Sie sich mitten im Definitionprozeß für einen anderen Namen entscheiden sollten. Haben Sie einen Namen auf der Kommandozeile angegeben, bleibt er Ihnen!
6.7 Funktions-Theorie
NZ-COM ist die spezielle Form einer Resident System Extension (RSX), die an eine hohe Speicheradresse des CP/M-BIOS geladen wird. Es beinhaltet folgende Moduln:
Kommando-Prozessor Disk Operating System Warm-Boot Umleitung Z-System-residente Segmente: Externe Environment Beschreibung Terminal Capabilities Puffer Message Puffer Path Wheel Byte Externer Datei-Kontroll-Block Multiple Befehlszeile Shell-Stack Externer Kommandoprozessor-Stack optionale Z-System Segment Puffer Named-Directory Register Residentes Kommando Paket Fluß Kommando Paket Input/Output Paket
Der Code zum Verbiegen des Warmboots initialisiert das Disksystem auf normale Art, lädt aber den Kommandoprozessor nicht aus den Systemspuren nach, sondern aus einer Datei namens NZCOM.CCP. Wenn das System durch NZCPM.COM entfernt wurde, werden das ursprüngliche DOS-Modul und der ursprüngliche Warmboot-Vektor wieder restauriert. Das CP/M-Host-System übernimmt dann und lädt seinen Standard Kommando-Prozessor aus den Systemspuren.
Wird ein neues NZ-COM-System geladen, während ein anderes System bereits aktiv ist, speichert NZCOM den Status des gegenwärtigen Z-System-Environments, entscheidet, welche Änderungen erforderlich sind (z. B. ein Puffer mit veränderter Größe), reloziert und installiert die neuen Pakete und restauriert die unveränderten Komponenten des Environments.