Die Optimierung der Hard- und Software des KCNET Interface ist abgeschlossen und nun auch für alle Benutzer eines CP/M 2.x Systems mit Z80 CPU problemlos nachnutzbar.

Die letzten 10 Prozent dauern meist am längsten. Das ist beim KCNET-Projekt leider auch nicht anders aber heute soll es wieder einmal eine grosse Aktualisierung geben. Mittlerweile ist aus der Nutzbarkeit, wie zum KC-Treffen 2008 demonstriert, eine Benutzbarkeit für alle CP/M 2.x Anwender mit einem Z80-System geworden und auch in der CAOS-Betriebsart des KC85 hat man jetzt das Netzwerk zur Verfügung.

Nach dem Märztreffen in Ballenstedt gab es erst einmal eine kleine Pause, um die bisherige Entwicklung noch einmal zu durchdenken und die verbliebenen Probleme zu lösen, was von Mai bis Juli erfolgte.

FIRMWARE 1.2

Hier war prinzipiell nicht mehr viel zu tun, da eigentlich alles sehr zuverlässig funktionierte. Aus Geschwindigkeitsgründen wurde allerdings die Reihenfolge der Protokollfunktionen so umgestellt, dass die am meisten benutzten und zeitkritischen Befehle an den Anfang und die weniger häufig benötigten Funktionen an das Ende gestellt wurden.

Die beiden Funktionen für den Abruf von Hard- bzw. Softwareversion des Interface wurden von ASCII- auf Binärausgabe umgeschrieben, da das für eine Versionskontrolle von der Z80-Software aus handlicher ist.

Um bestimmte immer notwendige Software Bestandteile von Netzwerkprogrammen eleganter umzusetzen und den TCP/IP-Treiber im Z80-System ROM-fähig halten zu können, kamen weitere 5 Protokoll-Funktionen hinzu, welche intern von der Firmware umgesetzt werden und nichts mit dem WIZnet TCP/IP-Stack zu tun haben.

Das Interface bietet jetzt für das Z80-System einen TIME-Service in Form eines unendlich laufenden Millisekunden Zählers von 0 bis 59.999 an. Über die Berechnung der Differenz von 2 Zählerständen ist man so in der Lage, sowohl kleine Zeitabstände im ms-Bereich zu messen als auch grosse Abstände für Timeouts u.ä. Zwecke zu erfassen und das vor allem hardwareunabhängig vom Hostsystem.

Weiterhin lassen sich jetzt im Interface bis zu 8 IP-Adressen speichern und zurücklesen. Bis jetzt ist nur eine Nummer für die Ablage des per DHCP erfragten DNS-Servers im Netzwerk vergeben, die 7 weiteren verfügbaren Plätze werden sich sicher im Laufe der Zeit noch definieren, was ja auch von den umgesetzten Netzwerkprotokollen abhängig ist bzw. von ihren Erfordernissen bestimmt wird.

Viele TCP- bzw. UDP-Protokolle bauen Verbindungen ins Netzwerk ausgehend über beliebige Portnummern auf. Dafür ist der Bereich von 49152 bis 65535 vorgesehen. Eine Bedingung ist allerdings, dass sich die gewählte zufällige Portnummer von 2 oder mehr Verbindungen unterscheidet, damit die Zuordnung von eingehenden Antwortpaketen im TCP/IP-Stack eindeutig ist. Dafür gibt es jetzt auch eine Interface-Funktion, welche ab 49152 aufsteigend mit jedem Aufruf die nächste Portnummer zurückgibt und damit für die Einhaltung der genannten Bedingung sorgt, zumindest für 16383 Aufrufe, was mehr als ausreichend sein dürfte.

Mit der letzten neuen Funktion lässt sich der interne Zähler für die aufgetretenen Kommandofehler beim Aufruf der Firmware-Befehle auslesen. Das ist mehr für den Programmierer von Interesse. Speziell, wenn man neue Programme schreibt, kann man damit die korrekte Nutzung der KCNET-Kommandos kontrollieren. In der Regel sollte dort immer eine 0 zurückgelesen werden, sonst stimmt etwas noch nicht mit dem neuen Programm!

 

HARDWARE 1.2

