KC-News 1/1996

Top-Themen:

• neue Standards
• Werkzeuge zur Textverarbeitung
• EDIPIC33
• Programmieren mit der SYSLIB

Ein paar Worte zur Einleitung

von Jörg Linder

Heute sind es wirklich nur ein paar Worte, denn mir will absolut nichts einfallen. Eigentlich gibt es ja kaum Neuigkeiten, die sich nicht schon herumgesprochen hätten.

Treffen in Erfurt

Offenbar war es nicht ganz eindeutig aus den Artikeln der letzten KC-News herauszulesen, daß das nächste Treffen in Erfurt stattfinden wird. Zumindest gab es Rückfragen in dieser Richtung. Wir geloben Besserung beim nächsten Mal!

Für dieses Jahr ist jedenfalls alles geregelt. Außer den KC-News sollte sich im Briefumschlag noch ein Zettel mit der Wegbeschreibung befinden. Hoffentlich finden wir alle die Jugendherberge.

Wie im letzten Jahr wurde die Mitgliederliste erweitert. All diejenigen, die sich bereiterklärt haben, noch jemanden mitzunehmen, haben wieder ein Kreuzchen abbekommen. Wer also "aufspringen" will, muß sich mit dem entsprechenden Mitglied persönlich in Verbindung setzen. Für alle anderen Fragen in Bezug auf das Treffen ist und bleibt aber Klaus Witzenhausen der Ansprechpartner.

Auch in diesem Jahr dürfen wir wieder Gäste begrüßen. Die beiden Mühlhäuser, Frank Pischel und Helmut Huhnstock, werden wieder vorbeischauen. Außerdem haben wir die Zusicherung von Tilmann Reh, dem Entwickler des GIDE-Interfaces. Eventuell kommt auch Helmut Jungkunz, wenn ich ihn dazu überreden kann.

Festplatte am KC

Eine freudige Nachricht, die sich dank modernster Kommunikationstechnologien wie ein Lauffeuer ausgebreitet hat, kennen vielleicht einige noch nicht: Mario Leubner ist es gelungen, eine Festplatte mittels GIDE-Interface an das D004 anzuschließen und ins System einzubinden.

Seit einiger Zeit hat er eine 10- und eine 32-MB-Partition, die sogar etwas schneller sind als die RAM-Floppy. Je nachdem, wie gut er voran kommt, kann er uns auf dem Treffen vielleicht schon das zukünftige "MicroDOS" zeigen.

So, jetzt will ich Euch nicht länger vom Rest der KC-News abhalten.

Euer Redakteur

Wieder neue BASIC-Spiele

von Jörg Linder

Von unserem aktivsten Nicht-Mitglied, Herrn Riehl, habe ich wieder neue Spiele bekommen. Auch dieses Mal sind sie alle auf einem KC 85/4 unter BASIC lauffähig.

Besondere Mühe hat sich Herr Riehl bei der einheitlichen Gestaltung der Oberflächen gemacht. Egal, welches Programm man startet, mit <H> bekommt man immer eine Hilfestellung.

Ansonsten sind die Programme eigentlich selbsterklärend. Technische Probleme dürften nicht mehr auftreten, sondern nur noch strategische - wie bekomme ich schnellstmöglich viele Punkte?

Herr Riehl würde sich freuen, wenn die Programme

FLAECHE, HALMA, KAROS, KREUZ, PIPELINE, ROLLY und WUERFEL

Zustimmung finden. Er wünscht uns jedenfalls viel Spaß.

Neue Standards

von Jörg Linder

Große Ereignisse werfen ihre Schatten voraus, heißt es. Kleine Ereignisse an, in und um unsere Kleincomputer auch! Bereits im September des vergangenen Jahres haben wir uns zu einem "Arbeitstreffen" versammelt. Wir das sind: Mario Leubner, Ralf Kästner, Uwe Felgentreu, Frank Dachselt, Hendrik Wagenknecht und Jörg Linder.

Aufgrund der Hardwareveränderungen am KC-System, die bereits realisiert wurden bzw. bevorstehen, ist die Festlegung neuer verbindlicher Standards notwendig geworden. Diese Standards betreffen sowohl das CAOS- als auch das MicroDOS-Betriebssystem. An dieser Stelle möchte ich jedoch darauf hinweisen, daß die erwähnten Veränderungen an der Hardware nur Empfehlungen darstellen. Auch weiterhin soll die Grundausstattung der Originalgeräte genügen, jedoch wird neue Software diese Erweiterungen bzw. Veränderungen unterstützen.

