8-bit computers emuleren in 2026: de complete beginnersgids

• Emuleren is de snelste manier om 8-bit computers veilig te verkennen: geen zeldzame onderdelen nodig, wel directe toegang tot klassieke besturingssystemen, games en programmeeromgevingen.
• De keuze in 2026 draait vooral om nauwkeurigheid (cycle-accurate) versus gemak (plug-and-play), plus goede invoeropties voor toetsenbord, joystick en opslag.
• Een goede beginnersgids begint bij het begrijpen van bus, klok, registers en geheugen; dat maakt instellingen zoals “CPU speed”, “frameskip” en “disk timing” ineens logisch.
• Retro gaming werkt het fijnst met lage input-latency, correcte framerates en passende video-output (CRT-shaders of integer scaling), niet met “sneller is beter”.
• Voor digitaal archiefwerk tellen reproduceerbaarheid, ROM-herkomst, checksums en metadata even zwaar als de emulator zelf.
• Van assembly tot BASIC: programmeren op 8-bit computers is een les in beperkingen, en juist die beperkingen maken het leerzaam en verslavend.

8-bit computers emuleren is in 2026 geen nichetruc meer voor ingewijden, maar een praktische manier om een hele generatie computers, software en spelcultuur opnieuw te ervaren. Emulatie brengt systemen als de Commodore 64, ZX Spectrum, MSX, Amstrad CPC, Atari 8-bit en vroege Apple-varianten naar laptops, mini-pc’s en zelfs telefoons, met een precisie die vaak hoger ligt dan wat veel oude machines na decennia nog stabiel halen. Voor retro gaming betekent dat: klassiekers starten zonder contactproblemen in cartridges, zonder uitgedroogde condensatoren en zonder de jacht op een werkende CRT.

Tegelijk speelt er meer dan nostalgie. Wie digitaal erfgoed wil bewaren, wil reproduceerbare resultaten: dezelfde ROM, dezelfde instellingen, dezelfde timing en dezelfde output. Emuleren raakt daardoor aan archivering, auteursrecht, metadata en de vraag hoe “authentiek” een ervaring moet zijn. Een beginnersgids die echt helpt, maakt die keuzes concreet: welke emulator past bij snel spelen, welke bij leren programmeren, en welke bij onderzoek waarbij details zoals disk-timing of randkleuren ertoe doen. Het loont om het onderwerp te benaderen alsof elke emulator een meetinstrument is: soms is een handmeter genoeg, soms is een oscilloscoop nodig.

8-bit computers emuleren in 2026: de juiste aanpak voor beginners

De dominante vraag achter “8-bit computers emuleren” is informationeel: hoe werkt het, welke keuzes zijn verstandig, en hoe voorkomt iemand frustratie met instellingen die vaag klinken. Een bruikbaar startpunt is het onderscheid tussen “machine” en “ervaring”. De machine is de historische computer met zijn CPU, geheugen en I/O. De ervaring is wat u wilt doen: retro gaming, oude software testen, of programmeren. De emulator is de brug, en die brug kan breed (gebruiksvriendelijk) of uiterst precies (hardware-getrouw) zijn.

Beginners lopen vaak vast op twee misverstanden. Het eerste: “Een emulator is gewoon een programma dat alles automatisch goed doet.” In praktijk moet de timing kloppen, zeker bij systemen waar veel software trucjes gebruikt: rasterinterrupts, cycle-stealing en zelfmodificerende code. Het tweede: “Sneller is beter.” Veel 8-bit software is geschreven voor een vaste snelheid; versnellen kan animatie, muziek of input-gevoel breken. Daarom is het zinvoller om te sturen op correcte framerate en lage latency dan op maximale FPS.

Vergelijking: nauwkeurigheid, gebruiksgemak en platform

In 2026 is de emulator-keuze groot, maar drie assen blijven leidend: nauwkeurigheid (hoe goed wordt hardware gesimuleerd), ergonomie (menu’s, presets, controllers) en platform (Windows/macOS/Linux, maar ook web of handheld). Wie vooral wil spelen, kiest vaak een emulator met goede profielen per game en makkelijke mapping voor controllers. Wie wil analyseren of bewaren, zoekt logging, savestates met metadata en deterministische run-modi.

