CP/M-86 en de 8080-emulator: zo draai je klassieke software vandaag nog

• CP/M-86 blijft relevant voor retrocomputing omdat veel tools en bedrijfssoftware uit de vroege pc-jaren nog altijd waardevol zijn voor onderzoek, conversie en digitaal erfgoed.
• Met een 8080-emulator kan 8-bit CP/M-software (zoals .COM-programma’s en BASIC) verrassend soepel draaien op moderne Windows-, Linux- en macOS-systemen.
• Niet elke aanpak is hetzelfde: sommige oplossingen kiezen voor hardware emulatie (complete machines), andere vertalen BDOS/BIOS-aanroepen direct naar het host-bestandssysteem voor snelle workflow.
• Software compatibiliteit draait vaak om details: 8.3-bestandsnamen, end-of-line conversie, consolecodes en randapparaten zoals printer (LIST) en AUX zijn bepalend.
• Praktische tools zoals cpmemu, Z80Pack, RunCPM en SIMH dekken verschillende scenario’s: van één enkel legacy software-programma starten tot volledige systeembeelden met schijfimages en netwerksimulatie.

CP/M-86 en de wereld van 8080/Z80-programma’s lijken op het eerste gezicht twee tijdlijnen: 16-bit CP/M voor de 8086-familie tegenover 8-bit CP/M voor oudere computers met een 8080 of Z80. In de praktijk lopen die lijnen door elkaar in archieven, universiteitscollecties en bedrijfszolders, waar diskettes en listings meestal geen strak label “8-bit” of “16-bit” dragen. Wie vandaag klassieke software wil draaien, stuit daarom op een gemengde werkelijkheid: een CP/M-86 tool voor bestandsbeheer naast een 8080-compiler, een tekstverwerker die een specifieke terminal verwacht, of een BASIC-dialect dat alleen “gelooft” in een printerdevice LIST:. De snelste route is zelden één magische emulator, maar een set keuzes die passen bij het doel: lezen, reconstrueren, exporteren of echt werken alsof het 1983 is.

De kern is eenvoudig: gebruik hardware emulatie als het volledige systeemgedrag nodig is (BIOS, diskcontrollers, front panel, timing), en kies een “compatibiliteitsmachine” als vooral het programma telt. Een 8080-emulator die BDOS/BIOS-functies afhandelt en bestands-I/O naar Unix/Windows vertaalt, kan in minuten een .COM draaien zonder gedoe met disk images. Tegelijk kan CP/M-86 interessant blijven wanneer 8086-achtige software of historische pc-platformen gereconstrueerd moeten worden. De kunst zit in het combineren: eerst snel uitvoeren en inspecteren, daarna pas historisch precies emuleren waar het er echt toe doet.

CP/M-86 en 8080-emulator uitgelegd: waar de compatibiliteit echt vandaan komt

CP/M-86 is een besturingssysteem uit dezelfde familie als CP/M 2.2, maar gericht op de 8086/8088-wereld. Dat verschil is groter dan alleen “16-bit”: binaire bestanden zijn anders opgebouwd, aanroepen naar het systeem verlopen anders, en veel 8-bit software is simpelweg niet direct uitvoerbaar op CP/M-86. Toch duikt CP/M-86 vaak op in dezelfde verzamelingen als 8080- en Z80-programma’s, omdat in de overgang van 8-bit naar vroege pc’s veel bedrijven en hobbyisten beide sporen bewandelden. Een archiefmap kan dus gerust een CP/M-86 utility bevatten naast een .COM-tool voor CP/M 2.2.

Daarom is het nuttig om het compatibiliteitsvraagstuk in lagen te bekijken. Onderin zit de CPU-instructieset: 8080 en Z80 zijn verwant, maar niet identiek. Daarboven ligt de CP/M-omgeving: BDOS (Basic Disk Operating System) en BIOS (Basic Input/Output System) bieden functies voor console, schijven en randapparatuur. Een moderne emulator kan op twee manieren werken. Ofwel simuleert hij de volledige machine (hardware emulatie), inclusief schijfimages en I/O-poorten. Ofwel emuleert hij “alleen” de CPU en vertaalt hij BDOS/BIOS-functies naar het host-systeem. Die tweede aanpak is vaak ideaal om legacy software snel te laten draaien, omdat het gedoe met het importeren/exporteren van bestanden verdwijnt.

