c64

MOS 6510 – niet alleen een 6502

De MOS 6510 is geen pure 6502. Het zichtbare verschil: hij heeft een geïntegreerde 8-bit-I/O-poort, direct op de chip, bereikbaar via de adressen $0000 (data direction register) en $0001 (datawoord). Dat klinkt als een detail. Dat is het niet.

Via deze poort stuurt de C64 de bankschakeling van het volledige geheugensysteem. Bits 0, 1 en 2 van $0001 bepalen welke combinatie van ROM, RAM en I/O in de adresruimte zichtbaar is. Daarnaast stuurt bit 3 de schrijfbeveiliging van de datasette en bit 4 de motor. Dat betekent: wie in $0001 schrijft, verandert niet alleen de geheugenindeling, maar grijpt tegelijk in een deel van de aangesloten hardware in.

De 6510 loopt in de PAL-C64 op iets minder dan 1 MHz, nauwkeuriger op 0,985 MHz. Dat komt doordat hij synchroon loopt met de VIC-II, die de systeemklok bepaalt. En deze klok hangt op zijn beurt samen met de beeldopbouw. Alleen daaraan zie je al: op de C64 is de CPU niet gescheiden van de weergave.

De belangrijkste consequentie: in de C64 bestaat er geen ROM waar geen RAM achter ligt. Het onderliggende RAM is altijd aanwezig en beschrijfbaar – het is alleen afgedekt. Schakel je het ROM uit, dan wordt dit RAM zichtbaar. Precies daarop berusten veel geavanceerde technieken.

Zero Page en stack

De eerste 256 bytes van de adresruimte – de Zero Page ($0000–$00FF) – hebben bij de 6502/6510 een bijzondere status. Veel instructies kunnen Zero-Page-adressen met slechts één byte coderen in plaats van twee, wat kortere en snellere instructies oplevert. KERNAL en BASIC gebruiken daarbij al een groot deel van deze adressen. Wie in machinetaal werkt, merkt daarom snel dat goede Zero-Page-kennis geen comfort is, maar snelheid.

De stack ligt bij $0100–$01FF en is 256 bytes groot. Dat lijkt op het eerste gezicht voldoende, maar is het niet in elke situatie. Diep geneste subroutines, interrupt-routines en onvoorzichtige register-save-operaties kunnen hem snel aan zijn grens brengen. Stack-problemen op de C64 melden zich zelden netjes. Meestal merk je alleen dat een programma op enig moment niet meer doet wat het zou moeten doen.

Geheugenmodel en bankschakeling

De 64 KB van de C64 zijn niet allemaal tegelijk vrij bruikbaar. De adresruimte is verdeeld tussen RAM, ROM-inblendingen en I/O-bereiken, en wat daarvan zichtbaar is, hangt af van de configuratie in $0001. Dat is het basisprincipe van het C64-geheugenmodel: fysiek 64 KB RAM, daaroverheen gelegd ROM en I/O.

Het I/O-bereik bij $D000–$DFFF is bijzonder interessant. Daar liggen de registers van alle belangrijke chips: VIC-II vanaf $D000, SID vanaf $D400, Color-RAM vanaf $D800, CIA1 vanaf $DC00, CIA2 vanaf $DD00. Dit gebied kan echter ook worden omgeschakeld naar het teken-ROM – wat het uitlezen van de ingebouwde tekenset mogelijk maakt – of naar het onderliggende RAM.

VIC-II en geheugengebieden

Nog een belangrijk punt: de VIC-II ziet de adresruimte niet zoals de CPU die ziet. Hij werkt met 16-kB-banken, waarvan er vier zijn. CIA2 stuurt welke van deze banken de VIC-II op dat moment ziet. Standaard is dat bank 0 ($0000–$3FFF).

Binnen deze 16-kB-bank wijst de VIC-II naar bitmapdata, scherm-RAM en tekenset. Dat betekent: wie de VIC-II naar een andere bank schakelt, kan beelddata in een gebied houden dat voor de CPU anders is georganiseerd. Precies daaruit ontstaan double-buffering- en scrolltechnieken.

VIC-II – hoe hij werkelijk werkt

De MOS 6569 (PAL) – kortweg VIC-II – is het hart van de C64. Hij genereert niet alleen het beeld, hij bepaalt ook de timing van het volledige systeem. Wie de VIC-II begrijpt, begrijpt de C64.

