C64-Netzwerk mit dem seriellen Bus

Ziel dieses kleinen Projektes ist die Vernetzung mehrerer C64 - theoretisch bis zu sieben - unter Verwendung des seriellen Ein-/Ausgangs.

Software

Download: serial.zip

Auf dem Disk-Image sind Programmfiles, die zu verschiedenen Programmgruppen gehören:

• wechselseitiger Datenaustausch zwischen 2 C64
• einseitige Übermittlung von Joysticksignalen
• Nachrichtennetzwerk für bis zu 6 C64

Hardware

Die Vernetzung über den seriellen Bus hat Vor- und Nachteile. Die Ausgänge des Inverters/Treibers 7406 sind mit bis zu 40mA belastbar, sie sind also sehr viel robuster als die Ausgänge des Userports und erlauben auch durchaus längere Leitungswege ohne zusätzliche Treiberbausteine. Nachteile sind die Langsamkeit der Übertragung und eine ziemliche Umständlichkeit bei der Handhabung, da der C64 von Haus aus dafür konzipiert ist, das ausschließliche Kommando über den Bus zu führen. Das Konzept der Gerätenummer ist auf ihn nicht anwendbar, die Kernal-Bus-Routinen können nicht verwendet werden, und für die Datenübertragung stehen nur zwei Leitungen zur Verfügung. Zwar hat der serielle Bus neben GND und RESET eigentlich vier Leitungen, jedoch ist ATN nur als Ausgang und SRQIN nur als (vom System ungenutzter) Eingang verfügbar, sodaß bloß die zwei Leitungen CLOCK und DATA überbleiben, über die gesendet und empfangen werden kann.

Jedes Gerät am Bus, egal ob C64 oder Floppy, belastet den Ausgang mit 5mA, daraus resultiert eine theoretische Obergrenze von 8 Geräten. Da ich das Aus- und Einlöten von ICs hasse, habe ich mich nie an das praktische Ausloten dieser Grenze gewagt. Zusätzlich belasten Kabelkapazitäten die Übertragung. Die bisherigen Tests haben ergeben, daß eine Gesamtlänge der seriellen Kabel von 25 Meter bei 5 Geräten am Bus problemlos funktioniert. Dabei habe ich eine abgeschirmte Steuerleitung mit 7 Adern verwendet, und darauf geachtet, daß im Kabel die signalführenden Leitungen Clock, Data und ATN nicht unmittelbar nebeneinander liegen, sondern "neutrale" Leitungen wie GND, SRQIN und Reset dazwischenliegen. Die Reset-Leitung habe ich gar nicht erst verbunden, da es keine Notwendigkeit für einen Hardware-Reset gibt und damit Probleme mit älteren C64 wegfallen. Über 25 Meter bin ich bei den Tests nicht gegangen. Eventuell ließen sich auch weit größere Entfernungen überbrücken, wenn für Clock, Data und ATN einzeln abgeschirmte Kabel mit geringen Kabelkapazitäten (Koaxkabel) verwendet würden.

Da der C64 keine zweite serielle Buchse zum Weiterverbinden hat, läßt sich mit Standard-Kabeln nur ein Netzwerk aus zwei C64 verwirklichen. Für eine größere Anzahl von Rechnern sind Weichen erforderlich. Die Lösung, bei der man am wenigsten verkehrt machen kann, sieht so aus, daß man mehrere 6-polige DIN-Buchsen in ein Gehäuse einbaut und die Buchsen parallel miteinander verschaltet. An diese Steckverteiler kann man nun Standardkabel für den seriellen Bus anschließen bzw. Kabel mit Sonderlängen selber herstellen. Die Pin-Belegung für den seriellen Anschluß ist im C64-Bedienungshandbuch auf Seite 142 oder hier zu finden.

Logik:

Die Leitungen am Bus werden im "Ruhezustand" durch einem Widerstand (1k) passiv auf 5V gehalten. Nach Jim Butterfields Artikel HOW THE VIC/&$ SERIAL BUS WORKS wird dieser Zustand als "false" bezeichnet. Wird der Ausgang aktiviert, zieht der Treiber die Leitung auf Masse, also auf annähernd 0V. Dieser Zustand nennt sich "true". Jedes der Geräte am Bus kann eine Leitung auf "true" legen, und dieser Zustand kann von allen registriert werden, da der Pegel der Leitungen parallel als Eingang abgefragt wird. Bei verschiedenen Outputs gilt immer die Regel: "true" schlägt "false". Hält ein Gerät die Leitung auf "true", ist es völlig egal was die anderen machen. Mehr als "true" kann sie nicht werden. Über den Output der anderen Geräte läßt sich in dem Fall also keine Feststellung treffen. Der Umstand, daß der Ausgang durch den Treiber invertiert wird, macht die Sache noch ein Stück verwirrender. Die Ein-/Ausgabe findet in einem einzigen Register statt (das nebenbei auch die Speicherbank für den VIC verwaltet):

CIA2 Port A Datenregister 56576 ($DD00):

Netzwerk einrichten:

Zuerst die C64 und eine Floppy mit seriellen Kabeln verbinden, dann die Geräte einschalten. Bei C64 älteren Baujahrs bewirkt die Reset-Leitung, daß der erste Rechner nicht "hochkommt" da er einen permanenten Reset empfängt, solange ein zweiter, ausgeschalteter C64 am Bus hängt. Bei neueren C64 (ab ca. 1985) fällt dieser Umstand weg, da der Reset vom seriellen Bus nicht durchgeschaltet wird.

Im Einschaltzustand hält der C64 die Clock-Line true. Jeder Rechner blockiert so für den anderen den Floppy-Zugriff. Man muß nun an einem der beiden Rechner eintippen

SYS 61061 (das ist leichter zu merken als POKE 56576,199 , was das gleiche bewirkt)

damit man mit dem anderen das Programm laden kann. Ist es fertig geladen, kann ohne weitere Umstände das Programm auch in den zweiten C64 geladen werden. Haben beide Rechner geladen, kann die Floppy ruhig weiter am Bus bleiben, den Datenaustausch zwischen den beiden C64 berührt das nicht im geringsten.

Wechselseitiger Datenaustausch zwischen 2 C64

Diese kleinen Programme sind eine Art Zwischenergebnis. Um erste Erfahrungen mit dem Problem zu sammeln, begann ich mit einer seriellen Verbindung zwischen zwei C64. Etwas derartiges gibt es übrigens schon lange: C64 SERIAL TALK auf der -=> The Singular Crew's homepage! <=- . Neu ist vielleicht nur, daß die Routinen hier universell für verschiedene Anwendungen einsetzbar sind.

Für ein Netzwerk mit mehr als 2 Teilnehmern müßte ein Identifikationssystem eingerichtet werden. Das habe ich im Programm "sermes" auch gemacht. Den Ansatz universell einsetzbarer Routinen habe ich dann aber nicht weiterverfolgt, der ist also bei der Übertragung zwischen 2 C64 steckengeblieben.

Zu dieser Programmgruppe gehören folgende Files:

• "serial2" - Die Routinen für den Datenaustausch
• "basictest" - Ein kleines Testprogramm in Basic

Das Maschinenprogramm "serial2" ist 416 Bytes lang und läuft in jedem Speicherbereich, ohne daß eine Anpassung nötig wäre. Es gibt 4 einzeln aufrufbare Subroutinen. Die Einsprungadresse bezieht sich auf die Basis- bzw. Ladeadresse des Programms. Die Originaladresse ist 49152 ($C000)

Vorbereitungen:

Das Programm benutzt die Zero-Page Adressen 163-176 ($A3-B0), die vom Betriebssystem sonst für Input/Output benutzt werden.

* Die mit einem Stern gekennzeichneten Register müssen vor Aufruf der Routinen gesetzt werden.

Die Zeiger für Anfang und Ende der ausgehenden Nachricht bestimmen die Länge der Nachricht - es kann ein einziges Byte gesendet werden oder praktisch der gesamte RAM-Inhalt.

Der Zeiger auf den Anfang der eingehenden Nachricht bestimmt, wo sie gespeichert werden soll. Der Zeiger auf das Ende wird vom Programm gesetzt und teilt die Länge der empfangenen Nachricht mit.