Een concrete manier om die lagen te onthouden is: CPU-correctheid bepaalt of het programma überhaupt loopt; BDOS/BIOS-gedrag bepaalt of het nuttig blijft; terminal- en bestandsgedrag bepaalt of het prettig werkt. Een tekstverwerker kan bijvoorbeeld prima rekenen en bestandsfuncties gebruiken, maar toch onbruikbaar zijn als pijltjestoetsen of schermcodes niet kloppen. In dat soort situaties is een emulator die VT100-achtig gedrag aanbiedt of terminalcodes kan doorgeven ineens belangrijker dan “perfecte” timing.

Wie CP/M-86 in dit verhaal plaatst, ziet het als zuster-ecosysteem: relevant voor 8086-software en voor het begrijpen van overgangsperiodes. Voor 8-bit programma’s blijft de 8080-emulator echter de directe sleutel. Een nuttig werkprincipe is daarom: start met het kleinste hulpmiddel dat het doel bereikt. Eerst het programma draaien en de output veiligstellen; pas daarna, indien nodig, naar een zwaardere set-up met disk images, specifieke BIOS-varianten of complete machinesimulatie. Dat voorkomt dat het project vastloopt op randzaken zoals schijfgeometry of obscure controllerdetails. De echte winst zit in het snel kunnen toetsen van software compatibiliteit voordat er dieper wordt geïnvesteerd.

In de volgende stap wordt het concreet: welke emulator past bij welke workflow, en waarom voelt de ene aanpak “archiefvriendelijker” dan de andere?

Praktische routes om klassieke software te draaien: cpmemu, RunCPM, Z80Pack en SIMH vergeleken

Vier namen keren steeds terug in hedendaagse retrocomputing-workflows: cpmemu, RunCPM, Z80Pack en SIMH. Ze dienen hetzelfde einddoel—klassieke software draaien—maar via verschillende routes. De keuze bepaalt of een project in een middag werkt, of verandert in een reconstructie van complete disk images en hardwareconfiguraties.

cpmemu is typisch voor de “BDOS/BIOS-vertaling”-school. Het emuleert 8080 of Z80 instructies (twee CPU-modi) en biedt een CP/M 2.2-achtige omgeving door console- en bestandsfuncties af te handelen. In plaats van een CP/M-schijfbestandssysteem in een image te beheren, kan het bestanden mappen naar het Linux- of Windows-bestandssysteem. Dat scheelt bij compilers, test-suites en tekstbestanden, omdat import/export geen apart ritueel meer is. Voor tekst kan automatische end-of-line conversie relevant zijn: CP/M verwacht vaak CRLF, terwijl Unix-achtige systemen LF gebruiken. Het is precies zo’n detail dat software compatibiliteit bepaalt.

RunCPM mikt op breedte: veel platforms, van desktop-OS’en tot microcontrollers zoals Arduino DUE en populaire boards als ESP32 of Teensy-varianten. Het is modulair in C opgebouwd, met een abstractielaag per platform. In een museumopstelling kan dat handig zijn: een klein bordje achter een scherm kan een CP/M-programma draaien zonder volledige pc. Het past ook bij educatie: een eenvoudige CP/M-omgeving als “app” die een programma start en klaar.

Z80Pack is een andere categorie: niet alleen een emulator, maar ook een cross-developmentpakket met generieke CPU-emulaties en een duidelijk geïsoleerde I/O-hardwarelaag. Het project is onder een BSD-achtige licentie beschikbaar en is historisch gebruikt om CP/M 1, CP/M 2, CP/M 3 en MP/M 2 vanuit broncode opnieuw op te bouwen. Juist dat “van bron tot draaiend systeem” maakt het aantrekkelijk voor onderzoekers: het dwingt tot begrip van opstart, BDOS, BIOS en tools. Bovendien bestaan er voorbeelden voor CP/NET-achtige netwerkmogelijkheden, waarbij virtuele systemen aan elkaar geknoopt worden met vroege RPC-achtige ideeën. Dat is niet voor iedereen nodig, maar voor reconstructies van oude kantooropstellingen kan het goud waard zijn.

SIMH tenslotte is het Zwitsers zakmes voor historische systemen. Het is een framework met vele simulators (oorspronkelijk verbonden aan het werk van Bob Supnik) en richt zich op het bewaren van hardware- en softwaregedrag door volledige systemen te simuleren. In ruil daarvoor vraagt het meestal dat schijfimages of softwarecollecties zelf aangeleverd worden. Dat is prima als er al images bestaan, of als een collectie zorgvuldig is gedigitaliseerd. Voor snelle “even dit .COM draaien” is SIMH vaak zwaarder dan nodig, maar voor authentieke omgevingen is het juist sterk.

