KC-News 3/1997

Top-Themen:

• ZAS beendet Speicherkriege im Grundgerät
• Beschreibung LINK v1.31
• ein Maustreiber für alle Fälle
• HELP-System für ZCPR3

Ein paar Worte zur Einleitung

von Jörg Linder

So, nun sitze ich wieder mal vor einem leeren Bildschirm und soll Euch etwas Sinnvolles mitteilen. Von Frank kam das Stichwort ,,Motivation der Clubmitglieder``, aber ich denke doch, daß wir alle hochmotiviert sind! (Unmotivierte haben sofort die rechte Hand zu heben und Besserung zu schwören - mit KC-Ehrenwort! :-))

Neue Strukturen

Wenn Ihr diese Ausgabe in den Händen haltet, hat die Umstellung in der Clubleitung offenbar geklappt. Zwar treffen vereinzelt noch Beiträge auf dem alten Clubkonto ein, aber alles in allem scheinen wohl alle Mitglieder die letzte Ausgabe der KC-News und die geänderten Leitsätze aufmerksam gelesen zu haben. Für die ,,Falsch- Überweiser`` gilt: Keine Panik, es wird dafür gesorgt, daß Euer Geld an der richtigen Stelle ankommt!

Alte Traditionen

Bei der Aufbereitung alter Ausgaben der KC-News ist mir eine in Vergessenheit geratene Tradition aufgefallen: Es gab mal eine Rubrik namens ,,Vorstellung der Clubmitglieder``. Um der Anonymität im Club entgegen zu wirken, wurde sie seinerzeit eingerichtet. Irgendwann versiegte jedoch der anfängliche Enthusiasmus.

Inzwischen sind ja wieder ein paar neue Gesichter hinzugekommen. Daher mein Aufruf: Schreibt doch mal auf, wer Ihr seid, was Ihr macht und wie Ihr zum KC gekommen seid! Dies gilt übrigens auch für die ,,Alt-Mitglieder``, die sich immer noch nicht vorgestellt haben!

Neue Medien

Natürlich hatte es auch einen Grund, daß ich in den alten Ausgaben gestöbert habe. Bereits in der letzten Ausgabe war über die Präsenz des KC-Clubs im Internet zu lesen. Die Web-Site wird in nächster Zeit generalüberholt und um zahlreiche Informationen erweitert - unter anderem halt auch Artikel der KC-News. Es lohnt sich also auf alle Fälle, mal wieder vorbeizuschauen!

Alter Hut

Ein anderer Dienst des Internet - nämlich eMail - wurde in den vergangenen Wochen stark strapaziert, denn über die neue Speicherverwaltung in/unter/mit ZAS wurde heiß diskutiert. Ralf Kästner berichtet in seinem Artikel darüber. Vielleicht ist zum Zeitpunkt der Veröffentlichung dieser Ausgabe schon ein Konsens gefunden worden.

Auf alle Fälle wird es bis zur nächsten Ausgabe fast schon ein ,,alter Hut`` sein. Sicherlich wird es dann auch schon die ersten Anwendungen geben, die diese neuen Standard nutzen.

Jetzt bin ich aber (erstmal) fertig. Frank wird bestimmt auch noch ein paar Worte an Euch richten wollen...

Noch ein paar mehr Worte zur Einleitung

von Frank Dachselt

Ja, natürlich möchte ich auch noch ein paar Worte an Euch richten, bevor ich Euch den inhaltlichen Teil dieser Ausgabe überlasse. Jörg hat es schon angedeutet: mit dieser Ausgabe sind einige Veränderungen innerhalb des Clubs und insbesondere bei der Erstellung der KC-News wirksam geworden. Die neue Verfahrensweise wurde schon in der letzten Ausgabe beschrieben, zum besseren Verständnis dieser etwas kompliziert anmutenden Prozedur ist selbige auf dem heutigen Titelblatt noch einmal grafisch dargestellt. Die dort namentlich aufgeführten Autoren sollten aber nur für diese Ausgabe repräsentativ sein.

Motivationen ...

Für die Zukunft wünsche ich mir wieder ein möglichst breites Spektrum an Autoren und Beiträgen, so wie es in der Vergangenheit eigentlich stets der Fall war. Unsere Stärke ist es ja, daß KC-User für KC-User schreiben. Und da sind bei weitem nicht nur die allerneusten Entwicklungen bei den Betriebssystemen und im Bereich der Hardware interessant. Nicht alle KC-User folgen sofort jedem Entwicklungstrend, sodaß auch kleinere Projekte, Tricks und Kniffe von Interesse sind. Und allen denen wollen wir in den KC-News gerecht werden. Ansonsten schließe ich mich Jörgs Worten zur ,,Motivation der Clubmitglieder`` an.

Dank ...

An dieser Stelle wird es nun auch endlich einmal Zeit, daß wir unserem langjährigen Redakteur und Kassenwart für seine geleistete Arbeit danken. Was es heißt, im ständigen Kampf gegen den Redaktionsschluß die Wünsche von Autoren und wartenden News-Lesern unter einen Hut zu bringen, habe ich nun zum ersten Mal ,,am eigenen Leib`` erfahren (ich gebe zu, ich selbst habe meine Beiträge auch fast immer erst in letzter Minute abgeschickt). Und was diese Aufgabe von einem einzelnen gefordert hat, zeigt sich nicht zuletzt auch daran, daß wir sie jetzt zu viert in Angriff nehmen mußten.

Also Jörg, ich glaube, daß ich es im Namen aller Clubmitglieder tun kann, wenn ich Dir hiermit unseren herzlichsten Dank ausspreche.

Diese Ausgabe ...

Als diese Ausgabe noch im Entstehen war, dachte ich zunächst, daß es ein ernsthaftes Sommerloch geben würde, denn kurz vor unserem angestrebten Redaktionsschluß hatten die News nur etwa den halben des jetzt vorliegenden Umfanges. Nachdem ich daraufhin einen ,,Hilferuf`` abgesetzt hatte, gingen aber noch einige Beiträge, insbesondere von Ralf und Jörg, bei mir ein. Die ,,Verdonnerung``, die Ralf in seinem ZAS-Artikel erwähnt, nehme ich in diesem Zusammenhang auf meine Kappe. In Zusammenhang mit der gegenwärtigen Weiterentwicklung von ZAS sind auch die Beiträge zum Linker LINK131 zu sehen, da dieser in der Lage ist, Dateien im PRL-Format zu erzeugen. Auf die Frage nach einer Beschreibung zu diesem Linker gab es zwei Antworten: Mario hat eine HLP-Datei (in HLPFILES.LBR) als Online- Hilfe erzeugt, während Jörgs ausführliche Beschreibung in dieser Ausgabe abgedruckt ist.

Artikelformat ...

Was das Format und das Layout der KC-News betrifft, so habe ich mich so weit wie möglich an Jörgs Vorarbeit gehalten und bekannte Elemente, die mir Jörg zur Verfügung gestellt hat, übernommen. Damit braucht sich also niemand in seinen Lesegewohnheiten umstellen. Für die Textbeiträge zur Veröffentlichung in den News gilt das in der letzten Ausgabe bereits gesagte: alle KC- und MSDOS-kompatiblen ASCII-Formate sind problemlos verarbeitbar. Wer besondere Wünsche bezüglich der Formatierung hat, sollte das als separate Hinweise oder als Probeausdruck beifügen. Ich werde dann versuchen, dem möglichst zu entsprechen. Ansonsten versuche ich natürlich bei allen Beiträgen, eine angemessene Formatierung vorzunehmen.

Ein Hinweis noch für Bilder und Zeichnungen, weil es bisher in dieser Form wohl noch nicht möglich war: PIP/PIF- und HIP/HIF-Grafiken sind ohne weiteres in den News abdruckbar (farbige Bilder natürlich nur mit Graustufen). Ebenso ist das Zusammensetzen von mehreren einzelnen Bildern zu einer größeren Abbildung (z. B. für Schaltpläne) möglich.

Unser nächstes Treffen ...

Ein letzter Punkt bedarf noch der Erwähnung: es geht um unser nächstes Clubtreffen. Das Frühjahr 1998 ist zwar noch in etwas weiter Ferne, aber mit der nächsten Ausgabe der KC-News im November sollen bereits die Anmeldeformulare verschickt werden, so daß wir bis dahin eine Entscheidung getroffen haben müssen. Ich möchte hierzu zunächst noch einmal meine Bereitschaft (wie bereits auf dem letzten Clubtreffen) erklären. Das würde bedeuten, daß unser nächstes Treffen in Dresden stattfände. Weiterhin gibt es ein Angebot aus Erfurt von den Organisatoren des 96-er Treffens. Als ,,Notlösung`` würde sich auch Andreas Ose bereiterklären, ein Treffen in Nordhausen zu organisieren, wobei das allerdings mit etwas Unsicherheit behaftet ist. Ich möchte Euch daher bitten, weitere Vorschläge und Meinungen - insbesondere auch über den genauen Zeitpunkt - an mich zu richten. Ich werde dann versuchen, im Kontakt mit anderen Clubmitgliedern eine Entscheidung zu treffen.

Damit bin auch ich am Ende meiner einleitenden Worte. Bleibt mir nur noch, Euch viel Spaß beim Lesen dieser Ausgabe zu wünschen.

Euer neuer Redakteur

Frank

Bericht vom Z-Fest 1997 in Güglingen

von Jörg Linder

In diesem Jahr haben es die letzten lebenden Exemplare der aussterbenden Spezies ,,CP/M-User`` wieder einmal geschafft, sich zum Z-Fest vom 19. bis 21. Juni 1997 in Güglingen zu versammeln. Dabei durfte ich natürlich nicht fehlen! Die Strapazen der langen Anreise habe ich gern auf mich genommen, schließlich ist das Z-Fest die einzige Gelegenheit, ,,alte`` Bekannte wiederzusehen. Es waren auch so ziemlich alle Teilnehmer des '95er Treffens wieder vor Ort.

