Die originale KERMIT-80 Version für RS-232 überträgt nach wenigen Änderungen Daten per Kermit-Protokoll im TCP/IP-Netzwerk und lässt sich als einfacher TELNET-Client mit dem KC85 unter CP/M einsetzen.

Im folgenden Beitrag geht es um das legendäre KERMIT-Programm. Die Bezeichnung Programm ist allerdings reichlich untertrieben, da es sich eigentlich um eine ganze Familie von Programmen handelt, welche seit 1981 im Rahmen des KERMIT-Projektes der "Columbia University" entwickelt wurden.

Der gemeinsame Nenner aller Programme ist das KERMIT-Protokoll für die Übertragung von Daten zwischen verschiedenen Systemen. Das Protokoll ist unabhängig von der physischen Verbindung, es funktioniert beispielsweise sowohl über TCP/IP in Netzwerken als auch über serielle Kabel oder Modems an der seriellen Schnittstelle.

Die KERMIT Software beherrscht viele weitere Funktionen, wie die Emulation verschiedener Terminals oder die Automatisierung von Kommunikationsaufgaben mit Hilfe einer integrierten hochsprachenähnlichen Script-Sprache, welche plattformunabhängig arbeitet. Sehr ausführliche Informationen über KERMIT und seine Geschichte findet man auf der umfangreichen Website der "Columbia University".

http://www.columbia.edu/kermit

Die KERMIT-Version für CP/M war die erste Umsetzung des Protokolls in ein Programm überhaupt. Die originale Version wurde von Bill Catchings 1981 an der Columbia University geschrieben. Die Weiterentwicklung endete 1991 mit der letzten Version 4.11. Die Assembler-Quellen kann man sich von der Universitätsseite herunterladen.

http://www.columbia.edu/kermit/cpm.html

KERMIT-80 Quelltexte

Da das KC85 System bis heute kein richtiges CP/M-Terminalprogramm für de Kommunikation per serieller Schnittstelle besitzt, hatte ich mich vor einiger Zeit schon einmal mit den Quelltexten von KERMIT-80 auseinandergesetzt. Das Ergebnis war damals eher ernüchternd, da ich es nicht geschafft habe, die Übersetzung der Originalquellen auch nur ansatzweise fehlerfrei durchzuführen. Der Assembler M80 meldete immer nicht nachvollziehbare Fehler, so dass die ganze Geschichte wieder weggelegt wurde.

Mit der Fertigstellung der Basis-Software für das Netzwerk wurde KERMIT allerdings wieder sehr interessant. Da es sich um fertige Software handelt, welche unabhängig von der Hardware arbeiten kann, sollte auch die Nutzung von TCP/IP als Übertragungsmedium problemlos möglich sein. Die "grösseren" Brüder und Schwestern von KERMIT für MS-DOS, Windows oder Unix beherrschen das auch.

Zunächst musste aber erst einmal das Übersetzungsproblem aufgeklärt werden. Die Lösung war dann - wie immer - recht einfach, man muss eben nur darauf kommen. Alle originalen CP/M-Quelltexte des Archives liegen merkwürdigerweise als Unix-Text vor, statt CR/LF gibt es nur ein LF für ein Zeilenende und damit kommt M80 nicht klar, nach der Konvertierung aller notwendigen Quellen in das CP/M übliche Textformat funktionierte die Übersetzung sofort ohne Fehler.

Der nächste Schritt war die Analyse und das Verstehen der vielen ASM-Dateien. Zum Glück gibt es ein sehr umfangreiches und ausführliches Handbuch dafür, wo die wichtigen Sachen auch alle erklärt werden. Nachdem das einigermassen verarbeitet war, gab es schon wieder ein Problem für mich - ASM bedeutet 8080-Code und nicht Z80, damit hatte ich bisher noch nie etwas zu tun.

