Eine der aufregendsten Erweiterungen für das Betriebssystem CP/M - dynamisch, flexibel und überaus leistungsfähig. Dies sind sehr ungewöhnliche Eigenschaften für ein Microcomputer-Betriebssystem. Das Z-System ist für viele Anwender einer der Hauptgründe, noch immer mit ihrem 8-Bit- Rechner zu arbeiten. Hier erfahren Sie, warum!

 

Genaugenommen ist die Überschrift nicht korrekt, denn in einem vollständigen Z-System sind alle Segmente des CP/M (BIOS, BDOS, CCP) durch leistungsfähigere, auf Z80-Code basierende Komponenten ersetzt worden. Hier geht es aber ausschließlich um den ZCPR (Z80 Command Processor Replacement), der als Ersatz für den Kommandoprozessor fungiert.

Ursprünglich sollte der durch den Einsatz von kompakterem Z80-Code gewonnene Platz lediglich dazu dienen, neue Kommandos oder verbesserte Funktionen im CCP unterzubringen. Im Laufe der Jahre wurde der ZCPR jedoch mehrfach (und von unterschiedlichen Personen) zu einer vollständigen Betriebssystemumgebung weiterentwickelt, die ihren vorläufigen Höhepunkt mit der Version 3.4 von Jay Sage erreichte.

Während die ersten Implementationen nur echten Systemkennern und Assemblercracks vorbehalten waren, kamen mit NZ-COM (für CP/M 2.2) und Z3PLUS (für CP/M Plus) zwei kommerzielle Produkte heraus, die das Z-System auf nahezu jedem CP/M Computer automatisch installierten. Der Arbeitsaufwand für den Anwender reduzierte sich dabei auf ein absolutes Minimum. Die Zeit des nächtelangen Code-Hackens zur Anpassung der Quellen an das BIOS (oder umgekehrt) war damit vorbei.

Diese einfache Handhabung verhalf dem Z-System auf breiter Front zum Durchbruch und ließ die Welle der Begeisterung sogar bis nach Deutschland überschwappen. Dort erfaßte sie insbesondere Helmut Jungkunz. Er übersetzte die Handbücher ins Deutsche, übernahm den Vertrieb und organisierte Verteilerstrukturen. Letztgenannte sind angesichts der umfangreichen Archive an Z-System Software auch unbedingt notwendig.

 

Z-SYSTEM / NZ-COM / Z3PLUS

Diese Begriffe sind vielleicht schon manchem aufgefallen. Insbesondere jenen, die des öfteren mit amerikanischer CP/M-Software zu tun haben. Aber auch im Zusammenhang mit dem KC-Fragebogen ist die Frage aufgetaucht, was das sein soll.

Es handelt sich dabei um einen Ersatz des CCP vom CP/M bzw. auch des BDOS. Die Fähigkeiten des Betriebssystems werden dadurch erweitert. Der Begriff "Z-System" ist sozusagen der Oberbegriff, mit dem (unter anderem) folgende Erweiterungen gemeint sind:

• Zugriff auf alle Userbereiche problemlos möglich
• Suchpfad für Dateien
• standardisierte Terminalschnittstelle
• benannte Verzeichnisse
• selbstdefinierte Makros und Aliase für komplizierte Kommandos
• Größe des Z-Systems kann selbst festgelegt werden

Man kann an diesen Möglichkeiten erkennen, daß das Z-System wesentlich komfortabler ist, als das "normale" CP/M. Weil es nur auf das alte System aufgesetzt wird, bleibt es voll kompatibel. Doch wie sieht denn nun die Arbeit mit dem Z-System aus?

Grundsätzlich ist Laufwerk A:, Userbereich 0 das Bezugslaufwerk - für KC85-User besonders günstig, da dieses Laufwerk immer durch die besonders schnelle RAM-Floppy gebildet wird. Alle Dateien, die sich dort befinden werden vom System automatisch von allen anderen Laufwerken und Nutzerbereichen aus gefunden. Ist dieses Verfahren nicht erwünscht, läßt es sich durch folgende Kommandozeile leicht ändern:

A0:>PATH $$: C0: C1: DBASE: A0:

In diesem Kommando tauchen gleich drei Neuheiten auf:

1. Beim Z-System wird immer Laufwerk und Userbereich im Prompt angezeigt, auch bei User 0.
   
   
2. Die Angabe "$$" stellt auch eine Laufwerks- und Userangabe dar, nämlich die aktuellen Werte. Ist man also in B5:, wird zunächst B5: durchsucht; bei A7: logischerweise A7: usw.
   
   
3. Was soll das "DBASE:" dazwischen? Naja, das war früher mal E3: und wurde umgetauft, weil dort alle dBase-Dateien zu finden sind. Dieses "DBASE" erscheint im Prompt, wenn man sich dort befindet.
   
   

Nachdem wir nun den Suchpfad für die Dateien festgelegt haben, wäre es an der Zeit, eines der vielen Z-System Tools auszuprobieren. Beim Aufruf von ZFILER, VLU oder ZPATCH sieht man gleich, wie effektiv diese Programme von den Möglichkeiten der Blockgrafik Gebrauch machen.