Während am Freitag lediglich die Weitgereisten eintrafen, ging es dann am Samstag richtig los. Überall wurden die unterschiedlichsten Systeme auf- und umgebaut. Zu unserer Schande müssen wir allerdings eingestehen, daß lediglich drei Geräte mit einem Z80 liefen und trotz sieben anwesender Besitzer nicht eine einzige CPU280 zu sehen war. Dies konnten auch die zahlreichen Emulatoren kaum ausmerzen.

Umso exotischer waren jedoch die Z80-Rechner. Es versteht sich von selbst, daß ich wieder meinen KC mitgebracht hatte. Besonderes Highlight war dabei/daran das Grafiktablett K 6405, dessen Anschluß mir kürzlich geglückt ist. Festplatte und Maus möchte ich hier nur der Vollständigkeit halber erwähnen, denn die gehören inzwischen schon fast zur Grundausstattung. Mit dem neuen Betriebssystem (ML-DOS) und der neuen UNIPIC-Version konnte ich auch ziemlich Eindruck schinden.

Roderich Vogelmann konnte mit seinem Kontron-System ebenfalls beeindrucken. Dazu trugen nicht zuletzt das eigenwillige Design des Gerätes und die spezielle CP/M-Variante bei. Der Mangel an entsprechenden Unterlagen über die Systemsoftware konnte Helmut Jungkunz nicht abschrecken, sondern forderte ihn vielmehr heraus, es mit der ,,alten Kiste`` aufzunehmen. Unterstützt von Andreas Kißlinger lautete das erfreuliche Ergebnis: Mensch siegt über Maschine. Insbesondere die Mischung aus ,,normalen`` (englischen) und ins Deutsche übertragene Befehle regte die Phantasien zu immer neuen Assoziationen an - welcher Computer bietet statt des DIR-Befehls ein schlichtes ,,IL`` (IL = Inhalt listen) und zugleich das gewohnte ,,ERA`` (ERA = erst Rückfrage abwarten)? :-)

Michael Scholich hat wieder seinen C128 mit Festplatte und CD-ROM-Laufwerk mitgebracht. Aufgrund der ungünstigen Organisation der Festplatte - sie kann nur in zahllosen Partitionen von Diskettengröße verwaltet werden - war er natürlich sehr an ZSDOS interessiert. Weil der C128 mit einem gebankten CP/M Plus System arbeitet, nützt es ihm allerdings nichts. Das ist leider sehr schade, denn ansonsten ist der C128 sehr leistungsfähig. Zahlreiche Utilities nutzen die speziellen hardwaremäßigen Gegenbenheiten optimal aus. So kann man z. B. dank Jugg'ler diverse CP/M- Diskettenformate lesen, schreiben und formatieren.

Natürlich sollen auch die anderen Computersysteme nicht unerwähnt bleiben, auch wenn diese keinen Z80 beherbergen. Außer einem Acorn-Rechner waren ca. ein halbes Dutzend Apple Macintosh-Computer zu sehen. Von den sonst allgegenwärtigen IBM-Kompatiblen waren lediglich zwei Exemplare ,,anwesend``, was sie in unserer Runde zu einer Minderheit machte.

Wie üblich wurde aber nicht nur über Computer, sondern über alles Mögliche geredet, geplaudert, diskutiert und gelacht. Das schlechte Wetter konnte uns am Samstagabend nicht davon abhalten, dem ,,Frosch- und Schneckenfest`` in der Nachbargemeinde Pfaffenhofen einen Besuch abzustatten und dort zu essen. Für alle Unwissenden: Die Bezeichnung leitet sich aus der Geschichte zweier Gemeinden ab und nicht etwa aus den angebotenen Speisen.

Erstaunlicherweise schafften wir es dann direkt vom Fest ins Hotel; und das noch vor Mitternacht! Entsprechend ausgeruht setzten wir das Z-Fest am Sonntag mit leicht dezimierter Teilnehmerzahl fort. Im Laufe des Tages nahm sie weiter ab, so daß gegen 17:30 Uhr das diesjährige Treffen ein Ende fand. Wir sind mit dem Versprechen auseinander gegangen, uns im nächsten Jahr wiederzusehen. Dann gibt es auch zwei triftige Gründe bzw. Jubiläen. Zum einen wird es das fünfte Z-Fest in Güglingen sein und zum anderen heißt es dann ,,20 Jahre CP/M (1978 - 1998)`` - wenn das kein Grund zum Feiern ist!

Bis dahin heißt es:
         Nicht Ver-Z-teln!

Euer Jörg

ZAS beendet Speicherkriege im Grundgerät

von Ralf Kästner

Bitte entschuldigt, aber eine bessere Überschrift ist mir leider nicht eingefallen. In letzter Zeit ist durch Mario Leubner Bewegung in eine Sache gekommen, welche seit geraumer Zeit einer Lösung bedarf - die Verwaltung des freien Speichers im Grundgerät, während das KC-Floppy-System in der CP/M- bzw. PC-Betriebsart betrieben wird.

Nachdem Mario am 07. 06. dieses Jahres eine in dieser Richtung erweiterte Testversion von ZAS an die Programmierer verschickt hatte, gab es heiße ON- und OFFLINE-Diskussionen hinter den Kulissen, wo sich um die genaue Spezifikation der ZAS-Funktionen und den Aufbau der Programmteile, welche im Grundgerät laufen sollen, förmlich gestritten wurde. Da auch ich zu dieser illustren Runde gehörte und die anderen momentan andere wichtige Dinge, wie Erstellung der nächsten KC-News, Hochwasserbekämpfung usw. zu bewältigen haben, wurde ich dazu verdonnert, etwas zum momentanen Stand zu schreiben, damit dieser zukünftige Standard bekannt wird und man sich ggf. darauf vorbereiten kann, wenn derartige Projekte in Arbeit sind bzw. geplant sind.

Die ZAS-Funktionen der Version 1.1 wurden von Mario in den News 4/96 S. 2 ff. ausführlich vorgestellt. In der gleichen Ausgabe kann man ab S. 10 den Artikel von Jörg Linder lesen, wo ausführlich Sinn und Zweck aber vor allem die Notwendigkeit einer derartigen Speicherverwaltung angedacht wurde. Genau wie dort vorgeschlagen, hat Mario damit begonnen, ZAS um entsprechende Funktionen zu erweitern. Der momentane Stand ist bereits vielversprechend aber noch nicht soweit, daß ich hier genaue Aussagen machen kann bzw. will, das macht Mario sicher selbst in einer der nächsten Ausgaben.

ZAS verwaltet in der neuen Version den freien Speicher des Grundgerätes im RAM0 von 1C00H-3AFFH und im RAM4 von 4000H-7FFFH, wobei den nutzenden Programmen immer ganze Pages (Speicherbereiche) zu je 256 Byte zugeteilt werden. Der Programmbeginn entspricht dabei einem Pagebeginn - Adresse xx00H, mehrere zusammenhängende Pages pro Programm sind natürlich auch möglich, man kann auch festlegen, ob ein Programm in den RAM0 oder RAM4 geladen werden soll/muß.

Wahrscheinlich werden auch temporäre Speicherbereiche für eine Zwischenablage von Daten u.ä. unterstützt, dort ist die Form noch nicht endgültig geklärt. Programme, welche ausführbaren Code enthalten, müssen frei verschieblich sein oder im PRL-Format vorliegen. Jedes Programm, welches im Grundgerät laufen soll, erhält einen Identifizierungscode (ID), welchen der Programmierer momentan bei Mario beantragt und den er dann für sein Programm verwenden muß. Der Beginn jedes Programmes (Header) hat einen einheitlichen Aufbau, welcher unbedingt eingehalten werden muß, da dort ZAS und das Ladeprogramm, welches das Grundgeräteprogramm vom D004 in das Grundgerät schreibt (s.u.), wichtige Informationen entnimmt - hier steht der Inhalt auch noch nicht ganz fest.

ZAS enthält eine neue ESC-Sequenz, mit der man Funktionen des Grundgeräteprogrammes direkt aufrufen kann, wobei eine Übergabe von Parametern über die CPU-Register möglich ist. Für umfangreichere Datentransporte muß/kann dann der Koppel-RAM benutzt werden, wobei man vor einem Aufruf die Daten dort hineinschreibt und nach einem Aufruf Daten von dort lesen kann, quittiert wird das von ZAS, wie bisher auch schon, in MEMANF.

ZAS übernimmt also in Zukunft die gesamte Speicherverwaltung im Grundgerät und kann anhand der ID Funktionsaufrufe an dort vorhandene aktivierte Programme weiterleiten. Das Konzept, welches hier verfolgt wird, sieht so aus, daß benötigte (möglichst universell nutzbare) Programme bereits beim Systemstart in das Grundgerät übertragen werden und sich nicht länger gegenseitig behindern bzw. sogar adressmäßig überschneiden.

Dies soll zukünftig ein Ladeprogramm erledigen, welches noch zu schreiben ist und sowohl verschiebliche Programme laden als auch Programme im PRL-Format lesen und reloziert auf eine freie Adresse im Grundgerät schreiben kann. ZAS enthält hierfür entsprechende ESC-Sequenzen, um den Speicher aufzuteilen.

