Datenverbindung KC--PC über parallele Schnittstellen - Version 1.0ß
von Sebastian Heßler
1. Einleitung
Bis vor einiger Zeit stand der Kommunikation von Rechnern über die parallele Schnittstelle die Sparpolitik der PC-Hersteller im Wege. Die LPT Schnittstelle war zwar in der Lage, 8 Bit gleichzeitig zu senden, leider konnte sie diese aber nicht empfangen. Was auf dem KC schon lange möglich ist, wurde nun auch auf dem PC realisiert, die LPT Schnittstelle ist bidirektional geworden. Dies brachte mich auf die Idee, Daten über die schnellere parallele Schnittstelle auszutauschen. Die hier vorgestellte Software dient dem Ersatz der LOAD und SAVE Routinen des CAOS. Sicher ist das Verfahren aber auch anders nutzbar.
2. Hardware
Als Verbindung dient ein 11-adriges Kabel, 8 Datenleitungen, 2 Steuerleitungen zur Synchronisation und Masse. Erst wollen wir uns aber die Schnittstellen näher ansehen. Wer hier schon Bescheid weiß, kann die Punkte natürlich überspringen.
2.a Die LPT Schnittstelle des PC
Um den bidirektionalen Betrieb zu ermöglichen, muss die LPT Schnittstelle im BIOS umgestellt werden. Benutzer von älteren Modellen werden hier Probleme haben, soweit ich weiß, ist der bidirektionale Betrieb erst ab Pentium II vorgesehen, aber darauf möchte ich mich nicht festnageln. Die Adressen der LPT1 liegen bei 378...37A. Da die meisten nur eine parallele Schnittstelle haben werden, behandle ich nur diesen Adressraum.
0x378 ist das Datenbyte, hierüber werden die Datenbytes zur Schnittstelle geschickt, und auch von der Schnittstelle ausgelesen, falls die Schnittstelle bidirektional ist. Ansonsten bekommt man das zuletzt gesendete Byte. Dies ist also ein guter Test, ob die Schnittstelle für unsere Zwecke geeignet ist:
- Sicherstellen, dass keine Daten zur Schnittstelle gesendet werden;
- 32 zum Port 0x37A schicken, um Bidirektionalität einzuschalten ( outp(0x37A,32) );
- 0x55 zur Schnittstelle schicken ( outp(0x378,0x55) );
- Schnittstelle lesen; Falls sie 0x55 zurückliefert, sieht das nicht gut aus, sonst ist die Schnittstelle bidirektional und 5...6 entfällt;
- 0xAA zur Schnittstelle schicken ( outp(0x378,0x55) );
- Schnittstelle lesen; Falls sie jetzt 0xAA zurückliefert, ist die mit Sicherheit nicht bidirektional, sonst war der Eingang zufällig auf 0x55 geschaltet.
Falls sich herausstellt, dass die Schnittstelle nicht bidirektional ist, dann sind vielleicht die Einstellungen im BIOS falsch, oder man sollte über eine Aufrüstung seiner Hardware nachdenken. Sonst können eben nur Daten zum KC geschickt werden, das ist ja auch ein Anfang.
0x379 ist das Statusbyte. Hier interessiert uns vor allen Dingen Bit 6, in dem der Zustand der ACKN-Leitung steht (siehe auch 2.c).
0x37A ist das Kontroll-Byte. Hier interessiert uns Bit 0, hier wird das Signal NEG(Strobe) geschrieben. Ist das Bit auf Eins gesetzt, ist die Strobeleitung Low und andersrum. Bit 5 aktiviert die Bidirektionalität, muss also beim Empfangen auf Eins gesetzt werden.
2.b Die PIO-Schnittstelle des KC
Der PIO-Baustein des KC ist vergleichsweise einfach zu handhaben. Er besitzt zwei Ports, der eine wird als Datenport benutzt, der andere verbindet die beiden Steuerbits. Laut DIO-Handbuch, Seite 10 interessieren uns die Ports 04-07. Um einen Port zu initialisieren, wird sein Statusbyte auf 255 für die Bit-Ein/Ausgabe gesetzt. Dann muss an den PIO die Information gesendet werden, welche Bits auf Eingang (1) und welche Bits auf Ausgang (0) stehen sollen. Will man zum Beispiel nur Daten über den Port senden, muss eine Null geschickt werden. Sollen Bit 2 und 4 aber Daten empfangen, so muss eine 20 zum Steuerport gesendet werden, einfach oder?
In meinem Beispiel wird der Port B als Datenport in der LOAD-Routine mit 255 und 255 initialisiert, in der SAVE-Routine mit 255 und 0. Der Port A als Steuerport wird immer mit 255 und 64 initialisiert, da Bit 6 das Stobesignal des PC empfangen soll, und sonst alle Bits auf Ausgang stehen dürfen.
2.c Das Kabel
Als Verbindung schlage ich folgendes Kabel vor: Die KC-seitige Belegung ist dabei sicherlich auch anders möglich, ich musste mich nach meinem leicht defekten Modul richten, bei dem an Port A nicht mehr alle Bits funktionierten.
| KC | PC | Beschreibung |
| 1A + 1B | 18...25 | Masse |
| 2B...9B | 2...9 | 8 Datenbits |
| 8A | 1 | PC-Strobe an KC, Bit 6 |
| 3A | 10 | PC-ACKN an KC, Bit 1 |
Da mein Modul eh schon halb defekt ist, habe ich eine männlich kodierte Buchse an die Stelle der Anschlussleiste geschraubt. So kann ein Verlängerungskabel die Verbindung herstellen. Sonstige Bastelideen sind sicher klar: Kleine zweiseitige Leiterplatte ein bisschen sägen, ein bisschen kratzen, ein bisschen löten und fertig. Falls Brücken im Kabel eingebaut werden, wird das durch die Software (siehe 3.b) mit einer Endlosschleife belohnt!
3. Software
Das von mir entworfene Protokoll ist sicher einfach gestrickt, ein Profi (ich bin erst ein kleiner Drittsemester) wird da vielleicht müde lächeln.
3.a Die Routinen Sendbyte und Loadbyte
Folgender Zyklus wird beim Datenaustausch durchlaufen:
- Sender wartet auf Empfangsbereitschaft (Empfänger muss auf High schalten);
- Sender schickt das Datenbyte;
- Empfänger wartet auf Sendebestätigung (Sender muss auf High schalten nachdem er das Datenbyte übertragen hat);
- Empfänger liest das Datenbyte aus;
- Sender wartet auf Empfangsbestätigung (Empfänger muss auf Low schalten nachdem er das Datenbyte gelesen hat);
- Empfänger wartet auf Sendeabschluss (Sender muss auf Low schalten).
Dies funktioniert ganz gut, Daten werden erst gelesen, wenn sie korrekt geschrieben wurden. Um einen definierten Beginn zu haben, müssen logischerweise beide Rechner am Anfang der Übertragung ihr Steuersignal auf Low geschaltet haben. Dies passiert auch am Anfang. Dabei entsteht ein kleines Problem: Steht einer der Sender zufällig auf Low, der Empfänger interpretiert dies falsch (siehe auch 3.b) und schaltet auf High, während das Sendeprogramm noch gar nicht läuft, dann hängen beide Programme in unterschiedlichen Schleifen fest, der Empfänger ist auf High und wartet auf High, der Sender ist auf Low und wartet auf Low. Die Methode, den Sender immer zuerst zu starten, ist sicher unbequem.
3.b Das Handshaking
Um dem genannten Problem zu begegnen, habe ich folgendes Handshaking entworfen:
Beide Rechner schalten auf Low und warten auf Low. Dann schaltet der Sender zwischen 0x55 und 0xAA hin und her (ein guter Leitungstest) und wartet auf High des Empfängers (dies ist schon Punkt 1 des Datenaustauschzyklus). Der Empfänger muss sowohl die 0x55 als auch die 0xAA empfangen haben, bevor er auf High schaltet (er initiiert somit den Datenaustauschzyklus). Der Empfänger kann also nichts mehr falsch interpretieren, da sich eine Änderung auf dem Port vollziehen muss, der Worst-case ist damit auf einen Zufall eingeschränkt, dass ein anderes Programm an den Sender Daten schickt, und somit den Empfänger verwirrt. Das sollte vermieden werden.
3.c Einfache Programmierung
Wie Anfangs erwähnt, habe ich die LOAD/SAVE-Routinen des CAOS4.3 ersetzt. Sicherlich arbeitet das Programm auch im Hauptspeicher. Alle Sprünge sind relativ. Nur die CALL-Befehle für die Funktionen SendByte und LoadByte müssen angepasst werden. Diese sind mit Ausrufezeichen im Kommentar gekennzeichnet. Die LOADPC Routine erwartet keine Parameter. Die Startadresse und die Anzahl der zu lesenden Bytes bekommt sie vom PC. Dieser liest die Daten aus dem KCC-Format aus. Die SAVEPC Routine erwartet zwei Parameter, die Startadresse und die Anzahl der zu sendenden Bytes. Der PC speichert dies in dem File KCFILE.KCC.
Wie sicherlich schon aufgefallen ist, ist der Platz im KC-Speicher nicht gerade üppig. Deswegen habe ich auf luxuriöse Programmfunktionen wie einen Abbruch, falls in den Schleifen zu lange gewartet wird, verzichtet. Hat die Übertragung nicht geklappt, muss eben die RESET Taste des KC gedrückt werden, macht ja nichts. Ich glaube SmartDrv ist noch nicht auf dem KC implementiert, oder? ;--)))))))
Die PC-Routinen sind in C geschrieben und mit Borland C++ kompilierbar. Das ganze läuft auch im DOS-Fenster von Windows, anscheinend überwacht Bill Gates den parallelen Port nicht so akribisch.
4. Schlusswort
Bitte seid mir nicht böse, dass ich in das CAOS 4.3 eingegriffen habe. Alle benötigten Dateien liegen bei. Ich hoffe die Softwarekommentare sind ausreichend. Folgende Dateien gehöhren zum Paket:
load.asm load.bin caos43pe.bin kcload.c kcload.exe kcsave.c kcsave.exe
Das war es erst mal, Verbesserungsvorschläge nehme ich gerne an. Ansonsten würde ich mich über die Umbauanleitung des M011 zum M035 freuen, ich habe Probleme, Daten über den Refresh zu finden.