iec-bus

Benaming en indeling

„IEC-bus“ is een naam die zich in de Duitstalige Commodore-omgeving heeft ingeburgerd. Helemaal precies is hij maar beperkt. De parallelle oorsprong van de Commodore-periferiebus stond in nauwe relatie tot IEEE-488 respectievelijk IEC-625. De seriële thuiscomputervariant, zoals die bij VIC-20, C64 en later C128 werd gebruikt, is echter geen loutere norm-herbenaming, maar een eigen bus met een eigen elektrische en protocolmatige uitwerking.

Commodore zelf sprak in documentatie vaak eenvoudig van „Serial“ of later van „Standard Serial“, om deze bus af te grenzen van de latere snellere „Fast Serial“ van de C128. Wanneer hier over de IEC-bus wordt gesproken, wordt precies die seriële standaardbus van de thuiscomputerwereld bedoeld.

„IEC-bus“ is in deze context een bruikbare naam – zolang men niet doet alsof daarmee al alles verklaard is.

Van IEEE-488 naar de thuiscomputerbus

De PET- en CBM-computers werkten met een parallelle periferiebus op IEEE-488-basis. Dat was technisch krachtig, maar duur: brede connectors, veel lijnen en overeenkomstige driverlogica. Voor een thuiscomputer met een veel krapper kostendoel was dat geen aantrekkelijke oplossing.

De weg naar VIC-20 en C64 leidde daarom naar een seriële variant. Het doel was niet om het functionele idee van de CBM-bus volledig op te geven, maar om het met minder hardwarekosten naar thuiscomputerniveau te brengen. Dat betekende: minder lijnen, lagere kosten, maar ook minder reserves. Die reductie was geen kleinigheid. Zij bepaalde het latere gedrag van het hele systeem.

De latere reputatie van de IEC-bus als „traag“ is daarom geen geïsoleerde fout van één enkel apparaat. Het is het resultaat van een fundamentele systeemkeuze: buskosten verlagen en de ontbrekende hardware-ondersteuning sterker verplaatsen naar software en periferielogica.

Lijnen en elektrische logica

Voor de dagelijkse standaardwerking van de seriële Commodore-bus zijn drie signaallijnen centraal: ATN, CLK en DATA. Daar komen uiteraard massa en de fysieke bekabeling zelf bij. In latere configuraties speelt bovendien SRQ een rol, vooral in de C128-/1571-context. Voor het begrip van de Standard-Serial-werking is echter in eerste instantie de drietalige groep voldoende.

• ATN (Attention): stuursignaal van de controller. Dient om de bus in een commando-context te zetten en adres- en beheerbytes over te dragen.
• CLK (Clock): klok- respectievelijk synchronisatielijn binnen de byte-overdracht.
• DATA: datalijn voor de eigenlijke bitoverdracht.

Elektrisch werkt de bus met actieve low-niveaus en Open-Collector- respectievelijk Wired-AND-logica. Praktisch betekent dat: een lijn is alleen dan werkelijk high wanneer niemand haar actief naar low trekt. Elke deelnemer kan haar dus dominant naar beneden trekken, maar niet actief omhoog sturen. Dat is traag vergeleken met agressievere driverlogica, maar wel robuust en conflictarm.

Juist deze terughoudende elektrische constructie verklaart een deel van de latere vertragingen: de bus is niet gebouwd als agressief getimede hogesnelheidsinterface. Het is een conservatieve, fouttolerante thuiscomputerinterface.

Rollen: Talker, Listener, Controller

De bus is logisch niet eenvoudigweg „computer zendt, drive ontvangt“. Hij kent rollen. Een deelnemer kan Controller, Talker of Listener zijn. De controller organiseert de bus, adresseert apparaten en stuurt het verloop. De talker verzendt data. Een of meer listeners ontvangen data.

Normaal gesproken is de thuiscomputer – bijvoorbeeld de C64 – eerst de controller. Hij zet ATN actief, adresseert het gewenste apparaat en bepaalt wie mag spreken en wie moet luisteren. Een drive zoals de 1541 wordt daarna op het juiste moment talker of listener, afhankelijk van of er gelezen of geschreven wordt.

TALK / LISTEN / secundaire adressen

Onder actief ATN worden geen gewone nuttige data overgedragen, maar commandobytes. Tot de belangrijkste behoren LISTEN, TALK, UNLISTEN en UNTALK. Die worden aangevuld met secundaire adressen, die binnen een apparaat onderscheid maken tussen kanalen, commandotypen of logische functies.