Im Grunde beschränkt sich aber die Anpassung von KERMIT-80 an ein noch nicht unterstütztes CP/M-System auf die Erstellung der systemspezifischen Datei CPX???.ASM, wenn man alle I/O-Routinen für das eigene System selbst zur Verfügung stellt. Benutzt man nun M80 als Assembler, kann man auch in seiner CPX-Datei mit ".Z80" auf Z80-Code umschalten und am Ende mit ".8080" wieder zurück. Da meine Version für den KC85 immer auf einem Z80 laufen wird, darf man das mischen, der Z80 kann ja beide Varianten. Dadurch konnte ich wie gewohnt meine Quelltexte schreiben und musste mich nicht weiter mit der 8080-Syntax auseinandersetzen.

KERMIT-80 4.11 über RS-232

Ich habe mich nur kurz mit den vielen vorhandenen CP/M-Varianten der anderen Systeme beschäftigt, nur soweit, wie das für das Verständnis der Quellen notwendig war. Der erste Anlauf war die Nutzung der seriellen Schnittstelle unter CP/M per Umschaltung über das I/O-Byte - also ohne direkte Programmierung der Hardware durch KERMIT.

Für einen spontanen Versuch gibt es sogar zwei fertige HEX-Dateien im Archiv für vollkommen generische CP/M Systeme, welche 100%-ig den Vorgaben von DR bezüglich I/O-Byte und zugeordneter Subkanäle entsprechen. Die beiden Dateien muss man nur noch mit MLOAD.COM zur KERMIT.COM-Datei zusammenfügen, welche sich anschliessend sofort auf dem eigenen System ausprobieren lässt. Das hat natürlich mit dem KC-CP/M nicht funktioniert, genauso wenig wie eine zweite Variante, mit speziellen Anpassungen der I/O-Byte Steuerung für das KC System.

Das eigentliche KERMIT Programm hat nach der Übersetzung der angepassten Quellen eigentlich problemlos gearbeitet. Ich konnte es starten und alle Offline-Befehle aufrufen. Wenn man allerdings versuchte mit anderen Rechnern zu kommunizieren, war es immer nur eine Frage der Zeit, bis KERMIT fest hing und der KC auch nicht mehr bedient werden konnte.

Die Ursachen liegen in der Programmierung der vorhandenen Koppeltreiber und ihrer komplizierten Anbindung und Handhabung vom D004 aus gesehen. Sobald man beispielsweise die Empfangsfunktion des Koppeltreibers aufruft und keine Zeichen zur Verfügung stehen, wird der KC blockiert, bis ein Zeichen empfangen wurde oder die BRK-Taste gedrückt wird. Damit kommt KERMIT nicht klar. Immerhin war ich aber zumindest in der Lage, in die andere Richtung Zeichen zum PC zu senden, welche dann auch im Fenster von HyperTerminal zu sehen waren. Eine Übertragung von Dateien war weder in die eine noch andere Richtung möglich.

Ich habe das dann auch nicht weiter untersucht. Abhilfe wäre sicher zu schaffen, wenn man für den KC85/4 einen universelleren DRV-Treiber für die seriellen Schnittstellen des M051 und M003 schreiben würde. Der dürfte den KC nicht blockieren und sollte idealerweise Statusabfragen enthalten, über die man die Bereitschaft zum Senden und das Vorhandensein von Empfangsdaten vor dem Aufruf der Sende- bzw. Empfangfunktion der Schnittstelle feststellen könnte - dann funktioniert KERMIT auch auf dem KC über die serielle(n) Schnittstelle(n). Interessant ist das auf alle Fälle, da man so Kontakt zu fast allen gängigen Systemen bekommt, angefangen vom C64 über den Amiga bis hin zu Mainframes :-).

KERMIT-80 4.11 über TCP/IP

Da ich nach dieser Aktion schon ziemlich tief in die Quellen von KERMIT eingestiegen war, ging es schliesslich noch in das Netzwerk-Experiment. Eine interessante Eigenschaft von KERMIT ist neben der Datenübertragung die eingebaute Terminal-Emulation. Damit würden sich andere Systeme auf standardisierte Art und Weise (fern)bedienen lassen, wenn sie die Standard-KERMIT-Emulation VT52 verstehen. Der Netzwerk-Treiber weist die o.g. Mängel der Koppeltreiber nicht auf und sollte dadurch problemlos funktionieren.