Doel	Waarop letten	Handige functies	Valkuil
Retro gaming	Input-latency, correcte framerate, controller-mapping	CRT-shaders, integer scaling, snelle savestates	Te agressieve “speed hacks”
Programmeren leren	Debugger, memory viewer, monitor/assembler	Breakpoints, disassembler, symbolen	Onbegrepen ROM-versies
Archief & onderzoek	Reproduceerbaarheid, checksums, logging	Deterministic mode, input recording, metadata export	Onvolledige bronvermelding
Hardware-nabootsing	Cycle-accurate gedrag, bus- en disk-timing	Periferiemodellen, exacte videochip-emulatie	Meer configuratie dan u verwacht

Een praktisch voorbeeld: een verzamelaar wil een oude demo die afhankelijk is van exacte rastertiming. Een “snelle” emulator kan de demo laten lopen, maar met verkeerde borders of haperende muziek. Een precieze emulator kost dan meer afstelling, maar levert het beeld op dat destijds de norm was. Die keuze bepaalt of emuleren voelt als “een spelletje starten” of als “een historisch systeem reproduceren”.

In het verlengde daarvan ligt de volgende stap: begrijpen welke onderdelen van 8-bit hardware emulators nadoen, zodat instellingen geen zwarte magie blijven.

Hoe emulators 8-bit hardware nabootsen: bus, klok, registers en geheugen

Wie de basis van hardware begrijpt, leest emulator-instellingen ineens als een bedieningspaneel in plaats van als een doolhof. Een 8-bit systeem heet “8-bit” omdat de databus typisch 8 bits breed is: er gaat per stap één byte over de lijn. Dat zegt minder over de instructiebreedte; sommige ontwerpen gebruiken bredere instructiewoorden om decodeerlogica eenvoudiger te maken. Dat principe duikt ook op in hobbyprojecten met TTL-logica, waar 24-bit instructies soms juist gekozen worden om minder complexe decoding te hoeven bouwen.

Emulators modelleren minstens vier kernonderdelen: de CPU (bijvoorbeeld 6502, Z80 of 6809), geheugen (RAM/ROM), de videochip en input/output (toetsenbord, joystick, opslag). Daarbovenop komen timingdetails: hoe een klokcyclus is opgebouwd, hoe busconflicten werken, en wanneer registers precies “latchen”. Het is precies daar dat het verschil ontstaat tussen “werkt meestal” en “werkt zoals vroeger”.

Klok en timing: waarom “cycle-accurate” meer is dan marketing

Een instructie op een 8-bit CPU bestaat uit microstappen. In zelfbouw-architecturen wordt zo’n cyclus soms expliciet in vier fases verdeeld, waarbij in elke fase andere modules actief zijn. Dat idee helpt om emulatie te begrijpen: een emulator die alleen op instructieniveau rekent, kan uitkomsten kloppend maken maar toch timingfouten introduceren. Games en demo’s die op de scanline precies een kleurregister veranderen, vragen om een nauwkeurige planning van die microstappen.

Timingproblemen lijken soms op “bugs in de emulator”, maar komen vaak door instellingen. Een voorbeeld: de ingestelde CPU-snelheid wijkt af, of de audio-buffer is te groot waardoor input-latency oploopt. Bij retro gaming voelt dat als “stroperig”, zeker bij snelle platformers. Voor onderzoek is het nog vervelender: een opname van een bug is dan niet reproduceerbaar.

Registers, latches en het nut van een buffer

In eenvoudige 8-bit ontwerpen zijn registers plaatsen waar tijdelijke waarden staan. Veel emulators tonen registers live in een debugvenster. Dat is meer dan een leuke gimmick: u ziet letterlijk waarom een programma vastloopt of waarom een sprong (JMP) naar een verkeerd adres gaat. Hardwarematig bestaat er een belangrijk verschil tussen level-triggered latches en edge-triggered flip-flops. Latches kunnen “meeschrijven” terwijl een signaal hoog is; dat kan bij bepaalde combinaties tot ongewenste feedback leiden. Een bekende oplossing is een master-slave opzet of een gedeelde buffer waarin eerst een waarde wordt klaargezet en pas later wordt doorgezet naar het doelregister.

Die gedachte verklaart ook emulatorfeatures zoals “single step”, “step over” en “break on write”. Daarmee wordt de virtuele klok als het ware met de hand bediend. Voor beginners is dat dé manier om programmeren te leren zonder te verdrinken: stap één instructie, kijk wat er in registers gebeurt, en herhaal. Als die basis staat, wordt opslag emuleren de volgende horde: tapes, disks, cartridges en flash-varianten.

