KC-News 4/1998

Rechnerkopplung - MTOOLS-Update

von Frank Dachselt

Dieser Beitrag knüpft direkt an das Thema Rechnerkopplung aus den KC-News 3/98 an. Dort wurde bereits das Programmpaket MTOOLS vorgestellt, für das es heute ein Update mit einigen Erweiterungen und wesentlichen Verbesserungen gibt. Die grundlegenden Funktionen zur Bedienung des MS-DOS-Filesystems vom KC aus sowie zum Dateitransfer zwischen KC und PC sind ja bereits vorhanden, allerdings gab es bisher noch einige Unzulänglichkeiten. Das wäre zum einen das fehlende Handshaking für die Übertragungsrichtung KC --> PC (wie bereits in den KC-News 3/98 beschrieben) sowie - wie sich inzwischen herausgestellt hat - die fehlende Verträglichkeit mit dem ,,Mutlitaskingbetriebssystem`` Windows. Letzteres hat es unmöglich gemacht, die Batch-Steuerschleife in einem MS-DOS-Fenster unter Windows aller bekannten Versionen fehlerfrei abzuarbeiten. Die Ursache dafür liegt in dem ungenügendem Standardtreiber für die serielle Schnittstelle in MS-DOS. Dieser verwendet zur Abfrage der seriellen Schnittstelle ein einfaches Polling ohne jegliche Hardware-Puffer (auch wenn solche auf dem SIO-Schaltkreis vorhanden sind). So kommt es unter Windows unweigerlich zu Datenverlusten bei der Übertragung KC --> PC, was mit entsprechenden Fehlermeldungen im MS-DOS-Fenster und dem Abbruch der Steuerschleife einhergeht. Die Anwendung der MTOOLS war damit bisher auf den reinen MS-DOS-Mode des PC beschränkt. Abhilfe war nur durch einen neuen Treiber für die serielle Schnittstelle zu erwarten.

Ein neuer Treiber löst (fast) alle Probleme

Nach einigem Suchen war dann auch ein geeigneter Treiber gefunden: Er nennt sich ADF und befindet sich im Archiv ADF_144.ZIP auf der Beilagendiskette. Dieser Treiber arbeitet interruptgesteuert, verwendet Sende- und Empfangspuffer (sowohl hard- als auch softwaremäßig) und realisiert ein richtiges RTS/CTS-Handshaking. Aus dem Paket werden eigentlich nur die Programmdateien ADF.EXE und REGISTER.EXE benötigt. Leider ist die Beschreibung in Englisch, deshalb im folgenden ein paar Hinweise zur Benutzung. Der Aufruf von ADF initialisiert den neuen Treiber und ersetzt das bisher verwendete MODE-Kommando. In der Datei START.BAT ist das MODE-Kommando also durch einen entsprechenden ADF-Aufruf auszutauschen. Beim Aufruf können eine Reihe von Parametern übergeben werden. Soll die COM1-Schnittstelle benutzt werden, sieht die Kommandozeile etwa wie folgt aus:

C:\>ADF COM1 3F8 4 2400 1024 1024 1

Die übergebenen Parameter haben in der angegebenen Reihenfolge folgende Bedeutung:

• Name des COM-Ports (COM1)
• I/O-Basisadresse des verwendeten COM-Ports (3F8)
• Nummer des verwendeten Interrupts (4)
• Baudrate (2400)
• Größe des FIFO-Puffers im Hauptspeicher für Empfangsdaten (1024)
• Größe des FIFO-Puffers im Hauptspeicher für Sendedaten (1024)
• Steuerbyte für den Hardware-FIFO-Puffer des SIO-Schaltkreises (1)

Soll ein anderer COM-Port benutzt werden, dann sind die ersten drei Parameter entsprechend anzupassen. Die Standardwerte dafür lauten:

C:\>ADF COM2 2F8 3 2400 1024 1024 1

C:\>ADF COM3 3E8 4 2400 1024 1024 1

C:\>ADF COM4 2E8 3 2400 1024 1024 1