Auf unserem Treffen wurden folgende Punkte besprochen:

MicroDOS

Mangels der Quelltexte für MicroDOS konnten nur allgemeine Festlegungen getroffen werden. Inzwischen liegt der Quelltext des KC-BIOS vor, so daß Mario Leubner bereits Anpassungen vornehmen konnte. Desweiteren ist ZSDOS verfügbar geworden, welches auf dem nächsten Clubtreffen vorgestellt werden soll und eventuell als Ersatz für das MicroDOS eingesetzt wird.

Zusätzlich zum vorhandenen EPROM im D004 wurde der Einbau eines weiteren beschlossen. Er erhält die Moduladresse 'F8', so daß weiterhin mit 'JUMP FC' das Originalsystem gestartet werden kann. Der neue EPROM soll von CAOS 5.0 unterstützt werden. Dazu bedarf es noch einer Abstimmung über den Inhalt, speziell die Bereitstellung von Treibern (z. B. für Maus).

Die Erweiterung des RAMs im Floppy Disk Basis ist (vorerst) nicht vorgesehen, da dies einen zu großen Aufwand darstellt. Ein gebanktes System wird es demzufolge nicht geben. Vielmehr soll das MicroDOS auf einen CP/M 2.2 kompatiblen Stand "abgespeckt" werden. Sinnvolle BDOS-Funktionen, die oberhalb der Definition für CP/M 2.2 liegen, sollen jedoch erhalten bleiben. Gegenüber Anwenderprogrammen wird die Versionsnummer 2.2 gemeldet. Auf keinen Fall soll die TPA-Grenze weiter herabgesetzt werden.

Anstelle des originalen BDOS in 8080-Code soll ein alternatives und leistungsfähigeres System eingebunden werden. Das eingangs erwähnte ZSDOS wird derzeitig auf Verwendbarkeit geprüft. Desweiteren soll versucht werden, den CCP auszulagern. Datumsstempel (Datestamps) für Dateien werden wahrscheinlich nicht eingeführt.

Die von Mario Leubner verbesserte zentrale Abfrageschleife (ZAS) soll über *.ZAS-Dateien (wie in den letzten KC-News vorgestellt) in das neue System eingebunden werden. Die Möglichkeit, ZAS mittels einer COM-Datei nachzuladen, soll jedoch weiterhin bestehen bleiben. Eventuell soll der Code für ZAS z. T. im EPROM F8 abgelegt werden. Für die Installation des neuen Systems wird voraussichtlich eine weiterentwickelte Variante von MSYSG.COM verwendet.

Über die Laufwerkszuordnungen innerhalb des neuen Systems konnte kein endgültiger Konsens gefunden werden. Eine Unterstützung von 16 Laufwerken (A: bis P:) ist geplant. Die Festplatte soll in 2 bis 8 Partitionen aufgeteilt werden, wobei nur Festplatten bis 80 MB sinnvoll erscheinen.

Darüberhinaus soll die Möglichkeit geschaffen werden, Formatdefinitionen über ein Tool aus der Kommandozeile heraus ändern zu können. (Format-Manager)

Neue Handbücher (speziell für Programmierer) werden erforderlich. Die Erarbeitung wird Jörg Linder auf der Grundlage von Dokumentationen der Programmierer übernehmen.

CAOS

Im Zusammenhang mit dem neuen Betriebssystem des Floppy Disk Basis wird die Entwicklung eines neuen DEP ebenfalls unumgänglich. Für die Anwenderprogramme soll sich die Schnittstelle jedoch nicht ändern. Somit wird auch die Nutzung der Festplatte aus derzeitiger Sicht kein Problem darstellen.

Eine Einigung über einen endgültigen Maustreiber konnte noch nicht erzielt werden. Mario Leubner wird eine weitere Variante erarbeiten und vorstellen.

In Zukunft soll eine "SYSLIB" (Sammlung von vorgefertigten Routinen) analog der unter CP/M existierenden erarbeitet werden. Da es jedoch keinen Linker unter CAOS gibt, steht die Form dieser Bibliothek noch nicht fest. Compiler für BASIC oder andere Hochsprachen werden in nächster Zeit für CAOS nicht entwickelt. Der Aufwand scheint derzeit nicht gerechtfertigt.