Voor wie dit liever visueel leert dan lezend: er bestaan heldere videoreeksen over 8-bit architectuur met breadboards, bussen en registers, die de vertaalslag naar emulators vergemakkelijken.

Met die hardwarelogica in het achterhoofd kan de focus verschuiven naar het praktische werk: software starten, media laden en instellingen kiezen die niet tegenwerken.

Software, ROM’s en media laden: van disk-images tot web-emulatie

Emuleren draait uiteindelijk om software: ROM’s (firmware), disk-images, tape-images en soms cartridges. Beginners hebben meestal één doel: een game of programma starten. Voor archiefwerk is de vraag strikter: welk exact bestand is gebruikt, waar kwam het vandaan, en is het intact? Daarom is het verstandig om met checksums (bijvoorbeeld SHA-256) en heldere mappenstructuur te werken, zeker als meerdere versies van dezelfde titel circuleren.

Een nuttig uitgangspunt is het onderscheid tussen systeem-ROM en applicatie-media. De systeem-ROM bevat de basiscode van de computer (bijvoorbeeld BASIC of een kernel). De applicatie-media is wat u “laadt”: een spel op disk of tape, of een executable. Niet elke emulator levert ROM’s mee, en dat is vaak bewust: distributierechten verschillen per platform. Daardoor is een beginnersgids pas compleet als ook de herkomst en juridische context worden benoemd, zonder grijze downloads te romantiseren.

Een praktisch laadpad dat frustratie voorkomt

Stel een fictieve casus: Noor, een student die onderzoek doet naar vroege spelvertalingen, wil dezelfde titel in drie landen vergelijken. Op dag één werkt alles, op dag twee ineens niet. De oorzaak is vaak banaal: per ongeluk een andere ROM-versie geselecteerd, of een emulator die automatisch “sneller” ging draaien omdat VSync uit stond. Een robuuste workflow helpt:

1. Kies één emulator per platform en noteer de versie.
2. Maak een map per systeem: ROM, media, saves, screenshots, logs.
3. Leg checksums vast van ROM’s en images, plus een korte bronnotitie.
4. Gebruik vaste video-instellingen: integer scaling en VSync aan.
5. Sla een configuratieprofiel op per project of per game.

Voor retro gaming is stap vier cruciaal. Bij een 50 Hz-systeem (veel Europese micro’s) voelt een 60 Hz-output net verkeerd genoeg om muziek en timing te veranderen. Andersom kan een 60 Hz-systeem dat op 50 Hz wordt gedwongen plots “traag” aanvoelen. Emulators hebben vaak presets, maar een beginner die begrijpt waarom 50/60 Hz ertoe doet, stelt sneller correct af.

Programma’s schrijven en laden: assembler, monitor en toolchain

Veel 8-bit computers nodigen uit tot programmeren, al is de route verschillend. Sommige systemen starten in BASIC, andere vragen om een monitorprogramma of assembler. Moderne tooling maakt het makkelijker: u schrijft code in een editor, assembleert op de host, en laadt in de emulator. In hobby-architecturen wordt soms een eigen assembler gebruikt (bijvoorbeeld in Go) die assembly omzet naar machinecode, waarna een flash- of laadroutine het programma in “program memory” zet. Dat concept is verrassend relevant voor emulatie: een emulator kan hetzelfde doen via een “inject binary” of een virtueel disk-image met het resultaat van uw build.

Hier raakt software direct aan hardware: een eenvoudige instructieset kan expres breder zijn (bijvoorbeeld 24-bit) om decodeerlogica eenvoudiger te maken. In emulators ziet u dat terug als “custom CPU cores” of “homebrew systems”, waar de data-bus 8-bit is maar instructies meer ruimte innemen. Dat is geen tegenspraak; het is een ontwerpkeuze.

De stap hierna is het finetunen van de ervaring: beeld, geluid, controllers en latency. Dat is waar retro gaming voor beginners vaak gewonnen of verloren wordt.

Als het laden betrouwbaar werkt, komt de vraag op hoe een moderne setup “oud” kan aanvoelen zonder kunstmatige filters die de leesbaarheid verpesten.

