Emulation und digitaler Erhalt

Digitaler Erhalt beginnt vor dem Emulator

Emulation ist ein Zugangswerkzeug. Digitaler Erhalt ist eine umfassendere Aufgabe. Ein Emulator kann historische Software heute nutzbar machen, doch ohne gesicherte Originaldaten, Firmware, Metadaten und dokumentierte Laufzeitbedingungen bleibt langfristige Reproduzierbarkeit unsicher.

Für Software und alte Datenträger müssen mehrere Ebenen getrennt werden: das physische Original, sein möglichst originalgetreues digitales Abbild, eine logisch interpretierte Nutzkopie, die benötigte Firmware und Hardwarebeschreibung sowie die konkrete Emulations- oder Virtualisierungsumgebung.

Ein belastbares Archiv bewahrt deshalb nicht nur „das Programm“, sondern die Kette, die aus gespeicherten Bits wieder eine nachvollziehbare historische Nutzungssituation macht.

Bit-Level-Preservation – die unveränderten Bits als Fundament

Bit-Level-Preservation hält den gespeicherten digitalen Datenstrom unverändert und überprüfbar. Mehrere Kopien, Prüfsummen und kontrollierte Migration auf neue Datenträger schützen vor unbemerkter Veränderung und Medienverlust.

Dieses Fundament allein garantiert keine spätere Nutzbarkeit. Ein perfekt erhaltener Bitstream bleibt unverständlich, wenn Format, Software, Codec, Firmware oder Hardwareverhalten nicht mehr bekannt sind.

Integrität und Interpretierbarkeit müssen deshalb gemeinsam erhalten werden.

Fünf Ebenen eines belastbaren Erhalts

Physisches Original, Rohabbild, logische Nutzkopie, Laufzeitumgebung und Dokumentation erfüllen unterschiedliche Aufgaben. Der Verlust einer Ebene kann die spätere Rekonstruktion erheblich erschweren.

Besonders robust ist ein Bestand, wenn aus dem unveränderten Rohabbild jederzeit neue Derivate erzeugt werden können und die Laufzeitumgebung separat beschrieben ist.

Was Emulation technisch bedeutet

Ein Emulator bildet das beobachtbare Verhalten eines Zielsystems auf einem anderen Host nach. Dazu gehören CPU, Adressräume, Timer, Interrupts, Grafik, Audio, Eingabe, Controller und Speichermedien.

Originalsoftware soll dieselben Schnittstellen und Zustandsänderungen vorfinden, die auf realer Hardware erwartet werden. Der Host muss den ursprünglichen Befehlssatz nicht nativ ausführen.

Genauigkeit ist damit eine Systemfrage und nicht nur die korrekte Berechnung einzelner CPU-Instruktionen.

Simulation, Emulation und Nachbildung

Eine Simulation kann Eigenschaften eines Systems modellieren, ohne binärkompatibel zu sein. Emulation zielt typischerweise darauf, originale Binärsoftware unverändert auszuführen.

Eine Oberfläche im Stil eines C64 simuliert dessen Erscheinung. Ein C64-Emulator muss zusätzlich 6510, VIC-II, SID, CIA, Banking und relevante Timings nachbilden.

Virtualisierung ist nicht dasselbe wie Emulation

Virtualisierung nutzt häufig denselben oder einen kompatiblen CPU-Befehlssatz wie der Host und delegiert große Teile der Ausführung an reale Hardware. Das erhöht die Geschwindigkeit, bildet aber keine fremde historische Architektur nach.

Eine x86-VM kann ältere x86-Betriebssysteme tragen. C64, Amiga, Atari oder CPC benötigen dagegen die Emulation ihrer jeweiligen CPU- und Chipsatzarchitektur.

Kompatibilitätsschicht statt Hardwareemulation

Eine Compatibility Layer implementiert Betriebssystem-APIs neu und leitet deren Funktionen auf das Hostsystem um. Das kann alte Anwendungen effizient ausführen, ohne die ursprüngliche Maschine zu emulieren.

Für digitalen Erhalt muss dokumentiert werden, ob eine Anwendung unter echter Systememulation, Virtualisierung oder einer API-Kompatibilitätsschicht ausgeführt wurde.

CPU-Interpreter – Befehl für Befehl

Ein Interpreter liest den nächsten Maschinenbefehl der Ziel-CPU, dekodiert ihn und aktualisiert den emulierten Zustand. Das ist nachvollziehbar und eignet sich gut für präzise Steuerung.

Korrektheit umfasst Register, Flags, Ausnahmen, Speicherzugriffe und gegebenenfalls Zyklusverhalten.

Dynamic Recompilation

Ein dynamischer Recompiler übersetzt Blöcke von Zielcode zur Laufzeit in Hostmaschinenbefehle. Das beschleunigt insbesondere neuere Systeme deutlich.

Selbstmodifizierender Code, präzise Ausnahmen und Timing machen die Umsetzung komplex. Geschwindigkeit darf keine für die Zielsoftware sichtbaren Seiteneffekte verändern.

High-Level- und Low-Level-Emulation

Low-Level-Emulation modelliert Hardware und Firmware vergleichsweise direkt. High-Level-Emulation ersetzt bekannte Firmwarefunktionen durch neue Implementierungen.

HLE kann bequem und schnell sein, während LLE mit korrekter Firmware häufig näher an undokumentierten Nebeneffekten der Originalplattform liegt.

Timing – der Unterschied zwischen „läuft“ und „stimmt“

Heimcomputer und Konsolen besitzen oft keine abstrahierte Grafik-API. Software schreibt Register an präzisen Rasterpositionen und erwartet festes Zusammenspiel zwischen CPU, DMA, Video, Audio und Interrupts.

Ein Emulator kann Standardsoftware korrekt starten und bei Demos, Schnellladern oder Kopierschutz dennoch scheitern, wenn nur Endzustände statt zeitlicher Abläufe modelliert werden.

Cycle Exact – kein magisches Etikett

Zyklusgenauigkeit bezeichnet die Synchronisation relevanter Hardwareereignisse auf feiner Zeitbasis. Das Label allein garantiert jedoch keine vollständige Übereinstimmung.

CPU-Zyklen können stimmen, während Busarbitration, Analogfilter oder Controllerdetails falsch bleiben. Belastbare Genauigkeit entsteht aus Tests gegen Dokumentation und reale Hardware.

Determinismus als Werkzeug für Reproduzierbarkeit