Mit VLU ist es möglich, Bibliotheken (*.LBR) anzusehen, Dateien daraus zu extrahieren oder selbst eine Bibliothek zusammenzustellen. Gleich nebenbei kann man die Dateien dazu Crunchen.

ZFILER ist eine sogenannte Shell (zu deutsch: Schale, Hülle). Derartige Programme tragen sich in einem bestimmten Speicherbereich ein (dem Shell-Stack). Innerhalb einer Shell können andere Programme aufgerufen werden. Sind diese beendet, wird automatisch die letzte Shell wieder aktiviert. ZFILER bietet z. B. alle Dateien des aktuellen Laufwerk-/Nutzerbereiches auf dem Bildschirm an. Man kann die Dateien kopieren, umbenennen, löschen usw. oder auch ein (selbstgeschriebenes) Makro darauf anwenden. Damit sind komplexe Aufgaben immer wieder mit nur einem Tastendruck ausführbar! Eine weitere Shell mit einem ganz anderen Konzept wäre z. B. HSH. HSH steht für History SHell. In einer speziellen Datei werden die letzten Kommandozeilen abgepeichert, die dann mittels Cursortasten zurückgeholt und editiert werden können (ähnlich DOSKEY unter MS-DOS).

Viele Z-System-Programme brauchen den Vergleich mit MS-DOS-Programmen nicht scheuen. Spätestens das Z-System ist der Beweis, daß man auch mit 8 Bit fabelhafte Software produzieren kann.

Hat man dann genug vom Z-System, gibt man einfach OFF ein, und schon befindet man sich im guten alten CP/M (MicroDOS/MLDOS). Allerdings empfindet man es dann erfahrungsgemäß eher alt als gut. Man gewöhnt sich sehr schnell an Komfort!

Alles schön und gut werden jetzt viele denken, aber wo bekommt man das Z-System? Was gehört alles dazu?

Vor einigen Jahren war es zur Installation eines Z-Systems notwendig, mehrere kByte Assemblerquelltext an das eigene CP/M-System anzupassen. Inzwischen gibt es jedoch die automatischen Z-Systeme bei:

Helmut Jungkunz, http://www.znode51.de/

 

Bevor man sich mit dem Z-System beschäftigen kann, muß man natürlich wissen, welches System man braucht.

• NZ-COM für CP/M 2.2 (auch unser MicroDOS 2.6 oder MLDOS)
  
  
• Z3PLUS für CP/M 3 (bekannt als CP/M PLUS)

 

Inzwischen wurden beide Varianten vom Autor freigegeben und können hier:

http://www.gaby.de

nach Eingabe von wenigen zusätzlichen Informationen kostenlos heruntergeladen werden.

Nach so vielen Lobeshymnen macht sich bestimmt Skepsis breit. Ich bekomme keine Prozente, aber ich arbeite selbst mit dem Z-System und würde mich mit Händen und Füßen wehren, wenn ich es wieder hergeben sollte.

An dieser Stelle möchte ich noch ganz besonders Mario Leubner danken, der solch wunderbare Programme wie ZAS schreibt. Damit wird unser KC speziell unter dem Z-System aufgewertet. Die IBM-Blockgrafik und die schnellen Invers-Routinen sind ein wahrer Augenschmaus bei Z-System-Programmen, die ausgiebig davon Gebrauch machen.

 

Die Zukunft beginnt mit "Z" unter MLDOS

Wer meine Vorliebe für das Z-System kennt und auf unserem '96er Clubtreffen war, ahnt sicherlich schon, was ihn hier erwartet. Doch es soll nicht nur um den ZCPR gehen, sondern auch um das CP/M-kompatible System für den KC85. Auf den Treffen konnte uns Mario Leubner schon einiges zeigen. Hier soll gezeigt werden, was "dahinter" steckt.

In den KC-NEWS Artikeln zu MLDOS hat Mario bereits geschildert, welche unschätzbare Mühe er sich mit der Entwicklung gemacht hat. Dank Helmut Jungkunz sind wir auf ein wunderbares Betriebssystem namens ZSDOS gestoßen. Mario ist die Anpassung des ZSDOS für unser D004 gelungen, wobei ein nagelneues (und vor allem CP/M-konformes) System herauskam - MLDOS.

Bemerkenswert ist dabei die Verwendung von rein Z80-codierten Segmenten. Normale CP/M-Systeme sind nämlich für i8080-Prozessoren geschrieben. Der Z80-Befehlssatz ist zwar voll kompatibel, wird aber nicht ausgenutzt. Programme für Z80-Rechner sind daher oftmals kleiner und trotzdem leistungsfähiger als i8080-Programme. Bevor wir uns jedoch vollends ins Vergnügen stürzen, sollten zunächst die verwendeten Begriffe erläutert werden.

 

Begriffe

Die Abkürzung ZCPR bedeutet "Z80 Command Processor Replacement" - zu deutsch: Z80-Ersatz des Kommandoprozessors. Was voerst recht nüchtern klingt, enthält vielfältige und fantastische Möglichkeiten. Der Kommandoprozessor stellt die Schnittstelle des Systems zum Anwender dar. Jede Veränderung dieses Segments hat also direkte Auswirkungen auf das Erscheinungsbild des Systems. Die inzwischen aktuelle Version 3.4 ist so komfortabel und flexibel, daß individuelle Anpassungen in Sekundenschnelle vorgenommen werden können und dabei kaum noch Wünsche offen bleiben.