Tool	Benadering	Handig voor	Typische frictiepunten
cpmemu	CPU-emulatie + BDOS/BIOS-vertaling naar host-OS	Snel .COM draaien, compilers testen, bestanden direct beheren	Niet elk “schijfgedrag” is echt; sommige diskfuncties zijn stub/instelbaar
RunCPM	Portabele CP/M runtime op veel platforms	Educatie, embedded demo’s, lichte opstellingen	Randapparatuur/terminalverwachtingen verschillen per port
Z80Pack	Emulatie + toolchain + systeemopbouw uit bronnen	Reconstructie, ontwikkeling, diep begrip van CP/M-varianten	Meer opzetwerk; vraagt keuzes over virtuele hardware
SIMH	Hardware emulatie van complete systemen	Authentieke machine-ervaring, historische configuraties	Disk images nodig; configuratie kan complex worden

De praktische regel is simpel: hoe meer historisch “echt” het moet voelen, hoe meer men naar SIMH of Z80Pack-achtige omgevingen neigt. Hoe meer het om output, conversie of snelle inspectie van legacy software gaat, hoe aantrekkelijker cpmemu of RunCPM wordt. De volgende stap is daarom: een werkbare installatie die niet struikelt over kleine maar bepalende details.

Voor wie de toolkeuze visueel wil toetsen, helpt het om demo’s te bekijken van zowel “complete machine”-emulatie als lichte runtimes.

Zo’n SIMH/Altair-demo laat vaak meteen zien waarom hardware emulatie anders aanvoelt: front panel, diskdrive-gedrag en het tempo van interactie hebben een eigen karakter. Dat is exact het soort context dat bij digitaal erfgoed telt.

cpmemu als snelle 8080-emulator: installatie, opties en een werkbare workflow

cpmemu is interessant omdat het de dagelijkse rompslomp rond CP/M-bestanden minimaliseert. Veel klassieke setups vereisen een “native CP/M file system” in een disk image. Dat werkt, maar het betekent importeren van bronbestanden en exporteren van resultaten bij elke testrun. Voor een onderzoeker die twintig varianten van een compiler wil doorlopen, wordt dat snel vermoeiend. Door CP/M-file-operations te mappen naar het host-bestandssysteem kan een projectmap op Linux of Windows de “schijf” worden, terwijl het CP/M-programma nog steeds denkt in 8.3-namen.

Installeren op Windows en Linux zonder omwegen

Op Windows kan cpmemu als MSIX-pakket geïnstalleerd worden. In de praktijk betekent dat: downloaden, dubbelklikken, of via PowerShell Add-AppPackage gebruiken. Daarna is het commando beschikbaar in een normale terminal. Op Linux bestaan pakketten voor Debian/Ubuntu (.deb) en RPM-gebaseerde distributies (.rpm), inclusief varianten voor ARM64, wat handig is voor bijvoorbeeld een kleine ARM-server of een compacte werkplek.

Wie liever vanuit bron bouwt, werkt doorgaans vanuit de src-map met make. In Windows kan een buildscript voor Visual Studio gebruikt worden. Zo’n keuze is niet alleen voor hobbyisten: in instellingen met streng softwarebeheer kan een eigen build met gecontroleerde bronversies juist wenselijk zijn.

8080- of Z80-modus: wanneer maakt het uit?

Standaard draait cpmemu in Z80-modus, maar het kan ook expliciet in 8080-modus starten. Dat is geen cosmetische optie. Sommige programma’s vertrouwen op Z80-instructies die op een pure 8080 niet bestaan. Omgekeerd kunnen tests of historische claims juist vragen om strikt 8080-gedrag. Voor software compatibiliteit is het waardevol om beide te kunnen proberen en het verschil te documenteren, zeker bij het valideren van toolchains.

Voorbeeldcommando’s zijn rechttoe rechtaan: een .COM direct starten, of MBASIC laden en vervolgens een .BAS meegeven. Een bekende rooktest is een klein BASIC-programma dat een regel tekst print. Het is simpel, maar het controleert console-I/O, BDOS-calls en bestandsargumenten.

Bestandsmapping en tekst/binaire nuances