Das Register Zeitlimit legt fest wie lange gewartet werden soll, wenn der andere Rechner nicht empfangsbereit ist. Ein Wert von Null bedeutet, daß ganz ohne Limit auf die Empfangsbereitschaft gewartet wird. Ein Wert zwischen 1 und 255 legt eine Zeit fest, nach deren Ablauf ein Sendeversuch abgebrochen wird. Die Zeit in Sekunden beträgt etwa X*X/330 und kann folglich zwischen 3 Millisekunden und 3 Minuten liegen.

Statusflags:

Die Routinen verwenden das I/O Statusregister 144 ($90), Variable ST, jedoch mit anderer Bedeutung der gesetzten Bits. Ein gesetztes Bit 7 bedeutet einen Error, ansonsten handelt es sich um informative Rückmeldungen.

Kommunikation:

Ehe irgendwelche Nachrichten verschickt werden können, müssen sich beide Rechner mit "Connect" als Teilnehmer am Bus anmelden. Damit signalisieren sie: ich bin online, aber derzeit nicht empfangsbereit. Von nun an ist übrigens für keinen der beiden Rechner ein Disk-Zugriff möglich!

Die Subroutine "Get Message" wird aufgerufen um zu überprüfen, ob eine Nachricht wartet. Wenn ja, wird sie an die angegebene Adresse verliefert und Bit 6 des Statusregisters gesetzt. Wenn nein, kehrt die Routine umgehend mit gelöschtem Bit 6 zurück.

Die Subroutine "Send Message" sendet die durch die Zeiger spezifizierte Nachricht. Genauer gesagt: sie versucht es. Sie muß nämlich warten bis der andere Rechner Empfangsbereitschaft signalisiert (und das tut dieser nur dann, wenn er "Get Message" absolviert). Zeigt der andere Rechner keine Empfangsbereitschaft, setzt die Routine nach Ablauf des Zeitlimits die Flags "Error", "Message not sent" und "Timeout" im Statusregister und kehrt unverrichteter Dinge zurück. Ein anderer Fall liegt vor, wenn der andere Rechner bereits zuvor das Signal gesetzt hat, daß er eine Nachricht senden möchte. In dem Fall tritt der Späterkommende zurück und empfängt die wartende Nachricht, anstatt seine eigene abzusetzen. Die Routine setzt die Flags "Message not sent" und "Message received", jedoch nicht das Error-Flag, da es sich um keinen eigentlichen Fehler sondern um ein lösbares Koordinationsproblem handelt. Wie auch immer, bei Benutzung der Routine "Send Message" ist danach das Statusflag zu prüfen und beim Flag "Message received" so zu verfahren wie bei der Routine "Get Message", nämlich die eingegangene Nachricht irgendwie zu verwerten. Die eigene, noch ungesendete Nachricht muß dann eben später abgesetzt werden.

Die Routine "Disconnect" gibt den Bus frei, um beispielsweise wieder auf die Floppy zugreifen zu können. Dazu muß "Disconnect" auf beiden Rechnern ausgeführt werden.

Je nachdem für welche Aufgaben die Routinen eingesetzt werden, können sich verschiedene Koordinationsprobleme ergeben. Wenn unklar ist, ob und wann Nachrichten vom anderen Rechner zu erwarten sind, muß permanent mit "Get Message" der Bus auf wartende Nachrichten überprüft werden, da der andere Rechner ansonsten mit dem Warten auf Empfangsbereitschaft blockiert ist. Die Routinen regeln den Datenaustausch auf sehr einfache Weise. Für eine feinere Koordination kann je nach Problemstellung ein Protokoll auf der nächsten Ebene entwickelt werden, indem Steuerbytes versandt werden, die bestimmte Anweisungen für den anderen Rechner enthalten.

Die Geschwindigkeit der Datenübermittlung beträgt etwa 700 Bytes/Sekunde und liegt damit etwa in der Größenordnung, die man von der Floppy gewohnt ist. Das größte Problem für das Tempo ist der VIC, der den Prozessor ausbremst und zu Verzögerungen führt, die einkalkuliert werden müssen. Das Timing wurde so eingestellt, daß aktive Sprites, die auch etwas Rechenzeit kosten, während des Zugriffs zulässig sind.

Einbindung in eigene Programme:

Das Programm enthält keinen internen absoluten Adressen, ist also in jedem beliebigen Speicherbereich lauffähig, es benutzt außer den genannten Zero-Page-Registern keine Ressourcen und verwendet keine Routinen des Betriebssystems.

Für die Einbindung in Assembler: Die Routinen schalten während der Ausführung den IRQ ab, bei der Rückkehr stellen sie diesbezüglich den anfänglichen Prozessor-Status wieder her. Ansonsten enthalten die Routinen nach Rückkehr das Statusbyte im Akku und haben Mi-Flag (Error) und V-Flag (Message received) gesetzt. Man kann die Routine "Get Message" in den IRQ einbinden, muß aber dann natürlich auch dafür Sorge tragen, daß eingegangene Nachrichten auch gleich richtig verliefert werden.

"basictest":

Dieses kleine Programm habe ich nur für Testzwecke geschrieben. Wenn beide C64 geladen haben, kann man es mit RUN starten. Nun empfängt man am Bildschirm jeden Tastendruck beider Rechner, dargestellt in verschiedenen Farben.

Einseitige Übermittlung von Joysticksignalen

Zu dieser Programmgruppe gehören folgende Files:

• "sendjoy ml " - Maschinenprogramm zum Senden von Joysticksignalen
• "sendjoy" - dasselbe mit einem Basic-Vorspann zum Starten
• "getjoy ml " - Maschinenprogramm zum Empfangen von Joysticksignalen
• "getjoy" - ein reines Testprogramm in Basic, das die Empfangsroutine enthält.

Sinn der Sache ist es, einen C64 zur Abfrage zusätzlicher Joystickeingänge einzusetzen (Joystickport 1 und 2 sowie Userport für den 4-Spieler-Adapter). Eine praktische Verwendung findet das im Spiel Protovision - Wor Wizards Tournament von BIG USER alias Stefan Gutsch.

Der C64 zum Abfragen der zusätzlichen Joystickports tut sonst nichts als die Eingänge zu prüfen und über den seriellen Bus zu senden. Sein Bildschirm ist aus Gründen des Timings abgeschaltet. Man kann es sich eigentlich ersparen, ihn an einen Monitor zu hängen, wenn man den Befehl zum Laden und Starten des Programms blind eintippt.

Das Programm zum Senden wartet auf eine Aufforderung durch das Empfangsprogramm, ehe es zu senden beginnt. Ansonsten verhält es sich still, sodaß für den empfangenden C64 ein Diskzugriff außerhalb der Empfangsroutine problemlos möglich ist. (Die spezielle Sendeaufforderung kommt im normalen Protokoll der Floppy-Kommunikation nicht vor - ob das auch für alle Fastloader zutrifft ?) Nachdem die Empfängerseite die Kommunikation mit der Floppy beendet hat, müssen mindestens 3328 Takte (ca. 3.3 Millisekunden) vergehen ehe die Empfangsroutine für die Joysticksignale aufgerufen werden kann, da der Sender erst nach einer Ruhepause am Bus wieder auf Sendeaufforderungen reagiert.

Die Routine "getjoy ml" kann sehr leicht in eigene Programme eingebaut werden. Sie ist in jedem Speicherbereich lauffähig, verwendet keine Arbeitsregister und erfordert nicht, daß der IRQ abgeschaltet wird. Da es nur ein Testprogramm ist, werden die empfangenen 4 Bytes im Bildschirmspeicher abgelegt (ab 1024 bzw. $0400), diese Ablageadresse muß an den jeweiligen Bedarf angepaßt werden.

Das Testprogramm "getjoy" zeigt die empfangenen Bytes am Bildschirm und liest bei einem Tastendruck den Titel des Directorys von Disk ein, um die Möglichkeit des parallelen Floppyzugriffs zu testen.

Listing

Die Routine "sendjoy ml" wartet bei Label "freebus" auf das Signal zum Senden, das aus einer chrarakteristischen Abfolge von Buszuständen besteht:

1. Signal: Data=true, Clock=true
2. Signal: Data=false, Clock=true
3. Signal: Data=false, Clock=false
4. Signal: Data=true, Clock=false
5. Signal: Data=false, Clock=false

Bei einer Abweichung von dieser Sequenz wird bei Label "watchbus" gewartet, bis der Bus für 3.3 Millisekunden den Zustand Data=false, Clock=false aufweist, also wieder frei ist.