Am Ende hätte man fast zum Nulltarif einen einfachen TELNET-Client für den KC zur Verfügung, mit dessen Hilfe eine Einwahl in den TELNET-Server andere Systeme möglich ist. Damit wird die Kommandozeile des anderen Systems auf den KC geholt und der andere Rechner kann komplett auf dieser Ebene fernbedient werden. Andere CP/M-Systeme dürften damit zur Zeit als Gegenstelle zwar nicht in Betracht kommen - dort müsste dann ein TELNET-Server laufen, welchen es ja per TCP/IP (noch) nicht gibt.

Wie und wo gab es dann etwas zu tun an KERMIT-80? Die Quellen sind zweigeteilt, es gibt den systemunabhängigen Teil, welcher fertig übersetzt als "cpsker.hex" zur Verfügung steht und unverändert genutzt werden kann. Für die Anpassung an das eigene System gibt es dann mehrere ASM-Dateien mit verschiedenen Aufgaben. In der folgenden Tabelle sind alle Dateien mit entsprechenden Hinweisen und Kommentaren aufgeführt (* - diese Dateien sind nicht Bestandteil der originalen KERMIT-Quellen):

Die Programmierung beschränkte sich nun hauptsächlich auf die Erstellung der Datei CPXK85.ASM mit den speziellen Programmen für alle KC85 Ein- und Ausgaben und die Nutzung des TCP/IP-Netzwerkes über die KCNet-Schnittstelle, statt serieller Schnittstelle. KERMIT bekommt davon selbst gar nichts mit, alles muss so aussehen, als ob die Daten über RS-232 transportiert werden.

Das KERMIT Handbuch beschreibt alle vorhandenen Unterprogramme, wo man Anpassungen für das eigene System vornehmen kann. Ein Teil davon befindet sich allerdings in der Datei "cpxcom.asm", für CP/M 2.x Systeme sollten die allerdings immer passen. Auch die KC85-Version nutzt diese allgemeinen CP/M Unterprogrammvarianten unverändert. In der Datei "CPXK85.ASM" gibt es dann die folgenden drei Hauptbereiche:

1. Eingabe- bzw. Ausgabe-Programme für RS-232 (TCP/IP), Konsole, Drucker
2. Programme für die Formatierung des Bildschirms
3. andere systemabhängige Programme

In der KC-Netzwerkvariante gibt es am Ende der Datei noch einen vierten Teil, welcher alle Vereinbarungen und spezielle Unterprogramme für die Einbindung und Nutzung der KCNet-Netzwerkschnittstelle enthält. Am Anfang der Datei liegen die Arbeitszellen für die Arbeit mit dem Netzwerk. Nachdem das alles fertig war, konnte KERMIT genauso wie die RS-232 Version übersetzt werden. Das folgende Bild zeigt die Ausgaben des KERMIT-Kommandos VERSION. In den beiden letzten Zeilen sieht man die Angaben zu den geänderten Dateien für die KC85-Familie, welche mit 18 Jahren Abstand zu den anderen eindeutig die Nesthäkchen darstellen :-) :

KERMIT4N.COM

Wie oben bereits geschrieben, gibt es KERMIT-Programme für nahezu alle gängigen Systeme und mit dem offengelegten KERMIT-Protokoll erfolgt die Übertragung von Daten inklusive eventuell notwendiger Anpassungen bzw. Umwandlungen automatisch und sehr flexibel. Mit KERMIT4N.COM funktioniert das nun unter CP/M auch im Netzwerk, wenn eine KCNet-Schnittstelle vorhanden ist. Allerdings benutzt diese Programmversion von KERMIT-80 ausschliesslich TCP/IP, eine Nutzung von RS-232 ist damit nicht möglich und auch nicht vorgesehen.

Das heisst, dass man als Transferpartner wiederum ein netzwerkfähiges KERMIT-Programm benötigt oder eine andere Software, welche Daten mit dem KERMIT-Protokoll per TCP/IP übertragen kann. Unter CP/M dürfte damit im Moment nur der KC85 selbst in Frage kommen, der damit auch der erste CP/M-Computer ist, welcher das überhaupt kann. Für alle nachfolgenden Systeme, beginnend mit MSDOS über die vielen Windows-Versionen bis hin zu Linux/Unix gibt es KERMIT-Versionen von der "Columbia University", welche netzwerkfähig sind.

