KC-News 3/1998

Rechnerkopplung KC - PC

von Frank Dachselt

Unter dem Eindruck des Artikels zu den neuen V.24-Koppeltreibern von Mario Leubner in der letzten News-Ausgabe habe ich mich auch einmal etwas intensiver mit dem Thema Rechnerkopplung beschäftigt. Es stand sowieso auf meiner Vorhabenliste für dieses Jahr und der erwähnte Artikel liefert einen guten Anknüpfungspunkt. Das Thema ist nicht neu: Bereits in den KC-News 4/95 hat Dirk Walther eine Lösung für eine Rechnerkopplung veröffentlicht, die den PC als Komforttastatur nutzte und eine Datenübertragung ermöglichte. Ich möchte im folgenden Beitrag zunächst noch einmal die elementaren Dinge einer Rechnerkopplung etwas näher betrachten und im zweiten Teil eine Lösung für die Fernsteuerung des PC durch den KC vorstellen.

Nullmodemkabel und Hardware-Protokoll

Die Kopplung von KC und PC erfolgt über die serielle Schnittstelle. KC-seitig ist also ein M003 (inwieweit an dieser Stelle auch ein M053 mit seinen niedrigeren Signalpegeln gefahrlos funktioniert, kann ich leider nicht sagen) notwendig, am PC brauchen wir eine noch unbelegte serielle Schnittstelle (COM1 ... COM4). Die PC-Schnittstelle liefert folgende Signale:

Am KC ist die serielle Schnittstelle nur über eine 5-pol. DIN-Buchse erreichbar, an der folgende Signale zur Verfügung stehen:

Beide Schnittstellen müssen mit einem sogenannten Nullmodemkabel verbunden werden. Solche Kabel werden auch zur Verbindung von PC untereinander verwendet, aber ein handelsübliches Kabel nutzt uns nichts, da wir am KC keine für diesen Zweck genormte Steckverbindung haben. Bleibt also nur der Selbstbau: Die Minimallösung für einen bidirektionalen Datenaustausch wäre das 3-adrige Nullmodemkabel (Bild 1 (a)), bei dem nur die beiden Datenleitungen RxD und TxD verwendet werden. Diese werden gekreuzt, d.h. der Ausgang des einen Rechners wird mit dem Eingang des anderen Rechners verbunden und umgekehrt. Mit einem solchen Kabel ist kein Hardware-Handshaking möglich, die Anpassung der Geschwindigkeit des Datenstroms zwischen Sender und Empfänger ist hier nur mit einem Software-Protokoll (z.B. Xon/Xoff-Protokoll) zu erreichen.

Wir wollen aber ein Hardware-Protokoll verwenden, das ist eleganter, zuverlässiger und in den KC-Treibern bereits implementiert. Auch von PCs wird das Hardware-Protokoll im Prinzip immer unterstützt. Mit diesem Protokoll wird sichergestellt, daß der sendende Rechner nur so schnell Daten übermittelt, wie sie der empfangende Rechner ohne Datenverlust entgegennehmen kann. Dazu setzt der Empfänger ein Signal, wenn er bereit ist, neue Daten entgegenzunehmen, und setzt dieses Signal wieder zurück, wenn er eine Verarbeitungspause benötigt oder der Empfangspuffer voll ist. Der Sender erkennt dies und unterbricht die Sendung so lange, wie es das empfangende Gerät verlangt. KC-seitig stehen uns für diesen Zweck noch zwei Signalleitungen an der V.24-Buchse zur Verfügung: DTR und CTS, ein Ausgang und ein Eingang, die zwei Handshake-Leitungen ermöglichen - für jede Übertragungsrichtung eine. In den Koppeltreibern des KC ist das Handshaking über diese beiden Leitungen schon entsprechend programmiert, so daß an dieser Stelle bereits Klarheit besteht.

Die Probleme beginnen auf der PC-Seite: Trotz weiter Verbreitung und Standardisierung gibt es keine eindeutige Festlegung, wie die Steuerleitungen der seriellen Schnittstelle zum Handshaking verwendet werden. Das ist allein Sache der Software. Arbeiten Sender und Empfänger mit unterschiedlicher Software oder gar unterschiedlicher Hardware, wie in unserem Fall, dann wird wegen meist fehlender Dokumentation die ganze Sache leicht zum Geduldsspiel.

Es gibt mindestens zwei unterschiedliche Hardware-Protokolle, die auch verschiedene Beschaltungen des Nullmodemkabels voraussetzen. Auf der Betriebssystemebene von MS-DOS ist offenbar das sogenannte DTR-Protokoll üblich. Das zugehörige Kabel ist in Bild 1 (c) gezeigt. Hier dienen die Signale DTR und CTS zum Handshaking während der Datenübertragung.

Vor allem in amerikanischen Quellen findet man noch eine weitere Variante des Nullmodemkabels, die auf dem sogenannten RTS/CTS-Protokoll basiert (Bild 1 (b)). Neben diesen beiden Handshake-Leitungen sind in diesem Kabel noch zwei weitere Steuerleitungen geschaltet, die beim Aufbau einer Datenverbindung eine Rolle spielen. Kommunikationsprogramme wie ,,Interlink`` und ,,Laplink`` (???) sollen diese Kabelvariante benötigen. Leider war es mir bis heute noch nicht möglich, an einem handelsüblichen Nullmodemkabel die Beschaltung zu ermitteln. Alle von mir als kompetente Ansprechpartner angesehenen Leute bauen sich ihre Kabel selbst, wobei die Varianten (a) und (c) Verwendung finden.