Im Zuge der Optimierung war bereits länger die oszillografische Kontrolle der PIO-Kommunikation mit dem ATmega geplant. Ich erwartete dort keine Probleme aber wenigstens einmal anschauen gehört einfach dazu. Richtiges Interesse hatte ich aber an einer Sache - wie schnell holt die PIO bei einem Kommando die Bytes vom Interface ab, damit steht und fällt die Übertragungsrate der Netzwerkkommunikation, sprich dort ist die dünnste Stelle der ganzen Kette.

Wie erwartet, bestanden beim Handshake der Byteübertragung keine Probleme, das linke Bild zeigt den Sender, das rechte den Empfänger. Das Handshake wird über 2 Signale abgewickelt, oben ist der  READY-Ausgang des PIO-Kanals und unten der /STROBE-Eingang. Sowohl vom Ablauf als auch den Signallängen wird das alles laut Plan abgewickelt.

Das nächste Bild zeigt den vollständigen Ablauf des Kommandos "Lese Link Status", dort wird 1 Kommandobyte geschickt und 1 Antwortbyte abgeholt.

Die Stelle, welche mich nun am meisten interessierte, zeigt das folgende Bild. Hier kann man den zeitlichen Ablauf beim Abholen von mehreren Bytes unter CP/M sehen und damit auch den Grund, warum ich das unbedingt anschauen wollte.

 

Die erste Erkenntnis war, der ATmega ist schnell genug, sofort nachdem RDY auf H geht, kommt der /STROBE-Impuls für das Einschreiben des nächsten Bytes in das Empfangsregister der PIO. Damit dürfte firmwareseitig kein Optimierungsbedarf mehr bestehen.

Zweitens ist die PIO selbst auch nicht das Problem, sie macht genau das, was laut Datenblatt ablaufen soll. Nachdem ein Byte im Empfangsregister gelandet ist, geht RDY auf L und könnte nach Annahme und Abarbeitung des Empfangsinterrupts, welcher dem Hauptprogramm das empfangene Byte signalisiert, von diesem abgeholt und weiterverarbeitet werden.

Und genau dort liegt der Grund für die doch recht gemächliche Arbeitsweise des KC85 unter CP/M. An sich ist das nichts Neues aber ein Abstand von ca. 260 µs zwischen zwei Empfangsbytes bietet doch noch erhebliches Optimierungspotential, was nur durch eine weitere Verbesserung des Schnittstellentreibers und allem was damit zu tun hat, ausgeschöpft werden kann.

Eine erste Massnahme war die Erweiterung der bisherigen Schnittstelle, damit sich die PIO-Kommunikation auf der Z80-Seite auch im Polling abwickeln lässt. Man kann dann zeitmässig den gesamten Mechanismus der Interruptannahme, -abarbeitung und -beendigung einsparen, wobei aber hardwaremässig dafür zu sorgen ist, dass sich der Zustand der beiden RDY-Ausgänge der PIO per Software abfragen lässt.

Genau das wurde noch geändert im Schaltplan, ARDY geht direkt auf PIOB0 und BRDY geht invertiert auf PIOB7, PIOB1 bis PIOB6 gehen an Masse und sind damit bei Eingaben von Kanal B immer 0. Der Kanal B wurde bisher schon im Bitbetrieb gefahren aber softwaremässig nicht benutzt.

Der geänderte Schaltplan der Version 1.2 ist im Downloadbereich zu finden.

 

CP/M TREIBER KC85

Eine ohnehin geplante Sache war die Erweiterung der CP/M-Treiber speziell für den KC85/4 und höher. Bedingungen dafür sind ein KC85/4 aufwärts, ZAS4 mindestens in der Version 1.3 und zweckmässigerweise das Ladeprogramm für DRV-Treiber DRIVER.COM.

Zunächst wurde der bisherige Koppeltreiber, welcher die PIO im INT-Betrieb nutzt, an die geänderte Hardwareversion angepasst, die erste Variante funktioniert damit nicht mehr!

Anschliessend wurde eine zweite Variante des Koppeltreibers erstellt, welche die PIO im POLLING nutzt. Das hat nebenbei noch den Vorteil gegenüber der INT-Version, dass ein ungewollter Interrrupt der initialisierten PIO im Grundgerät nach Wechsel in die CAOS-Betriebsart nicht mehr zu einem Absturz des D001 führt, wenn der Treibercode nicht mehr vorhanden ist. Dieser Treiber sollte aus diesem Grund ab sofort standardmässig verwendet werden, wenn man die DRV-Variante nicht benutzt bzw. nicht benutzen kann (KC85/3).