Paßt das Signal, werden in der Vorbereitung "prepare" die 4 zu sendenden Bytes auf Stack gelegt. "loopbyte" wird für die Anzahl zu sendender Bytes durchlaufen, am Schluß wird das gesendete Byte vom Stack geholt. In "loopbit" werden zwei Bits je Durchlauf gesendet. Gesendet wird nach Takt des Empfängers, der die Clock-Leitung abwechsend true und false legt, bei jedem Wechsel setzt der Sender die Data-Leitung entsprechend dem zu sendenden Bit. Das Bit wird invertiert, sodaß es nach der Invertierung durch die Hardware beim Empfänger gleich "richtig" ankommt.

Die Routine "getjoy ml" setzt zunächst das Signal, das den Datensender zum Senden veranlaßt. Die Verzögerungsloops "loop1-5" geben dem Sender Zeit, die Leitungen einzulesen, "loop5" berücksichtigt zusätzlich die Zeit, die der Sender zur Vorbereitung der Bytes braucht. "loopbyte" wird für die Anzahl der zu empfangenden Bytes, also 4mal durchlaufen, "loopbit" für jedes Bit, also 8mal. Der Zähler y in "loopbit" dient außerdem dazu, die Clock-Leitung abwechsend "true" und "false" zu setzen, was für den Sender das Signal ist, das nächste Datenbit auf der Data-Leitung bereitzustellen. Der Loop muß etwas verzögert werden, ehe der Zustand der Data-Leitung erneut abgefragt werden kann, dafür sorgt eine doppelte Folge von pha-pla. Die Ablageadresse "joymem" für die empfangenen Bytes muß für die jeweilige Anwendung festgelegt werden.

Mögliche Anpassungen:

1.) Andere Datenbytes senden:

Die Vorbereitung der Bytes in Label "prepare" von "sendjoy ml" legt die normalen Joystickports und den Userport für den 4-Spiele-Adapter auf Stack. Das Umschalten von Bit 7 in $DD01 bewirkt, daß erst Joystick 3 und dann Joystick 4 abgefragt wird. Da der Feuerknopf von Joystick 4 in Bit 5 gesetzt ist, wird Bit 5 nach Bit 4 verschoben. Sollen andere Daten gesendet werden, fällt das alles weg. Die zu sendenden Bytes müssen einfach auf den Stack geschoben werden. Die zur Vorbereitung der Bytes nötige Zeit muß im Verzögerungsloop "loop5" der Routine "getjoy ml" berücksichtigt werden, dauert die Vorbereitung der Daten länger, muß der Loop entsprechend öfter durchlaufen werden (5 Takte je Durchlauf), da der Empfänger keinesfalls schneller sein darf als der Sender.

2.) Mehr oder weniger Bytes senden:

Dazu müssen in der Vorbereitung von "sendjoy ml" die entsprechende Anzahl von Bytes auf Stack geschoben und in beiden Routinen die Zähler x von Loop Byte angepaßt werden. Wenn die zu sendenden Bytes hintereinander im Speicher liegen, können beim Senden am Anfang von "loopbyte" die Bytes auch mit Index x ausgelesen und einzeln auf den Stack geschoben werden. Durch das Wegfallen der Vorbereitungszeit kann in "getjoy ml" der Verzögerungsloop "loop5" kürzer dimensioniert werden.

3.) Zwei C64 als Sender:

Der Datensender sendet nach dem Takt des Empfängers - wenn zwei Sender beteiligt sind, senden sie synchron. Damit sich die übermittelten Daten nicht überlagern, muß der eine Sender Leerbytes senden, während der andere seine Datenbytes sendet, und umgekehrt. In der Vorbereitung von "sendbyte ml" kommen beim einen Sender also erst die Datenbytes auf Stack und danach die Leerbytes ($ff), beim zweiten Sender ist es umgekehrt. Der Zähler x für "loopbyte" muß bei Sendern und Empfänger verdoppelt werden, in "getjoy ml" ist zusätzlich die längere Vorbereitungszeit in der Vorgabe y für "loop5" zu berücksichtigen.

Nachrichtennetzwerk für bis zu 6 C64

Kontakt: kottira@webnet.at