Deterministische Emulation liefert bei identischem Anfangszustand und identischen Eingaben denselben Ablauf. Das erleichtert Regressionstests, Replays und wissenschaftliche Vergleiche.

Echtzeituhr, Netzwerk, Hosttimer und Zufallsquellen müssen dafür kontrolliert oder dokumentiert werden.

Save States sind Komfort, kein Archivmaster

Save States frieren RAM, Register, Timer und interne Gerätezustände zu einem Zeitpunkt ein. Sie können eine Sitzung bequem fortsetzen.

Das Format hängt häufig stark von der Emulatorversion ab. Änderungen interner Datenstrukturen machen alte States unlesbar. Originalmedien und reproduzierbare Konfiguration bleiben deshalb die dauerhaftere Basis.

ROM-Dumps – Bytefolge plus Hardwarekontext

Bei einfachem ROM entsteht durch Auslesen eine direkte Bytefolge. Komplexere Cartridges besitzen Mapper, Bankswitching, EEPROM, Zusatz-RAM oder Spezialprozessoren.

Ein Dump muss daher mit Platinenrevision, Chipbezeichnung, Größe, Mapping und Prüfsumme verbunden bleiben.

Bad Dumps, Overdumps und Byte-Swaps

Fehlerhafte ROM-Sicherungen können doppelte Daten, vertauschte Byte-Reihenfolgen oder abgeschnittene Bereiche enthalten. Manche starten trotzdem in toleranten Emulatoren.

Ein funktionierender Start beweist deshalb keine authentische Sicherung. Unabhängige Dumps und bekannte Hashwerte sind entscheidend.

Prüfsummen und kryptografische Hashes

CRC32 ist historisch weit verbreitet, SHA-1 ebenfalls in ROM- und Softwaredatenbanken. Für neue lokale Integritätsaufzeichnungen ist SHA-256 eine robuste zusätzliche Wahl.

Ein Hash identifiziert eine Bytefolge, aber nicht automatisch deren Herkunft. Provenienz und Erfassungsmethode bleiben separate Informationen.

object: disk01.scp
sha256: <digest>
source: 5,25-Zoll-Original
capture: raw flux
derivatives:
  - disk01.atr
  - extracted/

Master und Derivate besitzen jeweils eigene Prüfsummen.

Fixity Checks – Hashwerte regelmäßig neu prüfen

Ein einmal notierter Hash schützt praktisch nur dann, wenn er später erneut berechnet und verglichen wird. Datenträgerfehler, Übertragungsfehler oder Synchronisationsprobleme können Dateien verändern.

Abweichungen werden untersucht, bevor eine Kopie überschrieben wird. Mehrere unabhängige Archivkopien liefern Vergleichsmöglichkeiten.

Provenienz – woher stammt dieses Image?

Provenienz beschreibt Quelle und Bearbeitungsgeschichte. Bei einer Diskette gehören Medium, Laufwerk, Lesegerät, Toolversion, Datum und spätere Konvertierungen dazu.

Ohne Provenienz wirken zwei verschiedene Hashes lediglich wie zwei Varianten. Mit Dokumentation lassen sich Produktionsrevision, Benutzerdaten und Auslesefehler auseinanderhalten.

Metadaten – Interpretierbarkeit für die Zukunft

Mindestens sinnvoll sind Titel, Plattform, Version, Mediumtyp, Imageformat, Dateigröße, Prüfsummen, Erfassungsdatum und bekannte Laufzeitanforderungen.

Bei komplexen Systemen kommen Firmware, Sprache, Region, Seriennummer, benötigte Eingabegeräte, Grafikkarte oder Soundhardware hinzu.

Sektorimage – praktisch und analysierbar

Ein Sektorimage speichert die Nutzdaten adressierbarer Sektoren in definierter Reihenfolge. Solche Images sind kompakt und für Dateisystemtools sowie Emulatoren leicht nutzbar.

Sie verlieren jedoch physische Eigenschaften, wenn Kopierschutz, ungewöhnliche Sektorheader, Gap-Längen oder schwache Bereiche nicht in das Format passen.

Track- und Meta-Images

Erweiterte Formate können Trackaufbau, Sektor-IDs, Sektorgrößen und Fehlerzustände speichern. Damit bleibt mehr Struktur als in einem linearen Sektorabbild erhalten.

Gerade CPC-, CP/M- und andere Systeme mit vielen Formatvarianten profitieren davon.

Flux-Aufnahme – magnetische Übergänge erhalten

Flux-Imaging erfasst zeitliche Abstände magnetischer Flusswechsel direkt vom Laufwerk. Die Daten werden zunächst nicht auf ein bestimmtes Sektor- oder Dateisystem reduziert.

Dadurch bleiben ungewöhnliche Codierungen, absichtlich fehlerhafte Sektoren, schwache Bereiche und viele Kopierschutzmechanismen wesentlich besser rekonstruierbar.

Flux ist zugleich anspruchsvoller: Laufwerksdrehzahl, Spurposition, Index und zufällige Lesefehler müssen bei der Interpretation berücksichtigt werden.

Mehrere Umdrehungen statt einer Momentaufnahme

Mehrfach erfasste Revolutionen zeigen, welche Fluxübergänge stabil und welche variabel sind. Das ist wichtig für schwache Bitbereiche und schwer lesbare Medien.

Eine einzelne Revolution kann zufällige Lesefehler mit einem absichtlichen Schutzmerkmal verwechseln.

SCP, KryoFlux RAW/CTR, HFE und verwandte Formate

Fluxdaten werden in unterschiedlichen Containerformaten gespeichert. SCP, KryoFlux-nahe RAW/CTR-Formate und HFE besitzen verschiedene Metadaten- und Zeitmodelle.

Konvertierungen können für Emulatoren sinnvoll sein, sollten das zuerst erfasste Rohformat aber nicht ersetzen.

Greaseweazle – modernes Lesen alter Floppies

Greaseweazle verbindet klassische Diskettenlaufwerke über USB mit modernen Hosts und arbeitet auf Roh-Fluxebene. Dadurch können PC-, Amiga-, Amstrad-, Atari- und zahlreiche Spezialformate erfasst werden.

Bei wertvollen Originalen ist eine physisch deaktivierte Schreibmöglichkeit eine zusätzliche Schutzschicht.

MAMEs Floppy-Modell – unterhalb der Sektorebene