Bestanden mappen klinkt eenvoudig, maar CP/M denkt in 8.3-namen en heeft zijn eigen conventies rond tekstregels. cpmemu kan lange of “vreemde” host-namen koppelen aan een nep-8.3-naam. In een configuratiebestand kan per bestand bepaald worden of het als tekst of binair behandeld wordt, zodat end-of-line conversie alleen gebeurt waar het klopt. Dat voorkomt dat een binair bestand “kapot” gaat omdat CR/LF wordt aangepast. Een tweede voordeel is dat testbestanden in een moderne mapstructuur leesbaar blijven: een directory met “parser_regressie_2026-06.txt” kan in CP/M zichtbaar worden als PARSER.TXT, zonder dat de hostnaam hoeft te worden opgeofferd.

Device redirection is een tweede praktische winst. LIST: (printer) kan naar een bestand gestuurd worden, AUX in/uit kan via paden lopen, zodat oude software rapporten “print” zonder dat er een echte printer aan te pas komt. Voor archivering is dat perfect: het printerbestand wordt direct een artefact dat samen met de run-log bewaard kan worden.

Debuggen en controle: progress, interrupts en Ctrl+C

Bij lastige programma’s is zicht op voortgang nuttig. cpmemu kan periodiek rapporteren hoeveel instructies zijn uitgevoerd. Dat helpt bij een vastloper: blijft het programma rekenen of hangt het in I/O? Daarnaast bestaan er opties voor timer-interrupts (met instelbare cycli en RST-vector) om software die timing verwacht toch een ritme te geven. Dat is geen wondermiddel, maar het is precies het soort knop dat een testomgeving van “soms werkt het” naar “reproduceerbaar” tilt.

Ook Ctrl+C is doordacht: een CP/M-programma kan het signaal krijgen (bijvoorbeeld om BASIC te onderbreken), terwijl een reeks herhaalde Ctrl+C-toetsen de emulator zelf laat stoppen. Dat voorkomt dat een gebruiker per ongeluk de hele sessie afsluit zodra een oude interpreter op een break wacht.

Wie hiermee een eerste set programma’s kan draaien, staat meteen voor de volgende vraag: wanneer is “handig” niet genoeg, en is volledige hardware emulatie nodig om het gedrag correct vast te leggen?

Video’s van cpmemu-sessies laten vaak het belangrijkste zien: hoe snel een .COM start, hoe MBASIC reageert, en hoe bestandstoegang zonder disk images werkt. Dat maakt het makkelijker om een eigen workflow te kiezen.

Wanneer hardware emulatie beter is: terminalcodes, disk images, netwerken en historische nauwkeurigheid

Er zijn scenario’s waarin een “lichte” emulator te weinig context biedt. Neem een databaseprogramma dat direct met BIOS-schijfroutines speelt, of een toepassing die bijzondere sectorindelingen verwacht. Als zo’n programma niet alleen BDOS gebruikt maar ook onder de motorkap schijfgedrag aanneemt, dan is mapping naar een host-bestandssysteem te abstract. In dat geval helpt hardware emulatie, omdat een complete machine met disk image het gedrag van controllers, geometry en soms zelfs timing benadert. Dat is precies het domein waar SIMH en sommige Z80Pack-configuraties uitblinken.

Terminal- en consolecompatibiliteit als stille breker

Veel CP/M-software is geschreven voor specifieke terminals of schermbibliotheken. Cursorbeweging, clear-screen en functietoetsen lopen via escape sequences. Een emulator die “alle tekens ongefilterd” doorstuurt, is eerlijk maar niet altijd bruikbaar. Een VT100-achtige terminalemulatie kan een teksteditor ineens bruikbaar maken, terwijl dezelfde editor in een kale console onleesbaar blijft. Bij mobiel gebruik, zoals cpmdroid of ioscpm-achtige omgevingen die RomWBW/HBIOS en VT100-benadering ondersteunen, kan dat verschil zelfs bepalen of een programma op een tablet inzetbaar is.

In een archiefsituatie is het verstandig om vast te leggen welke terminalmodus is gebruikt bij een run. Een screenshot is leuk, maar een notitie “VT100-compatibel, 80×24” is soms belangrijker voor reproduceerbaarheid. Het klinkt administratief, maar het voorkomt dat een collega later denkt dat de software kapot is, terwijl alleen de escape sequences anders geïnterpreteerd worden.

Disk images en schijfgedrag: nuttig, maar niet altijd nodig

