KC-News 3/1996

Top-Themen:

• Umbau M035 mit SIMM-Modulen
• Multisync-/VGA-Monitor am KC
• Zufall und C(h)aos
• neues Betriebssystem ZSDOS und Updates
• Z-System

Ein paar Worte zur Einleitung

von Jörg Linder

Updates zur Systemsoftware

Bei den kurzen Innovationszyklen der neuen Systemsoftware und -utilities könnten selbst große Softwarehäuser nicht mehr mithalten. Mittlerweile habe ich auch die ersten Exemplare der (deutschen) Handbücher vom Kopieren zurück, so daß der Verbreitung nun nichts mehr im Wege steht.

Dank Mario Leubner's unermüdlicher Arbeit ist die Anpassung bzw. Erstellung der Startdatei für das neue System wesentlich leichter zu handhaben. Außerdem dürfte jetzt auch der Umstieg für "Nicht-Festplattenbesitzer" interessant sein.

Von Ralf Kästner kam noch ein Vorschlag für die Festplattenuser: Ich nehme die Informationen über die angeschlossene Festplatte in meine Datenbank auf. Wer Probleme oder Fragen hat, kann sich dann mit einem User in Verbindung setzen, der den gleichen Festplattentyp benutzt. Also Leute, nichts wie her mit den Daten!

Neue Hardware

Ich muß ehrlich zugeben, daß bei mir auch schon erheblicher Nachholebedarf im Hardwarebereich bestand. So nach und nach wird es aber: GIDE-Interface, CAOS 4.3, 256 kB RAM on board... Kaum ist das geschafft, lauert auch schon die nächste Entwicklung auf den nichtsahnenden Anwender:

Enrico Grämer arbeitet an der Realisierung eines Soundmoduls. Seine ersten Überlegungen stellt er in dieser Ausgabe vor.

Nächstes Clubtreffen

Mein größtes "Sorgenkind". Zwei Mitglieder unseres Clubs hatten sich schon um Räumlichkeiten bemüht. Doch leider waren beide Varianten nicht geeignet. Der erste Ort war (besonders für die "Nordstaatler") zu abgelegen, so daß mit einer sehr geringen Resonanz zu rechnen war. Die zweite Möglichkeit hätte sich in der Nähe von Eberswalde geboten, doch ist man dort sehr kommerziell ausgerichtet (sprich: es ist einfach zu teuer).

So habe ich inzwischen wieder zum Motel "Derfflinger" in Gusow Kontakt aufgenommen. Wenn nichts dazwischen kommt, werden wir uns also im nächsten Jahr dort wiedersehen.

Richtigstellung zu den Leitsätzen

Aus noch ungeklärter Ursache hat sich in die Adresse unseres Diskothekars, Jens Neumann, ein Fehler eingeschlichen. Die angegebene Telefonnummer ist falsch. In der Mitgliederliste ist jedoch die richtige abgedruckt. Mit dieser Ausgabe der KC-News erhält jedes Mitglied eine korrigierte Version.

Jetzt stürzt Euch schön ins vierteljährliche Lesevergnügen!

Euer Redakteur

Umbau M035 mit SIMM-Modulen

von Kai-Uwe Irrgang

Ergänzend zu der in den letzten News nochmals veröffentlichten Umbauanleitung zum 1MB-Modul und den Bilddateien für die neuere Variante mit SIMMs möchte ich dem mehrfach geäußerten Wunsch entsprechen und die Arbeitsschritte kurz zusammenfassen. Dabei wird vorausgesetzt, daß der Text aufmerksam gelesen wurde und die Bilddateien 3, 4 und 5 (auf Papier) dabeiliegen. Die Dateien 1 und 2 beziehen sich auf die alte Version. Da der Textbeitrag schon über drei Jahre alt ist, stimmen die darin genanten Preise natürlich nicht mehr. Leider bin ich auch nicht mehr in der Lage, Leiterplatten von Hand anzufertigen. Doch nun zu den im Vergleich zur alten Variante wenigen und einfachen Handgriffen.

Wer das Strukturbyte umschaltbar haben möchte, also zwischen M011 und M035 wechseln können will, verfährt mit der D04-Umverdrahtung wie in der alten Variante. Wer das nicht möchte oder braucht, der lötet nur die Pin's 3 und 6 aus und verdrahtet sie mit DB2 und DB7. Da jetzt keine Speicherschaltkreise mehr eingelötet werden, bieten sich jeweils die freigewordenen Pin's 2 und 14 zum Abgreifen der DB0..7 an.

1. Speicherschaltkreise und Stützkondensatoren auslöten
2. Pin's 12 und 13 des D17 auslöten
3. Strukturbyte s. o.
4. kleine Leiterplatte einbauen, außer A8 und A9 tragen alle Anschlußpunkte die Zielbezeichnung der Grundleiterplatte
5. SIMM-Fassung verdrahten, wobei A8 und A9 von der kleinen Leiterplatte kommen und alle anderen mit den gleichlautenden Anschlüssen der ausgelöteten Speicher verbunden werden
6. SIMM stecken - zuschrauben - fertig
   
   

SYSLIB und ASM/LINK

von Mario Leubner und Jörg Linder

Ich hoffe ja, daß ich nicht der einzige bin, der sich an den Funktionen der SYSLIB versucht hat, die Jörg Linder in den KC-News 1/96 im Zusammenhang mit seinem Konvertierungsprogramm UNIKON vorgestellt hat. Es gibt nämlich Probleme, wenn nicht mit dem Assembler und Linker von SLR gearbeitet wird.

Die meisten verwenden sicher den Assembler M80.COM und den Linker L80.COM bzw. die robotron-Versionen ASM.COM und LINK.COM. Für alle, die es nicht geschafft haben, mit Hilfe der SYSLIB das Programm UNIKON10.COM zu erzeugen, möchte ich mal aufzeigen was es alles zu beachten gibt.

Als erstes probierte ich es mit den Kommandos, die für M80 angegeben waren. Also

A>ASM =UNIKON10/R/Z

eingetippt und die einzige Reaktion war:

?File not found.

Natürlich war mir sofort klar, daß ASM.COM nach einer Datei UNIKON10.MAC gesucht hat und nicht nach UNIKON10.Z80. Also der zweite Versuch mit

A>ASM =UNIKON10.Z80/R/Z

Die Datei wurde gefunden, aber zwei Befehlszeilen werden beanstandet, die wie folgt zu ändern sind:

add 9 zu add a,9
add a zu add a,a

ASM.COM verlangt bei der Addition und Subtraktion die vollständige Angabe, auch wenn es immer das Register A sein kann. Der dritte Versuch glückte und zeigte 'No fatal error(s)' an.

So weit so gut, nun muß noch der Linker von der SYSLIB überzeugt werden. Also zunächst mal die Befehlszeile aus den KC-News abgetippt und abgewartet, was passiert:

A>LINK UNIKON10,SYSLIB/S,UNIKON10/N/E
LINK 1520(SCPX) V1.0

Data     0103    09E1       < 2270>

-FI0$CLO 041B    -FI0$OPE 0389    -FO$CLO 0428
-FO0$OPE 0391    -LUCLOSE 03E7
         5 Undefined Global(s)
38202 Bytes Free
[0000    09E1     9]

Der Linker konnte 5 der 10 externen Funktionen nicht in der SYSLIB finden. Was auffällt: Statt nach der Funktion FI0$CLOSE zu suchen, wird nur FI0$CLO angezeigt. Der Assembler hat also nicht den gesamten Funktionsnamen übergeben, wenn dieser länger als 7 Zeichen ist. Aber auch die Funktion LUCLOSE wurde nicht gefunden, obwohl der Name scheinbar vollständig erscheint. An dieser Stelle mußte ich erst mal im Handbuch vom Assembler nachlesen und fand folgendes:

"Bei allen externen Symbolnamen werden nur die ersten 6 Zeichen an den Programmverbinder übergeben. Zusätzliche Zeichen werden intern abgeschnitten."

Ganz scheint dies allerdings auch nicht zu stimmen, denn immerhin kennt der Linker noch 7 Zeichen!? Jedenfalls habe ich im Quelltext UNIKON10.Z80 alle externen Bezüge auf 6 Zeichen verkürzt, also z.B. FI0$CL geschrieben, wenn vorher FI0$CLOSE stand. Dabei auch die Aufrufstellen mit beachten!

Außerdem fällt noch auf, daß der ausgegebene Adreßbereich bei 103H beginnt. Dies liegt noch daran, daß LINK.COM den Code standardmäßig ab 103H ablegt, um vorher einen Sprungbefehl zum Programmstart eintragen zu können. Wenn im ersten oder einzigen Modul die Startadresse direkt am Programmanfang liegt, kann man ab 100H linken. Dies muß dem Linker aber mit dem Schalter /P angegeben werden. Die Kommandozeilen sehen damit endgültig so aus:

A>ASM =UNIKON10.Z80/R/Z
A>LINK /P:100,UNIKON10,SYSLIB/S,UNIKON10/N/E

Damit funktionierte die Übersetzung mit Einbeziehung der SYSLIB. Ein Vergleich meiner Datei UNIKON10.COM mit der von Jörg Linder ergab immer noch Unterschiede. Dies kann nur noch daran liegen, daß die beiden SYSLIB-Varianten (SYSLIB.REL für M80, SYSLIBS.REL für SLR) doch nicht ganz identisch sind. Beide Programme funktionieren aber - darauf kommt es an!

Ich hoffe, ich konnte mit der Weitergabe meiner Erfahrungen eine kleine Hilfe bei der Fehlersuche geben. Die SYSLIB ist wirklich eine prima Sache, da man viele der immer wieder benötigten Routinen einfach nutzen kann. In diesem Sinne wünsche ich Euch viel Spaß beim weiteren Untersuchen der SYSLIB.

Mario Leubner

Ergänzungen

An dieser Stelle möchte ich mich als Verursacher dieser Probleme nochmal zu Wort melden. Mit Bedacht hatte ich für die M80/L80-Befehlszeilen das Wort "müßten" gewählt. Da ich weder Erfahrung mit diesen Programmen noch mit den zahllosen umbenannten robotron-Clones habe, konnte ich keine Gewähr für fehlerfreies Funktionieren übernehmen.

Für die Änderungen in Bezug auf die ADD-Befehle muß ich mich entschuldigen, möchte aber dazu einen Auszug aus dem Handbuch des SLR-Assemblers wiedergeben:

"Um eine einfache Handhabung zu gewährleisten, erlaubt SLR180 bei 8-Bit Operationen sowohl eine kurze als auch eine lange Schreibweise. Zum Beispiel wird laut Zilog Mnemonik "ADD A,5" geschrieben, um 5 zum Akkumulatorinhalt zu addieren - logisch. Um mit dem Carry-Bit zu addieren, schreibt man "ADC A,5" - immer noch logisch. Ebenso verhält es sich bei der Subtraktion mit Carry-Bit. Ohne Carry-Bit ist das aber anders. Dann wird "SUB 5" geschrieben.

Das ist doch nicht konsequent! Und dann soll man sich auch noch merken, welche Form gerade die richtige ist. SLR180 vermindert die Fehlermöglichkeiten hierbei, indem beide Formen für alle 8-Bit Operationen akzeptiert werden."

Ohne mich jetzt allzu negativ über eine Firma äußern zu wollen, deren Abkürzung ebenso lautet wie die einer ganz schlimmen Krankheit, muß ich sagen, daß die Linkerprobleme wohl eher dem Format der REL-Dateien anzulasten sind als der SYSLIB. Wenn der Linker intern alle weiteren Zeichen "abschneidet", warum dann nicht überall - dann müßte es nämlich wieder funktionieren. Über die Anzahl der verwendeten Zeichen (6 oder 7) haben auch die klugen Köpfe von SLR-Systems gegrübelt. Offiziell sind es nur 6, vermutlich wegen Kompatibilität zu FORTRAN. Doch in Wirklichkeit werden, wie von Mario beobachtet, 7 Zeichen verwendet.

Allerdings wird dieses Geheimnis wie auch viele andere aus dem Hause Microsoft wohl niemals gelüftet werden. Vielleicht, weil es dort auch niemand weiß!?

Jörg Linder

Hinweise zu CHARSET.COM

von Hans-Rudolf Stoeßer

Mit diesem Programm kann zwischen Druckerzeichensätzen umgeschaltet werden. Man kann also mit den DIP-Schaltern den Zeichensatz einstellen, den man am häufigsten benutzt und mit dem Programm einen zeitweilig benötigten Zeichensatz wählen. Das Programm muß vor TPKC gestartet werden.

Die Wirkung des Programms ist abhängig von der Druckerhardware. Ich gehe aber davon aus, daß die meisten Drucker über ESCAPE-Folgen gesteuert werden können. Im Übrigen solltet Ihr probieren. Die größten Abweichungen zwischen den Druckern wird es bei der Zuordnung der Zeichensätze geben. Für die, die ihr Programm auf ihren Drucker anpassen wollen ist das Quellprogramm ebenfalls auf Diskette.

Viel Erfolg!

ESCAPE-Steuerfolgen im MicroDOS

von Uwe Felgentreu

Der KC bietet unter MicroDOS die Nutzung von Resourcen des Grundgerätes an. Dazu wurde im Code des ROM-FC im D004 eine Reihe von Unterprogrammen eingebunden, welche aus der zentralen Abfrageschleife heraus über spezielle Zeichensequenzen ansprechbar sind.

Das Prinzip ist mit den ESC-Folgen zur Druckersteuerung vergleichbar. Hier werden die Codefolgen für Großschrift, Fettschrift etc. auch nur ausgeführt und nicht gedruckt. Wird also im Zeichenstrom für den Bildschirm eine derartige ESC-Folge entdeckt, so werden die Zeichen nicht auf dem Bildschirm dargestellt, sondern eine der Funktion entsprechende Anzahl Bytes herausgefiltert, ausgewertet und die entsprechende Funktion ausgeführt.

Die Aufgabe für den Programmierer besteht nun darin, derartige Codefolgen zu erzeugen. Wichtig ist dabei die korrekte Erzeugung, da der KC nichts prüft und gegebenenfalls bei einer ungültigen Sprunganweisung ins Grundgerät außer Kontrolle gerät. Damit ist dann auch die Arbeit unter MicroDOS beendet, d. h. der KC ist abgestürzt.

Im Handbuch für den Programmierer auf Seite 74 sind die normalen ESC-Folgen abgedruckt. Ich hätte mich fast dazu hinreißen lassen, diese Seite abzutippen, aber Mario Leubner bastelt permanent an neuen ESC-Folgen, so daß er eigentlich die aktuellste Version veröffentlichen kann...

Die Erzeugung einer Codefolge ist denkbar einfach. Mit dem Befehl zur Ausgabe von Zeichen auf dem Bildschirm wird in der jeweiligen Programmiersprache die Zeichenfolge ausgegeben. Meine Beispiele sind in TurboPascal geschrieben. Folgender Befehl schreibt das Byte 41h ("A") an die Adresse 4000h im KC:

write(#27,#83,#00,#40#$41)

Konkret ist hier folgendes passiert. Das Byte 27 leitet eine ESC-Folge ein. Das Byte 83 legt fest, daß hier die Funktion "Speicherzelle im Grundgerät beschreiben" aufgerufen wird. Diese Funktion erwartet nun noch 3 Bytes als Parameter (Adresse-Low, Adresse-High, Datenbyte). Die Übersicht auf Seite 74 im Handbuch für den Programmierer zeigt alle verfügbaren Standardfunktonen mit der Syntax zum Aufruf.

Ich bevorzuge zur Ausgabe die BIOS-Funktionen, da die BDOS-Ausgaben im MicroDOS intern nochmals gefiltert werden. Dabei kann es unter ungünstigen Bedingungen zum Verschlucken von Bytes kommen. Das Grundgerät nimmt die erwartete Anzahl von Bytes aus der Wartschlange und erhält evtl. falsche Parameter. Damit könnte man den KC abstürzen lassen...

Prinzipiell gibt es 2 verschiedene Typen von ESC-Folgen:

• der Funktionsaufruf mit Parametern ohne Rückgabewert
• der Funktionsaufruf mit Parameter und Rückgabewert

Der einfache Funktionsaufruf ohne Rückgabewert wird in der Procedure WRITE_KC gezeigt.

procedure write_kc (adresse:integer;daten:byte);
begin
         bios(3,27);
         bios(3,83);
         bios(3,lo(adresse));
         bios(3,hi(adresse));
         bios(3,daten);
end;

Soll ein Wert zurückgegeben werden, so muß die Zelle MEMANF (=0FFAE Hex) im D004 auf einen Wert ungleich 0 gesetzt werden. Dann wird die betreffende Funktion aufgerufen (wie eine ESC-Folge ohne Rückgabewert) und anschließend gewartet, bis diese Speicherzelle einen Wert ungleich 0 annimmt. Der Wert 255 zeigt einen Fehler an. Erst dann kann ab Adresse 0FE00 Hex das Ergebnis bestaunt werden.

Die Art und Weise, wie man auf das Ergebnis wartet, entscheidet über die Qualität eines Programmes. Macht man es so wie im Beispiel READ_KC, so kann MicroDOS ewig auf das Setzen der Zelle MEMANF warten, wenn ein Parameterbyte verlorengegangen ist. Besser ist die Abfrage mit TimeOut.

Statt

repeat
until(mem[$ffae]=0)

sollte folgende Abfrage benutzt werden

TimeOut=1000     ;  (beliebiger Integer-Wert)
repeat
         TimeOut:=TimeOut-1
until((mem[$ffae]=0) and TimeOut)

Allerdings blähen derartige Sicherheitsvorkehrungen ein Programm sehr auf. Den Nutzen muß der Programmierer selbst abwägen:

function read_kc (adresse:integer):byte;
begin
         mem[$ffae]:=1;
         bios(3,$1b);
         bios(3,integer('Q'));
         bios(3,lo(adresse));
         bios(3,hi(adresse));
         repeat
         until(mem[$ffae]=0);
         read_kc:=mem[$fe00];
end;

Der Assemblerquelltext für READ_KC könnte folgendermaßen aussehen:

;---------------------------
; Input  DE = Adresse im KC
; Output A  = DatenByte
READ_KC: LD      HL,0FFAEH
         LD      (HL),0
         LD      A,01BH
         CALL    BIOS_OUT    ; irgendeine ominoese
                             ; BiosAusgabeRoutine
         LD      A,'Q'
         CALL    BIOS_OUT
         LD      A,E
         CALL    BIOS_OUT
         LD      A,D
         CALL    BIOS_OUT
         LD      HL,0FFAEH
LOOP:    LD      A,(HL)
         OR      A
         JR Z,LOOP
         LD      HL,0FE00H
         LD      A,(HL)
         RET

In BASIC würde ich folgendermaßen programmieren:

1000 POKE 65454,0
1010 PRINT CHR$(27)
1020 PRINT "Q"
1030 PRINT CHR$(LO(ADRESSE))
1040 PRINT CHR$(HI(ADRESSE))
1050 IF PEEK(65454)=0 THEN GOTO 1050
1060 ERGEBNIS=PEEK(65024)
1070 RETURN

In C ist der Quelltext noch kompakter:

read_kc(adr)
{
         poke(0xffae,0);
         printf("%cQ%c%c",27,lo(adr),hi(adr));
         while(!peek(0xffae);
         return(peek(0xfe00);
}

Es ist also in jeder erdenklichen Programmiersprache der Zugriff auf die ESC-Folgen möglich. Hat man sich erst einmal durchgearbeitet, so entstehen sehr schnell persönliche Bibliotheken, welche häufig benötigte Unterprogramm- und ESC-Rufe enthalten. Es wäre nicht schlecht, wenn jeder seine besten Bibliotheken gut dokumentiert dem KC-Club zur Verfügung stellt. In Verbindung mit einer Aufstellung von Mario Leubners aktueller ESC-Liste wäre hier eine Grundlage geschaffen, um Einsteigern das Programmiern mit ESC-Folgen schmackhaft zu machen.

KC am Multisync-/VGA-Monitor

von Enrico Grämer

Da ich einen Multisync-Monitor (Typ Commodore 1960) an meinem Amiga habe, habe ich mich dabeigemacht, diesen nach der Anleitung von Ralf Kästner an meinen KC anzuschließen. Wie sich dann herausstellte, funktioniert das nicht so einfach. Es kam nur "Bildsalat" heraus. Also suchte ich mir den Schaltplan vom KC heraus und bastelte den ganzen Tag herum, bis ich dann endlich die richtigen Leitungen für H-Sync und V-Sync gefunden hatte.

H-Sync nehme ich am Lötnagel der Videoplatine (Signalbezeichnung /SYN, von IC D28, LS 008 Pin 11 kommend) ab.

V-Sync kommt von IC D36, LS 000 Pin 8 (Bezeichnung VSY1).

Wegen der Übersichtlichkeit das Ganze noch in tabellarischer Form und die Skizzen dazu.

Darf's ein wenig Farbe sein?

von Hendrik Wagenknecht

Aufgrund eines kleinen Mißverständnisses wurde dieser kurze Artikel nicht in der vorigen Ausgabe der KC-News veröffentlicht, was hiermit nachgeholt werden soll. Sicherlich haben ihn aber schon einige auf der letzten Beilagen-Diskette in Form der Datei HP500C.DOK entdeckt.

Der HP500C für Wordpro 6.2

Es ist endlich geschafft. Mein Farbdrucker läuft am KC fehlerfrei. Bereits im vorigen Jahr hatte ich einen Treiber für EDIPIC fertiggestellt. Er war sehr einfach aufgebaut und benötigte eine bestimmte Systemkonfiguration. Für Wordpro 6.1 hatte ich auch bald einen Treiber für s/w-Druck umgeschrieben.

Mehr war damals aufgrund des geringen Speicherplatzes in Wordpro 6 nicht möglich. Erst mit Wordpro 6.2 war es möglich, den Bereich von BA00H bis BBFFH mit auszulagern. Nun hatten auch die Steuercodes für den Farbdruck Platz. Für den Ausdruck von Hires-Grafiken ist aber immer noch kein Platz. Das gleiche gilt auch für Vergrößerungen von Bildern und Bildausschnitten. Diese Argumente sind jedoch im Text weiterhin anzugeben!

Das letzte Argument, daß den Druckmodus angibt, wird für die Auflösung des Bildes verwendet. Somit können vier verschiedene Größen von Bildern ausgedruckt werden.

Installation des Treibers in Wordpro 6

Zur Installation werden die Dateien des .PMA-Files auf eine Diskette mit Wordpro 6.2 (WP 6.2 erkennt man beim Kopieren an der Abfrage "BA00 mit retten?") kopieren.

• WP 6 starten
• Grafikmenü aufrufen
• Resettaste drücken
• Datei HPWP6T1.KCC laden
• Datei HPWP62T2.KCC laden
• Datei IRM.KCC laden
• WP6 neu starten
• irgend ein PIP/PIF Bild laden und Treiber testen
• WP6COPY.KCC laden und WP6 neu abspeichern

Bei WP6.1 gilt der gleiche Ablauf. Nur muß hier nach einem neuen Einschalten des KC's nach dem Laden von WP6 die Datei HPWP6T2.KCC jedesmal nachgeladen werden!

Fügt man die beiden Dateien HPWP6T1.ASM und HPWP6T2.ASM in EDAS zusammen, so erhält man einen allgemeinen Treiber, den man in ein eigenes Programm einbinden kann. Die WP6 Zeilen sind dann durch DEFW zu ersetzen.

Viel Spaß beim Farbdruck!

Zufall und C(h)aos

von Frank Dachselt

Mitunter steht ein Programmierer vor der Aufgabe, etwas Zufälliges oder zumindest annähernd Zufälliges auf seinem Rechner zu erzeugen. Die bekannten Realisierungen reichen von der Verwendung bestimmter numerischer Rekursionen (Zufallsgeneratoren in Hochsprachen) bis hin zur Nutzung des beim Z80/U880 vorhandenen Refreshregisters.

Das Ergebnis steht dann meist als Folge zufällig erscheinender Zahlen zur weiteren Verwendung bereit. Der Vollständigkeit halber soll hier angemerkt werden, daß es sich bei allen soft- oder hardwaremäßig realisierten, freilaufenden Generatoren genaugenommen nur um Pseudozufall handelt, denn unser Rechner ist ja ein determiniertes System (auch, wenn es mitunter nicht so scheint).

Im folgenden soll ein Generatorprinzip mit einigen bemerkenswerten Eigenschaften vorgestellt werden, dessen softwaremäßige Realisierung besonderes einfach ist. Der Beitrag soll gleichzeitig ein kleiner Exkurs in die Assembler-Programmierung sein und auch einem Anfänger die Möglichkeit zum Experimentieren geben.

Das Prinzip des zur Klasse der linear rückgekoppelten Schieberegister gehörenden (Pseudo-)Zufallsgenerators ist in Bild 1 dargestellt. Er besteht aus einer Registerkette (hier 16 Bit), deren Inhalt mit jedem Takt um eine Bitstelle nach links verschoben wird. Das höchstwertigste Bit (hier Bit 15) geht dabei verloren, das niederwertigste Bit (Bit 0) ergibt sich aus der Modulo-2-Addition (XOR-Verknüpfung) einer bestimmten Menge von Bits des vorhergehenden Zustandes (hier sind das die Bits 10, 12, 13 und 15).

Bild 1: Linear rückgekoppeltes Schieberegister als Zufallsgenerator

Das bedeutet: Enthalten diese Bitstellen eine gerade Anzahl von Einsen, so ist Bit 0 im nächsten Takt Null, bei einer ungeraden Anzahl von Einsen ist es entsprechend Eins. Auf diese Weise wird in der Registerkette eine Folge von 16-Bit-Zahlen erzeugt. Bei geeigneter Wahl der Rückkopplung, die allein durch Anzahl und Wertigkeit der verknüpften Bitstellen bestimmt ist, durchläuft der Generator genau 2ⁿ - 1 Zustände, bis er wieder seinem Anfangszustand annimmt und der Zyklus von vorn beginnt. Dabei bezeichnet n die Länge der Registerkette, im abgebildeten Beispiel beträgt die Periode des Generators also 2¹⁶ - 1 = 65535.

Mit anderen Worten: Der Generator erzeugt innerhalb einer Periode genau 2ⁿ - 1 verschiedene n-Bit-Zahlen. Das sind bis auf eine Ausnahme alle möglichen mit n Bit darstellbaren Zahlen. Die Ausnahme ist, wie sich schnell überlegen läßt, die Zahl Null, denn der Null folgt stets wieder eine Null; dieser Zustand der Registerkette ist sozusagen stabil. Die Null darf demzufolge auch nicht als Startwert verwendet werden. Dagegen ist jede andere Zahl Bestandteil der 2ⁿ - 1 Takte dauernden Periode und kann als Startwert benutzt werden.

Die Reihenfolge, mit der die von Null verschiedenen Zahlen durch den Generator erzeugt werden, ist scheinbar zufällig, wenn auch durch das Generationsprinzip eindeutig bestimmt. Dies läßt sich besonders gut bei einer grafischen Ausgabe beobachten.

Dreh- und Angelpunkt des Generatorprinzips ist eine passende Rückkopplung. Auf die zugrundeliegenden Theorie soll an dieser Stelle nicht eingegangen werden; wer sich dennoch für die tieferen Zusammenhänge interessiert, kann mal unter den Stichworten "linear rückgekoppelte Schieberegister", "Maximallängenfolgen" und "primitive Polynome" nachschauen.

Solche geeigneten Rückkopplungen gibt es für jede Registerlänge n, wobei n - 1 jeweils das höchstwertigste in die Rückkopplung einfließende Bit bezeichnet. In der Tabelle am Ende dieses Textes ist für Registerlängen von 3 bis 16 Bit jeweils eine Rückkopplung angegeben, die für eine Programmierung besonders geeignet ist. Auf das Format der Darstellung wird im folgenden noch näher eingegangen.

Nun zur Umsetzung des Generators in einem Assemblerprogramm. Als Beispiel soll dazu zunächst die in Bild 1 dargestellte 16-Bit-Variante verwendet werden. Beschränkt man sich auf Registerlängen kleiner oder gleich 16 Bit, findet die Registerkette im Doppelregister HL Platz. In HL steht also stets die aktuelle Zufallszahl, aus der in jedem Schleifendurchlauf (Generatorschritt) der nächste Wert erzeugt wird.

Zunächst muß der Wert der Rückkoppelfunktion bestimmt werden, der dann Bit 0 der neuen Zufallszahl ergibt. Im Beispiel werden für die Rückkopplung nur Bits aus dem höherwertigen Byte verwendet, so daß auch nur das Register H betrachtet werden muß, was die ganze Sache etwas vereinfacht. Um nur die in der Rückkopplung verwendeten Bits von H zu erhalten, wird der Registerinhalt, nachdem er in den Akkumulator A geladen wurde, mit einem Rückkoppelbyte (0B4H) maskiert.

In dieser Maske sind genau die Bitstellen gleich Eins (markiert), die aus dem Register H in der Rückkoppelfunktion verwendet werden. Das Ergebnis im Akkumulator ist ein Byte, in dem alle nichtmarktierten Bits gleich Null sind und alle markierten Bits den korrespondierenden Bits des Registers H entsprechen. Da zusätzliche Null-Bits ohne Einfluß auf den Wert der Rückkopplung sind, kann das neue Bit 0 jetzt auch als Modulo-2-Addition aller 8 Bits des Akkumulators bestimmt werden.

Und genau das hat unser Prozessor aber im Prinzip bereits getan, sozusagen als Zugabe bei der AND-Operation, indem er nämlich die Parität des Ergebnisses bestimmt und in das P/V-Flag einträgt: Nach einer logischen Operation wie AND steht im P/V-Flag eine Eins, wenn die Anzahl der Einsen im Ergebnis gerade ist, sonst eine Null. Das ist bis auf eine Negation genau der neue Wert von Bit 0 der Registerkette.

Der Inhalt des P/V-Flags läßt sich nur als Sprungbedingung auswerten, günstiger für die nachfolgende Schiebeoperation ist aber ein Ergebnis im C-Flag. Um das zu erreichen, sind die dem AND folgenden zwei Befehle vorhanden. Dabei ist die Tatsache von Bedeutung, daß bei den logischen Operationen AND, OR und XOR das C-Flag gundsätzlich auf Null gesetzt wird.

Ist die Anzahl der Einsen im Ergebnis der AND-Operation gerade, dann ist das C-Flag bereits richtig gesetzt und es kann mit Bedingung PE (Parity even) sofort zur Verschiebeoperation gesprungen werden. Im anderen Fall wird zuvor das C-Flag noch negiert. Damit steht jetzt der richtige Wert der Rückkoppelfunktion im C-Flag und kann mittels einer zyklischen Linksverschiebung des Registers L in dessen Bit 0 übernommen werden.

Nach dieser Operation befindet sich im C-Flag das vormals höchstwertigste Bit des Register L und wird im folgenden durch die zyklische Linksverschiebung des Registers H als dessen niederwertigstes Bit übernommen. Damit ist der Generatorschritt abgeschlossen; im Register HL steht nun die neue Zufallszahl.

Mit nur 6 Maschinenbefehlen ist die Realisierung also überaus einfach und effektiv.

- Generatorschritt (16 Bit) -

;
; HL = alte Zufallszahl
      LD A,H
      AND 0B4H   ;Rückkoppel-Maske H (RKM H)
      JP PE,S1
      CCF        ;C-Flag negieren
S1:   RL L
      RL H       ;HL = neue Zufallszahl

Was jetzt noch fehlt, um den Zufallsgenerator zu testen, ist eine Schleife, die den Generatorschritt in einer bestimmten Anzahl von Durchläufen jeweils einmal ausführt und die erzeugte Zufallszahl in irgendeiner Weise weiterverarbeitet.

Dabei ist noch sicherzustellen, daß beim Start des Generators im Register HL eine von Null verschiedene Zahl steht und die Zufallszahl bei der Verarbeitung nicht verändert wird. Die Verwendung der Zufallszahl besteht in den hier gezeigten Programmbeispielen jeweils darin, einen Teil des Bildschirms "zufällig" mit Punkten zu füllen.

Dazu wird die erzeugte Zufallszahl in zwei Teile zerlegt, die jeweils die x- und y-Koordinaten des zu setzenden Punktes bilden. Die niederwertigen 8 Bit (Register L) entsprechen der y-Koordinate, die höherwertigen 8 Bit (Register H) der x-Koordinate. Der Nullpunkt ist dabei - abweichend von den üblichen Grafikkoordinaten - die linke obere Ecke.

Natürlich läßt sich für diesen Zweck auch das CAOS-Unterprogramm 30h verwenden, aber damit es schneller geht, ist das hier direkt programmiert. Auf eine ausführliche Beschreibung dieses Programmteils soll an dieser Stelle verzichtet werden; im Quelltext sind Kommentare enthalten, die das Verständnis ermöglichen sollten.

In der 16-Bit-Variante wird ein 256 mal 256 Punkte großes Quadrat auf dem Bildschirm mit Punkten gefüllt. Das ist noch nicht der gesammte Pixel-RAM, aber eine entsprechende Erweiterung ist wohl nicht allzu schwer zu programmieren. Die äußere Programmschleife wird genau 65535-mal durchlaufen, was genau der Periode des Generators entspricht.

Wer genau hinsieht, wird feststellen, daß der Punkt (0,0) in der linken oberen Ecke nicht gesetzt wird, denn dieser entspricht dem Zustand HL=0, der wie oben beschrieben nicht auftritt. Neben dem Setzen der Punkte auf dem Bildschirm ist in gleicher Weise auch das Rücksetzen und das Negieren möglich. Dazu ist an der gekennzeichneten Stelle im Quelltext die Verknüpfungsoperation der Bitmaske im Register A mit dem Byte aus dem IRM zu modifizieren.

Wie oben bereits gesagt, läßt sich der Generator auch für andere Registerlängen realisieren. Dabei tritt der Fall auf, daß sich die Bitstellen für die Rückkopplung nicht alle in einem Byte (also entweder im Register H oder im Register L) befinden, sondern auf beide 8-Bit-Register verteilen. Für die Registerlängen 9, 10 und 12 läßt sich das nicht vermeiden.

Die Bestimmung des Wertes der Rückkoppelfunktion ist dann etwas zu modifizieren, was am Beispiel eines 12 Bit langen Generators gezeigt werden soll.

Zunächst werden wie im ersten Beispiel die benötigten Bits des Registers H mit der Maske RKM H ausgewählt. Das Ergebnis wird dann erst einmal im Register C zwischengespeichert. Die bereits mitbestimmte Parität wird an dieser Stelle nicht benötigt. Danach erfolgt die Maskierung des Registers L mit der Maske RKM L. Die folgende Operation (XOR C) verknüpft die beiden maskierten Bytes bitweise und bildet so zunächst einmal Teilsummen von jeweils zwei Bits (wie bei der normalen Addition läßt sich auch die Modulo-2-Addition beliebig in Teilsummen zerlegen, d.h. die Reihenfolge der Addition der einzelnen Bits spielt keine Rolle).

Da XOR eine logische Funktion ist, wird auch hier gleich wieder die Parität des Ergebnisses bestimmt und im P/V-Flag eingetragen (genaugenommen enthält das P/V-Flag nach der Operation XOR C also die Parität der 16 Bit in den Registern A und C). Ebenso ist das C-Flag nach dieser Operation grundsätzlich auf Null gesetzt. Damit ist der gleiche Zustand erreicht wie nach AND im obigen 16-Bit-Beispiel und es kann in gleicher Weise fortgefahren werden.

Eine weitere Modifikation ist der letzte Befehl des Generatorschritts. Hier wird das dem höchstwertigsten folgende Bit der Registerkette auf Null gesetzt. Damit wird erreicht, daß alle nicht benötigten Bits des Registerpaares HL immer Null sind und der Inhalt von HL somit als 12-Bit-Zufallszahl verwendet werden kann.

- Generatorschritt (12 Bit) -

;
; HL = alte Zufallszahl (12 Bit)
      LD A,H
      AND 08H    ;Rückkoppel-Maske H (RKM H)
      LD C,A
      LD A,L
      AND 29H    ;Rückkoppel-Maske L (RKM L)
      XOR C
      JP PE,S1
      CCF
S1:   RL L
      RL H
;
      RES 4,H    ;HL = neue Zufallszahl (12 Bit)

Die folgende Tabelle nun zeigt für Registerlängen von 3 bis 16 Bit jeweils eine geeignete Rückkopplung in Form der Rückkoppelmasken RKM H und RKM L, die Operanden für den RES-Befehl (letzter Befehl im 12-Bit-Beispiel) sowie die jeweils erzeugte Periode der Zufallszahlenfolge. Mit diesen Parametern können die Beipspielprogramme modifiziert werden, um einen Generator der jeweiligen Registerlänge zu programmieren.

n	RKM H	RKM L	RES	Periode
16	B4h	-	-	65.535
15	60h	-	7,H	32.767
14	27h	-	6,H	16.383
13	1Bh	-	5,H	8.191
12	08h	29h	4,H	4.095
11	05h	-	3,H	2.047
10	02h	04h	2,H	1.023
9	01h	08h	1,H	511
8	-	8Eh	0,H	255
7	-	44h	7,L	127
6	-	21h	6,L	63
5	-	12h	5,L	31
4	-	09h	4,L	15
3	-	05h	3,L	7

Bei Generatoren mit Registerlängen bis zu 8 Bit kann auf die Verwendung des Registers H verzichtet werden, was zu einer Vereinfachung des Programmtextes führt. Für einige markante Fälle bezüglich der Registerlänge n sind im Paket ZUFALL.PMA vollständige Quelltexte enthalten.

Der visuelle Effekt auf dem Bildschirm ist sicherlich nur bei den größeren Registerlängen interessant. Die Variaten mit n kleiner oder gleich 8 erzeugen - bedingt durch das gewählte Verfahren der Koordinatenzuordnung - jeweils nur eine mehr oder weniger lange Linie am linken Bildschirmrand.

Viel Spaß beim Experimentieren!

Beispiele:

zufall08.asm

Assemblerquelltext des Demo-Programms für ein Register der Länge 8

 

zufall12.asm

Assemblerquelltext des Demo-Programms für ein Register der Länge 12

 

zufall15.asm

Assemblerquelltext des Demo-Programms für ein Register der Länge 15

 

zufall16.asm

Assemblerquelltext des Demo-Programms für ein Register der Länge 16

Updates zu FORMAT.COM und MODF.COM

von Mario Leubner

Wie schnell doch die Zeit vergeht: Da wurden erst in den letzten KC-News die beiden Programme FORMAT.COM und MODF.COM (im Beitrag zu TRANSFER 1.91) vorgestellt und schon sind sie überholt! Beide Programme mußten bei der Entwicklungsarbeit am neuen System ein wenig verändert werden.

Bei MODF.COM sind nur zwei kleine 'Schönheitsfehler' beseitigt worden, die mir erst jetzt aufgefallen sind. Der Einfachheit halber habe ich auch gleich Versionsnummern eingeführt. V1.0 ist die erste Version, die ausschließlich für MicroDOS war, V1.1 ist die Version von den KC-News 2/96 und V1.2 das aktuelle Programm.

FORMAT.COM hat dagegen größere Änderungen erfahren. Mit dem neuen System ist es möglich, bis zu 16 logische Laufwerke zu installieren. FORMAT V3.1 kann alle Laufwerke formatieren, die als Diskettenlaufwerk installiert wurden. Da KCFORMAT.COM von Uwe Felgentreu mit dem neuen System nicht mehr funktioniert, kam die Anfrage, mein FORMAT mit einer Kommandozeile zu versehen.

Dies habe ich jetzt ebenfalls realisiert. Es kann aber genausogut noch über Menü Laufwerk und Format gewählt werden, wenn nur das Kommando FORMAT eingegeben wird. Soll von der Kommandozeile aus formatiert werden, ist als erster Parameter zunächst das Laufwerk anzugeben. Danach sind noch einige Optionen möglich:

// oder /? Aufruf einer Hilfeseite
/u Unterdrücken der Sicherheitsabfrage
/f:xxx Wählen des Formates

Die Option /u ist für automatisch ablaufende SUB-Dateien oder Aliase gedacht. Mit der Option /f kann das Format gewählt werden. Normalerweise kann diese Option weggelassen werden, dann verwendet FORMAT.COM das Format des benutzten Laufwerkes. Durch Angabe von '/f:720' kann aber auch eine 720K-Diskette in einem 780K-Laufwerk erzeugt werden, ohne das Laufwerk uminstallieren zu müssen.

In der Option /f sind die Formate 780K (bzw. 800K), 720K und 624K (bzw. 640K) möglich. Eine Einschränkung gibt es: Die Kommandozeile ist nur für DS/DD-Laufwerke - also die normalen Laufwerke mit 80 Spuren und 2 Köpfen, während über Menü auch die älteren SS- und SD-Laufwerke formatiert werden können.

Noch eine KC-MailBox

von Uwe Felgentreu

Nachdem mich die Deutsche Telekom AG mit ISDN versorgt hat, kann ich in bescheidenem Umfang eine kleine MailBox anbieten. (sozusagen als Datenschleuder)

Der Begrüßungsbildschirm:

Sie sind verbunden mit dem Server von Dipl.-Ing. Uwe Felgentreu.
Der Gast-Username für den KC85-User-Club ist KC / Paßwort KC !

mit HELP erhalten Sie nach dem LOGIN eine kleine Hilfe.


Viel Spass ...

 VoiceConnect-Mailbox - LOGIN:
Username:KC
Passwort:**

User logged in
F:\MAILBOX\USERDIR\KC>

Und schon kann es losgehen. Neue User melden sich als User KC an und schicken mir eine Mail mit dem gewünschten Usernamen und Paßwort.

Die Hilfe zur Box (an jeder Stelle mit HELP aufzurufen):

Hilfedatei zu VCWBox
====================

Kommandos:
mail         eine Nachricht schreiben
dir          aktuelles Verzeichnis anzeigen
dir <pfad>   Verzeichnis <pfad> anzeigen
             z.B. 'dir c:\temp' oder 'dir d:\dos\*.sys'
hilfe        Hilfe anzeigen
upload       Datei senden (Z-Modem upload)
download     Datei empfangen (Z-Modem download)
exit         Ende

erweiterte Kommandos:
cd           wechselt das Verzeichnis (und ggf. das Laufwerk)
copy         eine Datei kopieren
del          eine Datei löschen
type         eine Datei anzeigen
md           ein Unterverzeichnis anlegen

Das Beenden...

F:\MAILBOX\USERDIR\KC>exit

Vielen Dank fuer Ihren Anruf...

[click]

Das soll es zur Vorstellung der Mailbox gewesen sein. Da die Anrufer erst nach dem 4. Rufzeichen auf meinen PC verbunden werden und dann auch noch ca. 12 Sekunden lang den Anrufbeantworterversuch über sich ergehen lassen müssen, ist eine Veränderung des Modemregisters S7 mit dem Befehl

ATS7=99
OK

recht sinnvoll. Vom Beginn des Anwählens bis zum Connect vergehen in der Regel ca. 45 - 55 Sekunden. Das Register S7 legt die Zeit in Sekunden fest, wie lang das Modem auf Connect wartet.

Kommandodateien unter CAOS

von Frank Dachselt

Kommandodateien bieten eine bequeme Möglichkeit, sich häufig wiederholende Kommandofolgen insbesondere auf Betriebssystemebene zu automatisieren, sparen somit Zeit und Tipparbeit und verringern die Fehlerrate. Unter MicroDOS sind sie als SUB-Dateien bekannt, die mit den Kommandos "<" oder "SUBMIT" gestartet werden. Auch CAOS bietet einige rudimentäre Voraussetzungen für diesen Zweck und viele KC-User nutzen diese Möglichkeiten, indem sie Funktionstasten belegen oder die Datei INITIAL.UUU auf einer CAOS-Diskette anlegen.

Ein paar Informationen zur Arbeit mit Kommandofolgen unter CAOS waren bereits in den KC-News 1/93 zu lesen. Zur Erinnerung hier noch einmal das Wesentliche:

In CAOS ist es möglich, Kommandofolgen beliebiger Länge, die sich an einer beliebigen Stelle im Speicher befinden, auszuführen. Eine solche Datei verhält sich wie die Kommandofolge einer Funktionstaste und wird vom Betriebssystem in gleicher Weise behandelt. Das folgende Programmstück löst die Abarbeitung von Kommandos aus, die ab Adresse xxxxh im Speicher stehen:

LD HL,xxxxH
LD (0B7D1H),HL
SET 6,(IX+8)

Danach kann mit dem RET-Befehl oder einem direkten Sprung über Unterprogramm 12h in die Kommandoebene von CAOS übergegangen werden. Das Ende einer Kommandofolge im Speicher wird mit dem Code 00h gekennzeichnet. Mittels BREAK-Taste kann die Abarbeitung vorzeitig abgebrochen und in den Tastatureingabemodus übergegangen werden. Sollen Programme auf diese Weise bedient werden, so sind die entsprechenden Eingaben über das Unterprogramm 04h zu realisieren. Die Unterprogramme 0Ch und 0Eh verlangen dagegen echte Tastatureingaben.

Diese Möglichkeit läßt sich nun überall dort sinnvoll nutzen, wo die Belegung einer Funktionstaste wegen der Begrenzung des Funktionstastenspeichers auf 156 Byte (B900 - B99B) nicht möglich ist oder wenn zusätzliche Flexibilität gefordert ist. In den nachfolgenden Beispielen kommt der Effekt der praktisch unbegrenzten Länge einer solchen Kommandofolge aus Platzgründen natürlich nicht zum Vorschein, vielmehr soll hier das prinzipielle Herangehen gezeigt werden.

Das erste Beispiel zeigt die Grundvariante einer solchen CAOS-Kommandodatei. Angenommen wird hier, daß die zwei jeweils 200h Byte langen Dateien FILE1.KCC und FILE2.KCC miteinander verkettet und als FILE3.KCC auf Diskette gespeichert werden sollen. Die Ausgangsdateien belegen dabei stets den Speicherbereich 6000h - 6200h. Vor den eigentlichen Kommandos wird zunächst der Bildschirm gelöscht, um Fehler durch den ursprünglichen Bildschirminhalt bei der Abarbeitung zu vermeiden. Das nachfolgende ENTER erzeugt einen CAOS-Prompt.

         ORG 200H
;
         DEFW 7F7FH
         DEFM 'COMBINE'
         DEFB 1
;
START:   LD HL,COMM
         LD (0B7D1H),HL
         SET 6,(IX+8)
         RET
;
COMM:    DEFB 12             ;CLS
         DEFB 13             ;Enter
         DEFM 'FLOAD'
         DEFB 13
         DEFM 'FILE1'
         DEFB 13
         DEFM 'FLOAD 200'
         DEFB 13
         DEFM 'FILE2'
         DEFB 13
         DEFM 'FSAVE 6000 6400'
         DEFB 13
         DEFM 'FILE3'
         DEFB 13
         NOP                 ;Ende der Kommandofolge

Im zweiten Beispiel ist die Grundvariante um eine Parameterübergabe erweitert worden. Die zwei Parameter bezeichnen dabei eine Ziffer im Dateinamen, wobei die Ziffern 0 bis 9 zulässig sind. Mit COMBINE 3 6 wird FILE3.KCC mit FILE6.KCC verkettet und als FILE3+6.KCC abgespeichert.

         ORG 200H
CAOS     EQU 0F003H
BEEP     EQU 7
CLS      EQU 12
LF       EQU 10
ET       EQU 13
;
         DEFW 7F7FH
         DEFM 'COMBINE'
         DEFB 1
;
PARAM:   LD A,(0B781H)
         CP 2
         JR NC,P1
ERROR:   CALL CAOS
         DEFB 23H
         DEFB BEEP
         DEFM 'Parameter fehlerhaft!'
         DEFB LF
         DEFB ET
         NOP
         RET
P1:      LD A,(0B782H)
         AND 0FH
         CP 9
         JR NC,ERROR
         ADD 30H
         LD (N11),1
         LD (N12),A
P2:      LD A,(0B784H)
         AND 0FH
         CP 9
         JR NC,ERROR
         ADD 30H
         LD (N21),A
         LD (N22),A
;
START:   LD HL,COMM
         LD (0B7D1H),HL
         SET 6,(IX+8)
         RET
;
COMM:    DEFB CLS
         DEFB ET
         DEFM 'FLOAD'
         DEFB ET
         DEFM 'FILE'
N11:     DEFM '1'
         DEFB ET
;
         DEFM 'FLOAD 200'
         DEFB ET
         DEFM 'FILE'
N21:     DEFM '2'
         DEFB ET
;
         DEFM 'FSAVE 6000 6400'
         DEFB ET
         DEFM 'FILE'
N12:     DEFM '1+'
N22:     DEFM '2'
         DEFB ET
         NOP

Die Möglichkeiten, Kommandofolgen unter CAOS zu benutzen, sind damit bei weitem noch nicht ausgeschöpft. Die gezeigten Beispiele sollen nur als Anregung dienen, wie die eine oder andere Aufgabe unter CAOS bequem und effektiv gelöst werden kann.

Neue CP/M-Software

von Jens Neumann

REDALERN.PMA

Das Archiv enthält Dateien für ein REDABAS-Lernprogramm, welches mir Hans-Rudolf-Stoeßer zugesandt hat. Es ist in Dialog-Form geschrieben und sehr gut zur Erlernung der Grundschritte von REDABAS / dBase II geeignet. Vor der Nutzung sollte die Diskette wie immer kopiert werden, da Teile des Programmes schreibend auf die Diskette zugreifen. Die Einzeldateien sind als PMA-Archiv gepackt. Am schnellsten und angenehmsten läuft das Programm natürlich, wenn man alles auf Lw A oder Festplatte kopieren kann.

Bei solch großen PMA-Dateien kann es bei Usern mit geringer RAM-Ausstattung zu Problemen beim Entpacken kommen. Sie sollten sich an mich wenden und erhalten dann eine entpackte Version.

SRTDIR31.COM

Dieses Programm dient zum Sortieren der Directory-Einträge einer Diskette. Die Dateinamen erscheinen nach Anwendung beim Directory-Aufruf unter CP/M alphabetisch sortiert.

Vorabbericht zum Sound-Modul

von Enrico Grämer

Die Entwicklungsarbeiten (Schaltplanerstellung) zum Soundmodul sind so gut wie abgeschlossen. Es muß aber noch der Prototyp gebaut und passende Software muß auch noch geschrieben werden. Ich hoffe, daß das Ganze bis zum nächsten Klubtreffen fertig wird. Das Modul wird mit einem eigenen, vom KC unabhängigen, Prozessorsystem arbeiten.

Die Hardware soll in etwa folgendes umfassen:

• Z80 CPU mit 10 MHz
• AD/DA Wandler AD7569 mit 5 MHz
• eigenes System ROM und RAM
• RAM für Sound-Daten mit mindestens 128 KB bis maximal 512KB in 2 Blöcke unterteilt (während 1 Block im Adressbereich des KC liegt, kann aus dem anderen Block der Sound abgespielt werden - Endlossamples)
• Stereo Ein- und Ausgänge
• Mikrofoneingang
• Befehlsaustausch über einen I/O-Port
• eventuell Tiefpassfilter und elektronische Lautstärkeeinstellung

Software:

• Abspielen von Samples aus einer Liste von Samples (für Spiele)
• digitalisieren von Samples
• Aufnehmen und Abspielen von Endlossamples (Festplatte vorausgesetzt und das Koppel-RAM ist schnell genug)
• diverse Effektsoftware zur Bearbeitung der Samples
• Abspielen von MOD-Files wie sie bei Amiga oder PC üblich sind

Ihr könnt mir ja mal schreiben, was Ihr davon haltet.

Fehlerfreies RESET für GIDE-Interface

von Mario Leubner

Der Artikel zum Einbau des GIDE-Interface in der letzten KC-News endete mit den Worten "Ein Problem gibt es allerdings noch...". Heute will ich nun eine preiswerte Lösung vorstellen, die recht sicher arbeitet. Herzstück der kleinen Zusatzschaltung ist ein Schaltkreis TL7705, der in die RESET-Leitung zu schalten ist.

Das Hauptproblem, warum die Uhr mit Batteriestützung nicht ordentlich gepuffert werden konnte, sind undefinierte Pegel beim Einschalten unseres Rechner-"Turmes". Die vielen Einzelnetzteile jedes Aufsatzes können eine Ursache sein. Andererseits liegen in der RESET-Leitung so viele TTL-Gatter, daß auch dadurch im Einschaltmoment kurzzeitig undefinierte Pegel auftreten können.

Der Schaltkreis TL7705 ist ein "Power-On Reset Generator". Beim Zuschalten der 5V-Spannung sorgt er sicher für die Erzeugung eines RESET-Impulses sobald die Spannung 3,6 V überschreitet. Bis 4V bleibt der RTC-Schaltkreis im Standby-Modus, so daß bei dessen Verlassen das RESET-Signal stabil anliegt. Die Dauer des RESET-Impulses ist abhängig vom Kondensator an Pin 3 des TL7705. Nach der Gleichung

t = 13000 * C

und der von mir gewählten Kapazität von 47 Microfarad ergibt sich eine Verzögerung von ca. 0,6 Sekunden. Den Wert habe ich rein gefühlsmäßig gewählt, eventuell reicht auch eine geringere Kapazität aus - 0,6 Sekunden sind aber durchaus zu verkraften. Das Ergebnis bestätigt jedenfalls, daß die Zeit ausreicht. Seit dem Einbau mußte ich die Uhr noch nicht wieder stellen!

Zum Einbau der kleinen Zusatzschaltung nach Bild 1 will ich keine detaillierte Anleitung geben. Jeder wird einen Platz für die 4 Bauelemente finden. Ich habe z.B. das freie Lötrasterfeld auf dem Modulinterface benutzt. Die +5V und Masse sind dort in unmittelbarer Nähe vorhanden, die RESET-Signale habe ich mit einem Draht herangeführt. Wichtig ist, daß das RESET-Signal auf dem GIDE-Interface an der richtigen Stelle unterbrochen wird.

Die Leitung von Pin 26 der CPU-Sockel läßt sich beim fertig bestückten Interface schlecht verfolgen, besser zugänglich ist Pin 15 des RTC (72421). Zu unterbrechen ist der auf der Lötseite an dieses Pin heranführende Leiterzug. Die Verbindung zwischen dem RTC und Pin 1 von CN2 (Laufwerksanschluß) liegt auf der Bestückungsseite, so daß unser stabilisiertes RESET-Signal auch mit zur Festplatte gelangt.

Bild 1: Zusatzschaltung für das RESET-Signal am GIDE-Interface

Zum Schluß noch zwei Bezugsquellen für den TL7705:

	Conrad-Elektronik	Reichel-Elektronik
Bestell-Nr.	18 16 25-77	TL 7705 DIP
Preis	2,95 DM	1,65 DM
Mindestbestellwert	35,00 DM	10,00 DM

Beachtet bitte die Mindestbestellwerte! Also den TL7705 bei der nächsten größeren Bestellung mit draufschreiben oder mit anderen zusammen bestellen.

Das neue Betriebssystem für den KC 85 (2)

von Mario Leubner

Seit den letzten KC-News und der ersten Vorstellung des neuen KC-Betriebssystems hat sich einiges getan. So hatten sich im CCP ein paar kleine Fehler eingeschlichen und die Installation des eigenen Systems war noch recht umständlich. Sobald es nenneswerte Verbesserungen gibt, werde ich diese auch in den KC-News veröffentlichen, damit jeder Nutzer des neuen Systems auf dem aktuellen Stand bleibt. Auf der Beilagendiskette werden jedoch nur die lizenzfreien Dateien verteilt, die lizensierten Dateien aus dem ZSDOS-Paket können über Jörg Linder bezogen werden.

Eine Bitte hätte ich noch:
Keiner ist fehlerfrei, deshalb kann und will ich auch keine Garantien geben, die meine Programme betreffen. Bei der Installation des Betriebssystems sollte mit größter Sorgfalt vorgegangen werden. Das gilt besonders bei der Verwendung einer Festplatte, da sich meist wertvolle Daten darauf befinden, die nur schwer wieder hergestellt werden können. Für Hinweise zu auftretenden Problemen, die von den Systemdateien kommen könnten, bin ich jedoch immer dankbar. Kommen wir nun aber zu den aktuellen Neuerungen:

Installation

Mit der Installation des Systems (siehe KC-News 2/96) war ich noch nicht zufrieden. Es war recht umständlich, erst das BIOS zu übersetzen und dann bei jedem weiteren Schritt die erforderlichen Adressen zu berechnen. Dabei kann auch ganz schnell mal ein Fehler auftreten, der weniger versierte Anwender zur Verzweiflung bringen kann. Inzwischen habe ich eine einfache Lösung gefunden. Das Schlüsselwort heißt SPR-Format. In diesem Zusammenhang danke ich Jörg Linder für seine Zuarbeit und die umfangreichen Informationen, die ich regelmäßig erhalte.

Die Erstellung des eigenen Systems vereinfacht sich soweit, daß nur noch die gewünschten 8 Laufwerke in der Datei OPTION.INC einzutragen sind. Zur Erzeugung der Datei CPM.COM sind dann die drei Befehlszeilen

A>ASM ZBIOS=ZBIOS

A>LINK131 SYSTEM=CCP,ZDDOS.ZRL,ZBIOS [D1600,OS,NR]

A>SYSGEN

einzugeben bzw. aus einer SUB-Datei abzuarbeiten und die Datei CPM.COM ist fertig. Dazu noch ein paar Erläuterungen:

• Beim Assemblieren des BIOS wird die Konfiguration der Laufwerke festgelegt. Die beiden Festplattenpartitionen werden zur Kontrolle auf dem Bildschirm angezeigt.
  Ergebnis: ZBIOS.REL
  
  
• Beim Linken werden die drei Systembestandteile zu einer SPR-Datei zusammengefügt. Die Option D1600 ist erforderlich, damit die BIOS-Funktionen im DOS korrekt erzeugt werden, 1600H ist definiert durch die Größe von CCP+DOS und ändert sich nicht, solange die Standardgrößen CCP = 2k und DOS = 3,5k beibehalten werden. Zur Kontrolle zeigt der Linker zwei Adressen an, die denselben Wert (1600H) haben müssen. Als DOS kann ZDDOS oder ZSDOS angegeben werden.
  Ergebnis: SYSTEM.SPR
  
  
• Im dritten Arbeitsschritt wird die Datei SYSTEM.SPR gelesen, die Anfangsadressen des Systems berechnet und die endgültige Anpassung des Codes vorgenommen. Alle Zwischenschritte, die bisher mit POWER.COM und den DMP-Dateien nötig waren, entfallen damit. Die Adressen des erzeugten Systems werden zur Kontrolle aufgelistet. SYSGEN prüft danach noch, ob ZSDOS oder ZDDOS vorhanden ist und aktiviert den Uhrentreiber.
  Ergebnis: CPM.COM

Bei Eingabe von SYSGEN // erscheint eine kurze Anleitung. Die Entwicklung von SYSGEN ist jedoch noch nicht abgeschlossen. Ähnlich wie in MSYSG.COM soll noch die Installation der Druckertreiber und Koppeltreiber eingebaut werden und natürlich das Abspeichern in den Systemspuren der Diskette (Festplatte).

Zu den Dateien:

Kommandoprozessor (CCP)

In die Entwicklung des CCP habe ich bisher die wenigste Zeit investiert - aus dem einfachen Grund, da er eigentlich nur für die Entwicklungsphase gebraucht wird. Sobald das Z-System installiert ist, übernimmt ein wesentlich besserer ZCPR die Arbeit. Dennoch sollten mit dem CCP die Grundfunktionen eines CP/M-Systems fehlerfrei ausführbar sein. Unter diesem Gesichtspunkt erfolgte die Überarbeitung:

• Das Stellen der Uhr ist jetzt fehlerfrei möglich, nach dem Stellen der Uhr wird die Zeit nochmal ausgelesen und angezeigt.
  
  
• Das Kommando "H" listet alle CCP-Kommandos auf.
  
  
• Das Kommando "U" zum Wechsel des Userbereichs entfällt, dafür ist wie beim Z-System die Angabe des USER-Bereiches direkt hinter dem Laufwerks-Buchstaben möglich. Der USER-Bereich wird ständig im Prompt mit angezeigt. Dazu ein paar Beispiele:

A0>B:	Wechsel zu Laufwerk B:
B0>7:	Wechsel zu USER-Bereich 7
B7>A15:	Wechsel zu Laufwerk A: und USER 15
A15>D B0:	Anzeige des Verzeichnisses von B0:
A15>B0:POWER	Aufruf des Programms POWER auf B0:
A15>_

ZSDOS oder ZDDOS?

Aufmerksame Leser werden bemerkt haben, daß einmal von ZSDOS und zum anderen von ZDDOS gesprochen wird, wenn es um das neue System für den KC geht. Was hat es damit auf sich? Zunächst soviel:

Beide DOS-Varianten sind im ZSDOS-Paket enthalten. Beide DOS-Varianten belegen 3,5 KByte (wie das Original CP/M 2.2) und können gleichermaßen verwendet werden. Es gibt aber Unterschiede, so daß jeder für sich entscheiden muß, welches DOS er verwenden will. Ich habe mal die wichtigsten zusammengestellt:

Funktion	ZDDOS	ZSDOS
DOS-Suchpfad	nein	ja
^R in DOS-Funktion 10	nein	ja
DateStamper-Unterstützung	intern	extern

Aufgrund der Beschränkung der DOS-Größe auf 3,5 KByte konnten nicht alle Funktionen untergebracht werden. Für ZSDOS ist deshalb ein externer Speicherbereich erforderlich, wo das DateStamper-Modul geladen wird. ZDDOS enthält dagegen dieses Modul, dafür wurde auf zwei andere Funktionen verzichtet.

Der DOS-Suchpfad stellt dabei die Eigenschaft dar, die vielleicht am meisten fehlen könnte, um alle erforderlichen Dateien zu erreichen. Der Suchpfad ermöglicht es, wenn die Datei im angegebenen Verzeichnis nicht vorhanden ist, diese auch von anderen Laufwerken/USER-Bereichen zu laden. Vergleichbar ist diese Aktion mit dem unter MicroDOS möglichen Systemlaufwerk, jedoch ist der ZSDOS-Suchpfad komfortabler - es können 3 zusätzliche Verzeichnisse angegeben werden.

Ich habe mich für folgende Systemkonfiguration(en) entschieden:

• Startsystem mit ZDDOS, da sofort DateStamper aktiv ist. Das heißt, alle Aktionen vor Start des Z-Systems werden bereits mit Datum und Uhrzeit protokolliert.
  
  
• Z-System mit ZSDOS, da das DateStamper-Modul einfach im UMA (User Memory Area) von NZCOM installiert werden kann.
  
  
• ZDDOS für die geplante CAOS-Betriebsart, da unter CAOS ein Suchpfad nicht erforderlich ist, das Aktualisieren der Datumsinformationen erfolgt automatisch.

Neues System auch ohne Festplatte?

Vielleicht mag sich der eine oder andere noch nicht dazu entschlossen haben, das GIDE-Interface in sein D004 einzubauen und die Festplatte anzuschließen. Damit stellt sich die Frage, ob es sinnvoll ist, auch ohne Festplatte auf das neue System umzusteigen. Ich würde diese Frage mit einem eindeutigen 'ja' beantworten und das aus mehreren Gründen:

Mit ZSDOS/ZDDOS erhält man ein stabileres und schnelleres Betriebssystem, das vollständig im Z80-Code geschrieben wurde. Dabei erhält man eine vollständige Kompatibilität zu CP/M 2.2, was einige Programme mehr für den KC erschließt.

Die Verwendung von DateStamper mit ZDDOS ist auch ohne GIDE-Interface möglich, da das BIOS dann wie bisher mit der CTC-Uhr läuft. Diese Uhr muß dann aber nach jedem Bootvorgang neu gestellt werden. Für die Programme, welche die Uhr verwenden, gibt es keinen Unterschied, da die Schnittstelle identisch ist.

Der größte Vorteil ist aber wahrscheinlich der größere TPA. MicroDOS belegt den Speicher von C900H bis FBFFH, läßt also 50 KByte für Anwenderprogramme übrig. Bei der gleichen Laufwerksinstallation wird unter ZSDOS/ZDDOS nur der Bereich von D800H bis FBFFH belegt, wobei der CCP noch überschrieben werden kann. Es bleibt also von 100H bis DFFFFH und somit 55,75 KByte TPA.

Gleich noch ein Artikel zum neuen Betriebssystem!

von Jörg Linder

Inzwischen habe ich den ersten Stapel Handbücher vom Kopieren zurückbekommen, sodaß ich nun konkrete Angebote machen kann. Das neue System kann man in drei "Varianten" erwerben.

Wer sich nur mit der Software zufrieden gibt, bekommt diese mit der ersten Variante. Allerdings ist keinerlei Erläuterung, Anleitung oder Handbuch dabei. Für weniger Versierte und Einsteiger ist diese Variante also nicht zu empfehlen, sondern eher für "Puristen".

Dem "Normal-Anwender" wäre die zweite Variante zu empfehlen. Zur Software (die übrigens bei allen Paketen gleich ist) gibt es ein mehr als 80 Seiten starkes Handbuch namens "Utilities Guide" dazu. Es beinhaltet die Einführung zum neuen System und die ausführliche Vorstellung aller mitgelieferten 11 Utilities - daher auch der Name.

Für "High-End-User" ist das dritte Paket gedacht. Es enthält außer der Software den "User's Guide". In diesem mehr als 120 Seiten starken Handbuch sind neben den Abschnitten des "Utilities Guide" zwei weitere zu finden. Zum einen werden die neuen und erweiterten Funktionen etwas eingehender beschrieben und zum anderen wird eine allgemeine Installationsanleitung gegeben, die für nahezu jeden CP/M Rechner genutzt werden kann. Dank Mario Leubner bleibt uns diese (nicht ganz einfache) Arbeit erspart. Diese Abschnitte dürften nur für wenige von Interesse sein, weshalb sie zur Senkung der Kopierkosten aus dem "Utilities Guide" herausgenommen wurden.

In Kürze wird ein weiteres Handbuch verfügbar sein. Wie der Titel bereits verrät, wendet sich das "Programmer's Manual" hauptsächlich an die Programmierer. Im Gegensatz zu den anderen beiden Handbüchern ist dieses nicht A4 sondern nur A5 groß. Dadurch werden weniger Blätter benötigt (Kosten!) und außerdem hat ein "richtiger" Programmierer sowieso nie genügend Platz auf dem Schreibtisch. Allerdings kann ich zum jetzigen Zeitpunkt noch nicht sagen, was das mehr als 80 Seiten starke "Programmer's Manual" kosten wird. Auf alle Fälle halte ich Euch aber auf dem Laufenden.

Ein kleines Problem gibt es im Hinblick auf die GIDE-Interfaces. Bei mir liegen momentan noch 3 vollständig bestückte und geprüfte Exemplare. Dies sind auch die letzten der ersten Serie, die Tilmann Reh aufgelegt hat. Eine weitere Kleinserie lohnt sich aber erst ab einer bestimmten Stückzahl, sodaß das bisherige "Klecker"-Bestellsystem nicht mehr funktioniert.

Wer also noch ein bestücktes und geprüftes Interface haben möchte, muß seine Bestellung spätestens bis zum 30. September 1996 an mich richten. Danach wird es nur noch Bausätze geben. Die sind zwar billiger, aber man hat auch mehr Arbeit (vor allem, wenn nicht alles auf Anhieb funktioniert). Dies war wieder einer meiner fast schon legendären Aufrufe. Hoffentlich erhalte ich diesmal mehr Echo.

Natürlich sind auch die Preise interessant. Leider hat die Post in der Zwischenzeit bei den Päckchen wieder einmal zugelangt! Trotzdem denke ich, daß alles noch in einem vertretbaren Rahmen bleibt.

Bezüglich der aktuellen Preise, Verfügbarkeit und Zahlungsmodalitäten bitte mit mir Kontakt aufnehmen.

Jörg Linder, Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein.

Für alle Unentschlossenen und Skeptiker möchte ich noch auf den Hinweis in Mario's Artikel aufmerksam machen. Auch ohne Festplatte lohnt sich der Umstieg auf das neue System - 55,75 kByte TPA dürften ein schlagendes Argument sein. Und spätestens nach dem Ausschalten des Rechners dürfte "RAM-Disk-Fanatikern" der Vorteil einer Festplatte klar werden!

Die Zukunft beginnt mit "Z" - Teil 2

von Jörg Linder

In der letzten Ausgabe hatte ich bereits angedroht, diese Artikelreihe fortzuführen. Diesmal dreht sich alles um "ZCPR", den 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! Wie Mario Leubner bereits in der letzten Ausgabe andeutete, kann ein ZCPR 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überhinaus 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.

So, das war jetzt aber eine ganze Menge. (Soviel hatte ich gar nicht geplant.) Bis zur nächsten Ausgabe werden sicherlich schon einige das neue System installiert haben. Dann kann ich vielleicht schon neben ein paar Anwendungsbeispielen auch Problemlösungen anbieten.