De VIC-II genereert het beeld door regel voor regel een rasterstraal te simuleren – net zoals een op een beeldbuis gebaseerd scherm dat werkelijk doet. De PAL-C64 heeft in totaal 312 rasterlijnen, waarvan 200 het zichtbare hoofdgebied vormen. Terwijl de rasterstraal een regel doorloopt, leest de VIC-II data uit het RAM. Precies daar begint het interessante samenspel met de CPU.

Badlines – wanneer de VIC-II de CPU afremt

Om de 8 rasterlijnen moet de VIC-II nieuwe tekencodes uit het scherm-RAM lezen. In deze lijnen – de zogenaamde badlines – houdt hij de CPU 40 tot 43 klokcycli tegen en gebruikt de bus alleen zelf. Dat gebeurt automatisch, telkens wanneer de onderste drie bits van de actuele rasterlijn overeenkomen met de onderste drie bits van het Y-scrollregister ($D011, bits 0–2).

Deze CPU-rem is regelmatig en voorspelbaar. Wie tijdkritische code schrijft – bijvoorbeeld voor stabiele raster-interrupts – moet badlines incalculeren. En wie het Y-scrollregister verandert, verschuift daarmee ook het badline-patroon. Dat wordt bewust benut: bijvoorbeeld voor FLD-effecten of andere verticale timingtrucs.

Grafische modi

Color-RAM – de bijzondere eigenschap

Het Color-RAM bij $D800–$DBFF is geen normaal RAM. Het is een aparte 4-bit-RAM-chip die altijd zichtbaar blijft – onafhankelijk van de bankschakeling. Dat heeft gevolgen: je kunt het niet zomaar verplaatsen of uitblenden. Wie de VIC-II-tekenmodus gebruikt, werkt met deze vaste kleurtoewijzing per tekenblok.

Rasterstraal-trucs

De VIC-II kan een interrupt genereren wanneer de rasterstraal een bepaalde lijn bereikt. Dat is de basis van een groot deel van wat de C64 visueel onderscheidt van andere computers uit zijn tijd.

De rasterlijn voor een interrupt wordt via $D012 geconfigureerd, samen met bit 7 van $D011. Wanneer de rasterstraal deze positie bereikt, zet de VIC-II een interrupt-flag en springt de CPU naar een service-routine. Daar kunnen VIC-II-registers in exact gedefinieerde beeldfasen worden veranderd.

Stabiele raster-IRQ

Het probleem: het moment waarop een IRQ werkelijk actief wordt, varieert licht – afhankelijk van welke CPU-instructie het systeem juist uitvoert. Voor grove effecten is dat onbelangrijk. Voor pixelnauwkeurige wissels niet.

De oplossing is de double-IRQ-truc. De eerste IRQ vangt de onscherpte op, de tweede werkt op een stabielere positie. Zo bereik je een timing die voor horizontale kleurgrenzen, splits of andere gevoelige effecten voldoende rustig is.

• Kleur-split Achtergrondkleur of randkleur wordt in een raster-routine veranderd. Zo ontstaan meerdere horizontale zones, hoewel het systeem officieel slechts enkele globale kleurregisters biedt.
• Horizontale scrolling-split Via $D016 kan een deel van het beeld scrollen terwijl een ander deel statisch blijft – klassieke opdeling tussen speelveld en statusgebied.
• FLD – Flexible Line Distance Door gericht naar $D011 te schrijven vlak voor de juiste rasterlijnen, kan dezelfde beeldinhoud meerdere keren worden weergegeven. Dat rekt gebieden verticaal op zonder beelddata in het geheugen zelf te verplaatsen.
• FLI – Flexible Line Interpretation In de bitmapmodus wordt per rasterlijn een andere kleurtabel ondergeschoven. Daardoor stijgt de kleurresolutie duidelijk – ten koste van aanzienlijke CPU-tijd en typische neveneffecten.
• DYCP – Different Y Character Positions Door herhaalde Y-scrollmanipulaties ontstaan golfvormig bewegende tekstregels. Dat is minder decoratief interessant dan technisch: het toont hoe sterk de weergave van exacte rastertiming afhangt.

“De rasterstraal is geen grafisch detail, maar een timingvraag. Wie dat begrepen heeft, ziet de VIC-II anders.”

Sprites en multiplex