MAME modelliert in seinem Floppy-Subsystem magnetischen Zustand, Laufwerk und Controller getrennt. Imagehandler übersetzen zwischen Dateiformat und internem magnetischem Modell.

Dieser Aufbau erklärt, warum präzise Diskettenemulation weit mehr als das Einlesen eines Dateisystems verlangt.

MAME Software Lists – Originalmedium als dokumentiertes Objekt

Softwarelisten beschreiben bekannte Medien mit Metadaten und Hashwerten. Sie identifizieren Images, prüfen Integrität und ordnen mehrere Teile oder Revisionen strukturiert zu.

Das Grundprinzip ist archivisch stark: Inhalt und erwarteter Digest sind wichtiger als ein zufälliger Dateiname.

CHD – große Medien verlustfrei bündeln

Compressed Hunks of Data wird für Festplatten, optische Medien und andere große Images genutzt. Das Format kombiniert Metadaten und verlustfreie Kompression.

Inhaltsdigests können unabhängig von der konkreten Containerkompression betrachtet werden. Zwei CHDs können denselben repräsentierten Inhalt besitzen, obwohl die Containerbytes aufgrund unterschiedlicher Kompression nicht identisch sind.

Optische Medien – mehr als ISO

Ein ISO-Image bildet häufig einen einzelnen Daten-Track ab. Mixed-Mode-CDs, mehrere Sessions, Audio-Tracks und Subchannel-Informationen benötigen reichhaltigere Repräsentationen.

BIN/CUE, CHD oder andere Track-orientierte Formate können solche Strukturen vollständiger beschreiben.

Warum ein ISO nicht jede CD vollständig beschreibt

ISO 9660 ist ein Dateisystem. Die physische Compact Disc kann weitere Tracks, Control Flags und Strukturen enthalten, die außerhalb eines einzelnen Daten-Track-Abbilds liegen.

Ein ISO kann für Installationsdaten perfekt und als vollständige Repräsentation des Originalmediums gleichzeitig unzureichend sein.

Datenkassette – WAV als quellennahe Ebene

Heimcomputer-Datenkassetten speichern Bits als analoge Audiosignale. Eine verlustfreie PCM-Aufnahme erhält diese Signalebene.

CAS-, TAP- oder andere logische Formate dekodieren Pulse oder Datenblöcke und sind für Emulatoren praktischer. Rohaufnahme und Derivat ergänzen sich.

Bandtransport, Pegel und Azimut

Bandgeschwindigkeit, Tonkopf-Azimut, Pegel und mechanischer Zustand beeinflussen die Lesbarkeit alter Kassetten. Eine schlechte Wiedergabe kann Fehler erzeugen, die nicht im Originalsignal liegen.

Nachträgliche Filterung und Normalisierung werden als Derivat behandelt; die unveränderte Aufnahme bleibt erhalten.

Cartridge – ROM plus Schaltung

Cartridges können Bankswitching, zusätzliche RAMs, Echtzeituhr, Speichercontroller oder Spezialprozessoren enthalten. Ein ROM-File beschreibt dann nur einen Teil des physischen Moduls.

Platinenfunktion und ROM-Inhalt müssen gemeinsam dokumentiert werden.

Firmware gehört zur Laufzeitkette

PC-BIOS, Amiga-Kickstart, C64-KERNAL, Zeichengeneratoren und andere ROMs beeinflussen die Ausführung. Softwareimages allein verraten nicht immer, welche Revision erwartet wird.

Firmwareversion, Region und Hash gehören deshalb zur Emulationskonfiguration. Technischer Erhalt und Weitergaberecht bleiben getrennte Fragen.

ROM-Revisionen und Regionen

PAL-/NTSC-Varianten, nationale Tastaturen und Produktionsrevisionen können unterschiedliche ROMs oder Initialisierungen verwenden.

Ein pauschaler Dateiname wie bios.bin ist deshalb archivisch schwach. Eindeutige Zuordnung und Prüfsumme sind besser.

MAME – Emulation als technische Dokumentation

MAME beschreibt nicht nur CPUs, sondern komplette Geräte, Adressräume, ROM-Komponenten, Eingaben und Medien. Softwarelisten erweitern diese Systemdefinitionen um bekannte Softwaremedien.

Emulatorversion und Systemdefinition sollten dokumentiert werden, weil Genauigkeit und Unterstützung fortlaufend verbessert werden.

86Box – konkrete historische PC-Hardware nachbilden

86Box emuliert x86-basierte Maschinen auf niedriger Hardwareebene und legt Wert auf konkrete Mainboards, BIOS-Versionen, Grafikkarten, Controller und weitere Peripherie.

Für alte PC-Software, die an Chipsatz- oder BIOS-Eigenheiten hängt, kann diese konkrete Maschinenwahl entscheidender sein als ein abstraktes „DOS-kompatibel“.

DOS-orientierte Emulatoren – Zugriff statt Mainboardrekonstruktion

DOS-orientierte Emulationsumgebungen priorisieren bequeme Ausführung von DOS-Spielen und Anwendungen. Hardware wird dort häufig pragmatisch in den relevanten Bereichen nachgebildet.

Für ein Archiv kann eine solche Zugriffsumgebung neben einer stärker hardwaregenauen PC-Konfiguration bestehen.

Frontend und Emulations-Core trennen

Core-basierte Frontends kapseln Benutzeroberfläche und Emulationsengine separat. Ein Wechsel des Cores kann Timing, Medienunterstützung und Save-State-Kompatibilität verändern.

Für Reproduzierbarkeit müssen Frontend, Core und Version getrennt dokumentiert werden.

C64 – Timing, VIC-II und SID

C64-Emulation muss 6510, VIC-II, CIA, SID, Speicherbanking und IEC zusammenspielen lassen. Demos, Rastereffekte und Schnelllader sind anspruchsvolle Genauigkeitstests.

SID-Revisionen und Filtermodelle beeinflussen den Klang. Die Hardwareseite liegt auf c64.htm.

Amiga – CPU, Custom Chips, RAM und Kickstart

Amiga-Software hängt von 68000-Familie, OCS/ECS/AGA, Chip RAM, Fast RAM, Kickstart und Laufwerkskonfiguration ab.

Ein ADF allein verrät nicht, ob A500, A1200 oder eine Festplatteninstallation erwartet wird. Modell und ROM gehören zur Dokumentation.

Atari 8-Bit – ANTIC, GTIA, POKEY und SIO

