iec-bus

Benennung und Einordnung

„IEC-Bus“ ist ein Name, der sich im deutschsprachigen Commodore-Umfeld eingebürgert hat. Ganz präzise ist er nur bedingt. Der parallele Ursprung des Commodore-Peripheriebusses stand in enger Beziehung zu IEEE-488 beziehungsweise IEC-625. Die serielle Heimcomputer-Variante, wie sie am VIC-20, C64 und später C128 verwendet wurde, ist aber keine bloße Norm-Umbenennung, sondern ein eigener Bus mit eigener elektrischer und protokollarischer Ausprägung.

Commodore selbst sprach in Dokumentationen häufig einfach von „Serial“ oder später von „Standard Serial“, um diesen Bus vom späteren schnelleren „Fast Serial“ des C128 abzugrenzen. Wenn hier von IEC-Bus die Rede ist, ist damit genau dieser serielle Standardbus der Heimcomputer-Welt gemeint.

„IEC-Bus“ ist in diesem Kontext ein brauchbarer Name – solange man nicht so tut, als sei damit schon alles erklärt.

Von IEEE-488 zum Heimcomputer-Bus

Die PET- und CBM-Rechner arbeiteten mit einem parallelen Peripheriebus auf IEEE-488-Basis. Das war technisch leistungsfähig, aber teuer: breite Steckverbinder, viele Leitungen, entsprechende Treiberlogik. Für einen Heimcomputer mit deutlich engerem Kostenziel war das keine attraktive Lösung.

Der Weg zu VIC-20 und C64 führte deshalb zu einer seriellen Variante. Ziel war nicht, den Funktionsgedanken des CBM-Busses vollständig aufzugeben, sondern ihn mit weniger Hardwareaufwand auf Heimcomputer-Niveau zu bringen. Das bedeutete: weniger Leitungen, weniger Kosten, aber auch weniger Reserven. Diese Reduktion war keine Nebensache. Sie definierte das spätere Verhalten des gesamten Systems.

Der spätere Ruf des IEC-Busses als „langsam“ ist daher kein isolierter Fehler eines einzelnen Geräts. Er ist das Resultat einer grundlegenden Systementscheidung: Buskosten senken und die fehlende Hardware-Unterstützung stärker in die Software und in die Peripherielogik verlagern.

Leitungen und elektrische Logik

Für den alltäglichen Standardbetrieb des seriellen Commodore-Busses sind drei Signalleitungen zentral: ATN, CLK und DATA. Hinzu kommen selbstverständlich Masse und die physische Verkabelung selbst. Bei späteren Konstellationen spielt zusätzlich SRQ eine Rolle, insbesondere im C128-/1571-Kontext. Für das Verständnis des Standard-Serial-Betriebs reicht jedoch zunächst die Dreiergruppe.

• ATN (Attention): Steuersignal des Controllers. Dient dazu, den Bus in einen Kommandokontext zu versetzen und Adress- sowie Verwaltungsbytes zu übertragen.
• CLK (Clock): Takt- beziehungsweise Synchronisationsleitung innerhalb der Byte-Übertragung.
• DATA: Datenleitung für die eigentliche Bitübertragung.

Elektrisch arbeitet der Bus mit aktiven Low-Pegeln und Open-Collector- beziehungsweise Wired-AND-Logik. Praktisch heißt das: Eine Leitung ist nur dann wirklich high, wenn niemand sie aktiv nach low zieht. Jeder Teilnehmer kann sie also dominant nach unten ziehen, aber nicht aktiv nach oben treiben. Das ist langsam im Vergleich zu aggressiverer Treiberlogik, dafür robust und konfliktarm.

Gerade diese zurückhaltende elektrische Konstruktion erklärt einen Teil der späteren Verzögerungen: Der Bus ist nicht als aggressiv getaktete Hochgeschwindigkeitsschnittstelle gebaut. Er ist eine konservative, fehlertolerante Heimcomputer-Schnittstelle.

Rollen: Talker, Listener, Controller

Der Bus ist logisch nicht einfach „Rechner sendet, Laufwerk empfängt“. Er kennt Rollen. Ein Teilnehmer kann Controller, Talker oder Listener sein. Der Controller organisiert den Bus, adressiert Geräte und steuert den Ablauf. Der Talker sendet Daten. Ein oder mehrere Listener empfangen Daten.

Im Normalfall ist der Heimcomputer – etwa der C64 – zunächst der Controller. Er setzt ATN aktiv, adressiert das gewünschte Gerät und legt fest, wer sprechen und wer zuhören soll. Ein Laufwerk wie die 1541 wird danach im geeigneten Moment zum Talker oder Listener, je nachdem ob gelesen oder geschrieben wird.

TALK / LISTEN / Sekundäradressen

Unter aktivem ATN werden keine gewöhnlichen Nutzdaten übertragen, sondern Kommandobytes. Zu den wichtigsten zählen LISTEN, TALK, UNLISTEN und UNTALK. Ergänzt werden sie durch Sekundäradressen, die innerhalb eines Geräts zwischen Kanälen, Befehlsarten oder logischen Funktionen unterscheiden.