Über die Neuauflage von Modulen in Kleinstserien wurde nachgedacht. Sie wäre möglich, sofern geeignete Unterlagen (Leiterplattenlayout) vorhanden sind. Auch modifizierte Ausführungen sind denkbar.

Die Definition eines Shell-Eintrittspunktes unter CAOS konnte nicht erfolgen, da es noch kein verbindliches Speichermanagement-System gibt. Erste Gedanken wurden dazu geäußert, jedoch genügten sie nicht, um einen Standard daraus zu entwickeln. Dieses Problem soll aber weiterhin im Auge behalten werden, um vielleicht später eine Lösung herbeizuführen.

Im Anhang werden die getroffenen Vereinbarungen für die Speicheraufteilung des CAOS wiedergegeben.

Allgemeines

Ralf Kästner zeigte die Arbeitsversion von UNIPIC 2.0, das nun Cursor- und Maussteuerung voneinander getrennt behandelt. So daß man mit einem frei beweglichen Mauspfeil im gesamten Programm arbeiten kann. Die Vorstellung war sehr beeindruckend.

Uwe Felgentreu wird im nächsten Jahr eine Mailbox für KC-User einrichten. Eine Zusammenarbeit mit Helmut Jungkunz (ZNODE 51) ist geplant. Über den Umfang der Box und den Anschluß an User-Netze steht noch nichts fest.

Als zukünftige Datenträger werden 3,5"-Disketten angesehen. In der Mitgliederliste der KC-News werden daher zusätzliche Symbole eingeführt. Mario Leubner wird versuchen, HD-Formate nutzbar zu machen, jedoch wird es ohne Veränderungen der Hardware mit unserem Floppy Disk System nicht möglich sein.

Frank Dachselt will TRANSFER.COM weiter ausbauen und damit zum standardmäßigen Austauschprogramm für MS-DOS-Disketten machen.

Der Anschluß eines Modems stellt nach wie vor eines der größten Probleme dar. Zum einen bietet CAOS kein Filesystem und zum anderen befindet sich unter MicroDOS die SIO nicht im Prozessorsystem des D004. Momentan scheint ein interruptgesteuerter Austausch über den Koppel-RAM den einzigen möglichen Lösungsweg darzustellen.

Hendrik Wagenknecht hat angeboten, anderen Usern beim Anschluß einer Tastatur des P8000-Terminals behilflich zu sein. Nach einer besseren Lösung für die Tastatur wird jedoch weiterhin gesucht, da der Bestand an P8000- und ähnlichen Tastaturen nahezu erschöpft sein dürfte.

Eine Satzung wird beim nächsten Treffen des KC-Clubs vorgelegt. Dann soll über deren Notwendigkeit und Inhalt abgestimmt werden.

Anhang

Speicheraufteilung unter CAOS

0000 - 0100
FLOAD

kann bei Bedarf überschrieben werden, jedoch auf eigene Gefahr des Programmierers, da dieser Bereich nicht reserviert ist

Vordergrundprogramme können diesen Bereich während der Laufzeit nutzen; bevorzugt für FLOAD inkl. Dateinamen

 

0100 - 0200
Systemarbeitszellen

dürfen nicht geändert werden

 

0200 - 7FFF
frei

RAM8-Blöcke frei

Interrupttabelle

Ergänzend zu den Vereinbarungen im System-Handbuch des KC 85/4 werden folgende Festlegungen getroffen:

01C4...01D2

frei für anwenderspezifische Systemerweiterungen; der Bereich darf nicht zur temporären Nutzung von Interrupts innerhalb eines Anwenderprogrammes verwendet werden

 

01D4

CTC Kanal 2 des 2. M003 [COM 3/4]

 

01D6

CTC Kanal 3 des 2. M003 [COM 3/4]

 

01D8

SIO des 2. M003 [COM 3/4]

 

01DA

SIO des 1. M003 [COM 1/2]

 

01DC

CTC Kanal 2 des 1. M003 [COM 1/2]

 

01DE

CTC Kanal 3 des 1. M003 [COM 1/2]

 

01E0

PIO Kanal A eines Joystick-Modules (M008 bzw. M021)

 

01E2

Empfangsroutine der SIO des 1. M003, solange die COM-Ports nicht initialisiert sind

 

01E4...01EE

entsprechend System-Handbuch

Die Interrupttabelle für temporäre Anwenderprogramme liegt auf dem Adreßbereich 0100 bis 011E. Sie ist nur für die Laufzeit des jeweiligen Vordergrundprogrammes gültig. Die Begrenzung durch den Systemstack ist zu beachten.