Atari-Software nutzt Display Lists, DMA, Rasterinterrupts und POKEY-Timing. Ein reiner 6502-Interpreter genügt nicht.

ATR ist für viele Disketten praktisch; tiefere Repräsentationen sind bei speziellen Loadern oder Schutzverfahren erforderlich. Vertiefung: atari-heimcomputer.htm.

CPC – CRTC-Varianten und Diskettenstrukturen

CPC-Demos können Unterschiede realer CRTC-Varianten sichtbar machen. Zusätzlich existieren zahlreiche Diskettengeometrien und CP/M-nahe Formate.

Extended DSK bewahrt mehr Struktur als ein einfaches Sektorabbild. Vertiefung: cpc.htm.

Videoausgabe – historische Signale waren nicht nur Pixel

RF, Composite und CRT-Wiedergabe besitzen analoge Bandbreite, Phasenlage, Scanlines und Phosphoreigenschaften. Ein Emulator rendert zunächst digitale Pixel.

Shader können eine Nutzungserfahrung annähern, sollten aber von einer unverfälschten digitalen Referenzdarstellung getrennt bleiben.

Composite-Artifacting

Einige Systeme erzeugen zusätzliche Farben aus hochfrequenten Pixelmustern und analogem Farbträger. Ein digitales RGB-Raster allein reproduziert diesen Effekt nicht automatisch.

Für historisch beabsichtigte NTSC-Artifact-Farben muss das Signalverhalten im Modell berücksichtigt werden.

Audio – Registerwerte und analoger Ausgang

Soundchips erzeugen digitale oder gemischt analog-digitale Signale, die über Filter und Ausgangsstufen weiter verändert werden.

SID, POKEY, Amiga-Audio und PC-Soundkarten benötigen daher neben Registerlogik auch angemessene Signalmodelle.

MIDI – das Zielgerät gehört zum Klang

DOS-Software kann identische MIDI-Daten an unterschiedliche Synthesizer senden. General MIDI, MT-32-kompatible Geräte und FM-Synthese klingen grundlegend anders.

Audiogerät und ROM-/Synthesemodell gehören deshalb zur Laufzeitbeschreibung.

Eingabegeräte – Mapping und Originalverhalten

Digitale Joysticks, analoge Paddles, Lichtgriffel, Mäuse und Trackballs besitzen verschiedene Signal- und Timingmodelle.

Ein modernes Gamepad kann Funktionen abbilden, ersetzt aber nicht automatisch Weg, Totzone, Abtastrate oder elektrische Besonderheiten des Originals.

Serielle Mäuse – echte Übertragungszeit gehört dazu

Eine serielle Maus sendet Daten mit begrenzter UART-Rate. Werden komplette Pakete im Emulator ohne Übertragungszeit injiziert, kann die virtuelle Maus reaktionsschneller als reale Hardware wirken.

Authentizität kann deshalb bedeuten, historische Begrenzungen bewusst zu reproduzieren.

Netzwerkemulation endet nicht am Adapter

Ein emulierter Ethernetadapter stellt noch keinen historischen Onlinedienst wieder her. BBS-, FTP-, IRC-, Web- und Multiplayer-Software benötigt Gegenstellen, Namensauflösung und passende Protokolle.

Netzwerkdienste gehören bei Bedarf zur rekonstruierten Umgebung. Vertiefung: netzwerk-und-heimvernetzung.htm.

Abgeschaltete Server als Erhaltungsproblem

Software kann vollständig vorhanden und trotzdem unbenutzbar sein, wenn Aktivierungs-, Login-, Matchmaking- oder Inhaltsserver verschwunden sind.

Erhalt muss dann Client, Protokoll und gegebenenfalls Serverlogik als zusammenhängendes System betrachten.

Datum, Uhrzeit und abgelaufene Zertifikate

Historische Software kann auf Systemdatum, Zertifikatsketten oder Lizenzzeiträume reagieren. Eine Installation kann im Jahr 2026 deshalb anders starten als zur ursprünglichen Nutzung.

Eine isolierte Emulationsumgebung kann ein historisch passendes Datum erhalten, ohne den realen Host zu verändern.

Kopierschutz und DRM

Schutzmechanismen können auf Diskettenanomalien, Dongles, Seriennummern oder Onlinedienste angewiesen sein. Für Erhalt ist zunächst wichtig, diese Abhängigkeit vollständig zu dokumentieren.

Technische Sicherung und rechtliche Zulässigkeit einer Umgehung sind getrennte Fragen.

Dongles und Sicherheitsgeräte

Professionelle Software nutzte parallele, serielle und später USB-Dongles. Festplattenimage und Installationsmedium reichen dann nicht aus.

Donglemodell, Treiber, Firmware und physisches Gerät sind Teil der Laufzeitkette.

Virtuelle Maschine als Zeitkapsel

Eine VM kann Betriebssystem, Anwendungen und Konfiguration bequem zusammenhalten. Das erleichtert unmittelbaren Zugang.

VM-Format und virtuelle Hardware hängen jedoch von einem Hypervisor ab. Installationsmedien, Konfiguration und Versionsangaben sollten zusätzlich erhalten werden.

RAW, VHD, VHDX, VMDK und QCOW2

Virtuelle Festplattenformate unterscheiden sich bei Snapshots, Sparse Allocation, Metadaten und Kompression. RAW ist einfach, benötigt aber den gesamten logischen Platz.

Containerformate sind praktisch, bringen jedoch eigene Versions- und Abhängigkeitsfragen mit.

Snapshots – Ketten können fragil werden

Viele VM-Snapshots speichern nur Unterschiede zu einer Basisdatei. Geht ein Glied verloren, kann der aktuelle Zustand unbrauchbar werden.

Für Langzeitsicherung sind konsolidierte Images oder vollständig dokumentierte Snapshotketten robuster.

Container – reproduzierbare Anwendung, keine alte Hardware

Container kapseln Dateien und Bibliotheken, teilen aber typischerweise den Kernel des Hosts. Sie eignen sich hervorragend für Build- und Serverumgebungen.

Für einen historischen Kernel oder fremde CPU-Architektur ersetzen Container keine VM oder Emulation.

Quellcode – mehr als die letzte ZIP-Datei

Quellcodeerhalt umfasst Repository-Historie, Branches, Tags, Buildskripte, Ressourcen, Submodule und Dokumentation.

