erschienen in: GO64! - Das Magazin für Computerfreaks, Ausgabe 7/2000

C64 goes Ethernet

Hello World,

Auf dem Wunschzettel so mancher C64-Enthusiasten steht an oberster Stelle eine Ethernetkarte zur Einbindung des C64 ins heimische Netzwerk. Doch Netzwerkkartenchips sind in aller Regel nicht für 8Bit-Systeme geeignet - zum Glück nicht alle...

Der Aufschrei

Auf große Resonanz in comp.sys.cbm stieß der Hinweis auf das "Embedded Ethernet Project" [1]. Hier wurde erstmals eine Methode dargestellt, wie man einen speziellen Netzwerkkartenchip, den CS8900A von Crystal Semiconductors, an gängige 8Bit-Mikrocontroller anschließt. Dieser Chip ist vergleichsweise alt und verfügt deshalb über eine Interfacemöglichkeit zu 8Bit-Systemen.

Was liegt also näher, diesen Chip auch für ein C64-Projekt zu nutzen? Flugs wurde das "EtherCart Project" ausgerufen [2], welches sich zum Ziel gesetzt hat, eine Netzwerkkarte auf Basis des CS8900A für den C64 zu entwickeln. Der große Vorteil dieses Chips liegt, neben dem einfachen Interface, in einem internen Pufferspeicher und erlaubt somit, den Datentransfer zwischen C64 und Ethernet nicht etwa per DMA zu erledigen (was beim C64 hardwaretechnisch etwas unbequem zu handhaben ist wegen der ständigen Unterbrechungen durch den VIC). Stattdessen kann der Datentransfer via polled I/O (PIO) bzw. interruptgesteuert durchgeführt werden. Somit ist dieses Projekt für den etwas begabteren Hardwarebastler sicher nicht schwer zu realisieren und, basierend auf [1] fast nur noch eine Fingerübung.

Resonanzen

Kurze Zeit später kam die Diskussion auf, ob der C64 denn schnell genug sei, um überhaupt mit dem Datenstrom eines 10MBit-Netzwerkes mithalten zu können. Für den Laien ist das etwas schwer verständlich, denn dafür ist doch eigentlich der Netzwerkchip da, so denkt man. Prinzipiell ist dies auch richtig: Der C64 muß sich nicht mehr um den eigentlichen Datentransfer kümmern, jedoch obliegt ihm die Datenflußkontrolle. Soll heißen, er muß Datenpakete vom Netzwerkchip abholen bzw. diesem zuführen. Die Versendung bzw. den Empfang der Datenbits übernimmt dann der Netzwerkchip. Doch was passiert, wenn die Datenpakete vom C64 ausbleiben bzw. dieser sie nicht rechtzeitig abliefert? In letzterem Falle mahnt die Gegenstelle die noch ausstehenden Pakete an. Holt der C64 jedoch die Datenpakete nicht rechtzeitig ab, so quittiert der Netzwerkchip neu eintreffende Daten mit einer "noch nicht bereit" Antwort.

In beiden Fällen kommt es zu vermehrtem Netzwerkverkehr, da - zuzüglich zum erhöhten Fluß von Kontrolldaten - Nutzdaten öfter als eigentlich nötig versandt werden müssen. Doch kann dieser Fall überhaupt eintreten? Leider ja, denn ein unbeschleunigter C64 kann - volle Netzlast vorausgesetzt - tatsächlich die Datenpakete nicht rechtzeitig abholen, wie folgende exemplarische Schleife zeigt. Hierbei wird davon ausgegangen, daß die Routine im Interrupt aufgerufen wird und zu empfangende Daten über ein Auto-Increment-Register ausgelesen werden können. Der Einfachheit halber wird zudem angenommen, daß immer nur Pakete zu 256 Byte übertragen werden.

                                ; Zyklen	
irq:    LDY #0                  ; 2
loop:   LDA status              ; 4
        BEQ end_of_loop         ; 3/4
        LDA data                ; 4
        STA (buf),Y             ; 5
        INY                     ; 2
        JMP loop                ; 3
eol:    RTI                     ; 6

Bereits für einen Durchlauf, also der Übertragung von nur einem Byte, werden inklusiv Rücksprung 37 Zyklen, d.h. etwa 37us benötigt. Die Übertragung eines Roh-Bytes (10 Bit bestehend aus Start-Bit, 8 Bit Daten plus Stop-Bit) mit einer Datenrate von 10MBit/s braucht jedoch nur 1us.