IRM-Arbeitszellen / -bereiche

Ergänzend zu den Vereinbarungen im System-Handbuch des KC 85/4 werden folgende Festlegungen getroffen:

A800

Erkennungsbyte V.24-Module

 

A801...A81F

Init-Tabellen V.24-Drucker

 

A820

Modulsteckplatz 1. M003

 

A821

Modulsteckplatz 2. M003

 

A822...A82F

Verwaltungsparameter COM 1 bis COM 4

 

A830...A8FF

reserviert für Maus [geretteter Maushintergrund; Aufbau wird noch festgelegt]

 

A900...ACFF

für anwenderspezifische Systemerweiterungen reserviert (z. B. Treiber für UOUT1/2 bzw. UIN1/2)

 

AD00...B1FF

Video-RAM Bild 1

 

B200...B6FF

Video-RAM Bild 0

 

B700...B77F

Kassetten-Puffer

 

B780...B7FF

Monitor-RAM [alle Zellen durch System belegt]

 

B800...B8FF

Modulsteuerwortspeicher

 

B900...B99B

Funktionstastenspeicher

 

B99C...B9FF

Fenstervektorspeicher

 

BA00...BFFF

Vordergrundprogramme können diesen Bereich während der Laufzeit nutzen; bevorzugt für CCTL2/3 und SERVICE bzw. DIENST

TTOOLS - Werkzeuge zur Textverarbeitung

(Copyright © 1984 Michael M. Rubenstein,
Übersetzung: Frank Dachselt)

Ich habe einige Programme gefunden, die ich als äußerst nützlich zur Bearbeitung verschiedener Textdateien ansehe. Textverarbeitung ist eine alltägliche Aufgabe für Kleincomputer und viele Programmierer haben daran gearbeitet. Darum hielt ich es für unnötig, von vorn anzufangen. Die meisten der folgenden Programme stammen von anderen Programmieren. Ich habe verschiedene Modifikationen vorgenommen, mal mehr - mal weniger, und mein eigenes Run-Time-System zur Compilierung genutzt.

Durch den verschiedenen Ursprung der Programme ist auch eine Vielzahl von Programmierstilen vertreten. Ich habe nicht den Versuch unternommen, das zu ändern, außer ich einigen wenigen Fällen, wo ich das Original nicht akzeptabel fand.

Ich habe einige Veränderungen vorgenommen, um ein konsistentes Nutzerinterface zu schaffen. Außer SORT (da hier der Speicherplatz besser für den Sortieralgorithmus benutzt werden sollte) erzeugen alle Programme eine Hilfeseite, wenn sie mit "?" als ersten Parameter aufgerufen werden. Zum Beispiel:

grep ?

Gemeinsame Eigenschaften

Das Run-Time-System, das zur Kompilierung genutzt wurde, bietet eine Reihe nützlicher Funktionen. Ein- und Ausgaben von der Konsole können in ein File oder zu einem Gerät umgeleitet werden. Die Umleitung der Eingabe ist in diesen Programmen wahrscheinlich nicht so wichtig, da sie meistens aus einen File kommen wird, umso nützlicher ist dafür die Umleitung der Ausgabe.

Die Umleitung der Eingabe erfolgt durch einen Parameter der Form

<filename

und die Umleitung der Ausgabe mit einem Parameter der Form

>filename

Anstelle eines Dateinamens (als Parameter oder Umleitung) kann auch eines der folgenden Geräte angegeben werden:

lst:	CP/M-List-Gerät
rdr:	CP/M-Reader-Gerät
pun:	CP/M-Punch-Gerät
con:	CP/M-Konsole
dum:	ein Dummy-Gerät, Fileende bei Eingabe, Senke bei Ausgabe

Bei Diskettendateien können das Laufwerk und die User-Nummer im "DU"-Format von ZCRP2 angegeben werden. Zum Beispiel:

8:file	Datei im Userbereich 8 auf aktuellem Laufwerk
b8:file	Datei im Userbereich 8 auf Laufwerk B
b:file	Datei im aktuellen Userbereich auf Laufwerk B

Dateinamen können Flags enthalten, die in eckigen Klammern anzugeben sind. Um eine solche Option auszuschalten, ist ein Minus voranzustellen. Das Einschalten geschieht mit einem Plus oder durch eine vorzeichenlose Angabe. Zum Beispiel:

lst:[e] oder lst:[+e]

file.txt[-b+e]

Die folgenden Flags können verwendet werden:

b

Erzeugen einer BAK-Datei, wenn die Ausgabedatei bereits existiert (nur bei Dateiausgabe auf Diskette);

 

d

Löschen der Datei beim Schließen (nur bei Diskettendateien, für die Ausgabe unüblich aber möglich);

 

e

Zusätzliches Echo zur Konsole (alle Dateien außer con: und dum:).

Für Ausgabedateien, die als Parameter angegeben sind, ist das b-Flag automatisch gesetzt, kann aber mit [-b] ausgeschaltet werden. Bei umgeleiteten Ausgaben ist dieses Flag nicht automatisch gesetzt.

In allen Fällen kann die Ausgabedatei den gleichen Namen wie die Eingabedatei besitzen. Die Ausgabedatei bekommt den Namen erst, wenn sie geschlossen wird, sodaß bei einem Fehler oder einer Unterbrechung während der Programmabarbeitung die ursprüngliche Version nicht zerstört wird.

Außer bei CHANGE, GREP und TR wird stets die Konsole benutzt, wenn keine Ausgabedatei angegeben wird. Die drei genannten verwenden dann zur Ausgabe die gleiche Datei wie zur Eingabe.

Vorsicht ist bei WordStar-Dateien geboten, da Bit 7 stets zurückgesetzt wird und so weiche Leerzeichen und Zeilenumbrüche in ihre harten Versionen geändert werden.

Beschreibung der Programme

Es folgt eine kurze Beschreibung der Programme. Die genaue Syntax kann mittels des "?"-Parameters erhalten werden.

CHANGE

Änderung eines Strings in einen anderen in der gesamten Datei. Die Strings sind die gleichen, wie sie auch in GREP genutzt werden (siehe unten). Im Normalfall wird im zu suchenden String nicht zwischen Groß- und Keinschreibung unterschieden und der String, in den dieser umgewandelt wird, in Kleinbuchstaben angenommen, solange nicht die \u-Option benutzt wird.

 

DETAB

Entfernen aller Tabulatoren aus einer Datei und Ersetzen durch Leerzeichen.

 

DF

Vergleich zweier Textdateien.

 

ENTAB

Einfügen von Tabulatoren in eine Datei an Stellen, wo dieses möglich ist.

 

GREP

Gereral Regular Expression Print.
Suchen eines Strings in einer Liste von Dateien. Das Programm akzeptiert Jokerzeichen in den Dateinamen. Leerzeichen im Suchstring müssen in Anführungszeichen oder Apostrophe eingeschlossen sein. Wegen der Komplexität des Programmes hier ein paar Beispiele:

 

Schreibe alle Zeilen, die mit einem Tabulator beginnen, von file1 nach file2:
grep -f ^\t file1 >file2

 

Schreibe alle Zeilen, die nicht mit einem "M" beginnen, von file1 nach file2:
grep -f -a ^[^\um] file1 >file2

Zeige jedes Auftreten von "fprintf" und "sprintf" (aber nicht von "printf") in allen C-Programmen im LW B: User 4:
grep -a [fs]printf b4:*.c

 

MPRINT

Drucken mehrerer Dateien in Spalten.

 

SORT

Ein allgemeines Sortierprogramm für lange Dateien.
Dieses komplexe Programm kann eine Menge leisten. In einigen Fällen wurde allerdings die Geschwindigkeit zugunsten der Funktionalität geopfert. Es sollte nicht erwartet werden, daß dieses Programm die "Sort Olympics" gewinnt.

 

SPLIT

Zerteilen einer Datei in mehrere andere. Das Programm ist nützlich in Verbindung mit MPRINT für den mehrspaltigen Ausdruck einer Datei.

 

TR

Übersetzen von Zeichen nach einer Übersetzungstabelle.

 

UNIQ

Entfernen doppelt auftretender Zeilen.

 

WC

Zählen von Worten, Zeilen und Zeichen. Es wird eine
sehr einfache Methode benutzt: Ein Wort ist ein String, der von Leerzeichen umschlossen ist. Es kann eine Liste von Dateien verwendet werden. Jokerzeichen sind erlaubt.

Ein Hinweis zur Nutzung der Programme unter MicroDOS