Es können noch weitere Parameter übergeben werden, aber bei denen sind die Vorgabewerte bereits passend gesetzt. Das betrifft auch das Datenformat (8,N,1), das standardmäßig verwendet wird. Die Größen für Empfangs- und Sendepuffer können auch höher gewählt werden, aber für die derzeitigen Übertragungsraten von maximal 2400 Baud sind 1024 Bytes völlig ausreichend.

Mit dem Wert 1 für den Hardware-FIFO-Puffer wird dieser praktisch ausgeschaltet. Das ist notwendig für ein datenverlustfreies Zusammenwirken mit der Z80-SIO am KC. Wird bei der Übertragung vom PC zum KC die Handshake-Leitung von der KC-Seite zurückgesetzt, um das Datensenden zu unterbrechen, wird stets noch der gesamte Pufferinhalt der PC-SIO gesendet. Das würde den 3-Byte-Empfangspuffer der Z80-SIO leicht überfüllen. Mit dem Wert 1 ist gesichert, daß nach dem Rücksetzten der Handshakeleitung maximal noch ein Byte gesendet wird, für das die Z80-SIO garantiert noch aufnahmefähig ist.

Der Beschreibung zum ADF-Paket ist zu entnehmen, daß der Hardware-FIFO-Puffer auch in der Systemsteuerung von Windows 95/98 auszuschalten sowie in der Datei SYSTEM.INI die Größe des Empfangspuffers im Hauptspeicher anzugeben ist (siehe ADF.TXT für Einzelheiten). Inwieweit letzteres wirklich notwendig ist, kann ich nicht genau beurteilen. Die Datenübertragung funktioniert auch ohne diese Angabe.

Mittels der Kommandozeile

C:\>ADF UNLOAD

wird der ADF-Treiber deaktiviert und aus dem Speicher gelöscht. Eventuell noch im Sende- oder Empfangspuffer vorhandene Daten gehen dabei verloren.

Das ADF-Paket ist Shareware. Vor der Benutzung ist eine Registrierung mittels REGISTER.EXE notwendig, sonst verweigert ADF seine Dienste. Die Frage nach dem Namen des zu registrierenden Programms ist mit ,,ADF.EXE`` zu beantworten. Die Eingabe des Nutzernames übergeht man mit ENTER, dann ist das Programm für eine Testphase von 30 Tagen ,,registriert``. Ob man sich nach diesem Zeitraum ,,richtig`` registrieren läßt, muß jeder selbst mit seinem Gewissen ausmachen. Das Programm funktioniert jedenfalls auch noch danach uneingeschränkt und läßt sich beliebig oft für eine neue Testphase ,,freischalten``...

Ein neues Kabel

Wie bereits erwähnt, beherrscht der ADF-Treiber im Gegensatz zum MS-DOS-Standardtreiber das RTS/CTS-Handshaking-Protokoll. Dessen Fehlen hatte ja für die erste Version der MTOOLS einige Konsequenzen. Um dieses Protokoll nun für die Datenübertragung zwischen KC und PC zu benutzen, muß am bisherigen Nullmodemkabel (Bild 4(d) auf Seite 7 der KC-News 3/98) nur ein Draht am PC-seitigen Stecker umgelötet werden, und zwar ist der wegführende Draht vom Anschluß DTR auf den noch freien Anschluß RTS zu legen. Das resultierende Kabel ist im Bild 1 noch einmal dargestellt.

Bild 1: Nullmodemkabel für das RTS/CTS-Protokoll mit ADF.EXE

Auch wenn der ADF-Treiber ebenso mit der alten Kabelvariante zusammenarbeitet, so ist die Benutzung dieses Protokolls dringend zu empfehlen. Die Übertragung wird dadurch erheblich sicherer, insbesondere bei den uns bevorstehenden wesentlich höheren Übertragungsraten.

Der Effekt des nunmehr vollständigen Handshakings kann am deutlichsten im Zusammenhang mit den Puffern des ADF-Treibers beobachtet werden. Dazu installiert man den neuen Treiber mit einer der oben angegebenen Kommandozeilen für einen Sende- und Empfangsdatenpuffer von jeweils 1024 Byte. Auf dem KC erzeugt man mit einem Texteditor eine Textdatei TEST.TXT, die eine Länge von etwa 2000 Byte hat, also ungefähr das Doppelte der Pufferkapazität im PC. Diese sendet man nun mittels KCSEND (KC-News 2/98) an den PC, ohne daß am PC schon etwas für den Empfang dieser Datei vorbereitet wurde:

A0>KCSEND TEXT.TXT

An der Ausgabe von KCSEND erkennt man, daß etwas gesendet wird. Etwa in der Mitte der Übertragung unterbricht der KC das Senden der Datei, weil jetzt der Empfangspuffer des ADF-Treibers voll ist und dieser diesen Zustand mittels eines inaktiven RTS-Signals dem KC mitteilt. Erst wenn die Bytes mit

C:\>COPY COM1 TEXT.TXT

aus dem Puffer abgeholt werden, wird die RTS-Leitung wieder aktiv und es können weitere Bytes gesendet werden. Der Test für die Gegenrichtung könnte wie folgt aussehen: Auf dem PC erzeugt man eine Textdatei TEXT1.TXT, die etwa 500 Bytes lang ist und damit bequem im Sendepuffer des ADF-Treibers Platz findet. Wird diese Datei mittels

C:\>COPY TEXT1.TXT COM1

an den KC gesendet, dann meldet die COPY-Routine am PC sofort den Erfolg dieser Aktion, auch wenn am KC noch kein Byte empfangen wurde. Die Textdatei steht jetzt vollständig im Sendepuffer und der ADF-Treiber wartet auf das aktive CTS-Signal, um mit den Senden beginnen zu können. Das geschieht, indem man am KC die Datei empfängt:

A0>KCEMPF TEXT1.TXT

Der Empfang muß an dieser Stelle noch mittels BRK-Taste am KC beendet werden, da der PC bekanntermaßen kein EOF-Zeichen am Ende einer Textdatei sendet.

Wenn diese beiden Experimente erfolgreich, d.h. ohne Datenverlust, verlaufen sind, dann kann man sich sicher sein, daß der ADF-Treiber richtig installiert ist. Nun ist es auch an der Zeit, die neue Version der MTOOLS auszuprobieren.

MTOOLS-Erweiterungen

Die Programme zur Fernsteuerung des PC und zum Zugriff auf das MS-DOS-Filesystem vom KC aus liegen jetzt in der Version 1.1 vor. Die Versionsnummer wird jetzt auch im Hilfetext angezeigt (Option -h). Die Veränderungen betreffen insbesondere die beiden Programme MPUT.COM und MGET.COM. Zum einen können beim Senden wie auch beim Empfangen von Dateien die Jokerzeichen ? und * verwendet werden und so ganze Dateigruppen mit jeweils einer Kommandozeile übertragen werden. Des weiteren sind diese beiden Programme jetzt mit der UUE-Kodierung (siehe KC-News 3/98) ausgerüstet worden, so daß auch Binärdateien übertragen werden können. Die Übertragung von Binärdateien wird mit der Option -b veranlaßt. Bei der Übertragung solcher Dateien vom KC zum PC (MPUT.COM) werden die einzelnen Bytes vor dem Senden kodiert. Die Dekodierung im PC geschieht durch einen (automatischen) Aufruf des Programms UUDECODE.COM, so daß nach der Übertragung sofort wieder die Binärdatei vorliegt. In der Gegenrichtung wird eine Binärdatei im PC zunächst (automatisch) mit dem Programm UUENCODE.COM kodiert. Danach wird die kodierte Datei gesendet und beim Empfang im KC durch MGET.COM wieder dekodiert. Damit dieses Verfahren funktioniert, müssen in PC die Programme UUENCODE.COM und UUDECODE.COM in einem Verzeichnis stehen, das Bestandteil der PATH-Variable von MS-DOS ist, damit ein grundsätzlich ein einfacher Aufruf über den Programmnamen möglich ist.

Es folgen einige Beispiele, die die neuen Möglichkeiten von MPUT.COM und MGET.COM demonstrieren:

• Übertragen aller Textdateien (*.TXT) vom Laufwerk A, Userbereich 1 an den PC:

  MPUT 1/A:*.TXT
  
  