ZSDOS steht für "Z-System Disk Operating System" - Diskettenbetriebssystem für Z-Systeme. Das ZSDOS ist eines der wenigen kommerziellen Ersatzsysteme für das BDOS des CP/M 2.2 und wahrscheinlich auch das beste. Es arbeitet "eine Schicht tiefer" im CP/M-System und stellt die Schnittstelle für alle Anwendungsprogramme dar. Veränderungen des BDOS-Segmentes offenbaren sich dem Nutzer nur spärlich, sind jedoch gravierend, wenn es um die Stabilität und die Geschwindigkeit des Systems geht. In ZSDOS können viele Einstellungen vorgenommen werden, die das Verhalten des Systems bestimmen.

Ein Z-System ist sozusagen das beste, was einem CP/M-Anwender passieren kann. Mit diesem Begriff werden CP/M-Systeme bezeichnet, deren Segmente vollständig in Z80 codiert sind.

Das Betriebssystem MLDOS für das D004 ist ein derartiges System, als BDOS-Ersatz wird ZSDOS/ZDDOS verwendet und mit NZ-COM für CP/M 2.2 bekommt man einen ZCPR - daher beginnt für uns die Zukunft mit einem "Z".

 

Die Entwicklung des ZSDOS war eine Gemeinschaftsarbeit von Harold F. Bower, Cameron W. Cotrill und Carson Wilson. Anhand der Namen kann man schon erkennen: made in U.S.A. Während der Programmierung sind die unterschiedlichsten Anregungen und Vorschläge in die Arbeit eingeflossen. Das ZSDOS ist einer der mächtigsten (das mächtigste?) und flexibelsten BDOS-Ersatzsysteme, die je für das CP/M-System geschrieben wurden. Es ist unmöglich, alle Funktionen und Verbesserungen in einem Artikel aufzuzählen. Die wichtigsten möchte ich jedoch vorstellen.

Alle Fehlermeldungen des BDOS werden in (englischem) Klartext ausgegeben. Anstelle unverständlicher Zahlen für Sektoren und Spuren erscheinen nun Funktionsnummer und Dateiname, bei denen der Fehler aufgetreten ist. Darüber hinaus kann (wie bei MicroDOS, jedoch fehlerfrei) die Fehlerbehandlung vom Programm übernommen werden. In diesem Modus werden keine Fehlermeldungen auf den Bildschirm ausgegeben.

ZSDOS unterstützt nicht nur die beiden bekannten Dateiattribute "schreibgeschützt" (R/O) und "System", sondern auch sechs weitere. Unter anderem auch das Archivbit, mit dessen Hilfe Sicherheitskopien schneller und unkomplizierter erstellt werden können.

Die zulässige Größe für Laufwerke beträgt 1 Gigabyte (1.084.576 kByte). Dateien können bis zu 32 Megabyte (32.768 kByte) groß sein und im wahlfreien Zugriff bis zu 262.144 logische Records umfassen. Desweiteren gibt es die Möglichkeit, Laufwerke als "fest" zu definieren. Das Verzeichnis dieser Laufwerke wird dann nicht nach jedem Warmstart erneut eingelesen, was die Arbeit wesentlich beschleunigt.

Zu den interessantesten Eigenschaften gehören auf jeden Fall die unterschiedlichen Zugriffsarten. Normalerweise werden von CP/M nur Dateien gefunden, die sich im eingeloggten Verzeichnis befinden. Alle Dateien, die auf einem anderen Laufwerk und/oder in einem anderen Nutzerbereich vorliegen, kann CP/M nicht finden und demzufolge auch nicht laden. Unter ZSDOS gibt es diverse Möglichkeiten, diese Beschränkung zu überwinden - öffentliche Dateien und den DOS-Pfad. Beide Zugriffsarten können sogar kombiniert werden. Erfahrene Anwender können dadurch nahezu jede Datei von allen Verzeichnissen erreichen.

Beim Zugriff auf andere Nutzerbereiche wird die Nummer des Bereichs im FCB gespeichert und automatisch vom System verwaltet. Ein Programm kann nun auf die Datei im anderen Nutzerbereich zugreifen, ohne vorher über die entsprechende BDOS-Funktion den Nutzerbereich zu setzen.

Mit der Echtzeituhr des GIDE-Interfaces steht unter MLDOS auch eine "richtige" Uhr zur Verfügung. Von ZSDOS bzw. ZDDOS werden Datumsstempel für Dateien unterstützt. Zu jeder Datei können der Zeitpunkt der Erstellung, der Änderung und des letzten Zugriffs gespeichert werden. Dadurch wird die Verwaltung wesentlich transparenter, insbesondere bei mehreren Versionen einer Datei.

Außerdem lassen sich viele Eigenschaften von ZSDOS während der Laufzeit über ein spezielles Utility einstellen. Somit kann das System für spezielle Anwendungen angepaßt werden. Nach Abarbeitung kann man einfach wieder die alten Parameter einstellen.

 