Im Commodore-Umfeld ist das nicht abstrakt, sondern sehr praktisch: Gerät 8 ist typischerweise das erste Diskettenlaufwerk. Der Controller kann also „LISTEN 8“ senden, um dieses Laufwerk als Empfänger anzusprechen, oder „TALK 8“, um es zum Sender zu machen. Erst danach folgen die eigentlichen Datenphasen.

Der Bus ist also logisch strukturierter, als die drei Leitungen zunächst vermuten lassen. Nicht die Anzahl der Drähte macht ihn primitiv oder komplex, sondern die Frage, wie viel Zustandslogik über diese Drähte zuverlässig transportiert werden kann.

Byte-Transfer und Handshake

Der eigentliche Byte-Transfer erfolgt bitweise. Genau das ist einer der Gründe, warum der Bus im Standardbetrieb langsam bleibt. Es wird nicht ein ganzes Byte parallel auf acht Leitungen gelegt, sondern jedes Bit durch einen Handshake über CLK und DATA übertragen.

In abstrahierter Form lässt sich der Ablauf so lesen: Der Sender bereitet das nächste Bit vor, signalisiert den gültigen Zeitpunkt über die Taktleitung, der Empfänger liest das Bit und bestätigt den Fortgang. Das ist logisch sauber, aber zeitlich teuer – besonders dann, wenn beide Seiten die Signale softwaregesteuert bedienen und konservative Wartezeiten einhalten.

Dazu kommt die Byte-Ebene mit zusätzlichen Wartezeiten zwischen Bytes, Verwaltungsbits und Sonderfällen wie End-of-Information. Auch wenn die Logik einfach aussieht, summieren sich diese zeitlichen Sicherheitsabstände zu einem sichtbaren Engpass.

Genau deshalb wirken Schnelllader im Rückblick so spektakulär: Nicht weil der Standardbus geheimnisvoll war, sondern weil seine konservative Originalimplementierung so viel Luft nach oben ließ.

C64, CIA und 1541, VIA

Ein Punkt, der oft unsauber erzählt wird, muss klar getrennt werden: Auf dem C64 hängt der serielle Bus an CIA #2 bei $DD00. In der 1541 hängt er an der ersten VIA bei $1800. Wer diese beiden Ebenen vermischt, verwischt genau die Stelle, an der viele praktische Unterschiede entstehen.

Dazu kommt die interne Architektur der Geräte selbst. Der C64 muss den Bus neben Bildschirmaufbau, IRQ-Logik und laufendem Programm bedienen. Die 1541 ist ihrerseits kein passives Laufwerk, sondern ein eigener kleiner Rechner mit 6502, RAM, ROM und VIA-Logik. Der Busverkehr ist also Kommunikation zweier aktiver Systeme – nicht nur ein Datenstrom aus einem dummen Peripheriegerät.

Wer schnelle serielle Übertragung implementiert, muss deshalb immer beide Seiten kennen: den Rechner und das Laufwerk. Einseitiges Optimieren reicht nicht.

Warum der C64-Bus so langsam wurde

Der Standardbus war ursprünglich nicht als so auffällig langsame Schnittstelle gedacht. Die Verlangsamung ist das Ergebnis mehrerer aufeinanderliegender Faktoren. Erstens: serielle statt paralleler Übertragung. Zweitens: konservative softwaregesteuerte Handshakes. Drittens – und für den C64 besonders wichtig – die Konkurrenz durch den Videochip.

Beim C64 stoppt der VIC-II die CPU regelmäßig für Speicherzugriffe. Diese DMA-Phasen liegen im Alltag ständig im Weg, besonders bei eng getakteten I/O-Routinen. Deshalb mussten die Haltezeiten des seriellen Protokolls gegenüber früheren Annahmen erhöht werden, damit der Rechner Bitfenster nicht verpasst. Das war funktional vernünftig, aber leistungsmäßig teuer.

Dazu kommt die Laufwerksseite: Auch die 1541 verarbeitet den Busverkehr softwaregesteuert. Ergebnis ist eine Kette aus serieller Bitübertragung, vorsichtigen Wartezeiten und begrenzten CPU-Ressourcen auf beiden Seiten. In der Praxis bedeutete das sehr geringe Transferraten – genau der Zustand, gegen den die gesamte Schnelllader-Kultur später anlief.

Der Bus ist nicht langsam, weil niemand es besser gekonnt hätte. Er ist langsam, weil billige Zuverlässigkeit hier Vorrang vor Geschwindigkeit hatte.

C128 Fast Serial und Burst

Der C128 führt später eine beschleunigte serielle Erweiterung ein, die rückwärtskompatibel zum Standardbus bleibt, aber mit geeigneten Laufwerken – insbesondere 1571 – deutlich schneller arbeiten kann. Wichtig ist dabei die begriffliche Sauberkeit: Standard Serial und Fast Serial sind nicht dasselbe. Und Fast Serial ist auch nicht einfach irgendein später Schnelllader, sondern eine eigene kompatible Erweiterung innerhalb der C128-Welt.