Retro gaming goed afstellen: latency, video, audio en controllers

Retro gaming op 8-bit computers is minder “plug-and-play” dan moderne games, maar het is ook niet ingewikkeld als u de volgorde goed kiest. Eerst komt input: toetsenbord en joystick. Daarna beeld: resolutie, schaling, framerate. Pas dan audio: buffers en synchronisatie. Veel beginners doen het andersom en zetten een CRT-filter aan, terwijl de echte oorzaak van “het speelt niet lekker” in de controller-instellingen zit.

Latency is de stille spelbreker. Elke stap telt: USB-polling, OS-latency, emulator buffering, audio-sync en display processing. Een eenvoudige, praktische regel: begin met VSync aan en een kleine audio-buffer, en test met een spel dat snelle reacties vraagt. Voelt het “zwaar”, probeer dan run-ahead of een lagere buffer, maar blijf bij correcte framerate. Emuleren is geen race; het is reconstructie.

Beeldinstellingen die bij 8-bit passen

Veel 8-bit computers gebruiken niet-standaard resoluties en pixelaspecten. Daarom ziet “fullscreen” vaak wazig uit. De twee instellingen die het meeste opleveren zijn integer scaling (pixels blijven blokjes) en een juiste aspect-correctie. Daarna kan een CRT-shader helpen, maar alleen als tekst en HUD leesbaar blijven. Voor archiefdoeleinden is het zelfs beter om zowel een “raw” capture als een “presentatie”-capture te bewaren, omdat filters interpretatie toevoegen.

Een concreet voorbeeld: een MSX-game met dunne fonts kan met zware scanlines onleesbaar worden, terwijl een subtiele phosphor-blend juist het originele gevoel benadert. Voor een ZX Spectrum-titel kan kleur-attribute “clash” historisch correct zijn; een filter dat dat maskeert, maakt de ervaring moderner maar minder authentiek. De keuze is niet moreel, maar doelgericht.

Controller-mapping en toetsenbordlayouts

Veel klassieke computers waren toetsenbordgericht. Een emulator vertaalt dat naar moderne input. Het loont om per systeem een mappingprofiel te maken: pijltjes, vuurknop, speciale toetsen (Space, Return, Run/Stop) en eventueel een “menu” knop. Voor spellen met één knop kan een tweede knop worden gemapt op “jump” of “auto-fire”, maar dat verandert het spel. Wie onderzoek doet, houdt het bij originele mappings en noteert wijzigingen.

• Maak één profiel voor “joystick-only” games en één voor “keyboard-heavy” titels.
• Leg turbo/auto-fire vast als aparte toggle, niet als standaard.
• Koppel savestate aan een toets die niet in games wordt gebruikt.
• Test een mapping met minstens twee verschillende spellen voordat het profiel “definitief” is.

Audio is de laatste stap. Veel systemen koppelen audio indirect aan videoframes of CPU-cycles. Een te grote buffer maakt het stabiel maar traag; een te kleine buffer kan kraken. De beste instelling is dus niet universeel. Wel is het universeel dat een consistente timing belangrijker is dan “zo laag mogelijk”, zeker bij muziek die op interrupts draait.

Wanneer de ervaring goed staat, wordt emulatie ook een gereedschap om te leren: debuggen, begrijpen en zelf bouwen. Dat brengt de beginnersgids naar het meest leerzame deel: programmeren en experimenteren.

Programmeren op 8-bit computers: van BASIC tot assembly en debugging

Programmeren op 8-bit computers voelt direct en tastbaar: weinig geheugen, simpele graphics, duidelijke limieten. Precies daarom is het ook in 2026 aantrekkelijk onderwijs: u ziet zonder lagen frameworks wat een loop doet, hoe een buffer overloopt, en waarom een sprong-instructie krachtig is. Emuleren maakt het laagdrempelig: geen originele hardware nodig om te beginnen, maar wel de mogelijkheid om hardwaregedrag te observeren.

Een logische leerlijn begint bij BASIC of een eenvoudige monitor, daarna komt assembly. BASIC leert structuur, maar assembly laat zien hoe registers, flags en geheugenadressen samenwerken. In een emulator met debugger kan een beginner letterlijk volgen hoe een variabele op een adres belandt en waarom een vergelijking (==, !=, <, <=) een sprong activeert. Dat is de plek waar “computers” weer een betekenis krijgen die verder gaat dan apps.