Bild 1: Varianten des Nullmodemkabels - Welches ist das richtige???

Noch eine Bemerkung zum Kabel, das in den KC-News 4/95 von Dirk Walther vorgeschlagen wurde. Dort wird das Signal DTR des KC mit dem Signal RTS des PC verbunden. Das kann auf gar keinen Fall funktionieren, denn beide Signale sind Ausgänge des jeweiligen Rechners - die armen Treiber...

Da ich für meine Versuche die Betriebssystemebene des DOS-PC benutzen möchte, habe ich mich zunächst einmal für die Kabelvariante (c) entschieden. Dieses Kabel verbindet außerdem noch die Signale RTS, DSR und DCD direkt am Stecker der PC-Seite. Sobald eine Verbindung aufgebaut wird, soll die vom PC selbst aktivgeschaltete Leitung RTS dafür sorgen, daß dieser die Betriebsbereitschaft der Gegenstelle an seinen Eingängen DSR und DCD erkennt (ein sogenanntes loop back).

Für meine Versuche stand mir bis jetzt nur ein etwas älteres PC-Modell, ein XT mit DOS-Version 3.2, zur Verfügung. Das folgende muß also nicht repräsentativ für moderne PCs sein. Es trat folgendes Problem auf: Beim Empfang von Daten schaltet der PC das Signal RTS nicht aktiv, sondern tut dieses erst beim Senden. Danach bleibt dieses Signal für alle Zeit aktiv, auch beim Empfang. Soll der PC nach einer Initialisierung nun aber zuerst empfangen und danach erst senden, erkennt er die ,,Betriebsbereitschaft der Gegenseite`` nicht und ein Empfang von Daten ist nicht möglich. Deshalb habe ich das Kabel noch etwas modifiziert: Statt RTS benutze ich DTR - das eigentliche Handshake-Signal - dazu, dem PC die Bereitschaft der Gegenstelle ,,vorzugaukeln`` (Bild 1 (d)). DTR wird nämlich sofort nach dem Initialisieren der Schnittstelle am PC aktiv (!) und bleibt auch während der Datenübertragung stets in diesem Zustand. Dieses Verhalten wird später noch einige Konsequenzen haben, aber es ist zunächst einmal ein zufriedenstellender Betrieb über die serielle Schnittstelle möglich.

So, nun habe ich zum Thema Nullmodemkabel und Handshaking ziemlich viele Worte verloren. Trotzdem sind an dieser Stelle noch viele Fragen offen. Ich möchte daher alle aufrufen, mir ihre Erfahrungen auf diesem Gebiet - insbesondere auch beim Nachvollziehen der noch folgenden Experimente - mitzuteilen, die sicherlich auch für andere Clubmitglieder von Interesse sein dürften.

Initialisierung der Schnittstelle und einfacher Filetransfer

Nachdem wir nun das (hoffentlich) passende Kabel sowie KC und PC damit verbunden haben, kann es auch schon mit der Datenübertragung losgehen. Zuerst müssen die seriellen Schnittstellen beider Rechner initialisiert werden. Am KC geschieht das z.B. mittels DRIVER.COM und einem der neuen Koppeltreiber von Mario Leubner (siehe KC-News 2/98):

A0>DRIVER V24H24A.KOP

Damit ist der Kanal A des V.24-Moduls mit 2400 Baud zur Kopplung initialisiert. Um am PC auf Betriebssystemebene mit der seriellen Schnittstelle zu arbeiten, wird diese mit dem MODE-Befehl und den passenden Parametern eingerichtet:

C:\>MODE COM1:2400,N,8,1,P

Im Beispiel ist es also die Schnittstelle COM1, die auf eine Übertragungsrate von ebenfalls 2400 Baud eingestellt wird. Die weiteren Parameter ,,keine Parität`` (N), ,,8 Datenbits`` (8) und ,,1 Stopbit`` (1) entsprechen genau den Werten, die auch der KC-Treiber verwendet. Das ,,P`` als abschließender Parameter bewirkt, daß sich der PC ,,tolerant`` gegenüber einem nicht empfangsbereiten KC verhält, also beim Senden in Richtung KC auf dessen Bereitschaft wartet und nicht mit einer Fehlermeldung abbricht.

Nun können wir zwischen KC und PC Dateien senden; zunächst soll es sich dabei mal um Textdateien handeln. Für die Übertragung der Datei TEXT.TXT vom KC zum PC sind dazu die Kommandos

C:\>COPY COM1 TEXT.TXT        (für den empfangenden PC)
A>KCSEND TEXT.TXT             (für den sendenden KC)

zu verwenden. In der Gegenrichtung wären das die Kommandos

A>KCEMPF TEXT.TXT             (für den empfangenden KC)
C:\>COPY TEXT.TXT COM1        (für den sendenden PC)

An dieser Stelle können wir zunächst das Funktionieren des Handshakings überprüfen.