ZCPR

Der "ZCPR" ist ein Ersatz für das CCP Segment eines CP/M Systems. Ursprünglich wurde der ZCPR von verschiedenen Interessengemeinschaften entwickelt und erfuhr mit der Version 3.0 Richard Conn eine grundlegende Überarbeitung. Den (vorläufigen) Endstand schuf Jay Sage mit den Versionen 3.3 bzw. 3.4, die inzwischen den Standard darstellen.

Während der Anwender von den Veränderungen des BDOS-Segmentes zwar profitiert, diese jedoch kaum oder gar nicht bemerkt, ist beim CCP oftmals schon die kleinste Veränderung sofort zu spüren. Die aktuellen Versionen des ZCPR benügen sich jedoch nicht mit Kleinigkeiten - im Gegenteil: Das gesamte Anwenderinterface wird generalüberholt! Ein ZCPR kann aus etlichen Elementen bestehen, von denen hier einige vorgestellt werden.

 

Kommando Pakete

Der Kommando Prozessor (CPR) stellt dem Anwender nur drei Befehle zur Verfügung. Es kann eine Datei bzw. ein Programm ab 0100h in den Speicher geladen werden, das Programm ausgeführt werden und auf eine bestimmte Adresse gesprungen werden. Auf den ersten Blick recht mager! Doch dies ist nur die "Grundausstattung".

Jeder Anwender hat seine eigene Vorstellungen, welche Befehle für ihn unbedingt notwendig sind und auf welche er verzichten kann. Dank ZCPR kann man diese Vorstellungen verwirklichen. Dazu gibt es zwei weitere Kommando Pakete. Zum einen das "Resident Command Package" (RCP) mit residenten Befehlen und zum anderen das "Flow Command Package" (FCP) mit Befehlen zur Ablaufsteuerung. Im RCP können sehr einfache Befehle, wie z. B. POKE, ERA oder REN enthalten sein, aber auch sehr mächtige Kommandozeileneditoren. Die Größe des RCP ist dementsprechend variabel - von 0,5 bis 2,5 kByte ist so ziemlich alles drin.

Bis zu dieser Stelle dürfte einem normalen CP/M Anwender noch alles sehr vertraut vorkommen. Doch nun geht es mit den Neuerungen richtig los. Das zweite Kommando Paket - FCP - erlaubt in gewisser Weise die Programmierung in der Kommandozeile. Mit Befehlen wie IF, ELSE, AND, OR usw. können nachfolgende Anweisungen vom Erfolg oder Mißerfolg des vorherigen Kommandos abhängig gemacht werden. So kann z. B. überprüft werden, ob die angegebene Datei vorhanden ist oder einen bestimmten Dateityp hat. Dementsprechend kann das "richtige" Programm aufgerufen oder eine Fehlermeldung am Bildschirm ausgegeben werden. Mit diesen Befehlen bieten sich bei der Verwendung in Kommandoscripts und Aliasen ungeahnte Möglichkeiten.

 

Kommandosuchpfad

Konnte weder im CPR noch im FCP oder RCP das eingegebene Kommando gefunden werden, dann versucht der Kommandoprozessor (wie in jedem CP/M System) eine entsprechende COM- oder SUB-Datei zu finden. Die Suche ist aber nicht nur auf das aktuelle Laufwerk und den aktuellen Nutzerbereich beschränkt. Es kann ein Suchpfad mit maximal 5 Elementen definiert werden. Ein Element steht stellvertretend für eine Kombination aus Laufwerk und Nutzerbereich. Im Gegensatz zum ZSDOS-Pfad steht der ZCPR-Pfad nur während der Kommandosuche zur Verfügung. Programme wie WordStar oder dBase können ihre Overlays nicht entlang des ZCPR-Pfades finden! (Dazu kann nur der ZSDOS-Pfad verwendet werden.)

 

Erweiterter Kommandoprozessor

Wurde entlang des Pfades auch kein Programm entsprechend dem eingegebenen Befehl gefunden, kann die gesamte Befehlszeile in einem ZCPR-System an einen erweiterten Kommandoprozessor (ECP) übergeben werden. Dabei handelt es sich um ein spezielles Programm, das Kommandoscripts mit dem Namen des Befehls sucht und ausführt oder eine entsprechende COM-Datei aus einer Bibliothek extrahiert und ausführt. Der Name des ECP kann vom Anwender frei definiert werden. Nach dem Motto "Wer nicht will, der hat schon" kann auch ganz auf den ECP verzichtet werden.

 

Error Handler

Wird das Kommando nirgends gefunden (CPR, FCP, RCP, Pfad, ECP), müßte eigentlich eine Fehlermeldung erscheinen. Meistens hat man sich nur vertippt und dürfte nun die gesamte Zeile erneut eingeben. Hier kann ein optionaler Error Handler weiterhelfen. Die fehlerhafte Befehlszeile wird am Bildschirm wiedergegeben und kann bequem editiert werden. Anschließend wird die korrigierte Zeile wieder dem Kommandoprozessor übergeben.

 

Mehrfachkommandozeile