Die Entwicklungsgeschichte kann für spätere Fehleranalyse und Rekonstruktion genauso wertvoll sein wie der letzte veröffentlichte Stand.

Software Heritage – Provenienz und inhaltsadressierte Softwareobjekte

Software Heritage archiviert öffentlich verfügbaren Quellcode und modelliert Inhalte, Verzeichnisse, Revisionen und Herkunft als zusammenhängende Softwareartefakte.

Persistente Software Hash Identifiers machen konkrete Objekte unabhängig von wechselnden Hostingpfaden referenzierbar.

Build-Umgebung erhalten

Alter Quellcode lässt sich mit modernen Compilern nicht zwangsläufig identisch bauen. Compilerfehler, undefiniertes Verhalten, Bibliotheksänderungen und Assemblerdialekte können Ergebnisse verändern.

Compiler, Linker, SDK, Include-Dateien und Buildparameter gehören deshalb zur Reproduzierbarkeit.

Reproducible Builds

Ein reproduzierbarer Build erzeugt aus identischem Quellstand und definierten Bedingungen dasselbe Binärergebnis oder eine klar definierte funktionale Entsprechung.

Zeitstempel, Pfade und zufällige IDs können Bitidentität verhindern. Gerade bei historischer Software ist schon ein dokumentiert wiederholbarer Build wertvoll.

Abhängigkeiten – häufig der eigentliche Verlust

Programme hängen von Bibliotheken, Laufzeiten, Fonts, Codecs, Datenbanken und Treibern ab. Quellcode allein genügt nicht, wenn diese Komponenten später fehlen.

Versionen und Herkunft wichtiger Dependencies sollten eingefroren oder dokumentiert werden.

Webseiten – statische und dynamische Erhaltung

Statische HTML-Seiten sind relativ gut erhaltbar, wenn CSS, JavaScript und Medien lokal vorliegen und Pfade funktionieren.

Dynamische Seiten benötigen zusätzlich Servercode, Laufzeit, Konfiguration, Datenbank und gegebenenfalls externe APIs.

CDNs, APIs und eingebettete Dienste

Eine Webseite kann lokal vollständig erscheinen und trotzdem von externen Fonts, Skripten, Karten oder API-Antworten abhängen.

Für dauerhafte technische Dokumentation sollten wesentliche Inhalte nicht ausschließlich von externen Diensten abhängen.

Datenbanken – Dump plus Enginekontext

Ein SQL-Dump enthält häufig Daten und Schema, aber nicht immer Collations, Extensions, Stored Procedures oder proprietäre Enginebesonderheiten.

Datenbanktyp, Version und getesteter Restore-Prozess gehören zur Dokumentation.

Fonts als Abhängigkeit historischer Dokumente

Fehlende Fonts verändern Zeilenumbrüche und Seitenlayout. Eine PDF-Zugriffskopie bewahrt Darstellung, aber nicht notwendigerweise Bearbeitbarkeit.

Originaldatei, benötigte Fonts soweit rechtlich zulässig, Anwendungsumgebung und gerenderte Referenz sind unterschiedliche Erhaltungsebenen.

Formatmigration – Zugang verbessern, Original behalten

Migration überführt Daten in ein moderneres Format. Sie kann Zugänglichkeit sichern, aber semantische Details verlieren.

Das Ausgangsobjekt bleibt erhalten; Werkzeug, Datum und Parameter der Migration werden protokolliert.

Emulation als Preservation Strategy

Statt ein altes Dokument ständig in neue Formate umzuwandeln, kann die ursprüngliche Anwendung in emulierter Umgebung erhalten werden.

Damit bleiben Bedienlogik und Softwareverhalten besser nachvollziehbar. Migration und Emulation ergänzen sich deshalb häufig.

Encapsulation – Objekt und Kontext zusammenhalten

Bei Encapsulation werden Master, Metadaten, Konfiguration und gegebenenfalls benötigte Software gemeinsam strukturiert abgelegt.

Der Vorteil liegt in der nachvollziehbaren Rekonstruktionskette; der Container selbst muss wiederum dokumentiert bleiben.

Referenzdarstellung auf Originalhardware

Screenshots, Video- und Audioaufnahmen realer Hardware liefern Vergleichswerte für spätere Emulatoren.

Sie ersetzen keine interaktive Software, helfen aber bei Farbe, Timing, Layout und Klang als Referenz.

Originalhardware bleibt Referenz

Emulatoren werden gegen reale Geräte, Messungen und technische Unterlagen entwickelt. Undokumentierte Eigenschaften lassen sich ohne erhaltene Hardware schwer rekonstruieren.

Digitalisierung macht Originalhardware deshalb nicht überflüssig. Beide Ebenen erhalten unterschiedliche Informationen.

FPGA-Reimplementierung

FPGA-Cores beschreiben digitale Hardware in rekonfigurierbarer Logik und können viele Systemteile parallel ausführen.

Ein FPGA-Core bleibt eine Neuimplementierung. Ungenaue HDL-Modelle werden nicht dadurch automatisch korrekt, dass sie in Hardware laufen.

Host-Latenz und historische Reaktionszeit

USB-Polling, Betriebssystem-Scheduler, Display-Refresh und Audiopuffer fügen Latenz zwischen Eingabe und Ausgabe hinzu.

Ein intern genauer Emulator kann sich deshalb anders anfühlen als Originalhardware am CRT. Messungen sollten Zielsystem und Hostpipeline getrennt betrachten.

50 Hz, 60 Hz und Hostdisplay

PAL- und NTSC-Systeme besitzen unterschiedliche Bildraten. Bei abweichender Hostfrequenz müssen Frames wiederholt, verworfen oder zeitlich angepasst werden.

Variable Refresh Rate kann die Ausgabe verbessern, beseitigt aber nicht alle Timingunterschiede.

Audio-Resampling

Historische Audiotakte passen selten exakt zu modernen Standardabtastraten. Emulatoren müssen Signale daher resamplen.

Filterqualität und Puffergröße beeinflussen Klang und Latenz. Für klangkritische Reproduktionen gehören diese Parameter zur Konfiguration.

Hostsystem und Emulatorversion dokumentieren

Emulatoren verändern sich. Fehler werden korrigiert, alte Workarounds entfernt und interne Formate angepasst.

Für reproduzierbare Ergebnisse werden Emulatorversion, Hostbetriebssystem und relevante Backendoptionen festgehalten.