Control flow begrijpen via sprongen en vergelijkingen

Veel minimalistische instructiesets kennen een onvoorwaardelijke sprong (JMP) en een conditionele variant (bijvoorbeeld “jump if not zero”). Daarmee bouwt u if/else en loops. Een comparator kan verschillende modi hebben: signed en unsigned, en meerdere vergelijkingen. In emulatie ziet u de output vaak als een flag of een 0/1-resultaat in een register. Door die te combineren met een conditionele sprong ontstaat controleflow zonder hoog-niveau constructies.

Een concreet leerproject: schrijf een routine die een teller van 10 naar 0 laat aftellen en bij elke stap een byte naar een geheugenadres schrijft dat de emulator als “screen memory” toont. In BASIC is dat een FOR-loop; in assembly is het een register, een decrement, een compare en een sprong. Het inzicht dat beide hetzelfde doen, blijft hangen.

Bitmanipulatie: AND/OR/NOT en shifts als bouwstenen

8-bit programmeren draait vaak om bittrucs. AND maskeert bits, OR zet bits, NOT keert om, shifts verplaatsen. Veel systemen hebben slechts shifts van één bit per instructie. Dat klinkt beperkt, maar een loop herhaalt een shift en simuleert zo een grotere verplaatsing. Het is inefficiënt, maar transparant. Voor beginners is dat juist goed: elke stap is zichtbaar in de debugger.

Daarmee komt ook het begrip “no-op” of “move” in beeld: een instructie die niets verandert behalve het verplaatsen van een waarde. Dat is een verrassend nuttige tool om constanten te laden, registers te kopiëren en tijdelijke buffers te gebruiken. In emulators ziet u zulke instructies terug in trace-logs; ze lijken saai, maar ze maken programma’s beheersbaar.

Van emulatie naar begrip van echte hardware

Wie verder wil, kan een stap zetten richting hardware-gevoel door te spelen met “clock speed” en “single stepping”, alsof een systeem een meerfasige klok heeft. In zelfbouwprojecten met 7400-serie logic gates wordt een cyclus soms in vier stages opgeknipt om modules in volgorde te activeren. Dat verklaart waarom een timing-glitch registers kan corrumperen en waarom ontwerpers soms kiezen voor een shiftregister-oplossing om fases te genereren. In een emulator vertaalt zich dat naar de waarde van een cycle-accurate core: die bewaart de volgorde van microstappen waarop zulke effecten berusten.

De volgende vraag is dan niet “kan het draaien?”, maar “kan het herhaald en gecontroleerd draaien?”. Dat brengt emulatie naar archivering en reproduceerbaarheid, waar technologie en cultuur elkaar raken.

Digitale archivering en reproduceerbaarheid: emuleren als onderzoeksinstrument

Emuleren is niet alleen een middel om te spelen of te leren programmeren; het is ook een methode om digitaal erfgoed te stabiliseren. In archieven gaat het zelden om “het werkt op mijn pc”, maar om herhaalbaarheid: dezelfde input moet dezelfde output geven, ook later op een andere machine. Daarom is documentatie rond software en instellingen essentieel. In 2026 is dat extra relevant omdat besturingssystemen en hardware sneller wisselen, terwijl collecties juist voor tientallen jaren worden aangelegd.

Een emulatieproject dat onderzoek moet doorstaan, behandelt de emulator als onderdeel van de bron. Dat betekent: emulatorversie, configuratiebestand, gebruikte ROM’s, checksums, input-methode en capture-instellingen worden vastgelegd. Voor sommige vragen is zelfs de hostomgeving van belang: bijvoorbeeld audio-latency of floating point-verschillen die net een timing beïnvloeden. Niet elk project heeft die diepte nodig, maar een beginnersgids mag wel het gereedschap aanreiken.

Metadata die echt helpt (en niet alleen “nice to have” is)

Een werkbare set metadata blijft compact, maar informatief. Denk aan: systeemnaam, regio (PAL/NTSC), ROM-versie, media-type (disk/tape/cart), bronvermelding, checksum, en een korte notitie over aanpassingen (bijvoorbeeld remapped controls). Bij retro gaming is dat vooral handig voor uzelf; bij collectiebeheer is het noodzakelijk. Een klein verschil in ROM kan een andere BASIC-versie betekenen, wat weer invloed heeft op tokenisering of geheugenindeling.