Ein normales CP/M System erlaubt nur die Eingabe eines Kommandos je Zeile. Mehrere Kommandos kann man über SUB-Dateien abarbeiten lassen. Allerdings muß man immer einen Editor zu Hilfe nehmen, wenn die SUB-Datei geändert werden soll. In einem ZCPR-System können beliebig viele Kommandos eingegeben werden, vorausgesetzt es wird die zur Verfügung stehende Anzahl Zeichen (über 200) nicht überschritten. Auf den ersten Blick ist kein Nutzen erkennbar, muß man doch weiterhin Kommando für Kommando eintippen - egal, ob nun in eine oder mehrere Zeilen.

Viele Z-System-Programme machen jedoch Gebrauch von Mehrfachkommandozeilen. Darüber hinaus wird die Schaffung eines völlig neuen Kommandotyps, Alias genannt, ermöglicht. Ein Alias ist ein einzelner Befehl, der stellvertretend für eine längere Kommandozeile oder mehrere Befehle steht. Ähnlich den SUB-Dateien können komplexe Aufgaben mit nur einem Befehl abgearbeitet werden. Allerdings können Aliase viel flexibler und mächtiger gestaltet werden als SUB-Dateien.

 

Terminal Capabilities Puffer

Terminals gibt es wie Sand am Meer. Jeder Hersteller hat seine Vorstellungen des "Standards" für Steuersequenzen verwirklicht. Viele Programme (wie z. B. WordStar) müssen vor der ersten Benutzung für ein spezielles Terminal installiert werden. Wer mit verschiedenen Computern arbeitet, muß in den meisten Fällen für jeden Computer eine entsprechende Version haben, sonst läuft nix.

Diesen Nachteil von CP/M Rechnern hebt der Terminal Capabilities Puffer (TCAP) auf. Es handelt sich um einen Bereich, in dem die Steuersequenzen des Terminals in einer definierten Datenstruktur hinterlegt sind. Z-System-Programme können auf diese Daten zugreifen und die benötigten Steuersequenzen "heraussuchen". Dadurch werden die Programme universell und laufen ohne Änderung auf jedem Computer mit vorhandenem TCAP.

 

Wheel Byte

Der Name dieses Bytes wurde von "The Big Wheel" (sinngemäß: großes Steuerrad) abgeleitet. Dabei handelt es sich um ein Kontrollelement des Systems für Sicherheitsfunktionen. Solange der in diesem Byte gespeicherte Wert gleich Null (00H) ist, können Dateien nicht gelöscht, umbenannt oder überschrieben werden. Diese Funktion lernt man spätestens dann schätzen, wenn sich mal ein "Systemfremder" über die Adreßdatei, den letzten Programmierversuch oder die neueste Beilagen-Diskette hermacht.

 

Benannte Verzeichnisse

Wer eine Festplatte oder eine große RAM-Disk sein eigen nennt, kennt sicherlich das Problem: Wo ist welche Datei gespeichert? War es C3, B7 oder D9? Bei 16 (oder 31) Nutzerbereichen wird man schneller vom Chaos beherrscht, als daß man es selbst beherrscht. Könnte man doch dem Verzeichnis mit allen dBase-Dateien den Namen "DBASE" geben... Mit ZCPR kann man! Der Name wird nicht nur an der Eingabeaufforderung angezeigt (z. B. "C3: DBASE>"), sondern auch von den meisten Z-System-Programmen unterstützt. Befehle, wie

DIR DBASE: oder CRUNCH WORK:*.* PACKED:

können genauso verwendet werden wie

DIR C3: bzw. CRUNCH A0:*.* D14:

Allerdings sind sie weniger kryptisch und für den Benutzer leichter zu merken. Benannte Verzeichnisse machen sich schnell "bezahlt", denn Ordnung ist bekanntlich das halbe Leben.

 

Shells

Hat ein Programm seine Arbeit erledigt, übernimmt das Betriebssystem wieder die Kontrolle. Unter normalen CP/M Systemen heißt das: Laden des CCP (falls er überschrieben wurde) und Anzeige des Systempromptes. Für Z-Systeme gibt es spezielle Programme, die sich wie eine Schale (Shell) um das System legen. Wird ein solches Programm aktiviert, dann wird anstelle des CCP die Shell mit der höchsten Priorität geladen und an sie die Kontrolle übergeben.

Auf dem Shell Stack stehen 4 Einträge zur Verfügung. Es können also maximal 4 Shells nacheinander gestartet werden. Jeweils eine Shell (die zuletzt aufgerufene) kann nur aktiv sein. Wird eine Shell beendet, wird die "darunterliegende" aktiv - sie sind sozusagen verschachtelt.

Wie sieht eigentlich eine Shell aus? Die Erscheinungsform kann sehr verschieden sein. So gibt es einfache History-Shells, deren Aktivität nur am Systemprompt zu erkennen ist. Sie zeichnen die eingegebenen Kommandozeilen auf, die später einfach per Tastendruck "durchgeblättert" und bequem editiert werden können. Andere Shells verändern das Erscheinungsbild vollkommen. ZFILER stellt das Directory eines Verzeichnisses auf dem Bildschirm dar. Mit einem Cursor können Dateien angewählt werden, um sie anschließend zu kopieren, zu löschen, Makros auf sie anzuwenden und, und, und ...

 