Konfigurationsdateien sind Archivobjekte

Grafisch eingestellte Maschinen sind schwer reproduzierbar, wenn Parameter nur in einer lokalen Registry oder Benutzeroberfläche existieren.

Exportierbare Konfigurationen gehören zusammen mit Images, Firmwarehinweisen und Prüfsummen ins Archiv.

Version pinnen und trotzdem migrieren können

Eine getestete Emulatorversion liefert einen stabilen Referenzzustand. Neuere Versionen sollten dennoch regelmäßig mit ausgewählten Testobjekten verglichen werden.

Damit bleiben sowohl historische Reproduzierbarkeit als auch ein zukünftiger Migrationspfad erhalten.

Testfälle und Regressionen

Diagnose-ROMs, Demos, Kopierschutzfälle und bekannte Anwendungen decken unterschiedliche Hardwarebereiche ab.

Screenshots, Audiovergleiche und automatisierte Zustandsprüfungen können Veränderungen nach Emulatorupdates sichtbar machen.

Golden Images – Master unverändert halten

Ein Golden Image ist eine schreibgeschützte Referenz. Emulatoren arbeiten auf Kopien oder Overlaydateien.

Dadurch verändern Highscores, Installationen oder Dateisystemzugriffe nicht versehentlich das archivierte Original.

Schreibschutz physisch und digital

Wertvolle Disketten sollten während der Erfassung möglichst gegen unbeabsichtigte Schreibzugriffe geschützt sein. Images werden anschließend read-only eingebunden.

Erfassung und Nutzung erfolgen auf unterschiedlichen Kopien.

Dateiname ist Hinweis, nicht Identität

disk1.adf ist kein eindeutiger Identifier. Namen können geändert werden oder mehrfach vorkommen.

Hashwerte, stabile Objekt-IDs und strukturierte Metadaten bilden die belastbarere Identität.

Archivstruktur – Masters und Derivate trennen

Eine klare Verzeichnisstruktur verhindert, dass Arbeitsdateien mit unveränderten Rohabbildern verwechselt werden.

Masters, derivatives, emulation, metadata und reference können als getrennte Rollen geführt werden.

/object-0001/
  metadata.json
  checksums.sha256
  /masters/
    disk01.scp
  /derivatives/
    disk01.adf
  /emulation/
    machine.cfg
  /reference/
    photos/
    screenshots/

Mehrere Kopien in getrennten Fehlerdomänen

Mehrere Kopien auf demselben Laufwerk schützen nicht vor dessen Ausfall. Kopien im selben Gebäude schützen nicht vor Brand oder Diebstahl.

Robuste Erhaltung verteilt Bestände auf getrennte Geräte und möglichst getrennte Standorte.

Backup und Archiv sind nicht dasselbe

Backups optimieren schnelle Wiederherstellung aktueller Arbeitsdaten. Archive erhalten historische Zustände unverändert und nachvollziehbar.

Backuprotation darf alte Stände löschen; ein Archiv benötigt eigene Aufbewahrungsregeln.

Verlustfreie Kompression und Container

Verlustfreie Kompression spart Platz ohne Nutzdatenverlust. Container können jedoch eigene Metadaten und unterschiedliche Bytefolgen erzeugen.

Es muss klar sein, ob der Hash den originalen Medieninhalt, einen Container oder eine abgeleitete Datei bezeichnet.

Verschlüsselung – Schutz und zusätzliche Abhängigkeit

Verschlüsselung schützt vertrauliche Archive. Ohne Schlüssel ist ein perfekt erhaltenes Bitstreamobjekt jedoch absichtlich unlesbar.

Schlüsselmanagement wird dadurch selbst Teil der Langzeitstrategie.

Cloud-Synchronisation ist kein Archiv

Synchronisation repliziert häufig auch versehentliches Löschen oder beschädigte Dateien. Versionierung und unveränderliche Backups sind davon getrennte Funktionen.

Lokale Prüfsummen sollten unabhängig vom Anbieter erhalten bleiben.

Technischer Erhalt und Nutzungsrechte trennen

Technische Kopierbarkeit beantwortet nicht automatisch die urheberrechtliche Frage. Eigene Werke, freie Software und kommerzielle Software können unterschiedliche Rechtebedingungen besitzen.

Ein Archiv dokumentiert Rechteinformationen und schließt nicht aus technischer Reproduzierbarkeit auf freie Weitergabe.

Alte Medien können personenbezogene Daten enthalten

Festplatten, Disketten, Mailboxarchive und Backups können private Nachrichten, Adressen, Passwörter oder Geschäftsdaten enthalten.

Ein vollständiges Image erhält diese Informationen ebenfalls. Interner Erhalt und öffentliche Bereitstellung sind deshalb getrennte Entscheidungen.

Historische Malware isoliert untersuchen

Alte Images können Bootsektorviren, Makroviren oder ausführbare Schadsoftware enthalten. Einige sind auf modernen Hosts wirkungslos, andere weiterhin gefährlich.

Unbekannte Medien werden in isolierter Umgebung mit deaktivierten Hostfreigaben und kontrolliertem Netzwerk untersucht.

Shared Folders sind eine Brücke zum Host

Gemeinsame Zwischenablage, Drag-and-drop, Netzwerkbrücken und Shared Folders erhöhen Komfort und verkleinern Isolation.

Bei unbekannter Software werden solche Integrationen minimiert; das Archivmaster bleibt außerhalb der Arbeitsumgebung.

Auch der Emulator selbst muss erhalten werden

Wenn ein Objekt nur mit einer bestimmten Emulatorversion korrekt läuft, wird dieser Emulator zur Abhängigkeit.

Quellcode, Buildhinweise und Releasebinary werden deshalb soweit möglich zusammen dokumentiert.

Handbücher und Schaltpläne erhalten

Software ohne Handbuch kann unverständlich werden. Tastenkombinationen, Diskettenwechsel, Installationspfade und Hardwareanforderungen fehlen sonst.

Service- und Entwicklerunterlagen sind zusätzlich entscheidend für genaue Emulation und spätere Reparatur.

OCR ist ein Zugriffsderivat

Durchsuchbarer OCR-Text erleichtert Recherche in gescannten Handbüchern, kann aber Code, Tabellen und Hexwerte falsch erkennen.

Der Bildscan bleibt Master; OCR wird als zusätzliche Schicht gespeichert.

Fotos verbinden Image und physisches Original