Da KERMIT-80 eigentlich nicht für den Netzwerk-Betrieb gedacht ist, musste ich allerdings einige kleine Kompromisse eingehen. Das betrifft vor allem die Überwachung einer einmal hergestellten TCP-Verbindung. Normalerweise bekommt man eine Fehlermeldung, wenn diese Verbindung durch irgendwelche Gründe nicht mehr besteht. Das entfällt bei KERMIT4N.COM, da diese Überwachung in der Kommandozeile des Hauptprogrammes erfolgen müsste. Darauf hat man aber in einem systemspezifischen Familienmodul (CPXK85.ASM) keinen Zugriff, so dass das nicht implementiert werden konnte. Am Hauptprogramm wollte ich nicht herumbasteln, so dass es zwar die Möglichkeit gibt, den TCP-Status zu überprüfen aber das ist nicht sehr intuitiv :-).

Die prinzipielle Handhabung von KERMIT-80 wird im Handbuch, Abschnitt 1.3, erklärt. Eine ausführliche Beschreibung aller Kommandos und Parameter steht in Abschnitt 1.5. Diese beiden Abschnitte sollte man als Anwender gelesen haben, bevor man das Programm das erste Mal startet. Nahezu alle Inhalte des Originalhandbuches treffen unverändert auch auf KERMIT4N.COM zu. Alle Befehle, welche sich unmittelbar auf die RS-232 Schnittstelle und ihre Parameter beziehen, sind natürlich nicht mehr relevant und es kommen die netzwerkbedingten Besonderheiten hinzu, welche anschliessend erläutert werden.

In den folgenden Abschnitten sind Einsatzbeispiele von KERMIT4N.COM für die Datenübertragung zwischen einem Windows-PC und KC85, sowie als TELNET Client zu sehen. Da ich auf den Einsatz von KERMIT4N.COM als TELNET Client nicht verzichten und beide Einsatzgebiete abdecken wollte, habe ich mich für die folgende Variante entschieden. Nach dem Start von KERMIT4N.COM muss man sich entscheiden, ob man das Programm für die Übertragung von Daten oder als TELNET Client benutzen möchte:

Programmstart

Mit 'T' entscheidet man sich für den Betrieb als TELNET Client (s.u.) und mit 'C' bzw. 'S' für den KERMIT Service, also die Übertragung von Daten im Netzwerk mit KERMIT-Protokoll. In der KERMIT Service Betriebsart muss ein Teilnehmer der Netzwerk-Sitzung Server und der andere Client sein, man betätigt daher am KC85 die entsprechende Taste, siehe folgendes Beispiel. Wenn man die KERMIT4N-Betriebsart wechseln will, muss das Programm beendet und noch einmal neu gestartet werden.

KERMIT Service

Der sogenannte Internet Kermit Service (IKS) wird ausführlich in RFC 2839 beschrieben. Allerdings erfordert er für eine automatisierte Kommunikation auf mindestens einer Seite das Vorhandensein eines KERMIT-Servers. Das ist eine KERMIT-Version, welche in der Lage ist, von der anderen Seite gegebene Server-Kommandos auszuführen.

KERMIT-80 und damit auch KERMIT4N beherrscht das allerdings nicht. Diese Version kann lediglich Server-Kommandos an die andere Seite ausgeben. Das sind alle Kommandos im Handbuch, welche mit REMOTE beginnen. Da ich keine solche serverfähige Variante besitze, habe ich das nicht ausprobiert. Die kostenlose MS-DOS Variante habe ich mir nicht angetan, die kann sowohl per TCP/IP kommunizieren, wenn man es konfiguriert bekommt :-), als auch Server-Kommandos ausführen. Die Windows-Versionen sind alle kostenpflichtig.

Um die Datenübertragung zu testen, gibt es aber auch noch andere Wege. Da das KERMIT-Protokoll innerhalb einer normalen TELNET-Sitzung arbeitet und das TELNET Protokoll auch nicht behindert, funktioniert es auch mit normalen Terminalprogrammen, welche TELNET per TCP/IP beherrschen. Und genau das kann jeder Windows-PC bis einschliesslich Windows XP mit Hilfe von HyperTerminal. Diese Konstellation wurde daher auch für den Test benutzt.