Zusammenarbeit von ZSDOS und ZCPR

Eigentlich würde schon ein Satz genügen: Die beiden arbeiten perfekt zusammen! Doch ein paar Einzelheiten sollen hier genannt werden:

Wie man sich denken kann, stellt der ZCPR gewisse Mindestanforderungen an das BDOS. Ein standardmäßiges BDOS hält da nicht mehr mit. Deshalb wird z. B. NZ-COM mit ZRDOS ausgeliefert. Dieses System enthält einige Erweiterungen gegenüber dem normalen CP/M BDOS. Alle Funktionen von ZRDOS werden von ZSDOS unterstützt, so daß es als Ersatz dafür eingesetzt werden kann. Außerdem bietet es etlichte neue Funktionen.

Dazu gehört z. B. das schnelle Wiedereinloggen "fester" Disketten. Nach einem Warmstart wird das Directory von Festplatten und RAM-Disks nicht erneut gelesen, was bei großen Verzeichnissen eine ganze Weile dauern kann. Dadurch wird die Arbeit mit derartigen Laufwerken erheblich beschleunigt.

Von ZCPR wird im Byte 13 des Dateisteuerblocks (S1 Byte) die Nummer des Nutzerbereichs abgelegt. Bisher wurde dieses Byte von keinem anderen BDOS benutzt. ZSDOS legt dort beim Öffnen einer Datei ebenfalls die Nummer des Nutzerbereichs ab. Anschließende Lese- und Schreiboperationen können durchgeführt werden, ohne daß zuvor die BDOS Funktion zum Setzen des Nutzerbereichs aufgerufen werden muß.

Unter ZSDOS hat man die Möglichkeit, einen von vier Fehlermodi zu wählen. MicroDOS bot zwar mit einem Funktionsaufruf auch schon die Unterdrückung der Fehlermeldungen am Bildschirm und die Übergabe von erweiterten Fehlercodes an das rufende Programm, doch die ZSDOS Funktion hält auch was sie verspricht. (Was man von MicroDOS leider nicht behaupten kann.)

Durch die geschickte Kombination des internen ZSDOS Pfades und des ZCPR Kommandosuchpfades kann man das System so einrichten, daß nahezu jede Datei bzw. jedes Programm von überall gefunden und gestartet wird.

Sicherlich fühlen sich jetzt einige überfordert: die vielen Abkürzungen, die vielen Funktionen ... und auch noch selbst einrichten?! Es verlangt aber niemand, daß man alles auf Anhieb versteht oder gar auswendig lernt. Vielmehr sollte man sich mit den einzelnen Komponenten vertraut machen und erst dann entscheiden, ob sie für den eigenen Gebrauch sinnvoll sind. So nach und nach ergibt es sich dann, daß man "sein" System zusammenstellt und der eigenen Arbeitsweise anpaßt. Und genau für diesen Zweck wurde ZCPR entwickelt. Das Betriebssystem bietet keine starren Vorgaben mehr, sondern eine Plattform, auf der Komponenten nach den eigenen Wünschen installiert werden.

Als erstes muß man sich beim Erstellen eines MLDOS-Systems zwischen ZDDOS und ZSDOS entscheiden. Für die Arbeit ohne NZ-COM bzw. unter CAOS empfehle ich ZDDOS. Zwar muß man dann auf den DOS-internen Suchpfad verzichten, doch dafür sind bereits die DateStamper-Funktionen integriert. Somit werden auch die CAOS-Aktivitäten mit Datum und Uhrzeit protokolliert. Übrigens könnte man unter CAOS den Suchpfad sowieso nicht beeinflussen.

Kann oder will man unter keinen Umständen auf die Vorzüge von ZSDOS verzichten und trotzdem die DateStamper-Funktionalität nutzen, gibt es auch dafür eine Lösung. Dazu muß im BIOS-Bereich ein ausreichend großer Raum für die entsprechenden Treiber geschaffen werden. Anwendern von NZ-COM ist ZSDOS auf alle Fälle zu empfehlen, da hiermit größtmögliche Funktionsvielfalt und Flexibilität erreicht wird. Durch die geschickte Kombination von DOS-internem Suchpfad und ZCPR-Kommandosuchpfad kann man alle Programme von nahezu allen Laufwerken und Nutzerbereichen benutzen. Treiber für Datumsstempel können in geschützten Bereichen untergebracht werden und beanspruchen nur wenig zusätzlichen Arbeitsspeicher.

Die Einrichtung der ZCPR-Umgebung erfordert ein wenig Überlegung. Während der Arbeit unter einer bestimmten Konfiguration stellt sich dann heraus, ob sie den eigenen Gewohnheiten entspricht oder geändert werden müßte. Spätestens dann lernt man NZ-COM zu schätzen, denn das Betriebssystem ist keine starre Einrichtung mehr, wo der Anwender den vom Programmierer vorgegebenen Beschränkungen ausgeliefert ist. Vielmehr kann man es den eigenen Bedürfnissen und Vorlieben anpassen.