In de Commodore-wereld is dat niet abstract, maar zeer praktisch: apparaat 8 is typisch de eerste diskdrive. De controller kan dus „LISTEN 8“ sturen om deze drive als ontvanger aan te spreken, of „TALK 8“ om haar tot zender te maken. Pas daarna volgen de eigenlijke datafasen.

De bus is dus logisch gestructureerder dan de drie lijnen aanvankelijk doen vermoeden. Niet het aantal draden maakt hem primitief of complex, maar de vraag hoeveel toestandslogica via deze draden betrouwbaar kan worden getransporteerd.

Byte-overdracht en handshake

De eigenlijke byte-overdracht gebeurt bit voor bit. Juist dat is een van de redenen waarom de bus in standaardbedrijf traag blijft. Er wordt niet een volledig byte parallel over acht lijnen gelegd, maar ieder bit wordt via een handshake over CLK en DATA overgedragen.

In geabstraheerde vorm laat het verloop zich zo lezen: de zender bereidt het volgende bit voor, signaleert het geldige moment via de kloklijn, de ontvanger leest het bit en bevestigt de voortgang. Dat is logisch netjes, maar kost veel tijd – vooral wanneer beide kanten de signalen softwarematig bedienen en conservatieve wachttijden aanhouden.

Daarbij komen de byte-laag met extra wachttijden tussen bytes, beheerbits en speciale gevallen zoals End-of-Information. Ook al ziet de logica er eenvoudig uit, deze tijdsmarges stapelen zich op tot een duidelijk zichtbaar knelpunt.

Juist daarom lijken snelladers in terugblik zo spectaculair: niet omdat de standaardbus geheimzinnig was, maar omdat zijn conservatieve oorspronkelijke implementatie zoveel ruimte naar boven liet.

C64, CIA en 1541, VIA

Een punt dat vaak onnauwkeurig wordt verteld, moet helder worden gescheiden: aan de C64 hangt de seriële bus aan CIA #2 op $DD00. In de 1541 hangt hij aan de eerste VIA op $1800. Wie deze twee niveaus door elkaar haalt, vervaagt precies de plek waar veel praktische verschillen ontstaan.

Daar komt de interne architectuur van de apparaten zelf nog bij. De C64 moet de bus naast beeldopbouw, IRQ-logica en lopend programma bedienen. De 1541 is op haar beurt geen passieve drive, maar een eigen kleine computer met 6502, RAM, ROM en VIA-logica. Het busverkeer is dus communicatie tussen twee actieve systemen – niet alleen een datastroom uit een dom periferieapparaat.

Wie snelle seriële overdracht implementeert, moet daarom altijd beide kanten kennen: de computer en de drive. Eenzijdig optimaliseren is niet genoeg.

Waarom de C64-bus zo traag werd

De standaardbus was oorspronkelijk niet bedoeld als zo opvallend trage interface. De vertraging is het resultaat van meerdere factoren boven op elkaar. Ten eerste: seriële in plaats van parallelle overdracht. Ten tweede: conservatieve softwaregestuurde handshakes. Ten derde – en voor de C64 bijzonder belangrijk – de concurrentie door de videochip.

Bij de C64 stopt de VIC-II de CPU regelmatig voor geheugentoegang. Deze DMA-fasen zitten in het dagelijkse bedrijf voortdurend in de weg, vooral bij strak getimede I/O-routines. Daarom moesten de houdtijden van het seriële protocol ten opzichte van eerdere aannames worden verhoogd, zodat de computer bitvensters niet miste. Dat was functioneel verstandig, maar qua prestaties duur.

Daar komt de drivezijde nog bij: ook de 1541 verwerkt het busverkeer softwaregestuurd. Het resultaat is een keten van seriële bitoverdracht, voorzichtige wachttijden en beperkte CPU-middelen aan beide kanten. In de praktijk betekende dat zeer lage overdrachtsnelheden – precies de toestand waartegen de hele snelladercultuur later in opstand kwam.

De bus is niet traag omdat niemand het beter had gekund. Hij is traag omdat goedkope betrouwbaarheid hier voorrang kreeg boven snelheid.

C128 Fast Serial en Burst

De C128 voert later een versnelde seriële uitbreiding in die achterwaarts compatibel blijft met de standaardbus, maar met geschikte drives – vooral 1571 – duidelijk sneller kan werken. Belangrijk daarbij is de begripsmatige zuiverheid: Standard Serial en Fast Serial zijn niet hetzelfde. En Fast Serial is ook niet simpelweg een willekeurige latere snellader, maar een eigen compatibele uitbreiding binnen de C128-wereld.