Die Benutzung der Koppelschnittstelle des KC85 erfordert für den Bytetransport zu/von der KCNET-Schnittstelle einen ziemlichen Aufwand auf dem KC85 System. Für jedes zu transportierende Byte ist ein BIOS CALL des Reader/Puncher Kanals erforderlich, welcher z.B. beim Senden folgende Vorgänge auslöst:

• CP/M Programm übergibt 1 Byte an BIOS Funktion 6
• BIOS Funktion legt das Byte im Koppel-RAM ab
• BIOS Funktion fordert die Ausgabe dieses Bytes im D001 bei ZAS an
• ZAS erkennt die Anforderung und liest das Byte aus dem Koppel-RAM
• ZAS ruft den Koppeltreiber im D001 auf und übergibt das Byte
• der Koppeltreiber schreibt das Byte in das Ausgaberegister der PIO
• das KCNET-Interface holt das Byte ab
• der Koppeltreiber kehrt zu ZAS zurück
• ZAS quittiert die Ausgabe des Byte an das D004
• BIOS Funktion erkennt die Quittierung
• BIOS Funktion kehrt zum CP/M Programm zurück
• das nächste Byte kann vom CP/M Programm gesendet werden

Das Empfangen läuft ähnlich ab und diese ganze Kette ist für jedes einzelne Byte zu durchlaufen, was Unmengen an Zeit erfordert! Bereits beim MTOOLS/WTOOLS-Projekt hat Mario Leubner an ZAS etwas gefeilt, damit es unter bestimmten Umständen etwas schneller wird aber prinzipiell lässt sich natürlich diese lange Kette, welche durch die Hardware des KC85 bedingt ist, nicht umgehen.

Die einzige erfolgversprechende Variante besteht darin, die Anzahl der Aufrufe bzw. Übertragungen zu reduzieren, indem man pro Aufruf möglichst viele Bytes auf einmal an das D001 übergibt bzw. aus dem D001 liest. Man muss zwar den Weg durch den Koppel-RAM trotzdem nehmen aber der ganze Aufwand für Quittierung und Aufruf der Unterprogramme entfällt ab dem zweiten übertragenen Byte komplett für jedes noch folgende.

Genau das war dann die nächste Optimierungsmassnahme und ist mittlerweile in Form des neuen Treibers KCNET.DRV umgesetzt. Der Treiber arbeitet auch nicht mehr auf der untersten Bytetransportebene, sondern bereits auf der Ebene des KCNET-Protokolls. Das CP/M-Programm kann also direkt eine KCNET Funktion im D001 aufrufen und bekommt sofort die Antwortdaten im Koppel-RAM geliefert, was ebenfalls eine Menge Zeit spart. Die wichtigste Neuerung liegt aber in der Implementierung einer Blockübertragung für bis zu 255 Bytes pro Lese-/Schreibvorgang im Koppel-RAM und das ist sehr deutlich zu spüren, siehe letzter Abschnitt.

 

SOCKET INTERFACE für WIZnet TCP/IP STACK II mit W3150A+ oder W5100

Das im letzten Artikel angekündigte SOCKET Interface für Netzwerksoftware war im März zum KC-Treffen nahezu vollständig und wurde von CPMNET 1.3 bereits intensiv genutzt.

Probleme gab es allerdings noch bei der RECEIVE FROM Funktion, wo mir die letzten Details des TCP/IP-Stacks nicht ganz klar waren. An dieser Stelle halfen mir leider weder das Datenblatt noch der WIZnet "C"-Treiber wesentlich weiter. Inzwischen ist aber auch diese Hürde genommen und endlich arbeiten alle Funktionen wie gewünscht, auch wenn man beispielsweise UDP-Pakete mit einer Länge grösser 1472 Byte empfängt. Das kann der Stack nicht verarbeiten und vorher kam der Socketempfang durcheinander, jetzt wird das Paket vom Treiber korrekt verworfen aber quittiert, so dass man den Socket ganz normal weiterbenutzen kann.