Disk images zijn het klassieke pad: een CP/M-schijf met directories, FCB’s en blokallocatie. Ze zijn essentieel wanneer software een echte CP/M-diskstructuur verwacht of wanneer historische distributies als images beschikbaar zijn. Tegelijk zijn ze een bron van fouten: verkeerde geometry, verkeerde interleave, of een BIOS dat net anders met een drive-letter omgaat. Daarom is het handig om disk images pas als tweede stap te gebruiken: eerst functioneel testen met een tool die snel start, daarna de authentieke omgeving bouwen als het resultaat het waard is.

Een middenweg bestaat ook: sommige emulators laten een “BIOS disk behavior” instellen op ok/fail/error, zodat een programma dat naar diskfuncties grijpt niet meteen alles blokkeert. Dat is geen historisch perfecte oplossing, maar het kan helpen om te onderscheiden of de crash uit de CPU-kant komt of uit disk-I/O.

Netwerken en multi-user: CP/NET en MP/M als onderzoeksobject

CP/M was niet alleen een single-user hobby-OS. MP/M en CP/NET-achtige constructies laten zien hoe men met multi-user en netwerkideeën experimenteerde in een tijd dat “RPC” nog lang geen buzzword was. Z80Pack heeft voorbeelden waarin virtuele systemen aan elkaar gekoppeld worden, wat interessant is voor onderwijs en reconstructie: een kleine “kantoor”-omgeving met meerdere terminals kan virtueel tot leven komen. Zulke opstellingen helpen om legacy software in context te begrijpen: waarom een programma op LIST: printte, waarom er een READER: bestond, en hoe bestanden gedeeld werden.

Een doorlopende casus: het conserveren van een kleine CP/M-toolchain

Stel een fictieve maar realistische collectie voor van een klein ingenieursbureau: een PL/M-80 compiler, wat MACRO-80 assemblerscripts, een set testbestanden en een printerrapport dat ooit in een dossier belandde. De snelle route is: met een 8080-emulator de binaries draaien, de printeroutput naar een bestand redirecten en de resultaten versioneren. Daarna kan in een hardware-setup een disk image worden opgebouwd die overeenkomt met de oorspronkelijke schijf, zodat ook de “look and feel” en het directorygedrag bewaard blijven. Zo wordt functionaliteit eerst veiliggesteld, en authenticiteit daarna zorgvuldig toegevoegd.

Op dat punt ontstaat een laatste laag die vaak vergeten wordt: hoe ga je om met archiefbestanden, compressieformaten en tooling rond het uitpakken en converteren?

Bestanden, toolchains en valkuilen: van LBR/ARC tot compilers en testsets in CP/M-omgevingen

Veel klassieke software komt niet als losse .COM binnen, maar als archief: LBR-bibliotheken, ARC-archieven of oudere compressievormen zoals squeeze. Uitpakken is geen detail, maar onderdeel van de keten. Een tool als “80un” (unpacker voor meerdere CP/M-formaten) past in een moderne workflow als voorbewerking: eerst de artefacten uitpakken, dan gecontroleerd draaien, en pas daarna exporteren of converteren. Wie die stap overslaat, eindigt soms met halve collecties of verkeerd geïnterpreteerde tekstbestanden.

Toolchains als levende objecten: meer dan alleen programma’s

Een compiler op CP/M is zelden één bestand. Er hoort een assembler bij, een linker, bibliotheken, include-bestanden, en vaak scripts of batchbestanden die in de CCP-wereld passen. In moderne reconstructies duiken projecten op die die keten opnieuw toegankelijk maken, zoals omgevingen rond MACRO-80-achtige toolchains, of experimentele compilers die naar Z80/CP/M targeten (bijvoorbeeld ANSI C, Ada of zelfs niche-talen). Voor digitaal erfgoed is dat waardevol: het gaat niet alleen om “de binary”, maar om de mogelijkheid om broncode opnieuw te bouwen en uitkomsten te vergelijken.

Daarom is een emulator met goede bestandsintegratie handig. Een test-suite kan in een gewone Git-repository staan, met moderne bestandsnamen en submappen. Via mapping wordt het zichtbaar als CP/M-8.3, zonder dat de hoststructuur wordt opgeofferd. Resultaten kunnen direct naast de input landen, wat reproduceerbaarheid bevordert. Een lichte aanpak versnelt hier, terwijl hardware emulatie later kan valideren of dezelfde build ook in een “echte” diskimage-context werkt.

Concreet: waar lopen mensen op vast?