Die Lage des Programmes im Grundgerät ist anschließend für das nutzende Programm im D004 uninteressant, da alle Funktionsaufrufe über den ID-Code automatisch an das richtige Programm im Grundgerät weitergeleitet werden. Damit werden die eigentlichen Programme von der gesamten administrativen Arbeit befreit, welche bisher notwendig war, um Programme im Grundgerät ablaufen zu lassen. Da ZAS den Speicher zuteilt, sind Adresskonflikte ausgeschlossen und der gesamte verfügbare freie RAM kann auch problemlos ausgenutzt werden Grundvoraussetzung ist natürlich, daß sich alle an den (wenigen) Vorgaben orientieren und die definierten Schnittstellen benutzen.

Wenn man es genau betrachtet, wird die Nutzung des Grundgerätes erheblich erleichtert. Man muß vorher lediglich eine Aufgabenverteilung vornehmen, was im Grundgerät gemacht werden soll und was im D004. Anschließend schreibt man das Programm für oben wie bisher und den Programmteil für das Grundgerät getrennt - ist er bereits verschieblich, war es das schon, ist er nicht verschieblich erzeugt man einfach mit dem Linker eine entsprechende PRL-Datei, welche dann genauso mit dem universellen Ladeprogramm geladen werden kann. Im D004 Programm fällt lediglich ein Test an, ob das zugehörige Programm im Grundgerät aufgerufen werden kann - es ist ja laut Konzept bereits zum Zeitpunkt des Systemstarts geladen worden.

Es soll natürlich auch nicht verschwiegen werden, daß es Probleme geben kann, wenn alte Programme benutzt werden, welche die neue Speicherverwaltung nicht kennen und mit den bereits vorhandenen ESC- Funktionen ins Grundgerät schreiben. Die sind nach wie vor alle verfügbar, da auch das neue ZAS abwärtskompatibel sein wird. Nun, da es nicht soviele sind, dürfte das nur in einer Übergangszeit stören. U.a. haben Frank Dachselt für DRUCK.COM bzw. HPKC.COM und Mario Leubner für ML.COM überarbeitete Versionen angekündigt, so daß diese Programme auch zukünftigt eingesetzt werden können, andere wichtige Programme, welche dies betrifft, fallen mir momentan auch nicht ein.

Der Gebrauch der alten Funktionen zum Schreiben in den Speicher des Grundgerätes ist dann auch nicht mehr so ohne Weiteres möglich, da sich in den o.g. Bereichen aktive Programme befinden können, welche dann zerstört werden - die Folge ist höchstwahrscheinlich ein Absturz im Grundgerät und damit auch der PC-Betriebsart! Hierzu wird Mario sicherlich etwas sagen, wenn er das neue ZAS vorstellt.

Soviel zum bisherigen Stand, abschließend noch einige Gedanken für eine sinnvolle Nutzung dieser ganzen Angelegenheit. Das KC-Floppy-System ist in der CP/M- bzw. PC-Betriebsart ein absoluter Exot unter den CP/M-kompatiblen Systemen, wie Jörg Linder schon einmal treffend schrieb, sind wir ja als KC-Nutzer Besonderes gewöhnt. Die Fähigkeiten unseres Grundgerätes stehen anderen CP/M-Programmierern nicht zur Verfügung, da dieses Betriebssystem von Hause aus z.B. weder vollgrafikfähig ist noch Musik erzeugen kann. Um dem Ganzen noch die Krone aufzusetzen, steht durch den RAM des Grundgerätes quasi eine kostenlose Vergrößerung des TPA zur Verfügung, indem man Programmteile einfach dorthin auslagert - dies wird durch die neue RAM-Verwaltung sogar noch gefördert, da es wesentlich einfacher und dann auch sicherer wird.

Genau dadurch entstehen allerdings auch Gefahren. Jedes CP/M-Programm, welches Programme im Grundgerät voraussetzt, ist zu anderen CP/M-Systemen inkompatibel und läuft dort nicht - die Lauffähigkeit von Programmen auf verschiedenen Plattformen war eigentlich mal ein Hauptgrund für den Erfolg dieses Betriebssystems. Alle Programme, welche auf die neue RAM-Verwaltung angewiesen sind, laufen nur noch auf dem KC 85/4..., da ZAS nicht auf dem 85/2,3 läuft. Wenn jeder Programmierer eigene Programme für das Grundgerät entwickelt, welche ähnliche Aufgaben erfüllen, wird es irgendwann wieder eng dort unten, da der Speicher begrenzt ist. Ziel muß also sein, daß man sich untereinander austauscht, um möglichst auf bereits vorhandene Programme für das Grundgerät zurückzugreifen. Man muß dann beim Systemstart weniger laden (warten) und erspart allen Anwendern Frust, dazu kommt, daß wir dann eine Speicherverwaltung gar nicht brauchen, da jedes D004-Programm seine Grundgeräteprogramme selbst laden und verwalten könnte.

Solange die Möglichkeiten von CP/M und beispielsweise NZCOM ausreichend sind, sollte man sich darauf beschränken, es erhöht die Bandbreite für die Nutzung auf anderen Systemen erheblich. Sinnvoll werden Programmteile im Grungerät erst, wenn es nicht anders machbar ist. Hierzu zählen u.a. direkte Zugriffe auf die Hardware von I/O-Modulen (Stichwort Modem an M003) und ähnliche Probleme. Weiterhin spezielle Programme, welche für grafisch orientierte Anwendungen notwendig sind, wenn diese mit den bisher vorhandenen ESC-Funktionen nicht auskommen, weil es sie nicht gibt oder diese u.U. zu langsam sind. In diesem Zusammenhang sind auch die o.g. temporären Speicherbereiche zu sehen, welche man für eine Zwischenspeicherung von vollgrafischen Daten (Dateien) benötigt, um sie anschließend über den IRM des Grundgerätes anzeigen lassen zu können. Ich will damit sagen, daß die Speicherverwaltung durch ZAS keine Aufforderung zum Auslagern von Programmcode in das Grundgerät ist oder ein ,,zweites`` ZAS parallel zum dort bereits laufenden geschrieben werden sollte, nur weil einem die vorhandenen ZAS-Funktionen nicht gefallen oder zu umständlich erscheinen - es sollte viel mehr als letztes Mittel verstanden werden, um besondere Anwendungen für den KC 85/4 überhaupt erst zu ermöglichen.

Soviel für heute von meiner Seite zu einem eher ungewohnten Thema, eigentlich bin ich ja eher CAOS-orientiert und habe für die CP/M-Betriebsart nicht so viel übrig, da die grafischen Möglichkeiten eher beschränkt sind bzw. offiziell gar nicht zur Verfügung stehen. Ich konnte mich hoffentlich einigermaßen verständlich ausdrücken und man kann diesen Zeilen brauchbare Informationen entnehmen.

Beschreibung LINK v1.31

von Jörg Linder

Bei der Erzeugung der SYS-Datei für ML-DOS sind viele User erstmalig mit LINK 1.31 von Digital Research Inc. in Berührung gekommen, dabei gehört er doch zum standardmäßigen Lieferumfang eines jeden CP/M Systems. Da wir KC-User aber nicht mit einem (ordentlichen) CP/M System bedacht wurden, gab's auch keine Standardsoftware dazu. Zwar haben sich viele die von Robotron in Umlauf gebrachten Clones besorgt, jedoch ist die Bedienung - sprich die Syntax - vollkommen anders.