Mit der heutigen Aktualisierung kann man diese ganze Geschichte jetzt benutzen. Im Downloadbereich gibt es entsprechende Quelltexte. In den Archiven befindet sich die Datei W5100-xx.INC, welche den kompletten TCP/IP-Treiber enthält, welchen man auf die gleiche Art und Weise wie beispiesweise CPMNETxx.MAC benutzen und in eigene Programme einbinden kann.

W5100-xx.INC stellt als Unterprogrammsammlung den Zugriff auf den TCP/IP-Stack bereit und kapselt die darunterliegenden Treiberfunktionen des KCNET-Interface. Das macht eine Nutzung erheblich einfacher und sicherer - die Gefahr einer Fehlprogrammierung des KCNET-Schnittstellen-Treibers wird nahezu ausgeschlossen, natürlich nur, wenn man die entsprechenden Parameter einhält.

Für die komfortable Programmierung von Netzwerksoftware stehen die folgenden 18 Funktionen zur Verfügung, welche in der Datei entsprechend kommentiert sind, die Verwendung lässt sich ja auch mühelos dem Quelltexten von CPMNETxx.MAC entnehmen. Im Moment ist dazu keine ausführliche Dokumentation geplant, für Entwickler sollten die umfangreichen Kommentare in den Quelltexten ausreichen:

Init und Status:	SOCKET, BIND, SELECT
Verbindungsaufbau:	LISTEN, ACCEPT, CONNECT
Datenübertragung:	SEND, RECEIVE, SEND TO, RECEIVE FROM
Verbindungsabbau:	SHUTDOWN, CLOSE
Verwaltung:	GET PEER DATA, GET LOCAL DATA
Konvertierung:	HTONS, NTOHS, HTONL, NTOHL

An der Socket-Schnittstelle wird sich grundlegend nichts mehr ändern, bis auf die Ergänzung fehlender Funktionen und kleinerer Hilfsfunktionen, welche man sowieso immer benötigt. Da der Treiber aber mit dem Programm übersetzt wird, kann man Änderungen durch eine Neuübersetzung relativ schnell einpflegen. Wie gesagt sind von meiner Seite aus keine wesentlichen Veränderungen mehr geplant, da mittlerweile alles ausgetestet ist und bei der Entwicklung von CPMNETxx.COM bereits jede Menge Optimierungen und Anpassungen durchgeführt wurden.

CPMNET 1.4 und CAOSNET 1.4

Mit den vielen Änderungen und Ergänzungen an Firmware, Treibern und Funktionen gab es ganz oben in der Software, welche man als Anwender zu Gesicht bekommt, natürlich dann auch jede Menge zu tun.

CPMNET.COM liegt jetzt in der Version 1.4 vor und hat einen Stand erreicht, welcher eine universelle Nachnutzung auf beliebigen CP/M 2.2 kompatiblen Systemen mit Z80 CPU gestattet. Es werden alle Funktionalitäten des KCNET-Interface zugänglich gemacht, man kann mit diversen Parametern des WIZnet TCP/IP-Stack herumspielen und für den Einsatz im Netzwerk bringt es gleich die absolut notwendigen Sachen mit, so dass man sofort loslegen kann.

Eine komplizierte Angelegenheit war der Umbau der Quelltexte und ihre Modularisierung für die universelle Nachnutzung. Alle konfigurierbaren Parameter wurden in eine Datei KCNET.INC ausgelagert.

Man setzt in der Datei KCNET.INC den Schalter KC85 auf NO, trägt die verwendete I/O-Adresse der eigenen PIO im System ein, vergleicht und ändert u.U. die verwendeten Terminalcodes für sein CP/M und schon sollte das Programm nach einer Neuübersetzung auch auf anderen CP/M 2.x Computern laufen, welche das KCNET-Interface eingebaut haben.

Der TCP/IP-Treiber mit SOCKET-Schnittstelle ist ebenfalls in einer eigenen Datei W5100-xx.INC und vollkommen hardwareunabhängig bezüglich des KCNET Interface-Treibers nach unten und des nutzenden Programmes bzw. Betriebssystems nach oben. Auf dem KC85 kann man damit sowohl für CAOS als auch CP/M Programme erstellen, ohne dass an der Datei W5100-xx.INC Änderungen vorgenommen werden müssten.