De VIC-II ondersteunt 8 hardware-sprites tegelijk. Elke sprite is 24×21 pixels groot, kan horizontaal of verticaal verdubbeld worden, heeft een eigen positie en een eigen kleur. Dat is voor games en bewegende objecten een aanzienlijk voordeel tegenover puur softwaregetekende grafiek.

Acht sprites voor een volledig speelveld zijn echter weinig. De oplossing is sprite-multiplex. Daarbij wordt een spritekanaal opnieuw gepositioneerd nadat de rasterstraal zijn vorige positie gepasseerd is. Daardoor verschijnt dezelfde hardware-sprite in hetzelfde beeld op meerdere plaatsen.

Hoe multiplex werkt

Voor elk opnieuw gebruikt spritekanaal wordt een raster-IRQ op een passende Y-positie gezet. In deze IRQ worden nieuwe spritedata, nieuwe pointers en nieuwe coördinaten geschreven. Dat werkt alleen wanneer de timing klopt en er voldoende CPU-tijd vrij blijft.

De harde grens blijft: per rasterlijn kunnen maximaal 8 sprites tegelijk worden weergegeven. Multiplex verhoogt dus niet het aantal per lijn, maar alleen het totale aantal in het beeld.

Sprite-prioriteit en botsingsdetectie

De VIC-II heeft hardwarematige botsingsdetectie: een register voor sprite-tegen-sprite-botsingen en een register voor sprite-tegen-achtergrond-botsingen. Dat vereenvoudigt eenvoudige controles aanzienlijk. Voor precieze gamefysica is het op zichzelf niet voldoende, maar als hardwarehint is het nuttig.

Open Border – het kader openbreken

Het C64-scherm heeft een zichtbare rand, de border. Officieel hoort dit gebied niet bij het bruikbare beeld. In de praktijk kan het worden gemanipuleerd.

Onderste en bovenste rand – verticale open border

De VIC-II zet de border aan boven- en onderrand afhankelijk van een interne status. Deze status kan worden beïnvloed door op het juiste moment het display-enable-bit in $D011 kort uit te schakelen en weer in te schakelen. Het resultaat is verticale open border: het normaal verborgen gebied kan voor extra weergave gebruikt worden.

Zijrand – horizontale open border

Op vergelijkbare wijze werkt de horizontale open border via $D016. De timing is krapper, de truc gevoeliger. Als hij lukt, kunnen ook de zijranden zichtbaar worden gebruikt.

Beide varianten samen maken zichtbaar dat het ogenschijnlijk vaste schermkader in werkelijkheid eveneens het resultaat is van interne toestandslogica – en dus principieel veranderbaar.

SID – wat de chip werkelijk kan

De MOS 6581 (later: MOS 8580) is een van de ongewoonste soundchips van zijn tijd. Hij heeft drie stemmen, elk met eigen golfvormsturing, envelope, frequentie- en pulsbreedteregeling. Daarnaast is er een analoog filter, dat het karakter van de chip wezenlijk bepaalt.

De SID is echter niet alleen interessant vanwege zijn gedocumenteerde functies. Veel van wat hem in de praktijk bijzonder maakte, ligt juist in die gebieden die pas door nauwkeurig experimenteren of door langdurig luisteren werkelijk begrepen werden.

Ringmodulatie en sync

Twee geavanceerde modulatiemodi zijn bijzonder belangrijk: ringmodulatie en oscillator-sync. Beide produceren klankkarakters die met eenvoudige basisgolven alleen niet te bereiken zijn. Juist daardoor wordt de SID meer dan een standaard driekanaals chip.

Gecombineerde golfvormen

Gedocumenteerd zijn vier afzonderlijke golfvormen. In de praktijk kunnen echter meerdere golfvormbits tegelijk gezet worden. Het resultaat zijn gecombineerde klanken die zich niet alleen uit het handboek laten verklaren. Veel typische SID-klankkleuren berusten precies op deze manier van gebruik.

De Voice-3-truc

De derde SID-stem kan uit de hoorbare mix worden verwijderd en toch verder blijven lopen. Haar toestand blijft uitleesbaar. Daarmee kan zij in de ruismodus als eenvoudige bron voor pseudo-toevalswaarden worden gebruikt – een bekend en nuttig neveneffect van de architectuur.

SID 6581 vs. 8580 – niet hetzelfde

De oudere 6581 en de nieuwere 8580 klinken merkbaar verschillend. De 6581 is ruwer en onpreciezer, de 8580 schoner en gecontroleerder. Veel composities en trucs zijn daarom niet volledig uitwisselbaar tussen beide chips.