Bei der Übertragung vom KC zum PC habe ich kein wirksames Handshaking feststellen können. Das Signal DTR wird am PC sofort beim Initialisieren aktiv (+ 12V) und verbleibt danach ständig in diesem Zustand. Der KC geht also stets von einer empfangsbereiten Gegenstelle aus. Als Konsequenz daraus darf das Senden am KC erst gestartet werden, nachdem am PC das Empfangen eingeleitet wurde. Sonst sendet der KC ,,ins Leere``. Auch bei der Übertragung selbst ,,bewegt`` sich DTR am PC nicht. Ich habe allerdings auch keinen Datenverlust - auch bei sehr großen Dateien (siehe unten) - feststellen können. Offenbar wird der PC mit der effektiven Übertragungsrate des KC spielend fertig.

Bei der Übertragung vom PC zum KC funktioniert dagegen das Handshaking erwartungsgemäß. Ist das Signal DTR am KC inaktiv (- 12V), unterbricht der PC die Datenübertragung. Man kann das am KC einfach testen, indem der Empfang manuell unterbrochen wird, z.B. durch Aktivieren des Druckermanagers DRUCK mit der Tastenkombination <Shift>-<CLR> während des Empfangs. Der KC bedient dann die Koppelschnittstelle nicht mehr, solange das Fenster auf dem Bildschirm zu sehen ist. Erst nach dem Verlassen des Druckermanagers geht die Übertragung weiter. Wenn bei einer solchen Aktion kein Datenverlust in der empfangenen Datei festzustellen ist, ist das Handshaking zumindest in dieser Richtung in Ordnung. Der Taschenrechner HPKC eignet sich übrigens nicht zu diesem Test, da er mittels <BRK> verlassen wird. Diese Tastenbetätigung wird aber auch von der Schnittstelle erkannt und die Übertragung daraufhin grundsätzlich abgebrochen.

Das nächste Problem, das an dieser Stelle deutlich wird, ist die Behandlung des Dateiendes und die Beendung der Übertragung. Wenn der KC sendet, dann überträgt er, sobald er das Ende einer Textdatei erkannt hat, das Zeichen EOF (1AH) und beendet die Übertragung. Das ist auch genau das, was das Programm COPY am PC erwartet: Erst wenn es dieses Zeichen erkannt hat, werden die empfangenen Daten in die Datei geschrieben. Leider verhält sich COPY in der Gegenrichtung nicht so kooperativ. Es erkennt zwar das Dateiende - entweder logisch durch ein vorhandenes EOF in der Textdatei oder physisch durch die Dateigröße - und beendet daraufhin die Übertragung, es sendet aber unter keinen Umständen ein EOF an den KC. Dieses Verhalten von COPY ist total unverständlich, da es auch die Kopplung zweier PCs in der gleichen Weise erschwert. Um die Übertragung auch am KC zu beenden, bleibt uns also zunächst nur das Drücken der BRK-Taste.

Übertragung von Binärdateien

Will man nicht nur Texte, sondern beliebige Binärdateien, also z.B. auch Programme übertragen, dann gibt es Probleme mit dem EOF-Zeichen. Wenn es zufällig in der Datei vorkommt, wird die Übertragung beendet. Sendet der PC, läßt sich des Problem durch einen Zusatz beseitigen:

C:\>COPY PROGRAMM.COM COM1 /B

Nun werden die aus der Datei PROGRAMM.COM gelesenen Zeichen als Binärdaten behandelt, d.h. das Zeichen EOF (1AH) wird mit übertragen. Das Ende der Übertragung erkennt der sendende PC jetzt nur am physischen Dateiende (Dateigröße). Am KC können wir die so gesendeten Daten mit dem Kommando

A>KCEMPF PROGRAMM.COM S

empfangen. Diese Übertragung kann am KC nur mit der BRK-Taste beendet werden. In der Gegenrichtung fehlt allerdings eine Möglichkeit zum Übertragen von Binärdateien. Zwar können wir dem Programm KCSEND durch Nachstellen der Option S mitteilen, daß es eine Binärdatei senden soll, am PC fehlt jedoch die Möglichkeit, dem Programm COPY das Ende der Datei anzuzeigen. Die Variante, die Übertragung mittels Tastendruck abzubrechen, existiert hier nicht.

Die Problematik mit den Binärdateien ist so alt wie die Datenübertragung selbst. Es gibt daher bereits eine große Anzahl von Verfahren, mit denen diese Schwierigkeiten in den Griff zu bekommen sind.

Am einfachsten ist es, die Binärdatei vor der Übertragung in eine Textdatei zu konvertieren und diese nach der Übertragung im empfangenden Rechner wieder in die ursprüngliche Binärdatei zurückzuverwandeln. Voraussetzung für eine ,,systemübergreifende`` Datenübertragung, wie wir sie vorhaben, ist natürlich, daß auf beiden Seiten mit der gleichen Konvertierungsmethode gearbeitet wird.

Das bekannteste Konvertierungsverfahren für diesen Zweck ist die UUENCODE-UUDECODE- Methode. Es verwendet zwei Programme, die üblicherweise UUENCODE und UUDECODE heißen. UUENCODE übersetzt eine Binärdatei in eine Textdatei, in der sich nur noch sogenannte ,,druckbare`` Zeichen befinden. UUDECODE macht diesen Vorgang rückgängig und erzeugt wieder die ursprüngliche Binärdatei. Die entstehenden Textdateien haben stets den Namen der Originaldatei mit der Dateierweiterung UUE. Die Kommandos zur Konvertierung sind unter CP/M und MS-DOS identisch:

A>UUENCODE TEST.COM       

      C:\>UUENCODE TEST.COM

A>UUDECODE TEST.UUE       

      C:\>UUDECODE TEST.UUE

Das Ergebnis von UUENCODE ist eine Textdatei, die prinzipiell wie folgt aussieht:

begin 644 TEST.COM
M*@8`^0``PPP!PP``S6(#S;@(PWL$0`VX!T`-1@W#=P3#9P3#E@3#X`3#Q03#
M(^7K"7XC9F_)X5XC.LF``E^(V9OR2$!`,@KR2$``,@CR2$!`-@KR2$``-@C
MR2$!`/`KR2$!`/@KR1$!`,@;R1$``,@3R1$!`-@;R1$``-@3R1$!`/`;R1$!
MS70,T--_#,')S0H#Q0X"7_X*PK@,'@W-!0`.`AX*S04`P`G--P/%*@$`*RLK
M.E`&1XA`7Q8`&W4J4@9$32'B#./I;R8`PKG-"@/%(RM\MQ+N#,')$1`G&WJS
M#@(^"E_-!0`."\T%`+?"-`W!R0X!S04`_@/*(`'!R1H:&AH:&AH:&AH:&AH:
M&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:&AH:
%&AH:&LH`
`
end

Die erste Zeile beginnt mit dem Wort ,,begin``, gefolgt von einer dreistelligen Nummer (diese enthält die Zugriffsrechte der Originaldatei für UNIX-Systeme in kodierter Form und ist für alle anderen Systeme bedeutungslos) und dem Namen der Originaldatei. Danach folgt der Inhalt der der Originaldatei in konvertierter Form, sowie das Wort ,,end`` in der letzten Zeile.

Für alle, die es genau wissen wollen, hier noch eine etwas genauere Beschreibung, wie die Konvertierung funktioniert: Die Bytes des Originalfiles werden in Gruppen zu je drei Bytes konvertiert. Drei Bytes ergeben eine Kette von 24 Bits, die in vier Gruppen zu jeweils 6 Bits - also in vier 6-Bit-Dualzahlen - aufgespalten wird. Diese 6-Bit-Zahlen können Werte zwischen 0 und 63 annehmen. Zu jeder dieser Zahlen wird 32 addiert, so daß die entstehenden Zahlen im Wertebereich 32 ... 95 liegen. Diese Zahlen entsprechen den ASCII-Codes ,,druckbarer`` Zeichen, angefangen vom Leerzeichen (ASCII-Code 32) bis hin zum Unterstreichungszeichen (ASCII-Code 95). Die Konvertierung ersetzt also jeweils drei Bytes des Originalfiles durch vier ,,druckbare`` Zeichen. Jeweils 45 Bytes bzw. 60 konvertierte Zeichen werden in der UUE-Datei in einer Zeile angeordnet. Hinzu kommt als erstes Zeichen einer jeden Zeile die Information über die Anzahl der Bytes, die durch diese Zeile verkörpert werden, konvertiert nach dem gleichen Verfahren (45 + 32 = 77, normale 45-Byte-Zeilen beginnen mit einem ,,M``). Die letzte Zeile ist gewöhnlich kürzer, so daß das erste Zeichen ein anderes sein kann.

Die Dekodierung eines UUE-Files kehrt diesen Vorgang um, indem jeweils vier Zeichen in drei Bytes zurückverwandelt werden.

Da UUE-Files gewöhnliche Textdateien sind, können sie auch als solche ohne Einschränkungen über die serielle Schnittstelle übertragen werden. ,,Erkauft`` wird diese Transportierbarkeit allerdings durch eine etwa 33%-ige Zunahme der Dateigröße und damit auch der Übertragungszeit.

Zum Abschluß dieser Problematik noch ein Hinweis: Den ganzen Aufwand mit der Konvertierung von Binärdateien haben wir wegen nur eines Zeichens unternommen, dem EOF-Zeichen. Wenn man sich sicher ist, daß die zu sendende Datei kein solches Zeichen (außer evtl. am Dateiende) enthält, dann kann man Binärdateien auch ohne die eben beschriebene Konvertierung übertragen. Zu dieser Gruppe von Dateien gehören z.B. Textdateien, die Sonder- und Grafikzeichen enthalten (z.B. WordPro-Textdateien). Wegen der verwendeten höherwertigen Zeichencodes (Zeichen, bei denen Bit 7 gesetzt ist), gelten solche Dateien zwar schon als Binärdateien, können für die hier beschriebene Übertragung über die serielle Schnittstelle aber wie Textdateien behandelt werden.

Fernsteuerung des PC

Bis jetzt können wir einzelne Dateien zwischen KC und PC übertragen. Dazu müssen wir an beiden Rechnern entsprechende Kommandos eintippen. Viel bequemer wäre es aber, wenn wir das alles von einem Rechner aus erledigen könnten, insbesondere dann, wenn die beiden Rechner räumlich etwas weiter voneinander entfernt sind (bei mir persönlich stehen sie z.B. in verschiedenen Zimmern und das Kabel ist etwa 15m lang...), oder wenn wir bestimmte Abläufe unter Einbeziehung beider Rechner automatisieren wollen. Und da wir natürlich ,,KC-orientiert`` sind, kommt nur eine Fernsteuerung des PC vom KC aus in Frage...

Zu diesem Zweck müssen wir uns überlegen, wie wir dem PC mitteilen, was er für uns tun soll, und wie wir anschließend das Ergebnis am KC erhalten. Da ich ohne viel Programmieraufwand am PC zum Ziel kommen wollte, habe ich mich für einen Ablauf mittels Batch-Dateien entschieden. Drei Batch-Dateien sind dazu notwendig, die sich im Verzeichnis C:\KCNET befinden: START.BAT, LOOP.BAT und RCOM.BAT. Wie diese prinzipiell zusammenwirken, ist in Bild 2 dargestellt.

Bild 2: Die Batch-Steuerschleife im PC

Die Datei START.BAT initialisiert zunächst die serielle Schnittstelle wie oben beschrieben und ruft danach die Datei LOOP.BAT auf:

mode com1:2400,n,8,1,p
c:\kcnet\loop

LOOP.BAT erwartet an der seriellen Schnittstelle Daten und schreibt diese in die Datei RCOM.BAT. Danach ruft sie diese eben empfangene Batch-Datei auf:

copy com1 c:\kcnet\rcom.bat
c:\kcnet\rcom

RCOM.BAT wird also erst während der Abarbeitung von LOOP.BAT erzeugt bzw. bei einem bereits existierenden File mit neuen Daten überschrieben. Diese Datei ist variabel und enthält genau die Kommandos, die wir vom KC aus auf dem PC ablaufen lassen wollen. Soll zum Beispiel das aktuelle Directory zum KC gesendet werden, dann sieht RCOM.BAT wie folgt aus:

dir >com1
copy c:\kcnet\eof.eof /b com1
c:\kcnet\loop

Zunächst wird mit dem Kommando DIR das Directory ausgegeben, aber die Anzeige, die sonst auf dem Bildschirm erscheint, wird mittels einer Ausgabeumlenkung zur seriellen Schnittstelle gesendet. In der zweiten Zeile wird anschließend die Datei EOF.EOF zum KC gesendet. Diese Datei enthält nur ein einziges Zeichen, nämlich EOF. Als Binärdatei gesendet (Option ,,/b``) wird dieses Zeichen auch wirklich an den KC übertragen, der damit den Abschluß der durch das DIR-Kommando gestarteten Übertragung erkennt. Mit dieser Kommandozeile lösen wir übrigens auch das bereits oben genannte Problem des COPY- Kommandos, beim Senden von Textdateien kein abschließendes EOF zu übertragen. Dazu wird diese Zeile einfach jedem COPY-Kommando nachgestellt. Die dritte Zeile schließlich ruft wieder die Datei LOOP.BAT auf. Sie bildet (mit Ausnahme der EXIT-Funktion) stets den Abschluß der Datei RCOM.BAT und schließt die Schleife der beiden Batch-Dateien. Als nächstes erwartet der PC wieder eine neue Datei RCOM.BAT an der seriellen Schnittstelle mit den Befehlen für einen weiteren Zyklus.

Damit ist der PC bereits hinreichend für eine Fernsteuerung vom KC aus vorbereitet. Was jetzt noch fehlt, sind die zu dem beschriebenen Ablauf passenden Aktionen auf dem KC. Ich habe zunächst versucht, die Abläufe auf dem KC ebenfalls mit Stapeldateien zu realisieren und nur bereits vorhandene Programme zu nutzen.

Für die Anzeige des PC-Directories auf dem KC sieht die SUB-Datei wie folgt aus:

;
; MDIR1.SUB:  Anzeige des PC-Directories
;
c0:rm con.txt
c0:kcsend dir.bat
c0:kcempf con.txt
c0:power type con.txt

Mit dem RM-Kommando wird zunächst die Datei CON.TXT gelöscht, damit beim späteren Empfang die Abfrage zum Überschreiben dieser Datei durch KCEMPF entfällt. Danach wird die Datei DIR.BAT zum PC gesendet. Sie enthält genau die Befehle, die der PC als RCOM.BAT abarbeiten soll (siehe oben). Als nächstes geht der KC zum Empfang der PC-Ausgabe über, die er in die Datei CON.TXT schreibt; in diesem Beispiel ist es die umgeleitete Ausgabe des DIR-Befehls. Zum Schluß wird diese Datei mit der TYPE- Funktion von POWER auf dem KC-Bildschirm angezeigt.

Rufen wir diese SUB-Datei mit dem Kommando

A0>SUBMIT MDIR1

auf, so erscheint nach einiger Zeit das Directory des PC auf dem KC-Bildschirm. Damit haben wir die gewünschte Funktion realisiert und im Prinzip wäre es so auch möglich, weitere Funktionen zu programmieren. Aber diese erste Variante hat noch jede Menge Unzulänglichkeiten: Zunächst sind für jede Funktion zwei Dateien erforderlich, eine SUB-Datei für den KC und eine BAT-Datei, die die Kommandos für den PC enthält. Die BAT-Datei läßt sich nicht ohne weiteres konfigurieren und ist ist sehr aufwendig, Parameter aus der CP/M-Kommandozeile in diese BAT-Datei einzusetzen, wie es für viele Funktionen notwendig ist. Außerdem dauert der ganze Vorgang durch die zahlreichen Zwischenschritte unnötig lange.

Um diese Mängel zu beseitigen, habe ich die folgenden zwei Programme geschrieben:

COMSEND.COM

Dieses Programm sendet die nach dem Programmnamen in der Kommandozeile angegeben Zeichen einschließlich eines abschließenden Zeilenumbruchs (0DH, 0AH) über die Koppelschnittstelle an einen anderen Rechner. Bedingt durch den CP/M-Kommandointerpreter werden dabei alle Kleinbuchstaben in Großbuchstaben umgewandelt. Direkt nach dem Programmnamen kann die Option ,,-A`` angegeben werden, mit der nach dem Zeilenumbruch noch ein EOF-Zeichen (1AH) gesendet wird:

COMSEND [-a] <command line>

 

CONEMPF.COM

Dieses Programm gibt alle über die Koppelschnittstelle empfangenen Zeichen auf dem Bildschirm aus. Das geschieht solange, bis ein EOF-Zeichen empfangen bzw. die BRK-Taste gedrückt wird. Nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen. Die Option ,,-C`` nach dem Programmnamen bewirkt die Unterdrückung von evtl. empfangenen CLS-Steuerzeichen, um die Anzeige auf dem Bildschirm nicht zu beeinträchtigen:

CONEMPF [-c]

 

Mit der Option ,,-H`` kann bei beiden Programmen jeweils die Ausgabe einer kurze Hilfe erreicht werden, ohne daß die eigentliche Funktion ausgeführt wird. Unter Verwendung dieser beiden Programme sieht die SUB-Datei zur Anzeige des PC-Directories auf dem KC nun wie folgt aus:

;
; MDIR.SUB:  Anzeige des PC-Directories
;
c0:comsend dir >com1
g          copy c:\kcnet\eof.eof /b com1
g -a       c:\kcnet\loop
c0:conempf

Die ersten drei Kommandos (,,g`` sorgt für den erneuten Start des sich bereits im TPA befindenden Programms COMSEND) senden jeweils eine Kommandozeile an den PC (genau die drei Zeilen, die in der ersten Variante in der Datei DIR.BAT standen), wobei die letzte Zeile zusätzlich mit einem EOF-Zeichen abgeschlossen wird und so das Ende dieses Übertragungsvorganges kennzeichnet. Diese drei Zeilen stehen nun im PC wieder in der Datei RCOM.BAT und werden abgearbeitet. Als nächstes erwartet CONEMPF die Reaktion des PCs, um sie direkt, ohne Umweg über eine Datei, auf dem Bildschirm darzustellen.

Um den Vorteil der Konfigurierbarkeit der an den PC zu sendenden Kommandos deutlich zu machen, zeigt das folgende Beispiel die SUB-Datei zum Wechsel des PC-Directories:

;
; MCD.SUB:  Wechsel des PC-Directories
;
c0:comsend cd $1
g          chdir >com1
g          copy c:\kcnet\eof.eof /b com1
g -a       c:\kcnet\loop
c0:conempf

Wird diese Datei mit

A0>SUBMIT MCD ..\TEXT

aufgerufen, erfolgt am PC zunächst ein Wechsel in das übergeordnete Verzeichnis und danach ein Wechsel in das Unterverzeichnis TEXT, da vor dem Senden der Kommandozeilen der Platzhalter ,,$1`` durch ,,..\TEXT`` ersetzt wird. Das CD-Kommando in der ersten Zeile sorgt für den eigentlichen Wechsel des Verzeichnisses, CHDIR in der zweiten Zeile erzeugt noch einmal die Ausgabe des aktuellen Verzeichnisses, die zum KC umgeleitet wird, um über Erfolg oder Mißerfolg der Aktion zu informieren.

In der gleichen Art und Weise habe ich nun noch einige weitere elementare Funktionen zum Dateimanagement zwischen KC und PC als SUB-Dateien realisiert:

MDIR.SUB

Anzeige des PC-Directories

 

MCD.SUB

Wechsel des PC-Verzeichnisses

Beispiel:     SUBMIT MCD ..\TEXT

 

MGET.SUB

Kopieren einer (Text-)Datei aus dem aktuellen Verzeichnis des PCs zum KC; die Datei im KC erhält den gleichen Namen wie im PC.

Beispiel:     SUBMIT MGET TEXT.TXT

 

MPUT.SUB

Kopieren einer (Text-)Datei vom KC in das aktuelle Verzeichnis des PCs; die Datei im PC erhält den gleichen Namen wie im KC.

Beispiel:     SUBMIT MPUT TEXT.TXT

 

MTYPE.SUB

Anzeige einer Textdatei vom PC auf dem KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich.

Beispiel:     SUBMIT MTYPE C:\TEXT.TXT

 

MDEL.SUB

Löschen einer Datei im PC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS- DOS üblich - ist möglich; der Dateiname muß eindeutig sein.

Beispiel:     SUBMIT MDEL C:\TEXT.TXT

 

MEXIT.SUB

Beenden der Batch-Schleife im PC und Rückkehr in den normalen Eingabemode über die Tastaur; diese Funktion ist die einzige, die nicht als letzte Kommandozeile den Aufruf der Datei LOOP.BAT im PC veranlaßt.

 

Diese Funktionen ermöglichen also ein elementares Dateimanagement zwischen KC und PC. Natürlich läßt sich das Prinzip in gleicher Weise auch zwischen zwei KC realisieren. Dazu sind für den fernzusteuernden KC zwei geeignete SUB-Dateien START.SUB und LOOP.SUB zu erzeugen und die zu sendenden Kommandos in den Dateien M*.SUB an die entsprechende CP/M-Syntax anzupassen. Lediglich die Umleitung der Konsolenausgabe zur Koppelschnitstelle ist wahrscheinlich nur mit ein paar Tricks zu erreichen...

In Ermangelung eines zweiten KC-Systems bleibe ich an dieser Stelle bei der Variante KC - PC. Zum Abschluß dieses Abschnitts möchte ich noch ein etwas komplexeres Beispiel vorstellen, für das ich diese ganze Sache ursprünglich einmal in Angriff genommen hatte. Die Situation ist die folgende: Für den Microcontroller meiner KC-Tastatur bearbeite ich den Assemblerquelltext am KC. Einen Assembler für den Controller gibt es aber nur für MS-DOS, so daß ich den Quelltext nur auf dem PC übersetzten kann. Das EPROM-Programmiergerät betreibe ich wiederum am KC, so daß der übersetzte Objektcode (Binärdatei!!!) im KC vorliegen muß. Die drei notwendigen Abläufe Quelltext zum PC übertragen, Assemblieren und Objektcode zum KC übertragen werden mit der folgenden SUB-Datei automatisert:

c0:comsend c:
g          cd \8048\cherry 
g copy c:\kcnet\eof.eof /b com1 
g copy com1 cherry.asm 
g \8048\asm\asm48 cherry.asm >com1 
g copy cherry.lst com1 
g copy c:\kcnet\eof.eof /b com1 
g uuencode -o cherry.bin 
g copy cherry.uue com1 
g copy c:\kcnet\eof.eof /b com1 
g -a c:\kcnet\loop 
; 
c0:rm cherry.uue cherry.bin 
c0:conempf 
c0:kcsend cherry.asm 
c0:conempf -c 
c0:kcempf cherry.uue 
c0:uudecode cherry.uue

Ich überlasse es dem Entdeckungsdrang eines jeden einzelnen, das Beispiel gedanklich nachzuvollziehen. Als Hinweise nur soviel: Zwischen dem Senden der Kommandofolge an den PC und dem Übertragen des Quelltextes empfängt der KC mittels CONEMPF eine leere Datei, ein einzelnes EOF, ausgelöst durch die dritte übertragene Kommandozeile. Wegen des fehlenden Handshakings bei der Übertragung zum PC verhindert dies, daß der Quelltext CHERRY.ASM bereits gesendet wird, bevor der PC dafür empfangsbereit ist - also eine Art Handshaking auf Dateiebene. Der Assembler \8048\ASM\ASM48 erzeugt neben dem Objektcode CHERRY.BIN auch die Textdatei CHERRY.LST, die eine kurze Statistik über den Verlauf des Assembliervorganges enthält.

Das Beispiel soll vor allem zeigen, daß auch Funktionen mit komplexeren Übertragungsabläufen möglich sind. Wichtig ist, daß man bei der Programmierung den Überblick behält, was zeitlich nacheinander auf beiden Rechnern abläuft, und wie der Ablauf auf beiden Rechnern synchronisiert werden kann. In der SUB- Datei sind dann die Kommandos für beide Rechner getrennt aufgeführt (oberer Teil PC, unterer Teil KC), so daß es durchaus einige Mühe macht, den Gesamtablauf zu rekonstruieren.

MTOOLS

Das Dateimanagement mit den oben beschriebenen SUB-Dateien funktioniert zwar schon ganz gut, aber um die ganze Sache noch etwas komfortabler, schneller und übersichtlicher zu machen, habe ich zu jeder der SUB-Dateien ein COM-Programm erzeugt, das die gleiche Funktion realisiert. Jedem dieser Programme kann durch Aufruf mit der Option ,,-H`` eine kurze Hilfe ,,entlockt`` werden, die auch beim Aufruf mit fehlenden Parametern angezeigt wird.

MDIR.COM

Anzeige des PC-Directories; die Angabe eines Laufwerkes, eines Pfades und/oder Filenames mit Jokerzeichen - wie unter MS-DOS üblich - ist möglich; nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen.

Beispiele:

MDIR
MDIR *.BAT
MDIR A:\TEXT\*.TXT

 

MCD.COM

Anzeige des aktuellen Pfades, Wechsel des Pfades oder Wechsel des PC-Laufwerkes.

Beispiele:

MCD                (Anzeige des aktuellen Pfades)
MCD ..\TEXT        (Wechsel des Pfades)
MCD A:             (Wechsel des Laufwerkes)

 

MGET.COM

Kopieren einer (Text-)Datei vom PC zum KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich und wird beim Speichern im KC ignoriert; die Datei wird ins aktuellen KC-Laufwerk geschrieben und erhält den gleichen Namen wie im PC; es gibt keine Beschränkung für die Dateigröße; für jeden empfangenen Sektor (128 Bytes) wird ein ,,#`` auf dem Bildschirm ausgegeben; eine mit ,,#`` gefüllte Zeile entspricht damit 10 KB.

Beispiele:

MGET TEXT.TXT
MGET A:\TEXT\TEXT.TXT

 

MPUT.COM

Kopieren einer (Text-)Datei vom KC zum PC; die Angabe eines Laufwerkes und/oder Userbereiches (Syntax beachten!) ist möglich und wird beim Speichern im PC ignoriert; die Datei wird in den aktuellen PC-Pfad geschrieben und erhält den gleichen Namen wie im KC; es gibt keine Beschränkung für die Dateigröße; für jeden gesendeten Sektor (128 Bytes) wird ein ,,#`` auf dem Bildschirm ausgegeben; eine mit ,,#`` gefüllte Zeile entspricht damit 10 KB.

Beispiele:

MPUT TEXT.TXT
MPUT 1/A:TEXT.TXT            (Kopieren der Datei A1:TEXT.TXT)

 

MTYPE.COM

Anzeige einer Textdatei vom PC auf dem KC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS-DOS üblich - ist möglich; nach Ausgabe einer Bildschirmseite wartet das Programm auf eine Tastenbetätigung, um die Anzeige fortzusetzen.

Beispiele:

MTYPE TEXT.TXT
MTYPE A:\TEXT\TEXT.TXT

 

MDEL.COM

Löschen einer Datei im PC; die Angabe eines Laufwerkes und/oder Pfades - wie unter MS- DOS üblich - ist möglich; der Dateiname muß eindeutig sein.

Beispiele:

MDEL TEXT.TXT
MDEL A:\TEXT\TEXT.TXT

 

MEXIT.COM

Beenden der Batch-Schleife im PC und Rückkehr des PCs in den normalen Eingabemode über die Tastaur.

 

Der Aufruf von MDIR bringt nun z.B. in kürzester Zeit und ohne störende anderweitige Bildschirmausgaben das PC-Directory zur Anzeige:

A0>mdir

 Volume in Laufwerk C ist harddisk 01
 Verzeichnis von  C:\KCNET

.            <DIR>     21.06.98  23.12
..           <DIR>     21.06.98  23.12
START    BAT       81   9.07.98  23.58
LOOP     BAT       46   8.07.98  18.32
EOF      EOF        1   4.07.98  21.36
RCOM     BAT       63   3.08.98  22.44
        6 Datei(en)   3639296 Bytes frei

Im einzelnen lösen diese Programme die gleichen Aktionen aus wie die entsprechenden SUB- Dateien. Um die Konfigurierbarkeit trotz der jetzt fest einkompilierten Kommandos zu gewährleisten, habe ich die Batch-Dateien im PC noch etwas erweitert. Dazu werden in START.BAT die zwei Systemvariablen KCPATH und KCPORT definiert. Sie enthalten zum einen das Verzeichnis, in dem sich die Batchdateien START.BAT, LOOP.BAT und RCOM.BAT sowie die Datei EOF.EOF befinden, und zum anderen die Schnittstelle, über die der KC am PC angeschlossen ist. Im folgenden wird nun anstelle der expliziten Pfad- bzw. Schnittstellenbezeichnung immer - auch in den vom KC gesendeten Kommandozeilen - der Inhalt der entsprechenden Systemvariable (%KCPATH% bzw. %KCPORT%) verwendet. Damit können die MTOOLS auch verwendet werden, wenn der PC über eine andere Schnittstelle mit dem KC verbunden ist oder die genannten Dateien in einem anderen Verzeichnis stehen. START.BAT hat somit folgenden Inhalt:

set kcpath=c:\kcnet\
set kcport=com1
mode %kcport%:2400,n,8,1,p
%kcpath%loop

LOOP.BAT enthält jetzt die folgenden Zeilen:

copy %kcport% %kcpath%rcom.bat
%kcpath%rcom

Diese Variante befindet sich auch im Archiv auf der Beilagendiskette. In dieser Form ist sie kompatibel mit den oben vorgestellten SUB-Dateien, in denen sich noch die direkten Angaben für Pfad und Schnittstelle befinden. Diese müßten bei Bedarf noch angepaßt werden, was aber leicht mit einem Texteditor zu erledigen ist.

In der vorliegenden Form sind die MTOOLS wegen der Abhängigkeit von einigen Arbeitszellen im Koppel-RAM nur auf dem KC lauffähig. Weiterhin beinhalten sie noch nicht die Übertragung von Binärdateien. Zu letzterem ist noch die Implementierung des UUDECODE- UUENCODE-Verfahrens notwendig. Ich verweise an dieser Stelle schon mal vorab auf das erste Update...

Ausblick

Nachdem wir nun den PC zu einer Art ,,intelligenten Peripheriegerät`` für den KC gemacht haben, dem wir durch Senden von geeigneten Kommandofolgen die gewünschten Reaktionen entlocken können, lassen weitere Wünsche bestimmt nicht lange auf sich warten.

Sehr wünschenswert wäre es natürlich, sich die Kommandozeile des PC direkt auf den KC zu holen. Dann wären wir nicht mehr auf Spezialprogramme für einzelne Funktionen angewiesen, sondern könnten mit einem Universalprogramm gleich die ganze Funktionalität des PC am KC erreichen. Dazu ist am KC ein Terminalprogramm notwendig und für den PC brauchen wir ein sogenanntes Remote-Access-Programm - also ein Programm für den Fernzugriff. Auch darüber wird es mehr in einer der nächsten Ausgaben der KC-News zu lesen geben.

Für heute bleibt mir nur noch, Euch viel Spaß beim Experimentieren zu wünschen und auch noch einmal die Bitte an Euch zu richten, mir und allen anderen Lesern Eure Erfahrungen, Probleme und Hinweise zu diesem Thema (insbesondere zu den Punkten Nullmodemkabel und Handshaking) mitzuteilen.