Das eigentliche CP/M-Programm wurde nun auch mit diversen Abfrage- und Testroutinen versehen, so dass notwendige Systembedingungen überprüft werden und bei Nichtvorhandensein eine Meldung erfolgt und der Programmstart abgebrochen wird. Auf dem KC85 System kann man stressfrei sowohl mit KCNET.KOP als auch KCNET.DRV arbeiten, die DRV-Variante wird i.d.R. bevorzugt, wenn beide Treiber geladen sind.

Im Zuge der Überarbeitung zur Version 1.4 bekam CPMNET.COM ein weiteres Menü spendiert, so dass man jetzt passend zur Hard- und Softwarelogik auf 3 Ebenen Funktionen oder ganze Programme aufrufen kann. Es gibt jetzt ein INTERFACE-, TCPIP- und ein NETWORK MENU - wo das Interface getestet, der TCPIP-Stack konfiguriert und die Netzwerkprogramme bzw. -testfunktionen gestartet werden können.

Nachdem das CP/M-Programm dann soweit rund war, ging es mit der CAOS-Software weiter. Dort war lange nichts passiert. Bis auf die ersten Testfunktionen und einige Konfigurationsausgaben der Version 1.2 vom Dezember 2007 fehlte dort noch die komplette Netzwerkfunktionalität.

Da es unter CAOS auch keine SYSLIB gibt, waren diese betriebssystemseitigen Routinen komplett in Eigenregie zu programmieren. Das wurde nun in den vergangenen Wochen alles nachgeholt und funktioniert mittlerweile genauso wie unter CP/M.

In der CAOS-Betriebsart gibt es ja bereits eine in das Betriebssystem eingebaute Menüverwaltung - diese wird von CAOSNET auch benutzt, so dass die drei o.g. Menüs im CAOS-Menü gelistet und von dort dann aufgerufen werden. Die einzelnen Befehle und Funktionen in den 3 Menüs sind nahezu identisch mit dem CP/M Programm. Lediglich der Code für den TFTP-Server wurde entfernt, ein TFTP-Client steht natürlich zur Verfügung, welcher sogar Direktkopien zwischen Netzwerk und Kassette in beide Richtungen beherrscht.

Die ausführliche Beschreibung der beiden KC85 Referenzprogramme für das KCNET-Interface erfolgt in einem späteren Artikel.

PRAXISTEST KCNET 1.2