Jeder der Bestandteile einer ZCPR-Umgebung bringt eine gewisse Steigerung des Komforts mit sich. Es soll aber nicht unerwähnt bleiben, daß dafür auch Arbeitsspeicher gebraucht wird, der den kostbaren TPA schmälert. Durch die vom verfügbaren Arbeitsspeicher vorgegebenen Einschränkungen muß man seinen eigenen Kompromiß zwischen den Ansprüchen an den TPA und an den Komfort finden.

 

Einrichtung der ZCPR-Umgebung

Bevor ich mich diesem Thema eingehender widme, möchte ich darauf hinweisen, daß die hier beschriebene Vorgehensweise auf eigenen Erfahrungen beruht und nur eine Empfehlung darstellt. Selbstverständlich hat jeder die Freiheit, nach seinen Vorstellungen und Wünschen zu verfahren! Auf alle Fälle sollte der Aufforderung im NZ-COM Handbuch Folge geleistet und eine Kopie der Orginaldiskette angefertigt werden. Sämtliche Manipulationen werden nur an der Kopie durchgeführt!

Bereits bei der Definition der Umgebung (System-Deskriptor) werden Entscheidungen getroffen, die das Erscheinungsbild und die Funktionalität des späteren System festlegen. Ganz wichtig: Der System-Deskriptor muß unter der Systemkonfiguration erstellt werden, mit der später NZ-COM laufen soll, da die enthaltenen Informationen adreßabhängig sind.

Auf einzelne Elemente kann man verzichten (z. B. ein I/O-Paket), bei anderen zwischen verschieden großen Versionen wählen (z. B. RCP - residente Befehle) oder zusätzlichen Platz im hohen Speicher (UMA) für die DateStamper-Routinen reservieren. Dies alles sollte im Hinblick auf den verbleibenden TPA geschehen.

Logischerweise bieten größere Pakete auch mehr Funktionen, doch oftmals können auch kleine Utilities die Aufgaben übernehmen. Wer mit dem von MicroDOS gewohnten Befehlsumfang arbeiten möchte, kann die von Mario Leubner angepaßte Version des RCP10H benutzen. Der Dateibezeichnung ist zu entnehmen, daß sie im Speicher 10 Records (1 Record = 128 Bytes) belegt. Legt man Wert auf absolute Funktionsvielfalt, kann ein mehr als 20 Records großer RCP verwendet werden. Die untere Grenze stellt ein nur 4 Records großes Paket dar.

Analog gilt dies auch für den FCP. Weil die Programmteile bereits im Speicher stehen und nicht erst vom Datenträger geladen werden müssen, werden interne Kommandos schneller ausgeführt. Kommen jedoch Bedingungen (IF, ELSE ...) kaum zur Anwendung, dann kann man eine Minimalvariante des FCPs benutzen oder ganz darauf verzichten. Alle Funktionen des FCPs können auch von IF.COM ausgeführt werden. (Erfahrungsgemäß entdeckt man den Nutzen von bedingten Kommandoausführungen viel zu spät!)

Die Anzahl der benannten Verzeichnisse ist reine Geschmackssache. Für die einen sind 7 schon zu viel und für die anderen 21 noch zu wenig. Doch Achtung - alles hat seinen (Speicher-)Preis! Auf den ersten Blick scheinen die Namen nur schmückendes Beiwerk der Eingabeaufforderung im jeweiligen Verzeichnis zu sein. Weiter unten in diesem Artikel werde ich jedoch Beispiele für die Benutzung in Aliasen zeigen.

Eine Komponente sollte jedoch unverändert bleiben: der Shell Stack. Der Platz für vier Einträge dürfte allen Ansprüchen genügen. Ein Verzicht ist nicht zu empfehlen, da überaus nützliche Tools wie ZFILER oder LSH zur "Gattung" der Shells gehören und ohne den Shell Stack ihren Dienst verweigern.

 

Start des Systems

Bevor das System gestartet werden kann, müssen noch die benötigten Bestandteile in der Bibliothek NZCOM.LBR abgelegt werden. Verwendet man die Namen der bereits vorhandenen Module (mit "NZ" beginnend), so werden sie beim Start automatisch geladen. Dazu entpackt man am besten die gesamte Bibliothek und kopiert die benötigten Komponenten in dasselbe Verzeichnis. Dann wird die Originaldatei gelöscht und die neue umbenannt, so daß sie jetzt den Namen der alten hat.

Kleines Beispiel gefällig? Das standardmäßige DOS-Segment namens NZDOS.ZRL wird gelöscht. Anschließend ZSDOS.ZRL (oder ZDDOS.ZRL) in NZDOS.ZRL umbenannt. Ebenso wird mit RCP, FCP usw. verfahren. Ist alles erledigt, werden die Dateien wieder in die Bibliothek NZCOM.LBR gepackt. Ab sofort startet das Z-System automatisch mit dem neuen BDOS-Segment und den definierten Bestandteilen.

Das wird auch gleich ausprobiert. Während des Startvorgangs kann man am Bildschirm verfolgen, wie NZ-COM die Systemumgebung entsprechend den Festlegungen zusammensetzt, linkt und startet. Jetzt ist das Z-System aktiv und es kann losgehen. Um es jedoch optimal an die eigenen Bedürfnisse anzupassen, ist noch ein wenig einzurichten...