Alle beschriebenen Programme veranlassen bei ihrer Beendigung einen Warmstart des Systems. Sie sind daher nicht für automatisierte Abläufe innerhalb der normalen MicroDOS-SUB-Dateien geeignet (höchstens als letzte Kommandozeile in einer solchen Datei). Einen Ausweg bietet die Verwendung des SUBMIT-Kommados. Hierbei ist wiederum zu beachten, daß das Zeichen '^' nicht für die Parameternotation verwendet werden kann, da es SUBMIT als Kennzeichnung von Control-Codes interpretiert.

Gibt es EDIPIC33 ?

von Wolfram Schütze

Ja, neuerdings gibt es das. Zur Erinnerung: Die Entwicklung von Grafikprogrammen durch Ralf Kästner begann 1990 mit dem EDIPIC32, das dann in den KC-News 2/92 vorgestellt wurde. Die Weiterentwicklung über EDIPIC40 bis UNIPIC ist sicher besser bekannt und wurde von ihm in den KC-News 2/95 auch recht ausführlich beschrieben.

Was ist besonderes am EDIPIC32? Es läuft auf dem KC85/3! Der Nachteil ist, daß es, was die Arbeit mit Bildern und Zeichensätzen betrifft, nur Kassettenbetrieb zuläßt.

Um die vielen Bilder, die mit den Beilage-Disketten unter's Volk gebracht werden, auch nutzen zu können, blieb mir als KC85/3-Betreiber nur die Möglichkeit, das EDIPIC32 diskettenfähig zu machen. Ich erhielt von Ralf Kästner bereitwillig die Quelltexte nebst wertvollen Hinweisen.

Die Umprogrammierung scheint gelungen zu sein. Es gibt also jetzt ein EDIPIC33, d. h. Version 3.3. Da die IRM-Konvertierung zwischen /3 und /4 sowieso enthalten ist, können alle PIP/PIF-Dateien geladen, ggf. bearbeitet und als PIC-Dateien wieder auf Diskette gespeichert werden.

Interessenten können sich direkt an mich wenden.

Programmieren mit der SYSLIB

von Jörg Linder

Einleitung

Welcher Assemblerprogrammierer kenn das nicht: Man erarbeitet sich jede Zeile Quelltext mühsam, erfindet das Fahrrad zum zigsten Mal neu und heraus kommen ein paar klägliche Bytes Programm. Wäre es nicht toll, wenn man auf vorgefertigte Routinen zurückgreifen könnte? Eine Sammlung von Programmroutinen für das CP/M-System gibt es in Form der SYSLIB.

Bereits in den 80er Jahren hat sich Richard Conn bemüht, Routinen für wiederkehrende Aufgaben zu sammeln und zu dokumentieren. Im Laufe der Jahre ist die SYSLIB gewachsen, die Routinen wurden debuggt, überarbeitet und optimiert, so daß sie nun eine solide Basis darstellen. Natürlich gibt es auch hier einen Haken! Die SYSLIB kommt aus Amerika, demzufolge sind alle Dokumentationen nur in englischer Sprache verfügbar.

Neben der eigentlichen SYSLIB findet ihr auf der Beilagen-Diskette auch die Help-Dateien dazu. Diese können mit dem Programm HILFE.COM angesehen werden, welches eine ältere Version des Z-System Programmes HELP.COM darstellt, die auch unter CP/M läuft. Wenn man wissen will, wie's funktioniert, braucht man nur "HILFE" einzugeben. Die Datei HILFE.HQP (gesqueezt) enthält alle notwendigen Informationen.

Für das Betrachten der Help-Dateien zur SYSLIB muß man "HILFE SYSLIB.HLP" eingeben. Die hierarchisch aufgebauten Hilfeseiten erreicht man über den jeweils vorangestellten Buchstaben. Noch sind alle Texte in englischer Sprache, aber vielleicht hat ja jemand Zeit und Muße, die Dateien ins Deutsche zu übertragen...

Um aus diesem Artikel eine Art "Programmierkurs" zu machen, habe ich mir ein Projekt herausgesucht, anhand dessen man (m)eine Vorgehensweise erkennen kann. Als Redakteur der KC-News muß ich mich mit den verschiedensten Dateiformaten herumplagen. Zwar gibt es schon diverse Konvertierungsprogramme, aber jedes hat seine Schwächen. Was lag näher, als selbst mal eine Variante zusammenzustellen.