Somit ist klar, daß es zwangsläufig zu dem geschilderten Problem der vermehrten Netzbelastung kommen muß, da ein unbeschleunigter C64 die Daten gar nicht schnell genug abholen bzw. aussenden kann und somit von der Gegenstelle Daten mehrfach angefragt werden bzw. ihrerseits Daten mehr als einmal übertragen werden.

Und nun?

Die Frage ist nun, ob dies überhaupt eine Rolle spielt. Und in der Tat mag obiger Einwand für 10BaseT-Netzwerke durchaus zutreffen, hier ziehen nämlich alle Netzwerkteilnehmer buchstäblich am gleichen Strang und teilen sich ein einziges (Koaxial-)Kabel als Verbindungsmedium. Andererseits ist diese Netzwerktopologie mit dem Wechsel zur 100MBit/s-Vernetzung längst abgelöst worden, da für die schnellen Verbindungstechnologien Sternnetze notwendig sind, so daß die "Blockade" lediglich zwischen Sender und Empfänger auftreten und den Netzbetrieb zwischen den anderen Netzwerkteilnehmern nicht beeinträchtigt. Zur Umsetzung zwischen 10 und 100MBit/s-Segmenten dient hierbei ein sogenannter Switch bzw. Switching Hub oder einfach ein ausrangierter PC mit zwei Netzwerkkarten.

Doch selbst bei Verwendung eines 10BaseT-Netzwerks wäre die Diskussion vermutlich eher müßig, denn die im C64-Bereich üblicherweise anfallenden Datenmengen sind doch zu gering, um im regulären Netzwerkbetrieb selbst bei Mehrfachübertragungen ernsthaft zu Stockungen zu führen. Was den C64-Benutzer anbelangt, so hat er in etwa die Geschwindigkeit eines guten Parallelspeeders zu erwarten - in einem typischen C64-System sicherlich eine recht angenehme Datentransfergeschwindigkeit.

Die Softwareseite

Soviel zur Hardware. Doch was braucht's an Software? Es ist leider nicht getan, lediglich Rohdaten auszusenden. Datentransfer übers Netz bedient sich des sogenannten ISO/OSI-Schemas und ist in sogenannte Schichten (Levels) eingeteilt. Auf unterster Ebene liegt die Hardwareübertragung, eine drüber die Bitübertragungsschicht. Um exakt diese kümmert sich der Netzwerkchip. Alles was darüber liegt, muß in Software geschehen. Hier haben wir an dritter Stelle das Transmission Control Protocol (TCP) und an vierter das Internet Protocol (IP), meist fälschlich in einem Atemzug als TCP/IP bezeichnet. Die Zusatzdaten dieser Schichten beinhalten z.B. Absender und Adressat oder das verwendete Protokoll (Telnet, FTP, HTTP). Wer's genauer wissen will, der mag einen Blick in [3] riskieren.

Dies gilt's nun auch auf dem C64 zu realisieren, bevorzugterweise in einer systemkonformen Art und Weise: Ideal wäre doch, auf das Internet in gewohnter Form mittels OPEN und CLOSE zugreifen zu können. Ludo "Groenteboer" Gorzeman hat sich hierzu bereits einige Gedanken gemacht [4], weit gediehen ist das Projekt jedoch noch nicht - nicht zuletzt wohl auch wegen eines gravierenden Hardwaredefektes seines C64, dessen VIC die Reise in die ewigen Jagdgründe angetreten hat.

Fazit

"Es gibt viel zu tun, packen wir's an.", lautete ein bekannter Werbeslogan der 70er und 80er. Gleiches gilt auch für das EtherCart-Projekt mit all seinen Aufgabenbereichen, denn eines muß jedem klar sein: Es wird sich mit ziemlicher Gewißheit keine Hardwareschmiede mehr dieser Herausforderung annehmen. Zu klein ist der C64-Markt geworden und damit eine kommerzielle Entwicklung von vorneherein unprofitabel. Doch das Ziel lohnt sich: Zwar wird ein unbeschleunigter C64 nie ein "Renner" im Netzwerk sein, dennoch ist die Möglichkeit, den geliebten Brotkasten einfach und ohne Umwege (SLIP/PPP bzw. Shell-Account mit Modemeinwahl) ans Netz zu hängen doch sehr reizvoll.

Quellen:

[1] Embedded 10BaseT Ethernet

[2] Commodore EtherCart Project Homepage

[3] Rechnernetze nach OSI

        Helmut Kerner, Addison Wesley, 1993
        ISBN 3-89319-632-3

[4] Groenteboer's Commodore Center