Wenn HyperTerminal dabei den Part des Client übernimmt, muss der KC85 als Server gestartet werden. Auf dem KC wird also KERMIT4N gestartet und 'S' betätigt, nun wartet der KC passiv auf eine Verbindungsanfrage per TCP-Port 1649, dem Standard-Port für den IKS. Auf dem PC wird HyperTerminal gestartet und folgende Verbindung eigerichtet, "Hostadresse" ist natürlich mit dem richtigen Namen des KC85 bzw. seiner IP-Adresse in Eurem Netzwerk zu ersetzen:

Nun kann mit HyperTerminal über das Menü 'Anrufen -> Anrufen' die Verbindung zum KC aufgebaut werden, welcher entsprechende Meldungen ausgibt. Oben im Screenshot "Programmstart" ist genau dieser Ablauf zu sehen und damit ist die KERMIT Sitzung eröffnet. Eine Verbindungsaufnahme funktioniert umgekehrt genauso. HyperTerminal muss dann über Menü 'Anrufen -> Auf Anruf warten' als passiver Server gestartet werden und auf die Verbindungsaufnahme warten. Am KC startet man dann KERMIT4N und betätigt Taste 'C'. Anschliessend wird der DNS-Name bzw. die IP-Adresse des PC eingegeben und bestätigt. Danach versucht der KC die Verbindung herzustellen. Ebenso kann man beide Varianten mit 2 KC's ausprobieren, wobei immer einer als Server und der andere als Client arbeiten muss.

Wenn die Verbindung steht, ist die KERMIT Sitzung eröffnet und man kann Dateien in beide Richtungen übertragen. HyperTerminal stellt dafür im Menü 'Übertragung' die beiden Befehle 'Datei senden' bzw. 'Datei empfangen' zur Verfügung. In den beiden folgenden Abbildungen kann man den Datentransfer beispielhaft sehen, wobei der PC eine Datei an den KC sendet. Bevor man in HyperTerminal nach Auswahl der Datei auf Senden bzw. Empfangen drückt, ist natürlich KERMIT als Übertragungsprotokoll einzustellen. Der Empfang mit KERMIT4N wird über den Befehl RECEIVE (ein 'R' reicht auch) gestartet, der Dateiname wird automatisch erkannt. Die Sendung einer Datei wird mit dem Befehl 'SEND Name.Typ' (für SEND reicht auch wieder ein 'S') eingeleitet. Das Directory kann mit DIR vorher direkt in KERMIT4N angezeigt werden. Für Name und/oder Typ können die üblichen Platzhalter verwendet werden.

HyperTerminal senden

KERMIT4N empfangen

Wie KERMIT-80 mit Text- und Binärdateien bei der Datenübertragung umgeht, kann man dem Originalhandbuch entnehmen. Die standardmässig aktivierte Automatik für die EOF-Erkennung lässt sich beispielsweise mit den Kommandos 'SET FILE-MODE BINARY' bzw. 'SET FILE-MODE ASCII' auch deaktivieren, zurück geht es wieder mit 'SET FILE-MODE DEFAULT'.

Was passiert während einer KERMIT Service Sitzung nach CONNECT? KERMIT-80 schaltet dann in den sog. transparenten Modus, welcher im folgenden Abschnitt noch einmal genauer erklärt wird. Da beide Teilnehmer schon verbunden sind, ändert sich auf den ersten Blick erst mal nicht viel. Wenn man aber jetzt Eingaben per Tastatur vornimmt, leitet KERMIT diese an den anderen Teilnehmer direkt weiter und umgekehrt. Das ist wie bei den bekannten Chat-Programmen, wo man Textnachrichten untereinander austauschen kann. Vorher sollte man auf der CP/M Seite mit dem Befehl 'SET LOCAL-ECHO ON' die gleichzeitige Ausgabe der eingetippten Zeichen auf den lokalen Bildschirm aktivieren, sonst sieht man die eigenen Eingaben nicht.