Platinen, Labels, Seriennummern, Diskettenetiketten und Verpackungen enthalten Informationen, die im digitalen Dump fehlen.

Fotos vor Reparatur oder Reinigung dokumentieren ursprünglichen Zustand und Provenienz.

Authentizität heißt nachvollziehbare Veränderungsgeschichte

Authentizität verlangt nicht, dass nur ein einziges Format existiert. Ein konvertiertes Image kann als Derivat authentisch dokumentiert sein, wenn Master und Transformationsweg erhalten bleiben.

Problematisch sind unprotokollierte Änderungen, die später mit dem Original verwechselt werden.

Welche Eigenschaften müssen erhalten bleiben?

Bei Text kann Byteidentität im Vordergrund stehen. Bei Spielen und Demos zählen zusätzlich Timing, Video, Audio, Eingabe und Speichermedienverhalten.

Preservation-Ziele sollten deshalb ausdrücklich benennen, welche Eigenschaften als signifikant gelten.

Access Copy – bequem nutzbar, Master unverändert

Eine Zugriffskopie kann konvertiert, komprimiert oder auf einen Emulator zugeschnitten werden.

Sie darf ersetzt werden, solange das unveränderte Master und die Transformationshistorie erhalten bleiben.

Mehrere Derivate sind sinnvoll

Fluxmaster, Sektorimage und extrahierte Dateien erfüllen verschiedene Aufgaben: Neuinterpretation, Emulation und direkte Analyse.

Diese Mehrschichtigkeit erhöht Robustheit, wenn Herkunft und Ableitung klar dokumentiert sind.

Konvertierungen protokollieren

Quellhash, Zielhash, Werkzeug, Version, Parameter und Datum gehören zu jeder relevanten Formatumwandlung.

Damit lässt sich später unterscheiden, ob eine Abweichung aus dem Original oder aus dem Konverter stammt.

Automatisierte Preservation-Pipelines

Hashberechnung, Dateityperkennung, Metadatenextraktion und Derivaterzeugung lassen sich automatisieren.

Eine Pipeline darf Rohdaten niemals still überschreiben und muss Fehler sichtbar protokollieren. Versionierter Pipeline-Code gehört selbst zur Dokumentation.

Inventar – wissen, was vorhanden ist

Ohne Bestandsverzeichnis lassen sich Vollständigkeit, Speicherort und Fixity nicht zuverlässig verwalten.

Jedes Objekt benötigt eine stabile Kennung; Zustand, Rechte, Priorität und letzte Prüfung können zusätzliche Felder sein.

Zuerst die gefährdetsten Originale sichern

Seltene Disketten, alternde Festplatten, EPROMs und proprietäre Wechselmedien besitzen unterschiedliche Ausfallrisiken.

Priorität erhalten Objekte, deren Inhalt nicht anderweitig verifiziert ist oder deren Lesegerät zu verschwinden droht.

Lesegeräte und Adapter mitdenken

SCSI-Wechsellaufwerke, Bandlaufwerke, proprietäre Karten und Spezialkabel können notwendig sein, um Originaldaten erneut auszulesen.

Dokumentierte Interfaces gehören zur Erhaltungsinfrastruktur. Vertiefung: interfaces.htm und laufwerke-und-diskettenstationen.htm.

Originalmedium möglichst wenig belasten

Jeder Leseversuch kann bei mechanisch geschädigten Bändern, Disketten oder Festplatten weitere Schäden verursachen.

Lesegeräte werden zuerst mit unkritischen Medien geprüft. Auffälliger Abrieb, Geräusche oder mechanischer Widerstand sind Gründe für einen Abbruch statt für weitere Versuche.

Festplatte – Image vor Dateisystemreparatur

Bei alten Festplatten kann jede zusätzliche Betriebsstunde riskant sein. Wenn das Laufwerk stabil liest, hat ein möglichst vollständiges Image Vorrang vor schreibenden Reparaturwerkzeugen.

Das Masterimage bleibt read-only; Dateisystemreparatur erfolgt auf Kopien.

CHS-Geometrie und BIOS-Kontext

Historische PC-Festplatten können von Cylinder/Head/Sector-Geometrie und BIOS-Translation abhängen. Derselbe lineare Datenstrom kann unter falscher Geometrie vom Gast anders interpretiert werden.

Maschinenkonfiguration und Image werden deshalb zusammen dokumentiert.

SyQuest und Wechselplatten

Wechselplatten verbinden magnetische Medien und präzise Mechanik. Langzeiterhalt benötigt entweder funktionsfähige Laufwerke oder rechtzeitiges Imaging.

Mehrere Generationen sind nicht beliebig kompatibel. Vertiefung: syquest.htm.

Dateien zusätzlich aus Images extrahieren

Extrahierte Dateien sind direkt durchsuchbar und analysierbar. Hostdateisysteme können jedoch Resource Forks, Attribute, alternative Datenströme oder ungewöhnliche Namen verlieren.

Die Extraktion ist deshalb ein Derivat, kein Ersatz des Images.

Zeitstempel bewahren

Alte Dateisysteme speichern Zeitstempel mit begrenzter Auflösung, ohne Zeitzone oder mit engen Jahresbereichen.

Eine normale Hostkopie kann diese Werte verändern. Das Image bleibt die zuverlässigere Quelle für originale Metadaten.

PETSCII, ATASCII, CP437 und andere Zeichensätze

Historische Plattformen verwenden Zeichencodierungen, die nicht direkt Unicode entsprechen. Beim Extrahieren können Zeichen transliteriert oder Dateinamen verändert werden.

Die Bytewerte im Originalimage bleiben deshalb erhalten; Konvertierungen werden dokumentiert.

RAM-Dumps – flüchtigen Zustand erfassen

Memory Dumps können laufende Programme, ungespeicherte Daten und Hardwarepuffer enthalten. Für Debugging und Forensik sind solche Zustände wertvoll.

Sie enthalten jedoch potenziell sensible Daten und ersetzen keine dauerhaften Medienimages.

Historische Browserumgebungen

Alte Webangebote können auf frühere JavaScript-Engines, Layoutfehler, Plugins oder TLS-Versionen angewiesen sein.

Ein heutiger Browser ist deshalb nicht immer eine authentische Wiedergabe. VM oder PC-Emulator plus Referenzscreenshots können historische Darstellung ergänzen.

Flash, Java-Applets und ActiveX