Das hier vorgestellte Programm ist universell einsetzbar und kann individuell erweitert werden. Es ist nicht nur auf Text­ sondern auch auf andere Dateien anwendbar. Selbstverständlich erhebe ich nicht den Anspruch auf Vollkommenheit. In erster Linie möchte ich damit eine Anregung geben, was mit der SYSLIB möglich ist und den einen oder anderen ermutigen, es selbst mal mit dem Programmieren zu versuchen.

Das Programm UNIKON

In diesem Kurs wird mit Hilfe der SYSLIB ein UNIverselles KONvertierungsprogramm "zusammengeschustert". Das Prinzip eines Konvertierungsprogrammes ist doch immer gleich: Quelldatei einlesen, Daten konvertieren, Zieldatei ausgeben. Für den ersten und letzten Schritt habe ich mich in der SYSLIB nach passenden Routinen umgesehen und bin fündig geworden. Hier die Übersetzung der Help-Texte:

Die folgende Dokumentation beschreibt die Reihe von byteorientierten Dateiein- und -ausgaberoutinen der SYSLIB. Mit diesen Routinen ist es möglich auf eine außerordentlich einfache Weise, sequentiell Byte für Byte von Dateien zu lesen (GET) und in Datei zu schreiben (PUT).

Ein Programm, das diese Routinen verwendet, muß zuerst die entsprechende Datei öffnen, bevor es irgendwelche Operationen ausführt. Anschließend wird der Verarbeitungsprozeß mit der geöffneten Datei durchgeführt. Ist der Prozeß beendet, muß die Datei geschlossen werden. (Das Schließen ist nicht zwingend erforderlich, wenn die Datei nur gelesen wurde, bei Schreiboperationen in eine Datei ist es jedoch unumgänglich.)

In der SYSLIB sind vier Sets von Routinen für byteorientierte Dateiein- und -ausgabe enthalten. Dies sind:

Dieses System erlaubt es, bis zu 8 Dateien gleichzeitig geöffnet zu halten - 4 geöffnete Dateien für die Eingabe (Input mittels GET) und 4 geöffnete Dateien für die Ausgabe (Output mittels PUT). Das folgende Beispiel zeigt, wie der Quellcode aussehen könnte, wenn diese Routinen für zwei Dateien benutzt werden.

EXT FI0$OPEN    ; Deklaration der externen Label
EXT FO0$OPEN    ; (Bezug auf Bibliothek)
EXT FI0$CLOSE
EXT FO0$CLOSE
EXT F0$GET
EXT F0$PUT
...
LD DE,FCBI      ; Zeiger auf FCB der Eingabedatei
CALL FI0$OPEN
LD DE,FCBO      ; Zeiger auf FCB der Ausgabedatei
CALL FO0$OPEN
...
[Verarbeitungsroutine - enthält CALL F0$GET und CALL F0$PUT]
...
CALL FI0$CLOSE  ; Dateien schließen
CALL FO0$CLOSE
...
END

Es ist dabei zu beachten, daß nur die wirklich verwendeten Routinen in den EXT-Anweisungen aufgeführt werden. Alle nicht benötigten Routinen sollten nicht aufgeführt werden, da sie zusätzlichen Speicher belegen.

Jedes Set von INPUT OPEN, INPUT CLOSE, OUTPUT OPEN, OUTPUT CLOSE, GET und PUT Routinen ist in einem Modul der Bibliothek enthalten. Demzufolge wird bei Bezug einer dieser Routinen das gesamte Modul geladen und alle enthaltenen Routinen sind für den Nutzer bzw. Programmierer verfügbar (vorausgesetzt, sie wurden als EXTerne Bezüge deklariert) ohne darüber hinaus zusätzlichen Speicher zu belegen. Alle Routinen mit einer Null, also FI0$OPEN, FI0$CLOSE, FO0$OPEN, FO0$CLOSE, F0$GET und F0$PUT, sind in einem Modul enthalten. Dies gilt ebenso für die anderen Sets.

Die CLOSE-Routine für die Ausgabe (FOn$CLOSE) wird immer benötigt. Sie füllt den Rest des Blocks mit Control-Z, gefolgt von <NULL>-Bytes und schließt die Datei ordnungsgemäß. Die CLOSE-Routine für die Eingabe (FIn$CLOSE) wird nur dann benötigt, wenn später mit der entsprechenden OPEN-Routine eine andere Datei geöffnet werden soll. FIn$CLOSE setzt nur das OPEN-Flag der Datei zurück. (Es wird benutzt, um der GET-Routine anzuzeigen, daß die Datei ordnungsgemäß geöffnet wurde.)