• Dem Programm MPUT.COM kann auf der Kommandozeile eine Liste von zu übertragenden Dateien übergeben werden, wobei jeder Eintrag in dieser Liste auch Jokerzeichen einhalten kann. Übertragung aller TXT- und DOK-Dateien sowie der Datei PROG.ASM aus dem aktuellen Laufwerk/Userbereich an den PC:

  MPUT *.TXT *.DOK PROG.ASM
  
  

• Werden dem Programm MPUT.COM mehrere Dateibezeichnungen übergeben, dann können diese auch auf unterschiedlichen Laufwerken stehen. Übertragung aller TXT-Dateien von den Laufwerken B und E (aus dem aktuellen Userbereich) an den PC:

  MPUT B:*.TXT E:*.TXT
  
  

• Alle PMA-Archive vom Laufwerk C: werden als Binärdateien an den PC gesendet:

  MPUT -B C:*.PMA
  
  

• Dem MGET-Kommando kann nur eine einzelne Dateibezeichnung übergeben werden, die aber auch Jokerzeichen enthalten kann. Übertragen aller TXT-Dateien aus dem aktuellen PC-Verzeichnis an den KC:

  MGET *.TXT
  
  

• Die Dateibezeichnung beim MGET-Kommando kann auch eine absolute oder relative Pfadangabe enthalten. Übertragen aller TXT-Dateien aus dem PC-Verzeichnis mit dem relativen Pfad ..\TEXT an den KC:

  MGET ..\TEXT\*.TXT
  
  

• Alle PMA-Archive aus dem aktuellen PC-Verzeichnis werden als Binärdateien an den KC gesendet:

  MGET -B *.PMA
  
  

Die Übertragung einer Datei als Binärdatei muß also explizit durch die Angabe der Option -b veranlaßt werden, im anderen Fall wird von einer Textdatei ausgegangen und die Übertragung beim ersten Byte 1AH beendet. Eine automatische Unterscheidung zwischen Text- und Binärdateien ist prinzipiell nicht möglich. Bestenfalls könnte man die Dateierweiterungen auswerten, aber auch das verspricht nur beschränkten Erfolg. Auf der sicheren Seite wäre man, wenn alle Dateien als Binärdateien übertragen werden. Auf diese Möglichkeit habe ich aber vorerst wegen der noch ungenügenden Übertragungsgeschwindigkeiten verzichtet, da das Senden als Binärdatei etwa 30 Prozent mehr Zeit in Anspruch nimmt. Allerdings ist auch hier Vorsicht geboten, da eine als Binärdatei an den KC gesendete Textdatei am Dateiende keine EOF-Marke mehr besitzt, was zum Anhängen ungütiger Zeichen am Dateiende führt.

Eine weitere Veränderung hat das Programm MEXIT.COM erfahren, mit dem die Batch-Steuerschleife im PC beendet wird. Um nach der Benutzung des ADF-Treibers (oder auch anderer) definierte Verhältnisse zu erreichen, wird jetzt noch die Datei EXIT.BAT aufgerufen (Bild 2). In dieser Datei können Kommandos zum Deaktivieren von Treibern und anderen ,,Aufräumarbeiten`` stehen. Im vorliegenden Fall enthält diese Datei nur den Befehl ADF UNLOAD (siehe oben) zum Deaktivieren des ADF-Treibers.

Bild 2: Batch-Steuerschleife für die MTOOLS-Version 1.1

Zum Schluß noch ein Hinweis, den ich nicht ausführlich begründen möchte: Bedingt durch eine Time-Out-Funktion des ADF-Treibers arbeiten die MTOOLS erst ab der aktuellen Version 1.1 korrekt mit diesem zusammen. Bei der Verwendung der Version 1.0 aus den KC-News 3/98 mit dem ADF-Treiber kommt es dagegen mitunter zu Fehlfunktionen (aber zu keinen Datenverlusten). Andererseits können die MTOOLS der Version 1.1 uneingeschränkt mit der ursprünglichen Treibervariante (MODE-Kommando) eingesetzt werden.

Installationshinweise

An dieser Stelle sollen die Schritte zur Installation der MTOOLS auf dem KC und dem PC noch einmal in kompakter Form zusammengestellt werden:

• Installationsschritte auf dem KC
  
  
  1. Entpacken der MTOOLS-COM-Dateien aus dem Archiv MTOOLS11.PMA
  2. Installieren des Koppeltreibers (siehe auch KC-News 2/98) für 2400 Baud:

     
     A0>DRIVER V24H24A.KOP

     oder

     A0>DRIVER V24H24B.KOP

     Diese beiden Befehle trägt man günstigerweise in die Start-SUBMIT-Datei ein, so daß die Treiber beim Booten des Systems automatisch geladen werden.

• Installationsschritte auf dem PC
  
  
  1. Aus dem Archiv ADF_144.ZIP werden die Dateien ADF.EXE und REGISTER.EXE benötigt. Diese gehören in ein Verzeichnis, das auch Bestandteil der Path-Variable von MS-DOS ist.
  2. Nach dem Wechsel in das Verzeichnis, in dem sich ADF.EXE und REGISTER.EXE befinden, wird das Programm REGISTER.EXE ausgeführt. Die Frage nach dem Namen wird mit ,,ADF.EXE`` beantwortet, die Frage nach dem Usernamen mit ENTER übergangen.
  3. Aus dem selbstentpackenden Archiv MTOOLS11.EXE gehören die Programme UUENCODE.COM und UUDECODE.COM in das gleiche Verzeichnis wie bereits der ADF-Treiber.
  4. Die BAT-Dateien sowie die Datei EOF.EOF aus MTOOLS11.EXE werden in ein neues Verzeichnis (z.B. C:\KCNET) kopiert.
  5. In der Datei START.BAT werden die beiden Variablen KCPORT und PCPATH - falls notwendig - angepaßt. KCPORT ist der Name der seriellen Schnittstelle, über die der KC angeschlossen ist. KCPATH ist der Pfad des Verzeichnisses mit den BAT-Dateien. Weiterhin muß der Aufruf des ADF-Treibers an die Nummer der verwendeten Schnittstelle angepaßt werden (siehe Beispiel am Beginn dieses Beitrages).

Nach diesen Schritten sind die MTOOLS startklar! Dabei wird immer zuerst die Datei START.BAT aus dem im Punkt 4 genannten Verzeichnis auf dem PC gestartet, womit die in Bild 2 gezeigte Steuerschleife in Aktion tritt. Danach können vom KC aus durch Aufruf der entsprechenden Programme die gewünschten Aktionen ausgelöst werden.

Schneller, weiter, höher, ...

An dieser Stelle soll es vorwiegend um das ,,schneller`` gehen. Jeder, der das langsame Wachsen des Balkens auf dem KC-Bildschirm beim Übertragen von Dateien beobachtet, wird sich unweigerlich fragen, ob das nicht auch schneller geht. Die Antwort lautet: Vorerst nicht! Bedingt durch die ,,krumme`` Taktfrequenz des KC-Grundgerätes ist es nicht möglich, im V.24-Modul hinreichend exakte Übertragungsraten jenseits der 2400 Baud zu erzeugen. Unter günstigen Umständen funktionieren zwar auch noch 4800 Baud, aber dazu ist ein kleiner Trick notwendig, mit dem ich hier nicht erst anfangen möchte.

Inzwischen zeichnet sich eine viel bessere Lösung ab. Mit der vollen Ausbaustufe des Scanner-Moduls von Enrico Grämer wird es möglich sein, Übertragungsraten von bis zu 115200 Baud zu erreichen. Mit geeigneten Schnittstellentreibern und einer angepaßten Kopplung von Grundgerät und D004 könnten damit die Übertragungsraten von derzeit etwa 0,2 KByte/s bis auf nahezu 10 KByte/s steigen. Wer also an einem schnellen Datenaustausch zwischen KC und PC interessiert ist, der sollte sich schon mal für eines dieser Module vormerken lassen!

Damit aber erst mal genug der Zukunftsmusik. Wie auch bereits beim letzten Mal bin ich wieder sehr an Erfahrungsberichten über das Nachvollziehen der Rechnerkopplung und über die Anwendung der MTOOLS interessiert.

Viel Spaß beim Experimentieren!