Pluginbasierte Webinhalte bestehen aus mehr als dem umgebenden HTML. Runtime, Pluginversion und eingebettete Datei gehören zur Anwendung.

Sicherheitskritische alte Plugins werden nur in isolierten Umgebungen betrieben.

CGI, PHP, Perl und serverseitige Anwendungen

Ein Crawl konserviert sichtbare Ausgaben, aber nicht automatisch die serverseitige Logik. Quellcode, Interpreter, Webserverkonfiguration und Datenbank bilden die eigentliche Anwendung.

Für technische Webgeschichte sind beide Ebenen wertvoll.

DNS und hart kodierte Hostnamen

Historische Anwendungen können feste Hostnamen erwarten. Domains und öffentliche Server ändern sich im Lauf der Zeit.

Eine isolierte Rekonstruktionsumgebung kann lokale Namensauflösung bereitstellen. Vertiefung: domains-dns-und-webhosting.htm.

Alte TLS-Versionen und Zertifikate

Historische Clients unterstützen teilweise nur heute unsichere Protokolle oder Cipher Suites. Für Forschung können solche Bedingungen isoliert rekonstruiert werden.

Unsichere historische Dienste gehören nicht ungeschützt ins öffentliche Produktionsnetz.

Ein reproduzierbares Emulationspaket

Ein technisches Paket beschreibt Medienimages, Firmwareanforderung, Emulatorversion, Maschinenkonfiguration, Prüfsummen und Startschritte.

Nicht weitergebbare ROMs können über Hashwerte und eindeutige Bezeichnungen referenziert werden, ohne sie in ein öffentliches Paket einzuschließen.

README – kleine Datei, große Wirkung

Eine menschenlesbare README erklärt Objektzweck, Master, Derivate, benötigte Firmware und reproduzierbaren Startweg.

Sie verhindert, dass zukünftige Nutzer nur unbekannte Dateiendungen und kryptische Konfigurationen vorfinden.

Machine Manifest

Ein Maschinenmanifest kann CPU, Takt, RAM, BIOS, Grafik, Sound, Controller, Laufwerke und Eingabegeräte beschreiben.

Bei Heimcomputern genügt oft Modell plus ROM- und Video-Norm; bei PC-Systemen können konkrete Karten und BIOSstände entscheidend sein.

Software Manifest

Titel, Version, Sprache, Region, Publisher, Medienseite, Seriennummer und bekannte Patches gehören in ein Softwaremanifest.

Mehrdisketten-Sets benötigen Reihenfolge und Zuordnung. Hashwerte binden Metadaten an konkrete Dateien.

Validierung – nicht nur Hash prüfen, sondern starten

Eine Datei kann ihren korrekten Hash besitzen und trotzdem wegen fehlender Firmware oder falscher Maschinenkonfiguration nicht nutzbar sein.

Regelmäßige Stichproben booten, mounten oder dekodieren ausgewählte Objekte zusätzlich zur Fixity-Prüfung.

Zukunftssicherheit heißt Interpretierbarkeit

Kein Archiv kennt die Hostplattformen in fünfzig Jahren. Robustheit entsteht aus offenen Formaten, mehreren Repräsentationsebenen, Provenienz, Quellcode und unabhängigen Prüfsummen.

Je weniger undokumentierte Abhängigkeiten existieren, desto größer ist die spätere Rekonstruktionschance.

Häufige Irrtümer über Emulation und Erhalt

Ein ROM-Ordner ist kein vollständiges Softwarearchiv. Ein ISO ist nicht automatisch eine vollständige CD-Repräsentation. Ein bootendes Image ist nicht automatisch fehlerfrei.

Emulation macht Originalhardware nicht überflüssig, und ein Save State ist kein stabileres Archivformat als das Originalmedium.

• Bit-Level-Erhalt ist Fundament, aber keine Garantie späterer Nutzbarkeit.
• Sektor-, Track- und Fluximages bewahren unterschiedliche Ebenen.
• ROM-Dump und Cartridge-Hardware sind nicht immer identisch.
• Firmwareversionen gehören zur Reproduzierbarkeit.
• Hashes identifizieren Bytefolgen, nicht automatisch Herkunft.
• Save States sind häufig versionsabhängig.
• VM-Snapshots können von Basisimages abhängen.
• Konvertierungen dürfen Masters nicht ersetzen.
• Quellcode benötigt Buildumgebung und Dependencies.
• Netzwerksoftware kann Serverdienste voraussetzen.
• Genauigkeit umfasst Timing, Video, Audio, Eingabe und Controller.

Praktischer Preservation-Workflow

Ein belastbarer Ablauf beginnt mit Inventarisierung und physischer Begutachtung. Danach folgt die möglichst schonende Erfassung, sofortige Prüfsummenbildung und schreibgeschützte Ablage des Masters.

Erst auf Arbeitskopien folgen Dekodierung, Dateiextraktion, Formatkonvertierung und Emulatoranpassung.

• 1. Objekt identifizieren und fotografieren.
• 2. Medium und Lesegerät prüfen.
• 3. Rohabbild oder vollständigen Dump erzeugen.
• 4. SHA-256 und relevante zusätzliche Hashes berechnen.
• 5. Master read-only ablegen.
• 6. Derivate aus Kopien erzeugen.
• 7. Inhalte extrahieren und analysieren.
• 8. Emulator, Firmware und Maschinenkonfiguration dokumentieren.
• 9. Referenzstart und Kernfunktionen testen.
• 10. Metadaten, Logs und Prüfsummen gemeinsam ablegen.
• 11. Kopien auf getrennte Speicherorte verteilen.
• 12. Fixity und Funktionsfähigkeit regelmäßig prüfen.

Einordnung im SSLXY-Archiv

Diese Seite verbindet Datenträger, Rechnerarchitektur, Programmierung, Betriebssysteme, Netzwerke und Backups. Digitaler Erhalt ist die Klammer zwischen gespeicherten Bits und späterer Nutzbarkeit.

Direkte Nachbarthemen sind Dateisysteme und Datenträger, Datensicherung und Backups, Laufwerke und Diskettenstationen, Arbeitsspeicher, ROM und Speichererweiterungen, Prozessoren und Rechnerarchitekturen und Programmierung und Skripting.

Verwandte Themen im SSLXY-Archiv

Emulation und digitaler Erhalt berühren nahezu jede historische Technikseite. Die folgenden Seiten bilden die wichtigsten direkten Nachbarn.