<<< Mit Rücksichtnahme auf die Downloadzeiten wurde auf die vollständige Beschreibung der einzelnen Routinen an dieser Stelle verzichtet. >>>

Der Quelltext

Den weniger interessierten Lesern und auch dem Kopierer möchte ich das vollständige Listing in gedruckter Form ersparen. Ich habe den Quelltext in mehrere Dateien aufgeteilt, um eine einfache Umsetzung (z. B. in eine andere Sprache) zu ermöglichen. Natürlich kann man auch alles aus einem Stück machen. Die Datei "-UNIKON." enthält eine kurze Beschreibung der mitgelieferten Dateien. Darüberhinaus habe ich nicht mit Kommentaren in den Quelltexten gespart.

Für alle, die noch nicht mit externen Bezügen gearbeitet haben, möchte ich nachfolgend etwas genauer darauf eingehen.

Grundsätzlich kann jedes Unterprogramm in einer separaten Datei abgelegt werden. Dazu darf jedoch während des Assemblierens keine feste Adresse feststehen. Auf diese Weise gewinnt man eine sogenannte relozierbare Datei (Dateityp im Normalfall .REL). Erst beim Linken (zu deutsch: verbinden) werden die Bezüge aufgelöst und die entsprechenden Adressen eingetragen. Jedoch nicht alle Assembler können .REL-Dateien erzeugen und nicht alle Linker sie verarbeiten.

Wer sich selbst eine Art SYSLIB zusammenstellen möchte kann dies tun. Dazu müssen alle Marken (Label) in der Datei, die für andere Routinen verfügbar sein sollen, zugänglich gemacht werden. Dies geschieht mit dem PUBLIC-Befehl. Hat man mehrere .REL-Dateien, kann man sie mit Hilfe eines speziellen Programmes zu einer Bibliothek zusammenführen. (Diese Art Bibliotheken entsprechen nicht den oben erwähnten "Libraries".) Möchte der Programmierer vorgefertigte Routinen verwenden, muß er sie über den EXT-Befehl deklarieren. Erst danach können im weiteren Programm darauf CALLs ausgeführt werden.

Die Benutzung der EXT-Befehle ist im Quelltext gut zu erkennen. Sinnvollerweise sollte man alle Deklarationen, Vereinbarungen etc. zu Beginn aufführen. Desweiteren sollte man auch nicht vergessen, ab und an Kommentare einzufügen. (Als ordentlicher Programmierer macht man das - und ordentliche Programmierer wollen wir doch werden!)

Dem Linker muß natürlich noch mitgeteilt werden, daß und vor allem in welcher Bibliothek er nach den Routinen suchen soll. Leider kann ich hier keine allgemeingültige Anleitung geben, wie der Quelltext zu assemblieren und zu linken ist, da jeder Linker eine andere Syntax verwendet. Hier sollte man das Handbuch und eventuelle Hilfe-Dateien zu Rate ziehen.

Für M80/L80 müßten die Kommandozeilen lauten:

M80 =UNIKON10/R/Z
L80 UNIKON10,SYSLIB/S,UNIKON10/N/E

Wer glücklicher Besitzer von SLR180 und SLRNK ist, gibt folgendes ein:

SLR180 UNIKON10/R
SLRNK /A:0100,UNIKON10,SYSLIBS/S,UNIKON10/N/E

Und wie geht's weiter?

An dieser Stelle erstmal gar nicht. In der Hoffnung, daß dieser Kurs sein Ziel zumindest ansatzweise erreicht hat, beende ich ihn gleich. Doch hier noch ein paar Anregungen, in welcher Weise das Programm noch erweitert werden könnte:

• Angabe von Laufwerk und Nutzerbereich für Quell-, Ziel- und Overlaydatei
• Ausgabe von Informationen auf dem Bildschirm (z. B. Anzahl konvertierter Zeichen)
• automatische Suche der Overlaydatei auf anderen (definierten) Laufwerken
• Erweiterung des Modulformates, um Informationen unterzubringen wie z. B. Text für Meldung, welche Konvertierung erfolgt oder automatische Dateityperkennung und -umbenennung

Vielleicht (oder hoffentlich) ist nun so mancher ermutigt worden, es auch mal mit dem Programmieren zu versuchen. Wenn dies der Fall wäre, hätte ich mein Ziel erreicht! Über eine Reaktion würde ich mich jedenfalls freuen.