Praktisch heißt das: Normales Standard-Serial bleibt als gemeinsame Basis erhalten. Wenn beide Partner die schnellere Variante beherrschen, kann auf das beschleunigte Verfahren umgeschaltet werden. Genau darin unterscheidet sich diese Erweiterung von vielen Drittanbieter-Lösungen, die Kernal oder Laufwerkscode gezielt austauschen.

Für eine strenge technische Einordnung sollte man deshalb nicht alles unter „IEC-Bus, aber schneller“ zusammenwerfen. Standard Serial, C128 Fast Serial, JiffyDOS und Parallelkabel lösen ähnliche Engpässe auf unterschiedliche Weise. Genau das sollte man auseinanderhalten.

Fast Loader und Kernal-Ersatz

Schnelllader greifen den Engpass dort an, wo er praktisch sichtbar wird: in der langsamen Originalimplementierung des Standardbusses. Das kann auf mehreren Ebenen geschehen. Manche Lösungen ersetzen oder ergänzen Rechner- und Laufwerksroutinen im RAM. Andere setzen auf Kernal-Ersatz, also auf dauerhaft geänderte ROM-Logik im Rechner, Laufwerk oder beidem.

• Software-Schnelllader: laden eigenen Code nach und optimieren das Protokoll zur Laufzeit.
• Kernal-Ersatz: etwa JiffyDOS oder bestimmte DOS-Ausbaustufen – verändern die Standardroutinen systematisch und dauerhaft.
• Kombinierte Lösungen: Rechner- und Laufwerksseite werden gemeinsam optimiert.

Der Punkt ist dabei nicht Mystik, sondern Reduktion von Overhead. Wenn Wartezeiten verkürzt, Handshakes entschlackt oder Byte-Transfers neu organisiert werden, steigt die Geschwindigkeit sofort. Genau deshalb war der Standardbus immer auch eine Einladung zur Optimierung.

Wichtig ist auch hier die Trennung der Begriffe: Nicht jede schnelle Lösung ist ein Parallelkabel-System. Nicht jede Cartridge ist gleichbedeutend mit Busumbau. Und nicht jede ROM-Lösung ist dasselbe wie C128 Fast Serial.

Parallelkabel-Systeme

Parallelkabel gehen den konsequentesten Weg: Sie versuchen nicht nur, das serielle Standardprotokoll zu straffen, sondern umgehen dessen wichtigste Begrenzung direkt. Statt Bits nacheinander durch den Standardbus zu schicken, wird ein zusätzlicher paralleler Datenpfad geschaffen – typischerweise über den User-Port des Rechners und entsprechende Hardwareanpassungen auf Laufwerksseite.

Technisch ist das sauber: Wenn der Flaschenhals die serielle Ein-Bit-Übertragung ist, dann beseitigt ein paralleler Zusatzkanal genau diesen Flaschenhals. Der Preis ist offensichtlich: Zusatzhardware, Umbauten, geringere Universalität und stärkere Bindung an eine konkrete Gerätekombination.

Typische Systeme in diesem Bereich sind verschiedene DOS-Ausbaustufen mit Parallelkabel-Unterstützung. Das ist eine andere Kategorie als reine Kernal-Beschleuniger und wiederum etwas anderes als die standardkompatible Fast-Serial-Welt des C128.

Parallelkabel sind die nüchterne Antwort auf ein nüchternes Problem: Wenn seriell der Engpass ist, hilft parallel.

Was der IEC-Bus technisch lehrt

Der IEC-Bus ist ein gutes Beispiel dafür, wie stark eine scheinbar kleine Hardwareentscheidung die gesamte Nutzung einer Plattform prägen kann. Drei Signalleitungen statt eines parallelen Busses klingen nach einem Detail. In der Praxis entstehen daraus Ladezeiten, Laufwerkskultur, Schnelllader, Umbauten, ROM-Austausch und ein ganzer Bestand an technischem Wissen, der ohne diesen Engpass nie in dieser Form entstanden wäre.

Gleichzeitig ist der Bus kein Chaos. Im Gegenteil: Seine Logik ist sauber, seine Rollenverteilung klar und seine elektrische Konstruktion vernünftig. Genau deshalb eignet er sich so gut als Lehrstück. Er zeigt, dass Systeme nicht dadurch interessant werden, dass sie perfekt sind, sondern dadurch, dass man ihre Grenzen präzise lesen kann.

Für mich gehört der IEC-Bus deshalb nicht nur zur Laufwerksgeschichte, sondern zur allgemeinen Schule des technischen Denkens. Er zeigt, wie Architektur, Kosten, Timing und praktische Nutzung ineinandergreifen – und warum sich an einer einzigen Schnittstelle oft mehr über ein System lernen lässt als an hundert allgemeinen Beschreibungen.