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.

Systemgeschichte: Commodore 64 und Commodore 128 zeigen die Rechnerseite dieser Entwicklung.

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. Pull-up-Widerstände stellen den High-Zustand her; Teilnehmer ziehen eine Leitung bei Bedarf aktiv nach Low. Dadurch können mehrere Geräte dieselben Leitungen ohne gegeneinander arbeitende High-/Low-Treiber nutzen. Die erreichbare Geschwindigkeit wird dabei nicht allein durch dieses elektrische Prinzip bestimmt, sondern durch Leitungskapazität, Pull-ups, Protokoll und vor allem die jeweilige Software- beziehungsweise Hardwareimplementierung.

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: Talker und Listener beobachten DATA und CLK und wechseln die Leitungszustände in festgelegten Zeitfenstern. Der Empfänger muss jedes Bit zuverlässig erkennen; zusätzlich existieren Byte-, Listener-Ready- und EOI-Sonderfälle. Das folgende Schema ist deshalb bewusst konzeptionell und nicht zyklusgenau. Gerade die softwaregesteuerte Bedienung der Leitungen macht die Originalroutinen empfindlich gegenüber engen Timingfenstern.

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 wird Standard Serial über CIA #2 im Bereich $DD00–$DD0F bedient. Commodores Serviceunterlagen zeigen dafür insbesondere die Port-A-Signale PA3 bis PA7 als ATN-, CLK- und DATA-Pfade. In der 1541 liegt die serielle Buslogik auf der ersten 6522-VIA im Bereich $1800. Rechner- und Laufwerksseite sind damit zwei getrennte aktive Implementierungen desselben Protokolls.

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.

Hardwarevertiefung: Schnittstellen und Kabel sowie Interfaces behandeln elektrische Anschluss- und Pegelgrenzen systemübergreifend.

Warum der C64-Bus so langsam wurde

Die bekannte Langsamkeit des C64/1541-Standardbetriebs hat mehrere Ebenen. Entscheidend ist nicht bloß, dass Daten seriell übertragen werden. Entscheidend ist, wie C64 und 1541 diese Übertragung tatsächlich ausführen: Die Busleitungen werden in den Standardroutinen softwaregesteuert bedient, und zwischen den Leitungswechseln liegen bewusst großzügige Timingfenster.

Commodores C64-Serviceunterlagen zeigen, dass Standard Serial über die parallelen Port-A-Leitungen von CIA #2 geführt wird, obwohl der 6526 zusätzlich eigene serielle SP/CNT-Funktionen besitzt. Damit ist der normale C64-Bus kein automatisch byteweise durchgeschobener Hardware-Shift-Register-Pfad. Auf der 1541-Seite arbeitet wiederum ein eigener Prozessor mit VIA und Laufwerks-DOS. Jeder Transfer hängt deshalb von Code und Timing auf beiden Seiten ab.

Der VIC-II verschärft diese Lage zusätzlich: Während bestimmter Videozugriffe kann er dem 6510 Buszyklen entziehen. Für enges softwaregesteuertes I/O bedeutet das, dass ein Protokoll nicht voraussetzen darf, die CPU könne jedes beliebig kurze Zeitfenster störungsfrei bedienen. Das ist ein zusätzlicher C64-spezifischer Timingfaktor – aber nicht die alleinige Erklärung dafür, warum Standard Serial langsam ist.

Genau hier setzen Fast Loader an. Sie ersetzen nicht zwingend die elektrische Schnittstelle, sondern häufig die langsamen Rechner- und Laufwerksroutinen durch enger abgestimmten Code. Dass auf denselben Leitungen wesentlich höhere Transferraten möglich sind, zeigt, wie groß der Anteil der ursprünglichen Protokoll- und Softwareentscheidungen am Flaschenhals ist.

Der Standardpfad ist langsam, weil Kosten, Kompatibilität, softwaregesteuertes Timing und sichere Reserven höher gewichtet wurden als maximaler Durchsatz.

C128 Fast Serial und Burst

Der C128 führt eine beschleunigte serielle Erweiterung ein, die neben dem bisherigen Standardpfad arbeitet und mit geeigneten Laufwerken – insbesondere der 1571 – deutlich höhere Transferraten ermöglicht. Commodores 1571-Serviceunterlagen nennen für Programmladevorgänge etwa 300 Zeichen/s unter C64-Steuerung und bis zu 5200 Zeichen/s als Burst-Rate unter C128- beziehungsweise CP/M-Steuerung. Wichtig bleibt die begriffliche Trennung: Standard Serial, Fast Serial/Burst und Drittanbieter-Schnelllader sind unterschiedliche Verfahren.

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.

Laufwerkskontext: Laufwerke und Diskettenstationen ordnet 1541, 1571 und weitere Medien-/Mechanikthemen breiter ein.

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.

Softwarekontext: Software- und Tool-Alltag führt KERNAL-Ersatz, Diagnose- und Ladehilfen als Werkzeugschicht weiter.

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.

Technischer Stand 2026: Originalbus, Beschleuniger und moderne Ersatzpfade auseinanderhalten

Die elektrische und protokollarische Grundlage von Commodore Standard Serial ist historisch abgeschlossen. ATN, CLK, DATA, Talker/Listener-Rollen, Geräteadressen und die KERNAL-/Laufwerksroutinen lassen sich aus den erhaltenen Commodore-Handbüchern, Serviceunterlagen und ROM-Beständen weiterhin exakt rekonstruieren.

Für die technische Einordnung ist entscheidend, nicht jede schnelle Übertragung als „schnelleren IEC-Bus“ zusammenzufassen. Ein Software-Fast-Loader, ein KERNAL-/DOS-Ersatz, ein Parallelkabel und C128/1571 Fast Serial lösen denselben Engpass mit unterschiedlichen Mitteln und besitzen unterschiedliche Kompatibilitätsgrenzen.

Auch moderne Massenspeicheradapter, Laufwerksemulatoren oder USB-IEC-Lösungen sind eine eigene Schicht. Sie können das Protokollverhalten eines Laufwerks sehr weit nachbilden, ersetzen aber nicht automatisch die elektrische, zeitliche und firmwarebezogene Realität einer bestimmten 1541- oder 1571-Revision.

Für eine Archivmessung sollten deshalb Rechnerrevision, Laufwerk, ROM-Version, verwendeter KERNAL, Beschleuniger, Kabelweg und Übertragungsmodus gemeinsam dokumentiert werden. Eine einzelne Transferzahl ohne diese Angaben ist kaum vergleichbar.

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.

Der IEC-Bus gehört 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 vielen allgemeinen Beschreibungen.

Erhaltung: Datensicherung und Backups behandelt Images und Prüfsummen; The Vault Provenienz und langfristigen Originalerhalt.

Querverweise im SSLXY-Archiv

Der IEC-/Standard-Serial-Bus verbindet im Archiv Rechnerarchitektur, Laufwerke, Schnittstellen, Softwarebeschleuniger und Datenträgererhaltung.

• Startseite von sslxy.de
• Commodore 64
• Commodore 128
• Commodore 65
• Hardware
• Systems
• Laufwerke und Diskettenstationen
• Schnittstellen und Kabel
• Interfaces
• Software- und Tool-Alltag
• Datensicherung und Backups
• The Vault
• Technische Philosophie