Wie oben bereits angedeutet, kann nur nach CONNECT, also im transparenten Modus, der Zustand der TCP-Verbindung überprüft werden. Man betätigt nacheinander 'CTRL+S' und 'T' und erhält eine entsprechende Meldung. Wenn "Peer offline" gemeldet wird, kann/muss man KERMIT4N beenden und neu starten, um die Verbindung wieder herzustellen. In die KERMIT-Kommandozeile gelangt man wieder zurück mit 'CTRL+S' und 'C', dabei wird die TCP-Verbindung aber nicht geschlossen, sondern nur der transparente Modus. Man kann also beliebig oft hin- und herschalten ohne die Verbindung zu stören. Mit 'CTRL+S' und '?' erhält man eine Liste der verfügbaren Befehle, während der transparente Modus aktiv ist.

Alles in allem ist KERMIT-80 ein sehr interessantes und mächtiges CP/M-Programm mit unzähligen Einstellmöglichkeiten, was die Benutzung anfangs etwas gewöhnungsbedürftig macht. Beim Start sucht es beispielsweise nach einer Datei KERMIT.INI, in der man seine persönlich bevorzugten Einstellungen für die vielen SET Kommandos hinterlegen kann. Damit lässt sich diese Geschichte komplett automatisieren und man muss keine Einstellungen händisch eingeben, siehe oben Screenshot "Programmstart". Speziell für die Netzwerknutzung mit dem KC85 werden im letzten Abschnitt Zusammenfassung noch einige Hinweise gegeben.

TELNET Client

Vor den TELNET-Beispielen noch kurz ein paar Hinweise zum transparenten Modus von KERMIT. Wenn man sich per CONNECT-Befehl mit einem anderen Computer verbunden hat, werden alle Tastatureingaben an diesen Computer weitergeleitet. Man ist also vom Rechner, an dem man selbst sitzt, abgeklemmt und kann ihn auch nicht mehr bedienen. Dieser Zustand kann nur und ausschliesslich durch das sogenannte ESC-Zeichen unterbrochen werden. Das unmittelbar folgende Zeichen wird als Befehlscode für den eigenen Computer interpretiert und direkt ausgeführt, wenn es einen passenden ESC-Befehl in KERMIT gibt. Wenn nicht, wird sofort und ohne Meldung wieder in den transparenten Modus zurückgeschaltet.

In den meisten Terminal-Emulationen ist CTRL+] das ESC-Zeichen, da man es fast nie für Tastatureingaben benötigt. Dieser Code kann auf dem KC allerdings nicht eingegeben werden, da das System nur CTRL+Grossbuchstaben unterstützt. Deshalb habe ich im Quelltext CTRL+S als ESC-Code für den KC85 definiert. Der ist im CP/M des KC frei und richtet damit keinen Schaden an. Eine Eingabe ist über die CTRL-Taste und S oder direkt über die STOP-Taste des KC möglich. Der ESC-Code kann nach dem Start von KERMIT auch mit dem Kommando SET ESCAPE geändert werden.

Die beiden wichtigsten ESC-Kommandos sind CTRL+SC (Close) und CTRL+S? (Hilfe). Das erste beendet den Transparentmodus und das zweite listet die verfügbaren ESC-Kommandos auf, ohne den Transparentmodus zu verlassen. Ein weiteres zusätzliches ESC-Kommando, speziell für das Netzwerk, ist CTRL+ST (TCP-Status), damit kann man sich den Status der Netzwerk-Verbindung zum Peer anzeigen lassen. Falls nach Eingaben nichts mehr passiert, sollte man diesen Befehl nutzen. Der Peer darf bzw. kann die TELNET-Verbindung auch von sich aus beenden, KERMIT-80 bekommt das nicht mit, da es den Zustand der Verbindung nicht überwacht. Wenn die Netzwerkverbindung zum anderen Rechner nicht mehr besteht, funktioniert natürlich auch das Terminal nicht mehr.