De meeste problemen zijn voorspelbaar. Bestandsnamen die niet in 8.3 passen, tekstbestanden met verkeerde regeleinden, programma’s die een specifieke consolebuffer verwachten, of utilities die direct naar disk-parameters vragen. Ook ontstaat verwarring rond CP/M-86: men probeert 8-bit .COM-bestanden in een 16-bit omgeving te starten, omdat “CP/M is CP/M”. Het helpt om in een projectlog expliciet te noteren: dit pakket is 8-bit CP/M 2.2 (8080/Z80), dit deel hoort bij CP/M-86 (8086), en de twee zijn historisch verwant maar technisch niet uitwisselbaar zonder bruggen.

Een korte checklist voor stabiele emulatie in dagelijkse praktijk

• Start met één klein programma (bijvoorbeeld een BASIC-interpreter of een simpele utility) om console en BDOS-functies te verifiëren.
• Leg vast of Z80- of 8080-modus is gebruikt; die keuze beïnvloedt compatibiliteit en reproduceerbaarheid.
• Kies per bestand tekst of binair en controleer end-of-line conversie voordat er massaal wordt geïmporteerd.
• Redirect LIST:/AUX indien mogelijk naar bestanden; dat maakt uitvoer direct archiveerbaar.
• Schakel pas over op disk images en hardware emulatie wanneer software echt afhankelijk blijkt van schijfgedrag of specifieke BIOS-routines.

Dit soort checklist lijkt klein, maar het voorkomt dat een collectie “bijna” werkt en vervolgens maanden blijft hangen op randvoorwaarden. Met de basis op orde wordt het ook eenvoudiger om vragen te beantwoorden die steeds terugkomen, van “waarom ziet mijn editor rommelig uit?” tot “hoe krijg ik printeroutput uit een CP/M-programma?”.

Kan CP/M-86 direct 8-bit CP/M .COM-programma’s draaien via een 8080-emulator?

Niet rechtstreeks als standaardfunctie van CP/M-86. CP/M-86 is gericht op 8086/8088-software en heeft een ander binaire en systeemmodel. In de praktijk wordt 8-bit legacy software vandaag meestal uitgevoerd in een 8080/Z80-emulator met een CP/M 2.2-achtige omgeving (zoals cpmemu, RunCPM, Z80Pack of een SIMH-systeem), en wordt CP/M-86 apart geëmuleerd wanneer 16-bit CP/M-86-programma’s onderzocht moeten worden.

Wat is het verschil tussen hardware emulatie en BDOS/BIOS-vertaling naar het host-bestandssysteem?

Bij hardware emulatie wordt een complete historische machine nagebootst, inclusief schijven (disk images), I/O en vaak timing. BDOS/BIOS-vertaling focust op het draaien van programma’s door CPU-instructies te emuleren en CP/M-systeemaanroepen (console en bestandsfuncties) om te zetten naar Windows/Linux/macOS. De tweede aanpak is vaak sneller voor dagelijks werk en testflows, terwijl de eerste aanpak beter is voor authentieke reconstructies.

Waarom werken bestandsnamen en tekstbestanden soms niet goed in CP/M-emulatie?

CP/M gebruikt doorgaans 8.3-bestandsnamen en verwacht voor tekst vaak CRLF-regeleinden. Moderne systemen gebruiken langere namen en op Unix-achtige systemen meestal alleen LF. Emulators die mapping en EOL-conversie bieden, kunnen lange host-namen aan 8.3 koppelen en regeleinden automatisch omzetten, zodat zowel leesbaarheid op de host als compatibiliteit in CP/M behouden blijft.

Hoe is printeroutput (LIST:) uit CP/M-programma’s het best te bewaren?

Gebruik device redirection wanneer de emulator dit ondersteunt: koppel LIST: aan een bestandspad op het host-systeem. Zo wordt elke ‘print’ direct een tekstbestand dat samen met de input en configuratie kan worden gearchiveerd. In een hardware-emulatieset-up kan hetzelfde vaak via een virtuele printer of spoolbestand.

Welke tool is het meest geschikt om snel één enkel CP/M-programma te testen?

Voor snelle tests zonder disk images is een lichte emulator met bestandsmapping doorgaans het meest praktisch, zoals cpmemu of in sommige gevallen RunCPM. Voor programma’s die sterk leunen op schijf- of hardwaregedrag is een complete machinesimulator (bijvoorbeeld via SIMH) vaak geschikter, omdat die het oorspronkelijke systeemgedrag dichter benadert.