SID als ADC – analoge ingang

Via POTX en POTY heeft de SID bovendien twee analoge ingangen, oorspronkelijk bedoeld voor paddle-controllers. Ook dat toont dat de chip niet alleen tot pure klanksynthese beperkt is, maar op meerdere plaatsen verder reikt dan zijn voor de hand liggende doel.

CIA – timers, interrupts en wat daar nog meer aan hangt

De C64 heeft twee MOS 6526 CIA-chips. CIA1 zit op $DC00, CIA2 op $DD00. Elke CIA bezit twee 16-bit-timers, twee 8-bit-I/O-poorten, een kloklogica en een serieel shiftregister.

CIA1 verzorgt in standaardbedrijf vooral toetsenbordscanning, joystickpoort 2 en de normale KERNAL-tijdbasis. CIA2 stuurt onder meer de seriële IEC-bus en de VIC-II-bankschakeling. Daarmee behoren beide CIA’s tot de chips die in het dagelijks gebruik gemakkelijk over het hoofd worden gezien, maar voor de totale werking onmisbaar zijn.

Timer-interrupts en NMI

CIA1 hangt aan de normale IRQ, CIA2 aan de NMI. Dat is een aanzienlijk verschil. Een NMI laat zich niet eenvoudig met SEI onderdrukken. Wie CIA2 gebruikt, grijpt dus duidelijk dieper in het systeemgedrag in.

Toetsenbordmatrix

Het toetsenbord is als 8×8-matrix georganiseerd en wordt via CIA1 uitgelezen. Daaruit volgt de bekende ghost-key-problematiek: bepaalde toetscombinaties beïnvloeden elkaar wederzijds. Wie eigen uitleesroutines schrijft, moet deze matrixlogica zelf netjes meenemen.

De 1541 en haar problemen

De Commodore 1541 is in zekere zin een computer op zich. Zij bevat een eigen MOS 6502-CPU, RAM, ROM en twee MOS 6522 VIA-chips. De drive is dus geen passief randapparaat, maar een zelfstandig systeem met eigen werking.

Dit ontwerp heeft voordelen, maar ook de beroemdste zwakte van de hele C64-wereld: de trage standaardcommunicatie via de seriële IEC-bus.

Het serial-bus-probleem

Bij de C64 werd de seriële aansluiting vergeleken met oudere Commodore-systemen sterk vereenvoudigd. De prijs daarvoor was snelheid. Waar duidelijk meer mogelijk geweest was, bleef in de praktijk vaak slechts ongeveer 300–400 bytes/s over.

Dat is de eigenlijke reden waarom fast loaders op de C64 zo belangrijk werden. Het probleem lag niet bij afzonderlijke programma’s, maar diep in het officiële overdrachtspad.

Waarom de 1541 toch interessant is

De 1541 gebruikt GCR (Group Code Recording) en vier verschillende snelheidszones om op verschillende spoorgebieden een zinvolle datadichtheid te bereiken. Technisch is dat doordachter dan de reputatie van de drive doet vermoeden.

De directory ligt op spoor 18, net als de BAM (Block Availability Map). Alleen daaraan zie je al: ook het DOS van de 1541 is geen bijzaak, maar een technische ruimte waarin veel te begrijpen en te manipuleren valt.

Fast loaders – hoe en waarom

Het voor de hand liggende antwoord op de trage standaardcommunicatie van de 1541 was: een eigen laadprotocol. Precies dat is de fast loader.

Een fast loader bestaat uit twee delen: een routine op de C64 en een routine die in het RAM van de 1541 wordt geladen. Vanaf dat moment werkt de drive niet meer met haar normale protocol, maar met een eigen geoptimaliseerd protocol.

Burst-overdracht en parallel-aansluiting

Zuiver softwarematige fast loaders halen meestal 1,5 tot 4 KB/s. Met extra parallel-aansluiting – dus een directe verbinding tussen C64-user-port en 1541-hardware – zijn duidelijk hogere snelheden mogelijk. Dan kom je dichter in de buurt van de fysieke grenzen van de drive.