Im Unterschied zur KERMIT Service Betriebsart, wird nach dem Start von KERMIT4N.COM im TELNET Client Mode keine Verbindung zum Peer aufgebaut. Die Herstellung einer TELNET-Verbindung zu einem anderen TELNET-Server wurde hier dem CONNECT-Kommando "untergeschoben". Wenn man das aufruft, wird nach der Adresse des Peer gefragt, optional kann man auch durch Doppelpunkt getrennt einen alternativen Port angeben. Ein Standard TELNET-Server wartet auf Port 23 auf eingehende TCP-Verbindungsanfragen.

Nach Abschluss der Eingabe versucht KERMIT4N die Verbindung herzustellen. Nimmt der Peer die Anfrage nicht entgegen, erfolgt die Meldung "Telnet session failed !" und nun kommt man nur noch mit CTRL+SC auf die KERMIT-Kommandoebene zurück. Wenn der Server annimmt, erfolgt im Hintergrund die Aushandlung der Verbindungsparameter (Negotiation) und danach erfolgt die Meldung "Telnet session opened.". Ab jetzt kommen alle Ausgaben vom TELNET-Server, welchen man nun durch die Eingabe von Zeichen bzw. Kommandos vom KC aus fernbedienen kann. Per TELNET hat man dann übrigens vom KC aus direkten Zugriff auf das Directory anderer Rechner. Das folgende Bild zeigt den gesamten Vorgang am Beispiel des TELNET-Servers von Windows XP Professional:

Die VT52-Emulation durch KERMIT funktioniert mit Windows ganz gut, bis auf die deutschen Umlaute wird alles durch den KC richtig dargestellt. Wenn es durch die Fehlinterpretation von übertragenen Codes zu unübersichtlich auf dem Bildschirm wird, sollte man mit dem entsprechenden KC-Tastaturkommando den Bildschirm löschen, damit man wieder einen "klaren Blick" hat.

Wenn man fertig ist, kann die TELNET-Sitzung mit CTRL+SC wieder beendet werden, worauf sich KERMIT wieder mit seiner eigenen Kommandozeile meldet. Dieses Kommando trennt auch die Netzwerkverbindung zum Peer. Im TELNET Mode ist der KC also immer nur ein Netzwerk-Client, welcher zu beliebigen TELNET-Servern Verbindung aufnehmen kann.

Der gleiche Vorgang funktioniert durch die einheitliche Definition der Netzwerkprotokolle in den RFC's mit allen TELNET-Servern, egal unter welchen Betriebssystemen sie betrieben werden. Deshalb auch noch zwei Beispiele mit einem TELNET-Server, welcher unter Linux läuft. Im zweiten Bild sieht man die Ausgabe des NETSTAT Kommandos. Die erste Ausgabezeile bestätigt die aktive Verbindung auf dem TELNET-Port zwischen dem Linux-Rechner und KC85:

Zusammenfassung

KERMIT4N.COM ersetzt im TELNET Mode natürlich nicht ein vollwertiges TELNET-Programm. Gemessen am Aufwand, stand es aber unschlagbar schnell zur Verfügung und es funktioniert auch ganz gut im Netzwerk für ein ca. 20 Jahre altes CP/M Programm. Nachdem ich die originalen KERMIT-Quellen übersetzen konnte, waren alle Anpassungen an KERMIT-80 in ca. 3 Wochen erledigt, da nur einige Ergänzungen am vorhandenen Programm vorgenommen werden mussten. Auch die Übertragung von Daten hat nach der Programmierung der entsprechenden Funktionen sofort ohne Fehler funktioniert.

Da KERMIT immer innerhalb einer TELNET-Sitzung arbeitet, wird jedes Zeichen einzeln in einem kompletten TCP-Paket über das Netzwerk geschickt und ist daher nicht besonders effizient oder schnell. Für solche Übertragungen ist das KC85-System aber denkbar schlecht geeignet (die einzelne Übertragung von Bytes durch den Koppel-RAM wurde im Projektartikel "KCNET 1.2" ausführlich erklärt). Im transparenten Modus von KERMIT geht jedes eingegebene Zeichen insgesamt 4x !!! durch den Koppel-RAM, bevor es auf dem Bildschirm des KC erscheint:

1. Tastatur D001 -> KERMIT D004
2. KERMIT D004 -> KCNet D001 zum TELNET-Server
3. TELNET-Server Echo zum KCNet D001 -> KERMIT D004
4. KERMIT D004 -> Bildschirmausgabe D001