Zuallererst sollte die richtige Datei für die Terminalansteuerung installiert werden. Der im Handbuch beschriebene Weg über den Startalias ist etwas mühselig. Eleganter geht es, wenn man die entsprechende Datei in NZCOM.Z3T umbenennt und ebenfalls in die Bibliothek NZCOM.LBR packt. Dann wird sie beim Start automatisch geladen. Für optimale optische Ergebnisse sollte man INVERS.COM (KC85/3) oder ZAS v1.x (nur für KC85/4 und höher) mit der passenden Z3T-Datei verwenden, die mit MLDOS geliefert werden.

 

Anpassung des Systems

So, nachdem das System jetzt läuft, geht es ans Tuning. Dazu werden wir unseren KC nicht tieferlegen und mit einem Heckspoiler versehen, sondern ein paar Systemeigenschaften beeinflussen, die die Arbeit noch beschleunigen.

Zunächst geht's an die Pfade. Dazu sollte man sich den Unterschied zwischen dem DOS-internen Suchpfad und dem Kommandosuchpfad von NZ-COM verdeutlichen. Beide können mit ZPATH eingestellt werden, unterscheiden sich aber in der Funktionsweise erheblich. Um nicht nach jedem Start die Pfade neu einstellen zu müssen, sollte man die ZPATH-Kommandos im Startalias speichern. Erfahrene User können den Kommandosuchpfad in NZ-COM patchen; wie das geht, steht im Handbuch.

Das letzte Pfadelement im Kommandosuchpfad nimmt eine Sonderstellung ein. Es bezeichnet das sogenannte "Root-Verzeichnis". Einige Programme und NZ-COM selbst legen dort spezielle Dateien ab. Deshalb sollte dieses Verzeichnis mit Bedacht gewählt werden. Als äußerst praktisch hat es sich erwiesen, A15: als Root-Verzeichnis zu wählen, während auf der Festplatte (in C0: oder C15:) die Utilities gespeichert sind. Die Einstellung für den Kommandosuchpfad könnte also lauten:

A0 C0 C15 $$ A15

Kommen wir nun zu einem der mächtigsten Werkzeuge eines Z-Systems. Der Alias. Was man darunter zu verstehen hat, ist im NZ-COM Handbuch beschrieben. Mit der von Helmut Jungkunz ausgelieferten Version bekommt man auch schon eine Reihe von Aliasen in der Datei ALIAS.CMD. Diese können selbstverständlich angepaßt oder um eigene Schöpfungen ergänzt werden. Hier sind benannte Verzeichnisse besonders nützlich.

Folgender Alias sorgt bei mir für den richtigen Durchblick:

HILFE command:help helpfile:$1.h?p

Sobald ich das Kommando HILFE, gefolgt vom Dateinamen einer HLP-Datei eingebe, wird im Verzeichnis "COMMAND:" das Programm HELP.COM aufgerufen. Diesem wird der Dateiname übergeben, jedoch die Verzeichnisangabe "HELPFILE:" vorangestellt. Daß sich hinter dem Verzeichnis "COMMAND" eigentlich C15: und hinter "HELPFILE" C14: verbirgt, ist für alle Beteiligten - Bediener und Programm - völlig uninteressant. Der Kommandoprozessor setzt die Befehlszeile in ein gültiges Format um.

Und was ist nun der Vorteil daran? Zum einen brauche ich mir keine Gedanken mehr darum zu machen, in welchem Verzeichnis sich HELP.COM befindet. Nun ja, das bräuchte ich bei entsprechender Pfaddefinition auch nicht. Zum anderen muß ich mich nicht darum kümmern, daß HELP.COM die gewünschte Helpdatei findet. Das könnte man sich aber zur Not auch noch merken. Wie elegant diese Lösung ist, merkt man aber, wenn z. B. das Standardverzeichnis für die Helpdateien gewechselt wird.

Angenommen, es soll nicht mehr C14: sondern D3: sein. Bei einer direkten Verzeichnisangabe müßten alle Verweise in allen Aliasen von C14: auf D3: geändert werden. Dank der benannten Verzeichnisse genügt aber nur eine einzige Änderung - nämlich in der Definition für den Verzeichnisnamen. Ähnliche Lösungen hat sich auch Mario Leubner für diverse CAOS-Programme eingerichtet:

BASICODE caos:;:dep3 basicode.uuu
DEP e0:dep3 $td1$tu1:initial.uuu
UNIPIC=UP unipic:;:dep3 initial.uuu
WORDPRO,6=WP6 wp6:;:dep3 initial.uuu

Dies sind längst nicht alle Möglichkeiten, die das Z-System bietet. Ich hoffe, wenigstens bei einigen das Interesse geweckt zu haben.

Weitere Informationen und Artikel zu MLDOS und Z-System auf KC85 Systemen findet man auf der Homepage des KC-Clubs.

Das deutsche Handbuch zu NZ-COM und weitere Dokumente zum Z-System findet man im Downloadbereich.