• 1541-RAM gebruiken De loader-code wordt in het RAM van de 1541 geschreven en daar uitgevoerd. Pas daardoor krijgt de drive zelf genoeg eigen logica voor snellere overdrachtswegen.
• Eigen protocol in plaats van KERNAL-pad De standaardweg wordt omzeild. Clock- en data-lijnen worden met strakkere timing gebruikt dan de officiële routine voorziet.
• KERNAL-bypass Veel loaders buigen laadvectoren om of vervangen KERNAL-diensten direct om de standaardweg volledig te vermijden.

“Een fast loader was geen spielerei. Hij was het nuchter juiste antwoord op een onnodig trage standaardweg.”

Disketten perforeren en andere drive-trucs

Een 5,25-inch-diskette heeft twee fysieke zijden. De 1541 gebruikt standaard slechts één daarvan. De andere blijft ongebruikt – tenzij men daar iets aan verandert.

Het perforeren

De oplossing was direct: aan de achterkant werd op de juiste plaats een tweede schrijfbeveiligingsinkeping aangebracht. Daarna kon de diskette omgedraaid opnieuw worden gebruikt. Dat is geen magie, maar een eenvoudige mechanische reactie op een eenvoudige mechanische blokkering.

Meer drive-trucs

• Half-spoor-toegang Via de fijne koppositionering kunnen halve stappen worden aangestuurd. Dat werd vooral voor kopieerbeveiliging en speciale formaten gebruikt.
• Spoor 36 en verder Officieel eindigt de diskette bij spoor 35. In de praktijk kunnen vaak verdere sporen gebruikt worden – met afnemende betrouwbaarheid.
• Directory-manipulatie De directory is direct sectorgewijs toegankelijk. Ingangen kunnen verborgen, veranderd of hersteld worden.
• BAM direct beschrijven Wie de Block Availability Map direct verandert, grijpt rechtstreeks in de bestandssysteemlogica van de drive in.

Machinetaal-technieken

BASIC op de C64 is voor veel taken te traag. Wie raster stabiel wilde houden, sprites netjes wilde multiplexen of snelle gamelogica wilde bouwen, belandde onvermijdelijk in machinetaal.

• Zelfveranderende code Operanden worden tijdens runtime aangepast om adresberekeningen te besparen. Dat is niet mooi, maar snel.
• Unrolled loops Lussen worden uitgeschreven om teller- en sprongoverhead te vermijden. Tijd wordt tegen ruimte geruild.
• Tabellen in plaats van berekening Sinus-, vermenigvuldigings- of andere waarden worden voorbereid opgeslagen. Rekentijd wordt tegen geheugen geruild.
• Zero-Page-gebruik maximaliseren Wie de Zero Page goed kent, schrijft kortere en snellere code.
• Interrupt-latentie kennen Wie IRQ’s wil gebruiken, moet weten wat er tussen trigger en werkelijke routine gebeurt.
• Stack als tijdelijke opslag In nauwe speciale gevallen kan ook de stack zelf anders gebruikt worden dan alleen voor return-adressen.
• PAL/NTSC onderscheiden Timing-code is nooit volledig platformneutraal zolang het systeem in verschillende videostandaarden bestaat.

Wat de C64 heeft geleerd

Wanneer ik op de C64 terugkijk, dan niet in de eerste plaats met nostalgie, maar met de vraag wat van deze werkhouding is overgebleven. Het antwoord is: nogal wat. Niet als registerkennis, maar als manier van denken.

De C64 leerde vooral dat grenzen geen storing hoeven te zijn, maar deel van de architectuur. Wie het systeem serieus neemt, leert niet alleen wat officieel voorzien is, maar ook wat daadwerkelijk gebeurt – op de bus, in de timing, in het geheugen, in het samenspel van de chips.

Precies deze manier van vragen blijft nuttig: niet bij de eerste voor de hand liggende verklaring blijven staan, maar eronder kijken. Waarom is iets traag? Waarom breekt iets juist op deze plek? Welke systeemeigenschap zit daarachter? De C64 heeft deze manier van kijken aangescherpt.

De C64 laat bovendien iets zien dat ver boven zijn eigen tijd uitgaat: goede techniek ontstaat niet automatisch uit veel middelen. Ze ontstaat vaak uit nauwkeurige kennis van wat er al is.

Ook daarom blijft de C64 voor mij niet als cultobject interessant, maar als een systeem waaraan heel duidelijk geleerd kon worden hoeveel uit een architectuur te halen is wanneer men haar werkelijk begrijpt.

“Aan de C64 leerde men vroeg dat grenzen geen storing hoeven te zijn, maar deel van de architectuur.”