Aus eigener, telefonseelsorgerischer Erfahrung weiß ich, das der größte Stolperstein beim Nachvollziehen der Arbeitsschritte zur Erstellung des Systems, wie sie in den KC-News veröffentlicht wurden, die Eingabe der eckigen Klammern war. Hier ist die Lösung ganz einfach: Da wir mit gutem alten ISO-7-Bit Code arbeiten, sind die länderspezifischen Sonderzeichen mehrfach belegt. Was beim deutschen Zeichensatz das große Ä ist, erscheint im amerikanischen Zeichensatz als linke eckige Klammer ,,[``. Man braucht also vor Eingabe der Kommandozeile nur auf den amerikanischen Zeichensatz umzuschalten (siehe D004 Manual, D004 Handbuch für den Bediener, Veröffentlichungen zu ZAS) oder man gibt in der Kommandozeile statt der Zeichen aus dem amerikanischen Satz die deutschen Entsprechungen ein.

Hier sind diese nochmal im Kurzüberblick:

amerikanisch	deutsch
[, linke eckige Klammer	Ä, Großbuchstabe A-Umlaut
\, Backslash	Ö, Großbuchstabe O-Umlaut
], rechte eckige Klammer	Ü, Großbuchstabe U-Umlaut
{, linke geschweifte Klammer	ä, Kleinbuchstabe a-Umlaut
|, senkrechter Strich (Pipe)	ö, Kleinbuchstabe o-Umlaut
}, rechte geschweifte Klammer	ü, Kleinbuchstabe u-Umlaut
~, Tilde	ß, Doppel-S-Laut

 

Sicherlich interessieren sich einige Anwender für eine vollständige Beschreibung der Kommandos und Optionen dieses recht leistungsfähigen Linkers. Deshalb habe ich mich an die Übersetzung der originalen CP/M Unterlagen gemacht, die an dieser Stelle veröffentlicht wird:

LINK-80

Einleitung

LINK-80 ist ein Utility, mit dem relokatible Programmodule zu einer absoluten, ausführbaren Datei zusammengefügt werden können. Die erzeugten Programme sind unter CP/M oder MP/M II lauffähig.

Relokatible Programmodule können in zwei verschiedenen Arten vorliegen. Zum einen als REL- Datei, die mittels PL/I-80, RMAC oder dem Übersetzungsprogramm einer anderen Sprache im Microsoft-REL-Format erstellt wurde. Zum anderen als IRL-Datei, die vom CP/M Bibliotheksverwaltungsprogramm LIB-80 erzeugt wurde. Eine IRL-Datei enthält dieselben Informationen wie eine REL-Datei und außerdem einen zusätzlichen Index, mit dessen Hilfe Suchvorgänge in großen Bibliotheken erheblich beschleunigt werden können.

Nachdem LINK-80 alle Operationen erfolgreich abgeschlossen hat, sind folgende Informationen auf dem Bildschirm zu lesen:

• Symboltabelle
• alle nicht aufgelösten Symbole
• Memory Map (Speicherbelegung)
• Use-Factor (Auslastung)

Die Memory Map zeigt Größe und Anfangsadresse der verschiedenen Segmente. Der Use Factor spiegelt den von LINK-80 benötigten Speicher im Verhältnis zum gesamten freien Speicher als hexadezimale Prozentzahl wider.

LINK-80 schreibt die Symboltabelle in eine SYM-Datei, die vom CP/M Symbolic Instruction Debugger (SID) direkt verarbeitet werden kann. Die erzeugte COM- oder PRL-Datei ist unter CP/M oder MP/M II ausführbar.

LINK-80 Operationen

Die allgemeine Kommandosyntax von LINK-80 lautet:

LINK dateiname1,dateiname2,...,dateinameN

Hierbei stehen ,,dateiname1,...,dateinameN`` für die Dateinamen der zu verbindenden Programmodule. Wird kein Dateityp angegeben, so geht LINK-80 automatisch von ,,REL`` aus.

Von LINK-80 werden zwei Dateien erstellt:

• dateiname1.COM
• dateiname1.SYM

Ein anderer Dateiname für die COM- und SYM-Datei kann mit einem Kommando in folgender Form festgelegt werden:

LINK Neuerdateiname=dateiname1,dateiname2,...,dateinameN

Zur Steuerung der Linkoperationen stellt LINK-80 eine Reihe von Optionen zur Verfügung. Diese werden weiter unten beschrieben.

Während der Verarbeitung erzeugt LINK-80 bis zu acht temporäre Dateien auf dem Standardlaufwerk mit folgenden Dateinamen:

XXABS.$$$    XXPROG.$$$    XXDATA.$$$    XXCOMM.$$$
YYABS.$$$    YYPROG.$$$    YYDATA.$$$    YYCOMM.$$$

Nach erfolgreich abgeschlossener Verarbeitung werden diese Dateien von LINK-80 gelöscht. Mitunter kann es jedoch bei Auftreten eines Fehlers vorkommen, daß sie auf der Diskette verbleiben.

Mehrfachzeilen-Kommandos

Reicht der Platz einer Kommandozeile (126 Zeichen) für ein LINK-80 Kommando nicht aus, besteht die Möglichkeit, die Zeile mit einem Ampersand (&) abzuschließen und das Kommando in der nächsten Zeile fortzusetzen. Das Ampersand kann auf ein beliebiges Zeichen folgen und muß nicht zwingend hinter einem Dateinamen stehen.

LINK-80 zeigt mit einem Asterix (*) in der nächsten Zeile die Bereitschaft an, wo das Kommando fortgesetzt werden kann. LINK-80 erlaubt eine beliebige Anzahl mit Ampersand abgeschlossener Zeilen. Die letzte Zeile des Kommandos wird mit <ENTER> abgeschlossen, wie im Beispiel zu erkennen ist.

A>LINK main, iomod1, iomod2, iomod3, iomod4, iomod5, &
LINK 1.31
*lib1[s], lib2[s], lib3[s], lib4&
*[s], lastmod[p.&
*,d200]
...
...
A>

Anstelle der Punkte erscheinen auf dem Bildschirm Symboltabelle, Memory Map usw.

LINK-80 Optionen

In der Kommandozeile können diverse Optionen angegeben werden, die die Linkoperationen während der Laufzeit beeinflussen. Die LINK-80 Optionen werden in eckige Klammern eingeschlossen und durch Komma voneinander getrennt. In der Kommandozeile folgen sie direkt nach einem oder mehreren Dateinamen.

Mit Ausnahme der Option S können die Optionen hinter einem beliebigen Dateinamen stehen. Die Option S hingegen muß auf den Namen der Datei folgen, auf die sie sich bezieht. Ein Beispiel:

A>LINK test[l4000],iomod,testlib[s,nl,gstart]

Option A - zusätzlicher Speicher für Symboltabelle:

Die Größe der von LINK-80 intern benutzten Puffer wird verringert, um zusätzlichen Platz für die Symboltabelle zu schaffen. Diese Option sollte nur dann benutzt werden, wenn dies unbedingt notwendig ist und durch die Fehlermeldung ,,MEMORY OVERFLOW`` (Speicherüberlauf) angezeigt wird. Durch die Option A wird LINK-80 veranlaßt, die internen Puffer auf Diskette auszulagern, was die Erstellung größerer Programme erlaubt, aber den Verarbeitungsprozeß erheblich verlangsamt.

Option B - BIOS einbinden:

Mit der Option B kann ein BIOS für gebankte CP/M 3 Systeme erstellt werden. LINK-80 legt dazu das Datensegment an die Seitengrenze und trägt die Länge des Codesegmentes im Dateiheader ein. Die erzeugte Datei ist vom Typ SPR.

Option D - Startadresse Daten- und allgemeiner Bereich:

Normalerweise werden die Daten- und allgemeinen Bereiche von LINK-80 unmittelbar nach dem Programmsegment plaziert. Mittels Option D kann man für die Daten- und allgemeinen Segmente eine andere Startadresse festlegen.

Die Syntax für die Option D lautet:

Dnnnn

wobei ,,nnnn`` die hexadezimale Startadresse ist.

Option G - Startadresse festlegen:

Durch die Option G wird das Symbol bezeichnet, ab dem die Programmausführung beginnen soll, sofern nicht das erste Byte des Programmsegmentes der Programmbeginn ist. Die Option G veranlaßt LINK-80, auf der Ladeadresse einen Sprung zum Symbol einzufügen.

Die Syntax für die Option G lautet:

G<symbol>

(Die spitzen Klammern werden nicht eingegeben.)

Option L - Ladeadresse festlegen:

Die Ladeadresse legt die Basisadresse der von LINK-80 erzeugten COM-Datei fest. Standardmäßig ist die Ladeadresse auf 100H (Basisadresse des TPA - Transient Program Area) festgelegt, so daß die erzeugten Programme unter einem standardmäßigen CP/M System lauffähig sind. Durch Benutzung der Option L wird auch die Startadresse des Programmsegmentes auf die angegebene Adresse gesetzt, sofern sie nicht durch die Option P definiert wurde.

Die Syntax für die Option L lautet:

Lnnnn

wobei ,,nnnn`` die hexadezimale Ladeadresse ist.

(COM-Dateien, deren Ladeadresse nicht 100H ist, können unter einem standardmäßigen CP/M System nicht ausgeführt werden.)

Option M - Speichergröße:

Mit der Option M wird bei der Erstellung einer PRL-Datei angezeigt, daß das Programm zur Ausführung zusätzlichen Datenspeicher benötigt.

Die Syntax für die Option M lautet:

Mnnnn

wobei ,,nnnn`` die Größe des zusätzlich benötigten Speichers (als Hexadezimalzahl) ist.

Option NL - kein Listing der Symboltabelle:

Wird die Option NL angegeben, so wird die Anzeige der Symboltabelle auf dem Bildschirm unterdrückt.

Option NR - keine Symboltabelle:

Durch Angabe der Option NR wird die Symboltabelle nicht in eine Datei auf Diskette geschrieben.

Option OC - COM-Datei erstellen (Standard):

Die Option OC bewirkt, daß LINK-80 eine COM-Datei erstellt. Dies ist die Standardeinstellung.

Option OP - PRL-Datei erstellen:

Bei Angabe der Option OP wird anstelle der COM-Datei von LINK-80 eine PRL-Datei erzeugt. (Im Abschnitt 7.1 des MP/M II Operating System Programmer's Guide sind weitere Informationen zu PRL-Dateien zu finden.)

Option OR - RSP-Datei erstellen:

Mittels Option OR wird eine RSP-Datei (Resident System Process) erstellt, die unter MP/M ausgeführt werden kann.

Option OS - SPR-Datei erstellen:

Gibt man die Option OS an, dann wird eine SPR-Datei (System Page Relocatable) erstellt, die unter MP/M ausgeführt werden kann.

Option P - Startadresse Programmbereich:

Normalerweise ist die Startadresse des Programmsegmentes auf 100H festgelegt, so daß das Programm unter einem standardmäßigen CP/M System ausgeführt werden kann. Durch die Option P kann eine andere Startadresse für den Programmbereich festgelegt werden.

Die Syntax der Option P lautet:

Pnnnn

wobei ,,nnnn`` die hexadezimale Startadresse ist.

Option Q - Symbole mit Fragezeichen:

In den Subroutinen vieler Laufzeitbibliotheken werden Symbole verwendet, die mit einem Fragezeichen (?) beginnen, um Konflikte mit anwenderseitigen Symbolen zu vermeiden. Von LINK-80 wird die Ausgabe dieser Symbole auf Bildschirm und Diskette normalerweise unterdrückt.

Die Angabe der Option Q veranlaßt LINK-80 auch diese Symbole in die Symboltabelle aufzunehmen, so daß sie im Bildschirmlisting und in der Datei erscheinen.

Option S - Bibliothek durchsuchen:

Mit der Option S wird angezeigt, daß es sich bei der bezeichneten Datei um eine Bibliothek handelt. LINK-80 durchsucht die Bibliothek(en) nach Symbolen und Referenzen, die in bereits gelinkten Modulen definiert, aber nicht gefunden wurden. Die entsprechenden Module aus der/den Bibliotheken werden in das Programm eingefügt.

Option $ - Ein- und Ausgabesteuerung:

Über die Option $ werden die Ein- und Ausgabeoperationen von LINK-80 gesteuert. Die allgemeine Form der Option $ lautet:

$td

Dabei bezeichnet ,,t`` den Typ und ,,d`` das Laufwerk.

LINK-80 unterscheidet fünf Typen:

C

- Konsole

I

- Zwischencode

L

- Bibliothek

O

- Ausgabedatei

S

- Symboltabelle

Für die Laufwerksbezeichnung kann ein Buchstabe zwischen A und P angegeben werden, mit dem das entsprechende logische Laufwerk ausgewählt wird. Darüberhinaus stehen folgende spezielle Zeichen zur Verfügung:

X

- Konsole

Y

- Drucker

Z

- keine Ausgabe

$Cd - Konsolemeldungen: Im Normalfall werden alle Meldungen von LINK-80 auf der Konsole (Bildschirm) ausgegeben. Durch Angabe der Option $CY können sie jedoch auf den Drucker umgelenkt oder mittels $CZ unterdrückt werden. Nachdem die Einstellung durch $CY oder $CZ geändert wurde, kann man die Ausgabe durch ein späteres $CX wieder zur Konsole umleiten.

$Id - Zwischencode: Standardmäßig legt LINK-80 alle Arbeitsdateien auf dem aktuellen Laufwerk an. Mit der Option $Id kann ein anderes Laufwerk bestimmt werden.

$Ld - Bibliothek: Enthält eine REL-Datei Symbole oder Referenzen, deren Module automatisch aus Bibliotheken eingefügt werden, so sucht LINK-80 standardmäßig auf dem aktuellen Laufwerk nach den Bibliotheksdateien. Die Option $Ld veranlaßt LINK-80 auf dem angegebenen Laufwerk nach den Bibliotheksdateien zu suchen.

$Od - Ausgabedatei: Wird in der Kommandozeile kein Laufwerk für die Ausgabedatei (COM, PRL, RSP oder SPR) angegeben, so legt LINK-80 sie auf dem Laufwerk an, von dem die erste REL-Datei geladen wurde. Mit der Option $Od wird die Ausgabe auf das bezeichnete Laufwerk veranlaßt. Neben den Buchstaben von A bis P für die logischen Laufwerke kann auch ein Z als Bezeichnung angegeben werden. Dadurch wird die Erstellung einer Ausgabedatei unterdrückt.

$Sd - Symboltabelle: Ebenso wie die Ausgabedatei wird auch die Symboltabelle auf dem Laufwerk der ersten REL-Datei erstellt, sofern in der Kommandozeile keine andere Festlegung getroffen wurde. Bei Angabe der Option $Sd wird die Symboltabellendatei auf dem bezeichneten Laufwerk (A bis P) erstellt. Darüberhinaus kann die Ausgabe der Symboltabelle mit der Option $SY auf den Drucker umgelenkt oder mit der Option $SZ unterdrückt werden.

Spezifikationen für die Kommandozeile

Die Optionen zur Ein-/Ausgabesteuerung - allgemeine Form $td - müssen untereinander nicht durch Komma getrennt werden. Eine Gruppe von Optionen zur Ein-/Ausgabesteuerung muß jedoch von anderen Optionen durch Komma getrennt werden. Das folgende Beispiel soll die Wirkungsweise veranschaulichen:

A>LINK teil1[$sz,$od,$lb,q],teil2

A>LINK teil1[$szodlb,q],teil2

A>LINK teil1[$sz od lb],teil2[q]

Die Funktionsweise der drei Kommandozeilen ist identisch.

Eine Option $I, mit der das Laufwerk für die Arbeitsdateien bestimmt wird, bezieht sich auf die gesamte Operation. Alle anderen Optionen zur Ein-/Ausgabesteuerung hingegen wirken sich bis zur nächsten Option - in der Kommandozeile von links nach rechts gesehen - desselben Typs auf die Datei(en) aus, d. h. diese Option verändert die Funktionsweise dann bis zum nächsten Auftreten dieses Optionstyps. Insbesondere bei der Verarbeitung von Overlays kann diese Eigenschaft sehr hilfreich sein:

A>LINK root (ov1[$szcz])(ov2)(ov3)(ov4[$sacx])

In diesem Beispiel würden die Ausgabe der Symboltabelle und der Konsolemeldungen während der Verarbeitung der Overlays OV1, OV2 und OV3 unterdrückt werden. Hingegen würden bei der Verarbeitung der Overlaydatei OV4 hingegen die Symboltabelle in eine Datei auf Laufwerk A geschrieben und die Konsolemeldungen ausgegeben werden.

LINK-80 Fehlermeldungen

Erkennt LINK-80 einen Fehler im Kommando, so wird die Kommandozeile bis zum fehlerverursachenden Zeichen mit einem anschließenden Fragezeichen ausgegeben:

A>LINK a, b, c; d
A, B, C;?

A>LINK langerdateiname
LANGERDAT?

Tritt während der Verarbeitung ein Fehler auf, so gibt LINK-80 eine entsprechende Fehlermeldung aus. Diese und die möglichen Ursachen werden nachfolgend erläutert.

CANNOT CLOSE
Eine Datei, die auf Diskette erstellt werden soll, kann nicht geschrieben werden. Möglicherweise ist die Diskette schreibgeschützt.

COMMON ERROR
Es erfolgte ein Bezug auf einen nicht definierten allgemeinen Block.

DIRECTORY FULL
Im Verzeichnis der Diskette ist nicht mehr genügend Platz, um die Ausgabe- oder Arbeitsdateien einzutragen.

DISK READ ERROR
Eine Datei kann nicht fehlerfrei von Diskette gelesen werden.

DISK WRITE ERROR
Eine Datei kann nicht fehlerfrei auf Diskette geschrieben werden. Möglicherweise ist die Diskette voll.

FIRST COMMON NOT LARGEST
Eine spätere Anweisung definiert einen allgemeinen Block größer als die erste Anweisung dies für den bezeichneten Block tat. Eventuell wurde eine falsche Reihenfolge der zu verarbeitenden Dateien angegeben oder die Bibliotheksmodule stehen nicht in der richtigen Reihenfolge.

INDEX ERROR
Der Index einer IRL-Datei enthält fehlerhafte Informationen.

INSUFFICIENT MEMORY
Es steht für LINK-80 nicht genügend Speicher für das Anlegen der Puffer zur Verfügung. Vielleicht schafft die Option A in diesem Fall Abhilfe.

INVALID REL FILE
Die bezeichnete Datei enthält ein fehlerhaftes Bit-Muster. Möglicherweise ist die angegebene Datei gar keine REL- oder IRL-Datei.

MAIN MODULE ERROR
LINK-80 ist auf ein zweites Hauptmodul gestoßen.

MEMORY OVERFLOW
Der verfügbare Arbeitsspeicher reicht für den Abschluß der Verarbeitung nicht aus. Vielleicht schafft die Option A in diesem Fall Abhilfe.

MULTIPLE DEFINITION
Das angezeigte Symbol wurde in mehr als einem der zu verarbeitenden Module definiert.

NO FILE
Die bezeichnete Datei konnte nicht gefunden werden.

OVERLAPPING SEGMENTS
LINK-80 hat versucht, ein Segment in einen Speicherbereich zu schreiben, der bereits von einem anderen Segment belegt ist. Wahrscheinlich wurde dieser Fehler durch falsche Werte der Optionen P und/oder D verursacht.

UNDEFINED START SYMBOL
Mit der Option G wurde ein Symbol bezeichnet, das in keinem Modul definiert ist.

UNDEFINED SYMBOLS
Alle nach dieser Meldung angezeigten Symbole wurden zwar benutzt bzw. darauf Bezug genommen, jedoch sind sie in keinem der verarbeiteten Module definiert.

UNRECOGNIZED ITEM
Ein unbekanntes Bit-Muster wurde von LINK-80 erkannt und ignoriert.

Hinweise zum Einbau des neuen Boot-EPROM F8

von Ralf Kästner

Hurra - er tut es! Nach einigen Problemen beim Einbau und Inbetriebnahme bootet mein KC 85/4 nun endlich automatisch von der Festplatte. Um anderen ,,mutigen`` Usern ähnliche Probleme zu ersparen, möchte ich an dieser Stelle den Beitrag von Mario Leubner aus den News 2/97 S. 7/8 noch etwas ergänzen.

Voranstellen möchte ich ausdrücklich, daß die Einbauanleitung absolut korrekt ist, man muß sie nur buchstabengetreu befolgen. Ich hatte mich für die genannte Variante 3 entschieden, da sie meinen Vorstellungen am meisten entspricht. Das Signal A10 an Pin 1 von D309 trennt man am besten unter D309 auf der Lötseite der Platine auf und verbindet dann Pin 1 mit Pin 14 (+5V=High-Pegel).

Genauso wollte ich dann mit dem Latch vorgehen und hier ist mir der entscheidende Fehler passiert. Wie von Mario geschrieben, soll das Pin 13 von D307 abgetrennt werden (Eingang des 4. Latch, in meiner Literatur 4 D und nicht, wie von Mario geschrieben, D 3), was mir aber nicht gefiel. Also einfach den lötseitig an das Pin herangehenden Leiterzug aufgetrennt, mit der EPROM-Fassung weitergemacht und anschließend laut Anleitung verdrahtet.

Nachdem alles wieder zusammengebaut war, bootete der KC überhaupt nicht mehr. Die Ursache lag in der aufgetrennten Masseverbindung zu Pin 13 von D307. Dieses Pin ist nur Zwischenstation des Masse-Leiterzuges, welcher auf der Lötseite an das Pin herangeführt wird, auf der Bestückungsseite unter dem Schaltkreis weitergeht und noch weitere Schaltungsteile versorgt, welche bei Unterbrechung sozusagen ,,in der Luft hängen``.

Man muß also dieses Pin abtrennen und auf der Bestückungsseite mit dem A10-Signal verdrahten! Dafür bietet sich übrigens eine Durchkontaktierung in der Nähe von D309 an (s.o., Unterbrechung von A10 kann natürlich erst dahinter erfolgen!). Dort kann man den Verbindungsdraht unten verlöten und oben herausführen. Nachdem ich diesen Fehler korrigiert hatte, bootete der KC auch wieder.

Da ich seit einiger Zeit CAOS 4.3 nutze, sollte nun natürlich sofort nach dem Einschalten von der HDD gebootet werden. Ich habe deshalb Mario's Tip realisiert und die EPROM-Adressen vertauscht angelötet, so daß sofort der neue EPROM angesprungen wird. Hier gab es dann noch ein kleines softwaretechnisches Problem, da der Urlader beim Kaltstart nicht wartete bis meine Festplatte bereit war, so daß ich wieder im CAOS landete und noch einmal J FC eingeben mußte.

Den EPROM erhielt ich von Mario unmittelbar nach dem diesjährigen Treffen in Gusow. Nachdem ich dieses Problem Mario geschrieben hatte, erhielt ich Mitte Juli von ihm einen geänderten EPROM, welcher nun wie gewünscht funktioniert. Ich kann also nun den KC einschalten und er bootet sofort von der Festplatte, beim Kaltstart dauert es etwa 5 s bis die Festplatte bereit ist und der Bootvorgang fortgesetzt wird.

Ich kann also allen HDD-Usern diesen kleinen Eingriff in das D004 weiterempfehlen - der Bootvorgang wird weiter verkürzt, da ZAS direkt vom EPROM in das Grundgerät kopiert wird. Es wird jeglichem Ärger mit Disketten aus dem Wege gegangen, darüber hinaus ist es natürlich ein tolles Gefühl, wenn alles wie bei den ,,großen Brüdern`` abläuft und das noch etwas schneller!

Ein Maustreiber für alle Fälle

von Ralf Kästner

Zum Treffen gab es das neue UNIPIC 2.0 zu sehen, u.a. wurde an mich die Bitte herangetragen, etwas zum verwendeten Maustreiber zu schreiben, was ich hiermit tun möchte. Im Archiv MAUS.PMA befinden sich die notwendigen Dateien, welche in der vergangenen Zeit entstanden sind.

Ich beziehe mich nachfolgend auf die News-Artikel ,,PC-MOUSE-Nachtrag`` von mir, Ausgabe 1/95 S. 12, ,,Ein Mauspfeiltreiber für CAOS`` von Mario Leubner, Ausgabe 3/95 S. 5ff., ,,Die neue Maus unter CAOS`` von mir, Ausgabe 4/95 S. 8ff. und ,,Neue Standards`` von Jörg Linder, Ausgabe 1/96 S. 2ff. Im jetzt vorliegenden Treiber habe ich versucht, alle Forderungen unter einen Hut zu bekommen, das Beste aus den eben genannten Artikeln zusammenzufassen und die Erfahrungen aus UNIPIC 2.0 mit einfließen zu lassen. Dort wird allerdings der Mauspfeil nicht im Interrupt gezeichnet, sondern vom Eingabe-Unterprogramm, das erste Ergebnis möchte ich heute vorstellen, damit es begutachtet werden kann. Als Ausgangspunkt habe ich MOUSEPF.ASM (siehe Artikel von Mario) benutzt, da er für meine Pläne am geeignetsten erschien.

Um es vorwegzunehmen, ich habe erst mal alles hineingepackt, was mir so vorschwebte, so daß die jetzige Form eine Maximalvariante darstellt, was einerseits eine ganze Menge an Speicherplatz erfordert, andererseits wird natürlich auch Leistung geboten, was die Nutzung erleichtert. Der Treiber müßte mit jeglichen Konstellationen klarkommen, es werden keine bestimmten Konfigurationen oder irgendwelche Systemzustände vorausgesetzt und durch den Treiber auch nichts verändert, so daß zum Beispiel auch eine Nutzung möglich ist, während das KC-BASIC läuft, wo der IRM immer aus ist.

Zunächst wurden mehrere Fehler im gewählten MOUSEPF.ASM beseitigt:

• Zeichenroutine für den Mauspfeil verursacht keine Fehler mehr, wen sich der Mauspfeil in den letzten beiden Bildschirmspalten befindet
• der Mauspfeil wird jetzt auch im Hires-Mode korrekt gezeichnet
• eine gesperrte Mausbewegung (MOVENA off) wird durch Cursorblinken bzw. Zeichenausgaben nicht mehr aufgehoben
• die Mauskoordinaten entsprechen den KC-Grafikkoordinaten, so daß der Ursprung links unten liegt

Ein größeres Problem war die Störung der Tastatur-CTC durch die Mausinterrupts im alten Treiber, auch das ist jetzt gelöst durch eine spezielle Initialisierung der Tastatur-CTC beim Ausschalten nach einem Keyboard-Interrupt. Die Tastatur geht dann immer vor und die Maus muß warten, wenn der CTC-Interrupt der Tastatur läuft, das funktioniert auch bei wilder gleichzeitiger Traktur von Maus und Keyboard, damit kommt man also auch ohne Eingriff in das M003 aus und hat trotzdem eine relativ ruhige flackerfreie Bewegung. Zusätzlich spart man einen CTC-Kanal im M003 ein, so daß für jeden SIO-Kanal ein freier CTC-Kanal bleibt, was eine symetrische Verteilung der Ressourcen für die COM-Schnittstellen ermöglicht.

Als nächstes wurden einige Erweiterungen vorgenommen. Die Zeichenroutine akzeptiert jetzt einen Offset zwischen Maussymbolmuster (16*16 Pixel) und sensitivem Mauspunkt (dieser entspricht den aktuellen Mauskoordinaten). Über diesen Offset, welcher frei wählbar ist, kann man das ebenfalls frei definierbare Mauspfeilmuster gegeneinander verschieben, so daß beispielsweise auch ein nach rechts unten weisender Pfeil realisiert werden kann oder eine stilisierte Hand, wo der Mauspunkt in deren Mittelpunkt plaziert werden sollte. Man muß nur entsprechende Muster bereitstellen und den gewünschten Offset angeben, die Zeichenarbeit übernimmt der Maustreiber.

Schließlich habe ich dann einige Programmteile aus UNIPIC 2.0 eingebaut und schon wieder etwas erweitert (siehe Artikel oben, ,,Die neue Maus unter CAOS``), so daß jetzt jede Taste Autorepeat auslösen kann und linke und rechte Taste einen Doppelklick, dafür bot sich der noch ungenutzte Mauscode 0EFH an. Doppelklick und Autorepeat schließen sich jetzt gegenseitig aus, das war eine Erfahrung aus UNIPIC, dort wandelt das Hauptprogramm bei erlaubtem Autorepeat die Doppelklicks umständlicherweise wieder in einfache um, da kann man das auch gleich den Int.-Treiber machen lassen, das nutzende Programm muß hier also dem Treiber mitteilen, ob Autorepeat gewünscht wird oder nicht, Normaleinstellung ist Aus.

Um nun eventuellen Diskussionen über den verwendeten Maus-Mode aus dem Wege zu gehen, habe ich den SIO-Treiber gleich universell geschrieben, er kann also jetzt sowohl im SYSTEM- als auch im MICROSOFT-Mode initialisiert werden, was ja auch einer flexiblen Handhabung anderer MS-kompatibler Eingabegeräte entgegenkommt.

Abschließend war dann noch die COM-Verwaltung zu realisieren, dort habe ich versucht, die beschlossenen Grundsätze von 1995 (siehe Artikel von Jörg oben) umzusetzen, auch das funktioniert. Die Maus kann also an COM1...4 initialisiert werden, wobei eine evtl. bereits initialisierte externe Tastatur an COM2 automatisch mit in die anschließend laufende COM-Verwaltung eingebunden wird. Hier können u.U. Probleme auftreten, wenn Geräte bereits per Interrupt an einer anderen COM-Schnittstelle betrieben werden. Diese Problematik löst sich wahrscheinlich erst, wenn die COM-Verwaltung mal von CAOS übernommen wird und dann im ROM steht.

Ich möchte heute noch nichts weiter zu einer programmtechnischen Auswertung der Mauscodes schreiben, das ist erst sinnvoll, wenn alles in CAOS integriert ist. Alle Informationen, welche für die Initialisierung und Programmierung von Interesse sind, stehen im Quelltext MAUS7500.ASM, den ich reichlichst kommentiert habe. Besonderes Augenmerk habe ich darauf verwendet, daß die ganze Angelegenheit auch unter BASIC nutzbar ist, deshalb auch einige ,,Verrenkungen`` in den Interruptroutinen und das Zeichnen/Löschen des Maussymbols im DI. Den Treiber MAUS7500.KCC habe ich für Tests unter BASIC bzw. in der CP/M-Betriebsart erst mal auf 7500H übersetzt, so daß er unmittelbar unter dem IRM steht. Am beiliegenden Quelltext kann man auch sehen, daß im Monitor-RAM nur wichtige Mausarbeitszellen gelassen wurden (alle, welche für die nutzenden Programme wichtig sind) alle anderen befinden sich im reservierten Bereich ab 0A830H, da bleiben im Monitor-RAM noch 8 Bytes frei, welche evtl. für den auch noch fehlenden Joysticktreiber verwendet werden können.

Für einen Test unter CAOS lädt man einfach MAUS7500.KCC und es erscheinen Kommandos in der Menüleiste, welche den Sprungverteiler am Anfang des Treibers aufrufen, so sollen es später mal alle mausbasierten Anwendungsprogramme machen. Die notwendigen Parameter für die Initialisierung bitte dem Quelltext entnehmen. Mit den Kommandos kann man ,,per Hand`` die Darstellung des Maussymbols, die Bewegung der Maus, die Maustasten und den Autorepeat der Tasten ein- und auschalten. %GETMICK gibt die aktuellen Mauskoordinaten hexadezimal auf dem Bildschirm aus. Mit %CODSW kann man die Ausgabe der Mauscodes an das Betriebssystem ein- und ausschalten, dann läuft der Bildschirm nicht so voll, man kann dann aber auch nur noch die Bewegung des Mauspfeils verfolgen.

Um alle Probleme beim Test unter BASIC auszuschließen, empfehle ich die RAM-Obergrenze auf beispielsweise 29900 beim Kaltstart zu begrenzen (Abfrage MEMORY END: nach %BASIC). Mit CALL*7520 kann man wieder die Mauscodes ein- und ausschalten. Mit CALL*7500 / 7503 / 7506 / 7509 / 750C / 750F / 7512 / 7515 / 7518 erreicht man die analogen CAOS-Kommandos auch direkt vom Basic-Interpreter aus. Sehr originell macht sich beispielsweise MUSIK.SSS, dort spielt der KC die Musiktitel, zeichnet nebenbei etwas Grafik und bewegt zwischendurch auch noch den Mauspfeil - bei mir funktionierte das problemlos!!! BASIC-Programme, welche PSET, LINE, CIRCLE usw. verwenden, nehmen bei diesen Befehlen aber den Mauspfeil nicht weg, so daß es dort zu Bildverfälschungen kommen kann, im Maustreiber werden momentan nur die normalen Zeichenausgaben umgeleitet, was zum Testen erst mal ausreicht! Probleme traten bei einigen Programmen in Form von unvermittelten Abstürzen auf, das lag aber nicht am Maustreiber, sondern an der RAM-Begrenzung beim Kaltstart, sie stürzten ohne Maustreiber mit RAM-Begrenzung genauso ab, merkwürdigerweise ohne RAM-Begrenzung nicht mehr.

Für einen Test unter der CP/M-Betriebsart habe ich für das neue HCBASIC2.COM von Mario (geht nur damit!, in MAUS.PMA nochmal enthalten), ein kleines BASIC-Programm geschrieben, dort wird der Maustreiber geladen und initialisiert bzw. ausgeschaltet. Die Abfrage CODES schaltet mit SWITCH die Codes ein/aus, mit OLD bleibt alles wie vorher. Am besten ist der Start gleich von der Kommandozeile über >HCBASIC2 MAUSHCB2, es startet selbst und beendet sich auch gleich wieder. Die Dateien HCBASIC2.COM, MAUSHCB2.SSS und MAUS7500.KCC müssen dann im Zugriff sein, es wird allerdings auch nichts überprüft, da es ja erst mal nur zum Testen gedacht ist. Der Mauspfeil wird allerdings von ZAS noch nicht berücksichtigt, so daß es hier generell zu Bildverfälschungen kommt, wenn sich Ausgaben mit dem Pfeil überschneiden, nach CLS ist er erst nach einer Bewegung der Maus wieder zu sehen.

Fazit, man muß zwar momentan noch ein paar Kompromisse eingehen, da der Treiber im RAM steht, auf alle Fälle läßt sich aber bereits jetzt die Funktion nachweisen und es ist ein komisches Gefühl, wenn beispielsweise in ML.COM wie auf dem PC ein richtiger Mauspfeil zu sehen ist, welcher die zukünftigen programmtechnischen Möglichkeiten erahnen läßt. Ich nehme auch gern noch Veränderungen vor, wenn dies gewünscht wird. Momentan läßt sich der Treiber nur in eigene Maschinenprogramme für die CAOS-Betriebsart einbinden, dort müssen dann alle Bildschirmausgaben (ESC-Codes nicht vergessen!) selbst den Mauspfeil berücksichtigen, wie das gemacht wird, kann man den Unterprogrammen OUTPUT bzw. CUCPL des Quelltextes entnehmen. Wenn die Unterprogramme des Betriebssystems bzw. von ZAS hier so weit sind, wird man weitestgehend von dieser Aufgabe entlastet und man muß sich im Programm überhaupt nicht mehr um die Maus an sich kümmern, nur die Codes muß man natürlich entsprechend in irgendeiner Form auswerten und umsetzen. Mario hatte ich den Treiber bereits zur Verfügung gestellt und er hat Zustimmung geäußert, so daß einer Einbindung ins CAOS, bis auf die Arbeit natürlich, nicht mehr viel entgegenstehen dürfte.

In diesem Sinne wünsche ich viel Spaß beim Ausprobieren.

Updates zu SYSGEN und DEP3

von Mario Leubner

In SYSGEN 1.0 ist noch eine Änderung vorgenommen worden. Diese betrifft das Aktivieren des Systems im RAM. Durch ungünstige Stackverhältnisse konnte es bisher zur Übertragung fehlerhafter ZAS-Treiber kommen. In SYSGEN 1.1 ist das jetzt korrigiert.

DEP 3.04 ist mit einer schnelleren Sortierung der Dateinamen ausgestattet worden, außerdem kann der Anwender die maximal zu sortierenden Dateinamen installieren. Die Installation kann mit dem Z-Systemprogramm ZCNFG oder einem beliebigen HEX-Editor vorgenommen werden. In der HLP-Datei ist alles genau beschrieben. Beim Start von DEP wird jetzt die erreichte Kapazität des Laufwerkes A: angezeigt.

Das HELP-System für ZCPR3

von Mario Leubner

Zu vielen Programmen vom Z-System existieren HELP-Dateien. Aber auch für zahlreiche CP/M-Programme existieren Dokumentationen, die sich leicht in HLP-Dateien umwandeln lassen. Eine recht umfangreiche HLP-Sammlung wurde zu den Z-HELP's auf 3 Disketten zusammengefaßt. Wenn eine Festplatte zur Verfügung steht, kann man sich damit ein HELP-System aufbauen. Die HLP-Dateien befinden sich in Libraries und sind meist gecruncht als *.HZP. Nun kann man alle Dateien auspacken und erhält 571 Einzeldateien, was nicht gerade zur Übersichtlichkeit beiträgt. In den Libraries sind stets HLP-Files zu Programmen, die mit dem selben Buchstaben beginnen - also A.LBR enthält ABORT.HZP, AC.HZP, ACMD.HZP... Damit gibt es 26 Libraries, die jeweils eine unterschiedliche Anzahl an HELP-Files zusammenfaßt. Eine Ausnahme bildet Y.LBR: Da es keine Programme gibt, die mit Y beginnen, sind dort die HELP-Files zu SYSLIB, VLIB, Z3LIB usw. untergebracht.

Zur Arbeit mit den HELP-Dateien existieren verschiedene Programme, wie z. B. HELP.COM, HELPC.COM und LBRHLP.COM. Das erste kann nur unkomprimierte Einzeldateien verarbeiten, HELPC kann gecrunchte Dateien lesen. Es existieren auch Versionen für gesqueezte Dateien, aber diese Methode ist nicht so leistungsfähig wie das Crunchen. Die besten Erfahrungen habe ich mit LBRHLP gemacht. In diesem Paket gibt es je ein Programm für gecrunchte und gesqueezte Dateien. Der Vorteil von LBRHLP besteht darin, daß die LBR's nicht ausgepackt werden müssen. Man behält die Übersicht auf der Festplatte und kann trotzdem auf alle Dateien schnell zugreifen. Zum Verwalten der Libraries existieren genügend Programme, so daß eine Aktualisierung/Erweiterung der LBR's problemlos möglich ist.

Die Version 2.2 von LBRHLP hatte aber auch noch ein paar kleine Schwächen, weshalb ich eine Überarbeitung vorgenommen habe. Bisher mußte man wissen, wo sich welche HELP-Datei befindet und dies beim Programmaufruf angeben also beispielsweise

A0>LBRHLP -A AC

oder man hatte ein ALIAS, was bei der Eingabe eines einzelnen Buchstaben daraus ein HELP-Kommando machte, wie

A=B=C=...=Z LBRHLP -$0 $0

Die jetzt vorliegende Version 2.3 kann

• direkt auf Einzeldateien zugreifen, wenn dies installiert ist,
• LBR's wechseln und zeigt an, wo sich die HLP-Datei befindet und
• verschiedene Informationen auf ein Blatt ausdrucken.

Damit kann ein Hauptmenü geschrieben werden, das bei Eingabe des Kommandos HELP (ohne zusätzlichen Parameter) erscheint. Die Gestaltung des Hauptmenüs bleibt jedem selbst überlassen. Bei Betätigung einer Buchstabentaste verzweige ich in das Untermenü der entsprechenden LBR's, die Methode über das ALIAS funktioniert aber ebenfalls. Für häufig benötigte Programme kann man Querverweise direkt einbauen. Auch Menüs zu bestimmten Themen sind denkbar. Der Phantasie sind also keine Grenzen mehr gesetzt, wenn man die Verschachtelungstiefe von maximal 15 einhält.

Auf der Beilagendiskette befindet sich unter anderem die Datei HELP.HLP, in der einige deutsche HELP's aus HLPFILES.LBR direkt erreicht werden können. Dieses Hauptmenü soll nur als Anregung dienen und kann beliebig ausgebaut werden.

Die Dateien in HLPFILES.LBR sind auch nicht alle so vorgefunden worden, einige einhalten den Hinweis ,,HELP-Index von...``, das heißt es war eigentlich eine normale DOK-Datei. Um daraus eine HELP-Datei zu machen, gibt es verschiedene Möglichkeiten:

1. Datei muß mit einem Doppelpunkt beginnen. Das eignet sich vor allem für kurze Beschreibungen, welche dann fortlaufend angezeigt werden.
2. Datei beginnt mit einem Inhaltsverzeichnis, jeder Abschnitt mit einem Doppelpunkt. LBRHLP numeriert dann die Zeilen des Inhaltsverzeichnisses automatisch durch.
3. Datei beginnt mit einem Semikolon, diesem folgt die Titelseite. Jeder Abschnitt beginnt mit einem Doppelpunkt gefolgt von der Taste, welche zu dem Abschnitt führen soll.

 

Die meisten HLP's sind im letzten Format. Eine vorhandene Beschreibung läßt sich meist ziemlich gut in dieses Format umwandeln, wenn man das Inhaltsverzeichnis als Titelseite nimmt. Dann ist jedem Abschnitt noch die Taste zuzuordnen und der Abschnitt entsprechend zu markieren. Etwas Feinarbeit mit Inversdarstellung und Bildaufteilung kann die Lesbarkeit weiter erhöhen. Wem dies zu schnell ging, der sollte am Besten HELP.HLP mal starten. Dort ist das Ganze etwas ausführlicher beschrieben. Wer mit englischen Beschreibungen keine Probleme hat, kann auch die HELP-Datei aus LBRHLP23.LBR durchlesen. Übrigens sind die meisten HELP-Dateien vom Z-System ebenfalls in englisch...

Ich hoffe, mein verbessertes LBRHLP kommt bei allen Z-System- Usern gut an. Alle Programmierer rufe ich auf, für größere Programme die Dokumentationen gleich als HLP zu schreiben. Für meine Programme (DEP3, HCBASIC, ...) ist das ja bereits geschehen. Interessant ist sicherlich auch die HLP-Datei zum Linker LINK131 (siehe SYSGEN), welche ich von einer SCP-3-Diskette entnommen und für HELP aufbereitet habe.

NZCOM-Tip

von Mario Leubner

Um Programe abzuarbeiten, die einen maximalen TPA benötigen, empfiehlt es sich, diese unter ML-DOS (also ganz ohne Z-System) auszuführen. Um nach ML-DOS wieder automatisch zum Z-System zurückzugelangen, kann ein SUBMIT-Programm benutzt werden. NZCOM (ohne LONGSUB-Option) und ML-DOS sind in der SUBMIT-Verarbeitung kompatibel. Angefangene SUBMIT's A0:$$$.SUB werden also von den jeweils gewechselten Systemen weitergeführt. Beispieldatei C.SUB:

NZCPM
D7:
C -V $1.C
C0:NZ

Aufgerufen mit

D7/HITECH>SUBMIT C PROG

erfolgt zunächst mit NZCPM das Verlassen des Z-Systems. Danach befindet man sich immer im Verzeichnis A0: und das gewünschte Laufwerk D7: muß neu eingestellt werden. Die nächste Zeile ruft den C-Compiler auf, der Parameter $1 wird dabei durch den Programmnamen PROG ersetzt. Nach Abarbeitung aller Compilerschritte wird mit C0:NZ das geblitzte Z-System zurückgeholt. Es ist sogar möglich, das laufende Z-System vor NZCPM mit NZBLITZ abzuspeichern um beim Laden alle Parameter zu regenerieren. C.SUB müßte dann folgendermaßen erweitert werden:

NZBLITZ A0:BLITZ
NZCPM
D7:
C -V $1.C
A0:BLITZ

Eine weitere Variante ist der Aufruf des SUBMIT über ein Alias, dann kann sogar das aktuelle Laufwerk der SUB-Datei als Parameter zugeordnet werden und mann kann das Kommando von jedem Laufwerk aus starten.

ML-DOS-Tip: CAPTURE.COM

von Frank Dachselt

Wer bereits vom guten alten MicroDOS auf das neue Betriebssystem ML-DOS umgestiegen ist, wird es sicherlich bemerkt haben: die residenten Kommandos ,,<`` und ,,>`` zur Umlenkung von Ein- und Ausgaben aus einer bzw. in eine Datei gibt es nicht mehr. Während für die Eingabe von Kommandos aus einer Datei mit SUBMIT.COM ein komfortabler Ersatz zur Verfügung steht, ist die Umleitung der Ausgabe auf den Drucker mittels ,,^P`` als einzige zur Verfügung stehende Möglichkeit bestimmt keine allseits befriedigende Lösung. Auf der Suche nach Alternativen bin ich nach einigen Experimenten schließlich auf das Programm CAPTURE.COM gestoßen, das umfangreiche Möglichkeiten zur Ausgabeumlenkung bietet und im folgenden kurz vorgestellt werden soll.

Der Aufruf von CAPTURE in der Kommandozeile besitzt folgenden Aufbau:

capture <options> | <command line>

Dabei sind die beiden Argumente <options> und | <command line> optional und können unabhängig voneinander weggelassen werden. In Abhängigkeit davon, ob der Bar gefolgt von einer Kommandozeile angegeben wird oder nicht, startet CAPTURE im Einzelkommando-Mode oder im Mehrfachkommando-Mode (extended mode). Im ersten Fall erstreckt sich die Wirkung des Programms nur auf die nachfolgend angegebene Kommandozeile, während das Programm im zweiten Fall auf alle nachfolgenden Kommandoeingaben wirkt, bis es erneut mit der Option /q aufgerufen wird (CAPTURE befindet sich während dieser Zeit resident im oberen Teil des TPA). Im Einzelkommando-Mode muß dem Bar der Aufruf einer COM-Datei folgen, die Verwendung der residenten Kommandos des Betriebssystems ist nur im Mehrfachkommando-Mode möglich.

CAPTURE bietet die Möglichkeit, eine Umlenkung der Zeichenausgabe aus einem von drei Quellkanälen in einen von drei Zielkanälen vorzunehmen. Als Quellkanal können die Konsolenausgabe, die Konsoleneingabe sowie die Druckerausgabe verwendet werden, als Zielkanal stehen die Druckerausgabe, die Konsolenausgabe und die Ausgabe in ein File zur Verfügung. Was dabei unter Umlenkung zu verstehen ist, hängt von der jeweiligen Situation ab. Wird zum Beispiel die Konsolenausgabe im Mehrfachkommando-Mode umgeleitet, so erfolgt die Ausgabe aller Zeichen zusätzlich auch im Zielkanal. Im Einzelkommando-Mode wird dagegen die Konsolenausgabe auf dem Bildschirm unterdrückt. Ebenso wird bei einer Umlenkung der Druckerausgabe grundsätzlich kein Zeichen zum Drucker gesendet, sondern die Ausgabe erfolgt dann nur im Zielkanal. Eine Umleitung der Konsoleneingabe hat aus naheliegenden Gründen stets eine zusätzliche Ausgabe im Zielkanal zur Folge.

Folgende Optionen können in der Kommandozeile angegeben werden:

c>

Umleitung der Konsolenausgabe (Quellkanal);

i>

Umleitung der Konsoleneingabe (Quellkanal);

l>

Umleitung der Druckerausgabe (Quellkanal);

lst:

Zielkanal ist die Druckerausgabe;

con:

Zielkanal ist die Konsolenausgabe;

<fname>

Zielkanal ist das File mit dem angegeben Namen, das Voranstellen eines Laufwerksbuchstaben ist möglich;

/x

existiert das File bereits, das als Zielkanal angegeben wurde, werden alle folgenden Ausgaben am Ende dieses Files angehängt, ansonsten wird das existierende File gelöscht und ein leeres mit gleichem Namen angelegt;

/t

Übersetzung von CTRL-Zeichen;

/un

Angabe der Usernummer für die Fileausgabe;

/bn

Anlegen eines Puffers von n Pages;

/f

Ausgabe des Pufferinhaltes (flush buffers);

/q

Ende der Umlenkung im Mehrfachkommando-Mode, der residente Teil von CAPTURE wird aus dem TPA entfernt;

//

Ausgabe einer Hilfeseite.

Wird beim Aufruf von CAPTURE kein Quellkanal angegeben, so wird die Konsolenausgabe umgelenkt. Wird CAPTURE ohne jegliche Parameter aufgerufen, so wird der Mehrfachkommando-Mode angenommen und die Konsolenausgabe in das File OUTLOG auf dem aktuellen Laufwerk umgelenkt.

Die folgenden Beispiele zeigen einige interessante Anwendungsmöglichkeiten von CAPTURE:

capture a:disk.dir | zxd e:

Hier arbeitet CAPTURE im Einzelkommando-Mode; die Ausgabe des Verzeichnisses von Laufwerk E: mittels des Programms ZXD.COM wird in die Datei DISK.DIR auf Laufwerk A: umgelenkt, wobei die Ausgabe auf dem Bildschirm unterdrückt wird;

capture a:asm.log /u1

Hier wird der Mehrfachkommando-Mode von CAPTURE aufgerufen; alle Konsolenausgaben in den nächsten Kommandos werden im File A:ASM.LOG im Userbereich 1 protokolliert; beendet wird diese Funktion durch den Aufruf von CAPTURE mit der Option /q;

capture i> a:input.log /x

Im Mehrfachkommando-Mode werden alle folgenden Konsoleneingaben im File A:INPUT.LOG protokolliert; ist das File bereits vorhanden, werden die Eingaben am Ende des Files angefügt;

capture i> lst:

Im Mehrfachkommando-Mode werden alle folgenden Konsoleneingaben auf dem Drucker protokolliert;

capture l> a:print.log

Im Mehrfachkommando-Mode werden alle folgenden Druckerausgaben in das File A:PRINT.LOG umgeleitet und die Ausgabe auf dem Drucker unterdrückt; damit ist es zum Beispiel möglich, die Protokollierung der Konsolenausgabe im genannten File auf Kommandozeilenebene mittels ^P zu steuern.

 

Ein Wort zum Schluß

 

Question:	Why do real Programmers always confuse with Halloween and Christmas?
Answer:	OCT 31 == DEC 25.