Die Vorteile des DRV-Treibers auf einem KC85/4+ mit dem schnellen Transfer von Datenblöcken in das / aus dem D001 können durch die Einzelbyte-Übertragung nicht wirksam werden, so dass sich alles recht zäh und langsam anfühlt, was sich leider unter CP/M auch nicht entscheidend ändern lassen wird. Wenn der andere Rechner aber weit entfernt ist oder nur schnell mal was nachgeschaut werden soll, ist das trotzdem eine ganz praktische Angelegenheit. Die Herrschaft über einen Windows Rechner (ab Windows 2000) können wir damit schon mal übernehmen, einfach mal folgendes Kommando eingeben:

C:\shutdown -r -t 0 -f

Neben dem DRV-Treiber gibt es für alle KC85-Systeme auch noch alternativ einen Koppeltreiber für den Betrieb des Netzwerk-Interface. Dieser Treiber ist durch die Art der Anbindung an das D004 und CP/M bei der Übertragung von einzelnen Bytes ca. doppelt so schnell und erlaubt damit auch ein ganz entspanntes Arbeiten speziell mit KERMIT4N.COM. Auf einem KC85/4+ kann zusätzlich zum DRV-Treiber der KOP-Treiber parallel geladen sein. KERMIT4N benutzt dann bevorzugt den Koppeltreiber und arbeitet wesentlich flüssiger, falls er nicht gefunden wird, benutzt es den DRV-Treiber und funktioniert trotzdem.

Was sollte man sonst noch beachten? Die Eingaben von "NAME|IP[:PORT] :" werden über die BDOS-Funktion 10 vorgenommen. An dieser Stelle sollte man nicht 'CTRL+C' bzw. 'BRK' betätigen. KERMIT4N.COM wird dann "hart" beendet und kann den reservierten Netzwerk-Socket nicht mehr freigeben, was zu Störungen beim nachfolgenden Aufruf von Netzwerkprogrammen führt.

Durch die umfangreiche Funktionalität von KERMIT-80 ist der Einsatz dieses Programmes wohl eher etwas für den fortgeschrittenen Anwender eines KC85 unter CP/M. Die Nutzung des Netzwerkes als Übertragungsmedium macht die Sache auch nicht unbedingt einfacher. Nach der Überwindung der Anfangsprobleme war für mich allerdings die grösste Überraschung, wie schnell und flexibel eine Anpassung an die eigenen Bedürfnisse möglich ist, wobei die Stabilität gewahrt bleibt.

Wer sich in der Materie etwas auskennt, sollte mit KERMIT4N.COM auch Daten per Internet zwischen 2 Rechnern übertragen können. Im Router ist dann für den TCP-Port 1649 eine Portweiterleitung zum serverseitigen Rechner einzurichten und KERMIT4N.COM als Server in der KERMIT Service Betriebsart zu starten. Anschliessend kann man von aussen (allerdings immer nur einmal) die Verbindung herstellen und Daten übertragen. Im Gegensatz zu TFTP, welches während der Übertragung von Daten Portwechsel durchführt, funktioniert das mit KERMIT einfach, da die gesamte Kommunikation über einen TCP-Port läuft.

Die speziell für den KC85 angepassten KERMIT-Quellen wurden 2012 in der Archivdatei KERMIT4N.PMA zusammengefasst. Das übersetzte Programm KERMIT4N.COM ist Bestandteil der KCNet-Software-Pakete. Alle Dateien sind wie üblich im Downloadbereich zu finden. Die Konfiguration von TELNET-Servern anderer Betriebssysteme ist deren Dokumentation zu entnehmen oder im Internet nachzulesen. Mittlerweile wird eine unverschlüsselte TELNET-Verbindung zwischen Netzwerkteilnehmern als Sicherheitsrisiko angesehen und es ist gar nicht mehr so einfach den meist vorhandenen TELNET-Server in Betrieb zu nehmen. In einem privaten Heimnetzwerk hinter dem Router kann man das durchaus noch benutzen, da man die Netzwerkteilnehmer ja in der Regel kennt bzw. selbst bestimmen kann :-).