Um die ganzen Optimierungen etwas zu verdeutlichen habe ich im Juli nun noch einige Tests durchgeführt. Dafür benötigt man das WIZnet eigene Windows-Programm AX1.EXE, welches man dort im Downloadbereich findet ( nach AX1 suchen - http://www.wiznet.co.kr ).

Da der Weg der Daten von/zur Schnittstelle des KCNET beim KC85 unter CP/M etwas kompliziert ist, war es gar nicht so einfach, eine reproduzierbare Messung der Übertragungsgeschwindigkeit zu erreichen. Es sollten möglichst keine Systemeinstellungen oder andere Faktoren die Vergleichbarkeit der Ergebnisse stören und auch für jeden nachvollziehbar sein.

Daher bietet sich das AX1 Programm an. Es sendet Daten an den KC85, der empfängt sie mit dem KCNET-Interface, wo sie unter CP/M den Weg über PIO, Treiber im D001, ZAS, Koppel-RAM, CPMNET nehmen, welches sie im TPA ablegt und unverändert aus dem TPA wieder auf umgekehrtem Weg zum PC-Programm zurückschickt, welches den richtigen Empfang verifiziert und anzeigt.

Unter CAOS entfällt die ganze Geschichte mit dem Koppel-RAM, CAOSNET holt die Daten per eingebautem PIO-Treiber selbst ab, speichert sie im RAM und schickt sie von dort wieder zurück, was dementsprechend schneller geht. 

Geht man stillschweigend davon aus, dass Empfang und Sendung symetrisch arbeiten, kann man die ermittelte Gesamtzeit der Übertragung durch 2 teilen und erhält damit ein Mass für die Übertragungsgeschwindigkeit an der Schnittstelle. Ob das absolut in Byte/s exakt stimmt, ist auch erst mal zweitrangig - die Erhöhung der Geschwindigkeit ist auf alle Fälle auf diese Art und Weise genau zu ermitteln. Da ein RAM zu RAM Datentransfer stattfindet, bremsen auch keine Speichermedien die Übertragung aus, speziell auf der KC85-Seite besteht ja diese Gefahr.

Für den Test wurde im PC immer die gleiche Datei geladen und über eine hergestellte TCP- bzw. UDP-Verbindung zwischen PC (Client) und KC (Server im Echobetrieb) übertragen. Die Länge der Datei (51164 Byte) wird durch die Zeitdifferenz zwischen Start und Ende der Übertragung dividiert und das Ergebnis mit 2 multipliziert, was schliesslich die Übertragungsgeschwindigkeit der Schnittstelle in Byte pro Sekunde ergibt. In der folgenden Tabelle sind die verschiedenen Testergebnisse zu sehen:

Übertragungsgeschwindigkeiten KCNET 1.2 mit KC85 unter CP/M und CAOS
			Testdatei: TEAC.PDF mit 51164 Byte
System	Test	Treiber	Handshake	Gesamtzeit	Byte/s	Bemerkungen
CP/M	1	KOP	Interrupt	52,85s	1936	Bytetransfer
CP/M	2	KOP	Polling	46,55s	2198	Bytetransfer
CP/M	3	DRV	Polling	14,33s	7141	Blocktransfer direkt BS SCROLL-Mode
CP/M	4	DRV	Polling	13,95s	7335	Blocktransfer überlappend BS SCROLL Mode
CP/M	5	DRV	Polling	9,51s	10760	Blocktransfer überlappend BS PAGE-Mode
CAOS	UDP	intern	Polling	4,81s	21274	BS Page Mode
CAOS	TCP	intern	Polling	4,53s	22589	BS Page Mode

Wichtigste Erkenntnis für die CP/M Betriebsart - die blockweise Datenübertragung von bis zu 255 Byte auf einmal durch den Koppel-RAM mit dem DRV-Treiber macht sich sehr deutlich gegenüber der byteweisen Variante bei Nutzung des KOP-Treibers bemerkbar - ca. 500 % Steigerung!

Aber auch beim KOP-Treiber kommt man noch auf eine akzeptable Übertragungsgeschwindigkeit bei der Datenübertragung, zum Treffen mit der KCNET Version 1.1 lag die noch bei ca. 1000 Byte/s, auch wenn es dort mehr am Softwaretimer des CPMNET lag, welcher das Programm abbremste und nicht an der Schnittstelle selbst.

Vielleicht noch zum Verständnis, Blocktransfer direkt bedeutet, dass im D001 direkt ein byteweiser I/O (PIO) zu I/O (Koppel-RAM) Transfer stattfindet. Beim Blocktransfer überlappend werden die PIO-Daten im RAM des D001 abgelegt und von dort mit einem einzigen Befehl in den/aus dem Koppel-RAM geschrieben/gelesen, wobei das D001 bereits den nächsten Block einliest, während das D004 oben die Daten in den TPA schreibt und umgekehrt, also wie ein kleiner Cache gebildet wird.

BS heisst Bildschirm und der spielt auch noch eine Rolle beim KC85, im Echobetrieb wird für jedes übertragene Datenpaket am Bildschirm eine Meldung ausgegeben und wenn die letzte Zeile erreicht wurde, muss der ganze Bildschirm im SCROLL-Mode hochgerollt werden, das benötigt relativ viel Zeit, da es unter CP/M von ZAS im D001 bzw. unter CAOS vom Betriebssystem selbst durchgeführt werden muss. Während des Scrollens können keine KCNET-Daten übertragen werden.

Unter CAOS gibt es nur einen Treiber, welcher sich in CAOSNET selbst befindet und die PIO direkt bedienen kann. Dann entfällt auch der Weg durch den Koppel-RAM, so dass man die höchstmögliche Übertragungsgeschwindigkeit im KC85 System erzielen kann.

Die liegt dann bei ca. 22,5 kByte/s und wird direkt durch die PIO und ihren Takt bestimmt bzw. limitiert. Mit einem 1,75 MHz Hostsystem muss der Controller im Interface beim Handshake der Datenbytes auf den KC85 warten. Erst ab schätzungsweise 4-6 MHz könnte dort das Hostsystem schneller als das Interface sein - vielleicht untersuchen wir das später noch einmal, wenn es erforderlich sein sollte.

Der KC85 ist natürlich weit von den theoretisch möglichen 1 MByte/s des WIZnet-Chips am AVR-Controller entfernt, was durch die PIO-Anbindung bedingt ist - das ist letztendlich der Preis für die hohe Kompatibilität und den geringen Hardwareaufwand des KCNET.

Für den Datentransfer von Datenträger zu Datenträger durch das Netzwerk braucht man aber gar nicht mehr als 2-3 kByte/s, dort liegt nämlich ungefähr das Limit, mit dem CP/M die Daten auf die Festplatte schreiben kann, deshalb müssen sich auch die Benutzer des KOP-Treibers unter CP/M (KC85/3) nicht ärgern, der KC85/4+ mit DRV-Treiber kann das auch nicht schneller erledigen.

Alle Theorie ist grau, ich will was sehen - kann man im Downloadbereich. Ich habe zur Veranschaulichung ein paar Videos des Windows-Desktops gemacht, wo man die Übertragung der Testdatei unter verschiedenen Bedingungen live sehen kann. Unten links läuft in den Videos eine Echtzeituhr mit, dort kann man die Übertragungszeiten genau ablesen:

KC85 CP/M	Test 1	KCNET12 TCP-ECHOSERVER KOP INT.MPG
KC85 CP/M	Test 5	KCNET12 TCP-ECHOSERVER DRV.MPG
KC85 CAOS	UDP	KCNET12 UDP-ECHOSERVER CAOS.MPG
KC85 CAOS	TCP	KCNET12 TCP-ECHOSERVER CAOS.MPG

Mit 22,5 kByte/s bin ich im anvisierten Zielbereich für die Datenübertragungsrate, denn Ethernet ist schnell, viel viel schneller als der KC85 es nutzen kann. Aber unter CAOS geht das trotz alledem ziemlich flott, falls es schon jemand vergessen haben sollte - wir sehen einen Rohdatentransport von Daten per TCP/IP auf dem UDP- bzw. TCP-Layer eines TCP/IP-Stacks.

Jetzt fehlt lediglich noch die Applikationsschicht der RFC-Protokolle - um die muss sich das Z80-System selbst kümmern, was aber in etwa der Arbeit eines normalen Anwendungsprogrammes entspricht. Die Zukunft wird zeigen, dass man mit dem KCNET alle gängigen textbasierten Netzwerkprotokolle umsetzen kann und keinen merkbaren Unterschied zu grösseren und schnelleren Systemen feststellen wird.

FAZIT und AUSBLICK

Damit ist mein KC85/5 unter CP/M und CAOS nun bereits vollwertiges Mitglied meines TCP/IP-Heimnetzwerkes, die Netzwerkkonfiguration erfolgt automatisch per DHCP und ich kann mit beliebigen Netzwerkteilnehmern Daten tauschen, wenn sie TFTP "sprechen". Praktisch ausprobiert wurde es bisher mit Windows, Linux und einem BSD-Unix und es funktioniert - zwar noch nicht besonders komfortabel aber sehr stabil.

Mit der Version 1.2 wäre ich nun auch bereit, die Firmware zur Nachnutzung zur Verfügung zu stellen, so wie das auf dem KC-Treffen besprochen wurde, dazu wird es auch noch einen extra Artikel geben. An der Schnittstellenhardware werde ich keine Änderungen mehr vornehmen und an der Firmware in naher Zukunft auch nicht, die lässt sich ja bei Notwendigkeit neu programmieren.

Für die KC85/x Besitzer ist ein KC-Modul in Arbeit, alle anderen Interessenten müssten sich für ihr System selbst Gedanken machen, wie sie eine PIO in ihre Hardware bringen oder eine vorhandene PIO nutzen können.

Da ein Z80 Standard-Schaltkreis als Schnittstelle verwendet wird, ist das eigentlich kein Problem. In den Quelltexten der Firmware ist eine Anpassung an andere Taktfrequenzen der CPU/PIO des Hostrechners ab 500 kHz aufwärts bereits eingebaut, das wird bei der Übersetzung automatisch entsprechend berücksichtigt.

Ich werde in nächster Zeit weiter an der Software arbeiten und vielleicht noch fehlende Funktionen, wie z.B. den DNS-Client ergänzen. Das hängt auch alles ein wenig davon ab, wie sich das Interesse an einer Nachnutzung entwickelt. Ich habe mit meinem Interface-Unikat meine Minimalziele ja bereits erreicht.