Een voorbeeld uit de praktijk: twee ogenschijnlijk identieke disk-images van een educatief programma. De ene heeft een aangepaste loader die sneller laadt maar timingtrucs gebruikt. In een instruction-level emulator werkt hij, in een cycle-accurate omgeving crasht hij minder vaak. Zonder checksum en bronnotitie is later niet meer te achterhalen welke variant is getest. Met documentatie wordt het een herhaalbaar resultaat in plaats van een anekdote.

Juridische en ethische kanten zonder mystiek

Veel 8-bit software is nog auteursrechtelijk beschermd, ook als het “oud” voelt. Emuleren als techniek is meestal legaal; distributie van ROM’s en commerciële games vaak niet. Er bestaan legale routes: officiële heruitgaven, publieke domein releases, homebrew, en projecten waarbij rechthebbenden toestemming geven. Voor onderwijs en archiefwerk kan een instelling soms binnen wettelijke uitzonderingen werken, maar dat verschilt per context. Het belangrijkst voor beginners: behandel herkomst als onderdeel van kwaliteit. Een vage download is niet alleen juridisch twijfelachtig, maar ook technisch onbetrouwbaar.

Reproduceerbare captures: beeld, audio en input

Wie een spel of programma wil “vastleggen” als bron, heeft baat bij twee soorten output: een ongefilterde capture (raw, integer scaled) en een presentatiestijl (met CRT-look) voor publiekscontext. Input recording is een krachtig hulpmiddel: een emulator kan een reeks toetsen en joystickbewegingen opslaan, zodat exact dezelfde demonstratie later opnieuw draait. Voor onderzoek naar snelheid, difficulty of timingbugs is dat goud waard.

Daarmee sluit de cirkel: emuleren ondersteunt retro gaming, leert programmeren, en helpt erfgoed te bewaren. Wat blijft, zijn de vragen die beginners altijd stellen wanneer ze beginnen. Die horen netjes beantwoord te worden, zonder omwegen.

Welke 8-bit computers zijn het meest geschikt om als beginner te emuleren?

Systemen met veel documentatie en actieve communities werken het prettigst: bijvoorbeeld Commodore 64, ZX Spectrum, MSX en Atari 8-bit. Ze hebben veel beschikbare handleidingen, voorbeelden en vaak emulatorprofielen, wat de eerste stappen met software laden en controller-mapping eenvoudiger maakt. Kies vooral een platform waarvan de software u aanspreekt; motivatie wint het van specificaties.

Waarom voelt een geëmuleerd spel soms ‘zwaarder’ aan dan op originele hardware?

Meestal komt dat door input-latency: buffering in audio, VSync-instellingen, display processing of een controllerprofiel dat niet optimaal is. Zet VSync aan, gebruik integer scaling, verlaag de audio-buffer voorzichtig en test met een responsief spel. Vermijd het verhogen van emulatiesnelheid als ‘oplossing’, omdat dat timing en muziek kan verstoren.

Wat is het verschil tussen instruction-level en cycle-accurate emuleren?

Instruction-level emulatie voert CPU-instructies correct uit, maar modelleert niet altijd de exacte timing per microstap. Cycle-accurate emulatie simuleert ook de cycli en timingrelaties met video en I/O. Voor veel games is instruction-level voldoende, maar demo’s, timinggevoelige loaders en bepaalde grafische effecten vragen vaker om cycle-accurate gedrag.

Hoe kan programmeren in een emulator het makkelijkst beginnen?

Start met een omgeving die directe feedback geeft, zoals BASIC of een ingebouwde monitor, en gebruik daarna een emulator met debugger (registers, memory viewer, breakpoints). Kleine projecten werken het best: een teller, een sprite-beweging, een eenvoudige geluidroutine. Door single-step en registerweergave te gebruiken, wordt de link tussen code en hardwaregedrag snel duidelijk.

Welke bestanden en gegevens moeten bewaard worden voor reproduceerbare emulatie?

Bewaar minimaal: emulatornaam en -versie, configuratiebestanden, gebruikte ROM’s en media-images met checksums, plus notities over regio (PAL/NTSC), controller-mapping en video/audio-instellingen. Voor demonstraties helpen input recordings en twee soorten captures (raw en presentatie) om zowel onderzoek als publieksgebruik te ondersteunen.