Praktisch betekent dat: normaal Standard Serial blijft als gemeenschappelijke basis bestaan. Als beide partners de snellere variant beheersen, kan naar de versnelde methode worden omgeschakeld. Juist daarin verschilt deze uitbreiding van veel oplossingen van derden die kernal of drivecode doelgericht vervangen.

Voor een strikte technische indeling moet men daarom niet alles onder „IEC-bus, maar sneller“ samenvegen. Standard Serial, C128 Fast Serial, JiffyDOS en parallelkabels lossen vergelijkbare knelpunten op op verschillende manieren. Juist dat moet men uit elkaar houden.

Fast loaders en kernal-vervanging

Snelladers pakken het knelpunt daar aan waar het praktisch zichtbaar wordt: in de trage oorspronkelijke implementatie van de standaardbus. Dat kan op meerdere niveaus gebeuren. Sommige oplossingen vervangen of vullen computer- en driveroutines in RAM aan. Andere zetten in op kernal-vervanging, dus op blijvend gewijzigde ROM-logica in computer, drive of beide.

• Software-snelladers: laden eigen code na en optimaliseren het protocol tijdens runtime.
• Kernal-vervanging: bijvoorbeeld JiffyDOS of bepaalde DOS-uitbreidingen – veranderen de standaardroutines systematisch en blijvend.
• Gecombineerde oplossingen: computer- en drivezijde worden gezamenlijk geoptimaliseerd.

Het punt daarbij is niet mystiek, maar reductie van overhead. Als wachttijden worden verkort, handshakes worden afgeslankt of byte-overdrachten opnieuw worden georganiseerd, stijgt de snelheid meteen. Juist daarom was de standaardbus altijd ook een uitnodiging tot optimalisatie.

Belangrijk is ook hier de scheiding van begrippen: niet elke snelle oplossing is een parallelkabelsysteem. Niet elke cartridge staat gelijk aan een busombouw. En niet elke ROM-oplossing is hetzelfde als C128 Fast Serial.

Parallelkabelsystemen

Parallelkabels kiezen de consequentste weg: zij proberen niet alleen het seriële standaardprotocol te versmallen, maar omzeilen de belangrijkste begrenzing direct. In plaats van bits achter elkaar door de standaardbus te sturen, wordt een extra parallel datapad gecreëerd – typisch via de user port van de computer en overeenkomstige hardwareaanpassingen aan de drivezijde.

Technisch is dat zuiver: als het knelpunt de seriële één-bit-overdracht is, dan verwijdert een parallel extra kanaal precies dat knelpunt. De prijs ligt voor de hand: extra hardware, ombouw, minder universaliteit en een sterkere binding aan een concrete apparaatcombinatie.

Typische systemen op dit gebied zijn verschillende DOS-uitbreidingen met parallelkabel-ondersteuning. Dat is een andere categorie dan zuivere kernal-versnellers en opnieuw iets anders dan de standaardcompatibele Fast-Serial-wereld van de C128.

Parallelkabels zijn het nuchtere antwoord op een nuchter probleem: als serieel de flessenhals is, helpt parallel.

Wat de IEC-bus technisch leert

De IEC-bus is een goed voorbeeld van hoe sterk een ogenschijnlijk kleine hardwarebeslissing het gebruik van een platform kan vormen. Drie signaallijnen in plaats van een parallelle bus klinken als een detail. In de praktijk ontstaan daaruit laadtijden, drivecultuur, snelladers, ombouw, ROM-wissels en een hele voorraad technische kennis die zonder dit knelpunt nooit in deze vorm zou zijn ontstaan.

Tegelijk is de bus geen chaos. Integendeel: zijn logica is zuiver, zijn rolverdeling helder en zijn elektrische constructie verstandig. Juist daarom is hij zo geschikt als leervoorbeeld. Hij laat zien dat systemen niet interessant worden doordat ze perfect zijn, maar doordat men hun grenzen precies kan lezen.

Voor mij hoort de IEC-bus daarom niet alleen bij de drivegeschiedenis, maar bij de algemene school van het technische denken. Hij laat zien hoe architectuur, kosten, timing en praktisch gebruik in elkaar grijpen – en waarom men aan één enkele interface vaak meer over een systeem leert dan aan honderd algemene beschrijvingen.