Emulation bzw. emulieren (von lateinisch aemulari: „sich bestreben es jemandem in einer Sache ganz gleich zu thun“^[1]Georges, K. E.: Ausführliches lateinisch-deutsches Handwörterbuch. unveränderter Nachdruck der 7. verbesserten und vermehrten Auflage, Hannover: Hahnsche Buchhandlung, 1911, S. 64. bezeichnet allgemein Verfahren zur Nachahmung oder Nachbildung von Gegenständen oder Lebewesen. Im Kontext der Informatik meint Emulation die Nachahmung von bestimmten Teilaspekten eines Computersystems mittels Soft- oder Hardware, welche als Emulator bezeichnet werden. Ein solcher Emulator ist in der Lage, die Software eines Systems A (beispielsweise ein obsoleter Heimcomputer, wie der Commodore 64) auf einem System B (z.B. ein aktueller Intel-PC) auszuführen und erzielt im Idealfall bei gleichen Eingabedaten die gleichen Ergebnisse. Die Maschinenbefehle des Originalsystems werden (zumeist) zur Laufzeit in entsprechende semantisch äquivalente Softwarebefehle des Hostsystems übersetzt. Emulatoren arbeiten somit ähnlich wie Compiler.^[2]Für eine komprimierte Einführung in das Gebiet der Übersetzung von Programmen mittels Cross-Compilern im Zusammenhang mit Emulatoren siehe Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, … Continue reading Anders als die Migration, setzt die Emulation also nicht am Objekt selbst, sondern an der Soft- und Hardwareumgebung des digitalen Objektes an. Emulatoren sind dadurch in der Lage die temporale und technologische Kluft zwischen zwei Rechnersystemen zu überbrücken. Zentrale Idee ist die Loslösung der Bindung bzw. Abhängigkeit des digitalen Objektes von der Originalhardware.

Dabei wird der Begriff in Abgrenzung zur Simulation verwendet, bei der eine Reduktion auf spezifische Eigenschaften im Vordergrund steht und der in der Regel ein abstraktes oder abstrahiertes Modell zugrunde liegt. Demgegenüber verfolgt die Emulation einen ergebnisorientierten Ansatz: Gleiche Eingaben sollen zu gleichen Ausgaben führen, wobei die internen Zustände des Systems je nach Grad der Abstraktion weniger von Interesse sind. Dies spiegelt sich auch in den verschiedenen Definitionsversuchen für die Emulationsstrategie im Kontext der Langzeitbewahrung wieder.^[3]vgl. u.a. UNESCO (Hrsg.): Guidelines for the Preservation of Digital He­ritage. Dokument CI-2003/WS/3, 2003 und Neuroth, H. (Hrsg.); et al.: Eine kleine Enzyklopädie der digitalen … Continue reading Eine Einführung in das Konzept der Emulation sowie die Klassifikation von Emulatoren und Formen der Binärübersetzung im Kontrast zu anderen Methoden ist in [Tijms 2000] zu finden. Für Tijms ist Emulation “[…] the art of presenting an environment to a binary, which behaves just like its original target environment”.^[4]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 1.

In der Langzeitbewahrung bietet der Emulationsansatz die Möglichkeit, obsolete Systeme (Hard- und Software) durch deren Imitation auf der aktuellen Gerätegeneration wieder erlebbar und zugänglich zu machen. Dabei existieren verschiedene Umsetzungen sowohl auf Softwareals auch auf Hardwareebene. Zur Erstellung eines Emulators sind aber in jedem Fall umfangreiche und fundierte Kenntnisse über das zugrunde liegende System vonnöten.

In den folgenden Abschnitten dieses Kapitels werden die verschiedenen Emulationstechniken in allen Facetten ausführlich behandelt. Das Thema wird in den historischen und wissenschaftlichen Kontext eingeordnet und die Funktionsweise von Emulatoren technisch untersucht, um Grenzen bei der Erhaltung dynamischer Objekte eruieren und Chancen aufzeigen zu können.

3.1 Historische Entwicklung und Anforderungen

Die Emulation ist in der Informatik ein altbekanntes, gut verstandenes und bewährtes Konzept. Die Verwendung des Begriffs Emulation bzw. Emulator im informatischen Sinne als Nachahmung von Computersystemen geht zurück auf die IBM. Als diese in den 1960er-Jahren die konzeptionell vollkommen neue und zur alten Rechnergeneration inkompatible 360-Rechnerarchitektur zusammen mit dem Betriebssystem OS/360 einführte, musste eine Lösung für die vielen bestehenden Programme der IBM 7070-, 7090- und 7094-Maschinen gefunden werden. Die IBM-Ingenieure Larry M. Moss und Stuart G. Tucker kamen auf die Idee, für die 360-Rechner eine Kombination spezieller Hardware-Befehlserweiterungen und Software zu entwickeln, die es ermöglicht, die Befehle der alten 7070-Programme zur Laufzeit in kompatible Befehle für die 360-Architektur zu übersetzen und dadurch Rechner der alten Generation zu „simulieren“. Somit konnten 7070-Programme auf der neuen Rechnerarchitektur ausgeführt werden. Ein 360-Rechner verhielt sich für 7070-Programme wie ein 7070-Computer. Moss brachte Tucker dabei auf die Idee, die Softwareübersetzung zur Steigerung der Ausführungsgeschwindigkeit durch spezielle Hardware(befehle) zu unterstützen. Für die Kombination aus Software, Microcode und Hardware fand er den Begriff „Simulator“ nicht mehr passend. Er schlug deshalb aufgrund der lateinischen Bedeutung „Emulator“ bzw. „Emulation“ als neue Namen vor.^[5]vgl. Pugh, E. W.; Johnson, L. R.; Palmer, J. H.: IBM’s 360 and Early 370 Systems. Cambridge: M.I.T. Press, 1991, S. 161]. [Pugh u.a. 1991]^[6]ebenda. bietet eine umfangreiche historische Dokumentation zu IBMs 360 und frühen 370er-Systemen.

In [Tucker 1965]^[7]Tucker, S. G.: Emulation of large systems. In: Communications of the ACM, Volume 8, Number 12, 1965, S. 753–761. beschreibt Tucker erstmals das neue Emulationssystem, den „Emulation-Mode“ der IBM 360, und die prinzipielle Funktionsweise eines Emulators. Er führt an, das alternative Techniken zur Programmkonvertierung auf die 360-Architektur, wie die Übertragung in Hochsprachen, Re-Kompillierung oder Neuprogrammierung, ungeeignet sind, nicht ökonomisch und schlecht skalieren.^[8]vgl. ebenda. Für ihn bedeutete die schrittweise Interpretation und Übersetzung des Programms mittels eines Emulator die einzige Möglichkeit, diese Programme zu transferieren. Für ihn meint Emulation allerdings immer die Kombination von Hard- und Software:

Grund ist die Ausführungsgeschwindigkeit und Eigenschaften der damaligen Rechner. Die IBM-Maschinen besaßen zu wenig Speicher und Register, um die alte Rechnergeneration nachahmen zu können. Diese Funktionen musste daher in extra Hardware mit Zusatzbefehlen (die in Software lange Ausführungszeiten haben) implementiert werden. Ein reiner Software-Emulator wäre zu langsam gewesen.

Durch die rasante Entwicklung der PC-Technologie hat sich dieser Nachteil etwas relativiert, sodass heutzutage mit dem Begriff Emulator üblicherweise reine Software-Emulatoren gemeint sind (die Emulation von Hardware mittels Software). Dies gilt insbesondere im Kontext der Langzeitbewahrung.

Das Prinzip der Emulation ist so einfach wie wirkungsvoll, weswegen sie in verschiedenen Anwendungsgebieten zum Einsatz kommt und heute weit verbreitet ist. Bereits in den 1970er-Jahren wurde die Technik auch in Deutschland in der Lehre vermittelt und eingesetzt.^[10]vgl. u.a. Knorz, P.; Bressler, H.: Einführung in die Elektronische Datenverarbeitung, Band 3. Wiesbaden: TR-Verlagsunion, 1973. Im Laufe der Jahre wurden die Emulationstechniken immer weiter verfeinert.

Haupteinsatzzweck bleibt die Herstellung von Rückwärtskompatibilität zu älteren Systemen und Architekturen. Coy nennt u. a. die verschiedenen Generationswechsel von Apple-Computern – zuerst von den frühen 68000-Prozessoren zur PowerPC-Architektur dann von PowerPC- zu Intel-CPUs – als erfolgreiche Praxisbeispiele für den Großeinsatz von Emulation. Apple baute Software-Emulatoren in sein Betriebssystem ein, die es Kunden ermöglichten, Programme der alten und neuen Rechnerarchitektur bzw. Systeme gleichzeitig zu betreiben.^[11]vgl.Coy, W.: Perspektiven der Langzeitarchivierung multimedialer Objekte. [= Kompetenznetzwerk Langzeitarchivierung (Hrsg.): nestor-materialien, Nummer 5], 2006, S. 58f. Aber auch in Geräten wie Druckern bzw. Druckertreibern wird Emulation eingesetzt, um beispielsweise Kompatibilität zur PostScript-Druckersprache herzustellen. Emulation ist ebenfalls eine gängige Praxis zum Design neuer Rechnersysteme, zur Schaltkreissimulation (sogenannte In-Circuit-Emulatoren^[12]vgl. auch Chung, E. S.; Nurvitadhi, E.; Hoe, J. C.; Falsafi, B.; Mai, K.: Virtualized Full-System Emulation of Multiprocessors using FPGAs. In: WARP 2007, 2nd Workshop on Architectural Research … Continue reading), usw. sowie als „Sandbox“ für Testzwecke, um eine sichere Ausführungsumgebung zu bieten. Software-Emulatoren sind kommerziell weit verbreitet.

Im Bereich von Computerspielen haben die Hersteller das Potenzial von Emulation ebenfalls bereits erkannt und bieten Emulatoren an, um ältere Spiele für aktuelle Systeme zu portieren. Dies war jedoch nicht immer der Fall. Als die Firma Coleco 1982 eine Emulator für ihr System herausbrachte, der es ermöglichte, Spiele (in Form Steckmodulen, sogenannten Cartridges) des Konkurrenzsystems VCS 2600 der Firma Atari Inc. auf Coleco-System abzuspielen, wurde sie von Atari auf Schadensersatz und Unterlassung verklagt. Coleco musste letztendlich Lizenzgebühren an Atari bezahlen.

Daneben existiert eine Szene von Hobbyisten, die sogenannte „Emulatoren-Community“. Diese Interessengemeinschaft verfolgt das Ziel, Spiele der eigenen Kindheit und Jugend und die dazugehörigen Systeme dauerhaft spielbar zu erhalten. Dazu findet vorwiegend über das Internet ein Gesprächs- und Wissensaustausch statt und es werden Emulatoren für obsolete Heimcomputer und Konsolen entwickelt, die in der Regel frei und quelloffen über das Internet der Allgemeinheit zur Verfügung gestellt werden.

Ebenso rückt das Thema im wissenschaftlichen Bereich im Zusammenhang mit der Bewahrung von dynamischen interaktiven Objekten in den Fokus der Forschung, da die Emulationstechnik als einzige geeignet scheint, die hohen Anforderungen dieser Klasse von Objekten zu erfüllen. Jeff Rothenberg hat als erster die Emulation im Kontext der Langzeitbewahrung propagiert und populär gemacht. Er startete eine Reihe von Fallstudien und stellte Kriterien für eine erfolgreiche Emulationsstrategie auf (siehe Abschnitt 3.2.1). Die verschiedenen Interessengemeinschaften werden in Abschnitt 4.3 genauer betrachtet.

Anforderungen an Emulation im Rahmen der Langzeitarchivierung

Um Emulation als Bewahrungsstrategie einzusetzen, bedarf es einer Einbettung in etablierte Bewahrungsstrukturen und Workflows wie dem OAIS-Modell. Dabei müssen insbesondere für dynamische und komplexe Objekte die technischen Gegebenheiten des Ansatzes beachtet werden. Rothenberg sieht entsprechend für den Ingest nach OAIS eine Kapselung des konzeptuellen Objekts durch die Erstellung eines sogenannten Images (Abbild) sowie die Anreicherung mit für den Emulator erforderlichen technischen Metadaten vor.^[13]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 47. Die Imageerstellung ist der technischen Funktionsweise vieler Emulatorprogramme geschuldet. Die konzeptuelle Repräsentation eines komplexen digitalen Objekts besteht auf der logischen und technischen Ebene zumeist aus einer Sammlung digitaler Entitäten (Dateien). Diese sind systemabhängig so strukturiert, dass sie von bestimmter Systemsoftware und dafür bestimmten Applikationen interpretiert werden können. Für Rothenberg ist es daher einfacher, ein Image dieser Repräsentation zu erstellen, welches alle Komponenten beinhaltet und von Emulatoren verarbeitet werden kann.^[14]vgl. ebenda, S. 37 sowie Abschnitt 5.2. Die angelegten Metadaten sollen für Rothenberg Referenzen auf passende Emulationsumgebungen enthalten.

Diese Referenz zwischen Dokument und Emulator muss über den wiederkehrenden Prozess der Bitstream- und Metadaten-Preservation erhalten bleiben. Das Emulationsprogramm muss dabei ebenfalls Teil des Archivs sein und dem Langzeitbewahrungsprozess unterworfen werden. Sobald notwendig, muss dieses (oder die virtuelle Umgebung für die es programmiert wurde) durch eine aktuelle Version bzw. eine Version für die dann aktuelle Rechnergeneration ersetzt werden.^[15]vgl. ebenda, S. 47 sowie Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003, S. 66ff. Beim Access (siehe OAIS) muss dann eine Abspielumgebung bestehend aus Emulatorprogramm, notwendigen Zusatzkomponenten und dem digitalen Objekt für den Nutzer bereit gestellt werden.

Das Herzstück des Ansatzes bilden also die Emulatorprogramme. Sie müssen entwickelt, gewartet und in Archivierungssysteme integriert werden, wobei pragmatische und ökonomische Gesichtspunkte zu beachten sind (siehe Abschnitt 4.3). Rothenberg nennt dementsprechend die Entwicklung von Techniken zur Spezifikation von Emulatoren für künftige unbekannte Systeme, zur Aufbewahrung von Annotationen und Erklärungen in menschenlesbarer Form sowie zur Kapselung und Verlinkung des digitalen Objekts, der notwendigen Betrachtungssoftware und des Emulatorprogramms als Kernanforderungen.^[16]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 32 [abgerufen 24.04.2008].

Die Bewahrung dynamischer Objekte erfordert ein Höchstmaß an Authentizität der emulierten Umgebung, um die Interaktion originalgetreu zu erhalten. Das Konzept der Authentizität ist jedoch ein externes, also nicht dem Objekt innewohnendes Konstrukt. In der Informatik kann dies nur im Rahmen technischer Anforderungen, wie Authentizitätsstufen oder Implementierungsdetails einer Software (siehe Abschnitt 3.6) diskutiert werden. Das Konzept ist jedoch wesentlich breiter und schließt die gesamte Interaktion mit der originalen Abspielumgebung sowie bestimmte Aufführungspraxen mit ein, welche in Kapitel 4 genauer betrachtet werden. Auf der technischen Ebene nennt Supnik Anforderungen an Emulationssoftware für dynamische Objekte. Diese muss das System selbst originalgetreu nachbilden, ebenso wie die vom Objekt erwartete Systemumgebung inklusive komplexer Ein-/Ausgabe- und Timing-Strukturen und darüber hinaus eine adäquate Performance besitzen, um benutzbar zu sein.^[17]vgl. Supnik, R. M.: Simulators: virtual machines of the past (and future). In: ACM Queue, Volume 2, Number 5, Issue July/August 2004, S. 53–58. Daraus ergibt sich die Notwendigkeit, alle signifikanten Details der Abspielumgebung bzw. des Abspielkontextes zu identifizieren, zu erfassen und zusammen mit dem Objekt im Langzeitarchiv zu speichern.

Der Emulationsansatz bedingt jedoch implizit eine weitere neue Klasse von Anforderungen. Da das Originalsystem bzw. die Originalumgebung nachgeahmt werden und mit dem Objekt im Rahmen dieser obsoleten Systemumgebung interagiert wird, muss auch das Wissen über die Bedienung des historischen Systems gesondert gesammelt, gespeichert und dem Nutzer bei der Betrachtung des Objekts in adäquater Form zur Verfügung gestellt werden. Andernfalls droht de facto ein Verlust der Interaktion mit dem Objekt, wenn ein Nutzer beispielsweise nicht über das Wissen verfügt, ein Spiel für den C64 Heimcomputer mittels Befehlen an das BASIC-Textinterface zu laden und starten. Die Interaktion mit dem emulierten System unterliegt prinzipiell den Beschränkungen des Originalsystems. Verbesserungen bei der Nutzinteraktion und Softwareergonomie, die Anwender aktueller und künftiger System erwarten bzw. gewohnt sind, sind auf dem obsoleten System nicht vorhanden.

Mit dem langsamen Verschwinden obsoleter Systeme vom (Gebraucht-) Markt geht oft der Verlust von System-Dokumentationen wie Designplänen, Hardwarebeschreibungen und Schaltplänen aber auch Wissen über die Benutzung der Systeme und deren typische Rezeptionsumgebung einher.^[18]Letzterem kann zeitnah u. a. mit ethnographischen Methoden begegnet werden. So widmet sich beispielsweise die Website http://www.folklore.org/ der Sammlung von Anekdoten und Zeitzeugenberichten der … Continue reading

Die Erstellung eines Emulators, der den Anforderungen von Supnik gerecht wird benötigt allerdings umfangreiche Kenntnisse der Interna des zu emulierenden Systems und ist dementsprechend aufwendig (siehe Abschnitt 3.5).

Es ist daher essenziell, den Emulator als integralen Baustein dieses Ansatzes, und seine Funktionsweise vor allem aus technischer Sicht – aber auch im Rahmen des beteiligten sozio-ökonomischen Entstehungsprozesses und beteiligter Akteure – differenzierter und genauer zu betrachten.

3.2 Forschungsprojekte und Vorarbeiten

Um in der Langzeitbewahrung verwendete Emulatoren untersuchen zu können, sollen zunächst repräsentative Forschungsprojekte und Vorarbeiten untersucht werden, die sich primär mit Emulationstechnik in diesem Kontext auseinandersetzen. Nachfolgend werden daher die wichtigsten internationalen Projekte vorgestellt, die Emulation als zentrale Bewahrungsstrategie verwenden.

Der Diskurs wird dabei vor allem durch Universitäten sowie Bibliotheken und andere Gedächtnisorganisationen geprägt, die das Problem früh erkannt bzw. die über einen meist großen zu erhaltenen Bestand digitaler Artefakte verfügen (siehe Abschnitt 2.1).

Neben den vorgestellten Projekten existieren eine Reihe weiterer Projekte, Forschungsverbünde und Organisationen zum Thema Langzeitarchivierung allgemein, von denen einige ebenfalls Emulation als eine mögliche Strategie mitbehandeln, jedoch den Rahmen sprengen und außerdem keine neuen Aspekte hervorbringen würden.

Die folgenden Vorarbeiten werden im weiteren Verlauf einer Analyse unterzogen. Dabei wird den Gesichtspunkten welche Emulatoren ausgewählt oder entwickelt wurden, welche Ausschlusskriterien es gab (siehe Abschnitt 4.3), welche Kompatibilitätsstufe und technische Abstraktionsebene die gewählten Emulatoren verwenden (siehe Abschnitt 3.6) und welche Zielvorgaben an die Emulation und die Art der zu archivierenden Objekte gemacht wurden (siehe Kapitel 4) besonderes Augenmerk gewidmet.

3.2.1 Anfänge: Jeff Rothenberg, Fallstudien mit der KB der Niederlande

Als der erste Befürworter des Einsatzes von Emulation im Kontext des Langzeitbewahrung digitaler Artefakte ist Jeff Rothenberg zu nennen. Bereits 1995 legte er den Grundstein in einem Artikel der Zeitschrift Scientific American.^[19]vgl. Rothenberg, J.: Ensuring the longevity of digital documents. In: Scientific American, Volume 272, Issue 1 (January), 1995, S. 42–47. Rothenberg erkannte das Haltbarkeitsproblem digitaler Medien im Zusammenhang mit dem schwerwiegenderen Problem, digitale Bitströme dauerhaft interpretieren zu können.^[20]vgl. ebenda, S. 46. Er zog 1995 aus diesen ungelösten Problemen das pointierte und ernüchternde Fazit “[i]t is only slightly facetious to say that digital information lasts forever – or five years, whichever comes first”^[21]ebenda, S. 42. und wies damit auf die Dringlichkeit der Suche nach praktikablen Lösungsansätzen zur Erhaltung digitaler Kulturgüter hin.

Rothenberg zeigte die Grenzen der Formatmigration und des Museumsansatzes auf sah in Folge die Methode der Emulation als Ausweg. Unter der Prämisse, dass zukünftige Computer immer deutlich leistungsfähiger sein werden als die aktuelle Generation, forderte er auf, Emulatorprogramme zu schreiben, mit deren Hilfe diese alten Systeme emuliert werden können. Als Hauptnachteil der Strategie nennt Rothenberg die Erfordernis detaillierter Spezifikation sowie Detailkenntnissen der alten Hardware, die zur Programmierung zwingend benötigt werden und daher ebenfalls verfügbar archiviert werden müssen.^[22]vgl. ebenda, S. 47.

Rothenberg arbeitete seine Überlegungen in den folgenden Jahren systematisch aus und bewies in ersten Versuchen die generelle Tauglichkeit von Emulation. In [Rothenberg 1999] nennt er drei Schritte, die für eine erfolgreiche Emulationsstrategie erfüllt und die für Lösungen gefunden werden müssen:^[23]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 17 [abgerufen 24.04.2008].

• Die Entwicklung einer generischen Methode zur Spezifikation von Emulatorprogrammen für künftige unbekannte Computersysteme,
• die Entwicklung von Methoden zur Speicherung von Metadaten, die alle Aspekte erfassen, mit denen das Verhalten und Look-and-Feel aller aktuellen und künftigen digitalen Dokumente in menschenlesbarer Form erfasst werden kann und
• die Entwicklung von Methoden zur Einbettung dieser Informationen (Metadaten, Software, Emulatorspezifikationen) mit digitalen Dokumenten, sodass diese nicht beschädigt (corruption) werden können.

Diese Schritte sollten als Prozess gesehen werden. Insbesondere Metadaten und Spezifikationen müssen immer wieder neu „übersetzt“ (transliterate) werden, damit sie für künftige Systeme auswertbar bleiben.^[24]vgl. ebenda, S. 18. Es ergibt sich ein Bewahrungspfad der Systemhardware über den Emulator, das Betriebssystem bis hin zum Dokument. Diese Idee wird später von Dirk von Suchodoletz mit seinen „View-Paths“ aufgegriffen^[25]vgl.von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009. und um Wahlmöglichkeiten erweitert. Sie bildet auch die zentrale Metapher der Softwareprodukte von Forschungsprojekten wie KEEP (Emulation Framework) oder PLANETS.^[26]Für nähere Informationen siehe Abschnitt 3.2.3 bzw. 3.2.4 respektive.

Im Rahmen seiner ersten Fallstudien stellte sich die Emulation als vielversprechender Kandidat für eine dauerhafte Langzeitbewahrungsstrategie heraus.^[27]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 30 [abgerufen 24.04.2008.

Rothenberg führte daraufhin eine langfristig angelegte Praxisstudie zur Erprobung von Emulation in Zusammenarbeit mit der Koninklijke Bibliotheek (KB, Staatsbibliothek der Niederlande) an einer Auswahl des KB-Bestandes durch. Entwickelt werden sollte eine prototypische Experimentalumgebung mithilfe bereits bestehender kommerzieller und Open-Source-Emulationssoftware (components off-the-shelf, COTS), welche sich in den OAIS- und DSEP-Bewahrungsworkflow integrieren lässt.^[28]vgl. Rothenberg, J.: An Experiment in Using Emulation to Preserve Digital Publications. Den Haag: Koninklijke Bibliotheek (NEDLIB Report Series), 2000. Besonderes Augenmerk wurde bei dem dreistufig iterativ ausgelegten Experiment auf die Festlegung und Erstellung von Metadaten im Hinblick auf die Emulationsstrategie sowie der Untersuchung alternativer Spezifikationssprachen mit dem Ziel der Erstellung einer Emulatorspezifikation gerichtet.^[29]vgl. ebenda, S. 50ff.

Rothenberg stellte erstmals Authentizitätskriterien auf, die sich nach einem “Authenticity Principle” absteigend von “[…] retain as much as possible of the exact function, form, appearance, look, and feel that the [sic!] it presented to its author or publisher” zu “[…] retain the function, form, appearance, look, and feel that it presented to its original intended audience (or readership)”^[30] ebenda, S. 71f. formulieren lassen.

Es wird also vom Betrachter und dessen Erlebnis ausgegangen, wobei insbesondere für interaktive und multimediale Objekte ein Höchstmaß an Authentizität anzustreben ist. Aus diesen Kriterien lassen sich Anforderungen an die Emulationsstrategie und den Emulator selbst ableiten und entsprechende Validierungstests entwickeln (siehe Kapitel 4).

Rothenbergs Untersuchungen sind Grundlage vieler weiterer Projekte, die sich den einzelnen Teilproblemen der Bewahrungsstrategie widmen. An der KB wurde Rothenbergs Projekt von Jeffrey van der Hoeven konsequent weiterbetrieben woraus letztendlich 2007 ein erster eigens zur Langzeitbewahrung entwickelter modularer PC-Emulator namens Dioscuri entstand.^[31]vgl. van der Hoeven, J.; et al.: Emulation for digital preservation in practice: The results. In: The International Journal of Digital Curation, Volume 2, Number 2, 2007, S. 123–132; siehe auch … Continue reading

3.2.2 CAMiLEON

Rothenbergs Authentizitätskriterien werden vom Projekt CAMiLEON („Creative Archiving at Michigan & Leeds: Emulating the Old on the New, Projektlaufzeit 1999–2003“)^[32]Siehe Projektwebsite unter http://www2.si.umich.edu/CAMILEON/. aufgegriffen und im Zusammenhang der Entwicklung und Evaluation einer Reihe technischer Strategien empirisch untersucht. CAMiLEON ist ein gemeinsames Projekt der Universitäten von Michigan in den U.S.A. und Leeds in England, gefördert durch das Joint Information Systems Committee (JISC, England) und die National Science Foundation (NSF, U.S.A.). Dabei wurde die Maxime der größtmöglichen Langzeiterhaltung der Funktionalität und des Look-and-Feels des Objekts zugrunde gelegt und rechtliche sowie ökonomische Faktoren berücksichtigt.^[33]Siehe auch http://www2.si.umich.edu/CAMILEON/about/aboutcam.html.

Der Leiter des Forschungsprojekts, Stewart Granger, identifiziert vier Kernthemen der Emulation im Kontext der Langzeitbewahrung. Diese sind

• der technische Ansatz des Emulators, insbesondere die Genauigkeits-ebene,
• die Erhaltung der Integrität der dynamischen Objekte im Zusammenhangmit ihrem Look-and-Feel und ihrer Interaktivität,
• rechtliche und organisatorische Fragestellungen wie geistiges Eigentum, Reverse Engineering, die Kostenreduktion und zentrale Organisation der Entwicklung sowie
• weitere Fragestellungen im Zusammenhang mit offenen Standards und benötigten Metadaten.^[34]vgl. Granger, S.: Emulation as a digital preservation strategy. In: D-Lib Magazine, Volume 6, Number 10, October 2000, S. 2.

Diese zentralen Themen sollen auch in diesem und dem nächsten Kapitel als erster grober Leitfaden dienen.

Granger bestätigt Rothenbergs Einschätzung und sieht Emulation im Hinblick auf die Proliferation dynamischer Objekte als besten Ansatz. Wichtige Detailfragen bleiben für ihn bei Rothenberg jedoch ungeklärt. Insbesondere die Aspekte der Erstellung und des Formats der Emulator-Spezifikationen werden bei Rothenberg nur beiläufig erwähnt.^[35]vgl. ebenda, S. 3.

Wichtig ist, dass bei CAMiLEON ebenfalls nur bereits öffentlich verfügbare Emulatoren anhand konkreter Testszenarien evaluiert aber keine eigenen Emulatoren entwickelt werden. Dabei wurden Nutzerbefragungen anhand von Vergleichstests zwischen emulierter und Originalumgebung durchgeführt. Ziel war eine detaillierte Kosten-Nutzen-Analyse der Emulationsstrategie mit konkreten Handlungsempfehlungen und technischen Standards für Emulatoren und deren Spezifikation für Gedächtnisorganisationen.

Tatsächlich konnten diese Ziele jedoch nicht ansatzweise erreicht werden. In [Holdsworth und Wheatley 2001] sind erste Ergebnisse des Projektes zusammengefasst. Bezüglich der Emulatorspezifikation wurde festgestellt, dass ein Emulator entwickelt werden sollte, solange die Originalplattform noch existiert bzw. zur Verfügung steht, da eine technische Spezifikation alleine oft nicht ausreichend ist: “[…] it is important to get in early and at least achieve a proof of concept before relevant information (including human memory) is lost”^[36] Holdsworth, D.; Wheatley, P.: Emulation, Pre­servation and Abstraction. CAMiLEON Project.In: RLG DigiNews, Volume 5, Issue 4, 2001, S. 5. Es existieren Probleme bei der Abbildung obsoleter Peripherie durch einen Emulator (siehe Abschnitt 4.2). Verbindliche Regeln und Definitionen für ein abstraktes Emulatorinterface oder eine Emulatorspezifikation konnten nicht gefunden werden. Stattdessen sollen wesentliche Eigenschaften (significant properties) dynamischer Objekte erfasst werden und erhalten bleiben. Eine Antwort darauf, welches diese Eigenschaften sind, bleiben die Autoren schuldig.^[37]vgl. ebenda, S. 4f. Stattdessen wird versucht, dem Problem der Obsoleszenz des Emulators selbst und der dadurch ständig notwendigen Anpassung an künftige Systeme durch die Definition von Anforderungen an die Emulatorenprogrammierung zu begegnen. Ein Emulator soll anhand von “standard Software Engineering techniques” entwickelt werden und insbesondere eine „gute“ Code-Struktur und viele Kommentare aufweisen.^[38]ebenda, S. 4. „Nicht standardisierter“ Code soll modularisiert und dokumentiert werden. Die Autoren empfehlen eine Untermenge der Sprache C als Entwicklungssprache, in der Hoffnung, dass diese bzw. dessen Semantik auf lange Zeit und universell einsatzbereit bleibt. Angesichts der rasanten Entwicklung von Programmiersprachen und -konzepten muss dies jedoch stark bezweifelt werden. Das Thema der Emulatorentwicklung wird in Abschnitt 4.4 ausführlich behandelt.

Leider sind die finalen Ergebnisse des Projektes nicht (öffentlich) zugänglich. Die zentralen Abschlussberichte “Guide to Digital Preservation Strategies“, “Guide to the Costs of Digital Preservation Strategies“ und “Guide to Collection Management“ werden seit 2002 bis heute auf der Projektwebsite lediglich durch den Text “The final reports will be available in December 2002” angekündigt.^[39]Vgl. http://www2.si.umich.edu/CAMILEON/reports/reports.html. Somit bleiben die spärlichen Ausführungen von Holdsworth und Wheatley – neben den Informationen auf der Projektwebsite – vorerst die einzig greifbaren Ergebnisse des Projekts.

3.2.3 KEEP

KEEP („Keeping Emulation Environments Portable“) ist ein mit EU-Mitteln gefördertes dreijähriges Forschungsprojekt (2009–2012) des Computerspielemuseums Berlin, der französischen Nationalbibliothek, der University of Portsmouth und Mitgliedern der Retro-Gamer-Community (Emulatorenprogrammierern aus dem Hobbybereich), insbesondere des M.A.M.E.-Projekts.^[40]vgl. Lange, A.: Save Game: die Bewahrung komplexer digitaler Artefakte am Beispiel von Computerspielen. In: Sieck, J.; Herzog, M.A. (Hrsg.): Kultur und Informatik: Serious Games. Boizenburg: … Continue reading Das Projekt greift explizit das Problem der Langzeitbewahrung und Portierung des Emulatorprogramms selbst auf (siehe Abschnitt 5.3). KEEP setzt sich mit dem Partner Computerspielemuseum die Aufgabe, insbesondere dynamische und komplexe multimediale Objekte wie Computerspiele in ihrem originalen Kontext zu bewahren. Geschaffen werden soll ein Framework, welches alle Aspekte des Bewahrungsworkflows (Transfer, Bewahrung und Zugang) abdeckt. Ziel ist die Entwicklung eines Softwarepaketes, des sogenannten Emulation Framework, mit dessen Hilfe Emulatoren in bestehende Langzeitarchive integriert und digitale Objekte von ihren originären Datenträgern transferiert werden können. Das Emulation Framework basiert dabei auf der Idee der Virtualisierung und stellt den integrierten Emulatoren eine einheitliche virtuelle Systemumgebung zur Verfügung, mit deren Hilfe die Portierung und Migration der einzelnen Emulatoren vereinfacht werden soll. Das Framework soll dabei gleichzeitig den Zugang durch den Nutzer vereinfachen, indem es einen passenden Emulator, Werkzeuge zur automatischen Auswahl sowie Verknüpfung eines Emulators mit dem angeforderten digitalen Objekt über eine Online-Schnittstelle bereitstellt.^[41]Siehe Projektwebsite unter http://www.keep-project.eu/.

Für Andreas Lange, den Leiter des Computerspielemuseums Berlin, ist dabei die Brücke zur Emulatoren-Community von Hobbyprogrammierern von essenzieller Bedeutung. Er führt an, dass die ersten Bewahrungsversuche von Computerspielen von Fans ausgingen, die sich über das damals aufkommende WWW vernetzten und austauschten. Auf diese Weise ist eine Vielzahl von technischem Know-how zur Erstellung von Emulatoren, zur Wartung obsoleter Systeme sowie große Metadaten-Datenbanken in kollaborativ gepflegten Online-Archiven entstanden. Die einzelnen Aktivitäten erfolgten jedoch eher unsystematisch. Die Community entwickelte zudem erste praktikable Lösungen zur Bewahrung von Spielen, deren Kernstück selbst programmierte Emulatoren bilden, die kostenlos und meist quelloffen im Internet verteilt wurden und werden.^[42]vgl. ebenda, S. 192f.

Die Emulatoren für das Emulation Framework sollen dementsprechend aus der Community kommen und auf die Virtuelle Maschine von KEEP angepasst werden. Innerhalb von KEEP werden keine eigenen Emulatoren entwickelt, da dies finanziell und personell zu aufwendig wäre und den Rahmen des Projektes sprengen würde.^[43]Dies bestätigte der Archivleiter des Computerspielemuseums Winfried Bergmeyer im Interview mit dem Autor vom 18.11.2011 in Berlin und kann zudem der Website des Emulation Frameworks entnommen werden. KEEP ist damit direkt auf die Mithilfe der Community angewiesen und das Erreichen zentraler Projektziele davon abhängig.

Zusätzlich untersucht das Projekt rechtliche Aspekte im Zusammenhang mit der Anfertigung von Sicherheitskopien multimedialer Objekte. In Zusammenarbeit mit der University of Portsmouth wird zudem eine Datenbank mit Metadaten und Informationen zu technischen Abspielumgebungen und historischen Ein- und Ausgabeschnittstellen von Spieleplattformen und Computern erstellt. Diese Datenbank namens TOTEM („Trustworthy Online Technical Environment Metadata Database“) befindet sich derzeit im Aufbau und versucht, eine Ontologie existierender Ein- und Ausgabegeräte zu erstellen. Derzeit sind Informationen zum Commodore C64, PC-Spiele und Eigenschaften von Spielecontrollern wie Joysticks enthalten.^[44]Siehe Datenbank-Website unter http://keep-totem.co.uk/. Zur Benutzung der Datenbank ist eine Registrierung erforderlich. Die Projektergebnisse können auf der KEEP-Website^[45]Siehe http://www.keep-project.eu/ezpub2/index.php?/eng/Products-Results/Public-de-liverables. eingesehen und das entwickelte Emulatorenframework über die Open-Source-Plattform SourceForge^[46]Siehe http://emuframework.sourceforge.net/. Zum Zeitpunkt der Veröffentlichung dieses Werkes ist Version 2.1.0 aktuell. heruntergeladen werden.

3.2.4 PLANETS

PLANETS („Preservation and Long-term Access through Networked Services“) war ein von 2006 bis 2010 mit EU-Mitteln gefördertes Forschungsprojekt, mit dem Ziel, durch die Bereitstellung von vernetzten Diensten und Werkzeugen den Bewahrungsworkflow in Langzeitarchivierungssystemen zu unterstützen. Beteiligt sind neben zahlreichen Nationalbibliotheken und -archiven wie der British Library, der niederländischen KB oder dem Schweizerischen Bundesarchiv, vier deutsche Universitäten sowie Technologieunternehmen aus der Privatwirtschaft. Durch PLANETS sollen Werkzeuge entwickelt werden, die Gedächtnisorganisationen u.a. bei der Charakterisierung in Identifikation von digitalen Objekten unterstützen. Gleichzeitig soll die Plattform Funktionen zur Emulation der aufgenommen Objekte enthalten. Dabei werden die verschiedenen Dienste in einem Interoperability Framework gebündelt. Der PLANETS-Ansatz besteht dabei aus der Identifikation signifikanter Merkmale der Objekte und der anschließenden Entwicklung, Durchführung und Analyse von Fallstudien.^[47]Strodl, S.; Becker, C.; Neumayer, R.; Rauber, A.: How to choose a digital preservation strategy: Evaluating a preservation planning procedure. In: Proceedings of the ACM IEEE Joint Conference on … Continue reading Seit Projektende führt die nichtkommerzielle Organisation Open Planets Foundation (OPF) die Arbeit weiter, stellt diese Online-Dienste zur Verfügung und führt Schulungen durch.^[48]Siehe Homepage unter http://www.openplanetsfoundation.org/.

Farquhar und Hockx-Yu berichten über Ergebnisse und Herausforderungen des Projekts.^[49]Farquhar, A.; Hockx-Yu, H.: Planets: Integrated services for digital preservation. In: Serials: The Journal for the Serials Community, Volume 21, No 2., 2008, S. 140–145. Sie sehen die wichtigsten Funktionen des PLANETS Interoperability Frameworks in der Content-Charakterisierung und den Preservation-Aktionen. Mittels der Content-Charakterisierung werden einfache technische Eigenschaften des Objektes wie die Auflösung von Bildern, die Seiten eines Dokuments oder Besonderheiten einer Datenbank als Metadaten gespeichert, um andere Objekte mit ähnlichen Eigenschaften gruppieren zu können. Die Preservation-Aktionen integrieren Migrations- und Emulationswerkzeuge und verzahnen dabei unterschiedliche Open-Source-Projekte und -Werkzeuge.^[50]vgl. ebenda, S. 142. Als Emulationsprogramm kommt dabei Dioscuri (u. a. von J. van der Hoeven, siehe Abschnitt 4.3.5) zum Einsatz.

Wie auch bei KEEP und CAMiLEON entwickelte PLANETS keine eigenen Emulatorprogramme, sondern ist auf existierende Software angewiesen. Das Interoperability Framework ist selbst auch kein Repository zur Speicherung der digitalen Objekte.^[51]ebenda, S. 143.

3.2.5 Weitere Projekte und Vorarbeiten

Daneben gibt es eine Reihe weiterer Forschungs- und Bewahrungsprojekte, die das Thema Emulation streifen bzw. im Rahmen des Bewahrungswork-flows mitbehandeln. So untersucht das CASPAR-Projekt („Cultural, Artistic, and Scientific Knowledge for Preservation, Access and Retrieval“) Werkzeuge und Infrastrukturkomponenten des zur Bewahrung komplexer und diverser digitaler Objekte u. a. mittels Emulation.^[52]vgl.Giaretta, D.: Tools for Preservation and Use of Complex and Diverse Digital Resources. Summary of the CASPAR Project. In: iPRES 2009: the Sixth International Conference on Preservation of … Continue reading KOPAL („Kooperativer Aufbau eines Langzeitarchivs digitaler Informationen“), ein Verbundprojekt der IBM mit der Deutschen Nationalbibliothek und der Staats- und Universitätsbibliothek Göttingen, befasst sich mit der Entwicklung tragfähiger Konzepte im Preservation Planing. Im Rahmen des Arbeitspaketes E3 wird dabei Emulation untersucht, wobei Emulationsstrategien von Projektpartnern entwickelt werden sollen.^[53]Vgl. Arbeitspakete auf der Projektwebsite unter http://kopal.langzeitarchivierung.de/index_arbeitspakete.php.de/.

Das 2014 gestartete und von der DFG geförderte Projekt „Bereitstellung von Multimedia-Objekten durch Emulation“ greift die Vorarbeiten aus vergangenen Forschungsprojekten zum Thema Emulation auf und will die entstandenen Frameworks und Werkzeuge einer Evaluation in Bezug auf ihre Praxistauglichkeit unterziehen. Ziel ist die Anpassung, Ergänzung und Optimierung von bibliothekseigenen Bereitstellungswerkzeugen. Das Projekt ist auf zwei Jahre ausgelegt und wird von der Deutschen Nationalbibliothek geleitet.^[54]Vgl. Ankündigung auf der DNB-Website unter http://www.dnb.de/DE/Wir/Projekte/Laufend/emulationMultimediaObjekte.html. Das so entstandene System soll den Bedürfnissen von Gedächtnisorganisationen sowie deren Nutzer/-innen Rechnung tragen. Projektpartner sind die Universität Freiburg, die Bayrische Staatsbibliothek sowie die Staatliche Hochschule für Gestaltung in Karlsruhe.

Die Nutzung von Emulationstechniken zur Aufarbeitung historischer digitaler Artefakte spielt ebenfalls in den Forschungsprojekten des 2014 gegründeten interdisziplinären Arbeitskreises „Medienarchäologie“ eine zentrale Rolle. Methodisch werden dabei zum einen Vergleiche mit den Originalobjekten und zum anderen Zeitzeugenbefragungen durchgeführt.^[55]Weitere Informationen finden sich auf der Website des Arbeitskreises unter http://medienarchaeologie.de/. Ein erstes Projekt befasst sich mit Multimedia-CD-ROMs der 90er-Jahre und den Treibern und … Continue reading

Darüber hinaus existiert eine Vielzahl von Projekten und Praxisstudien zur Bewahrung von komplexen dynamischen Objekten und Computerkunst. Exemplarisch seien hier das „Preserving Virtual Worlds Project“ (PVW) der University of Illinois^[56]Siehe Homepage des Projekts unter http://pvw.illinois.edu/pvw/. Vgl. McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010. und die Ausstellung „Seeing Double – Emulation in Theory and Practice“^[57]vgl. Solomon R. Guggenheim Museum: Seeing Double: Emulation in Theory and Practice.Ausstellung des Museums 2004, New York, NY, U.S.A. genannt, welche Problembereiche beim Praxiseinsatz der Emulationsstrategie verdeutlichen. PVW fokussiert explizit auf die Langzeitbewahrung von Computerspielen und sogenannter interactive fiction. Die Projektempfehlungen werden in Abschnitt 4.3.1 genauer behandelt. Eine Zusammenfassung findet sich u. a. in [McDonough u. a. 2010].^[58]McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010.

Der Bericht der Ausstellung „Seeing Double – Emulation in Theory and Practice“ des Guggenheim Museums von Jones liefert erste Praxiserfahrungen für digitale Kunstobjekte. Gegenstand war die mittels Emulation restaurierte Fassung von Grahame Weinbren und Roberta Friedmans Videostück „The Erl King“ (1982–1985), einem der ersten Werke interaktiver Videokunst. Die Betrachter können den Verlauf der Videosequenzen durch einen Touchscreenmonitor beeinflussen. Für die technische Umsetzung benutzten die Künstler damals eine Kombination aus Hardware (Laserdisc-Player, Videoswitcher) und selbst geschriebener Software in einem komplexen Setup. Sowohl die Hardware als auch die originale Rechnerplattform sind heute obsolet. Zur Emulation mussten die Laserdisc-Aufnahmen ohne Qualitätsverlust digitalisiert werden. Für die Softwareemulation wurde mit Jeff Rothenberg zusammengearbeitet. Rothenberg empfahl, einen bestehenden Emulator aus dem Internet zu laden, da keine Ressourcen für eine Eigenentwicklung zur Verfügung standen. Zur vollständigen Emulation der Laserdiscs und Anbindung an die Videoswitcher musste dieser jedoch angepasst und um Einsprungpunkte (hooks) für die externe Hardware erweitert werden. Dies war jedoch im zur Verfügung stehenden Zeit- und Geldrahmen nicht möglich. In Zusammenarbeit mit den Künstlern und Rothenberg wurde schließlich der original Pascal-Quelltext genommen und angepasst. In der Ausstellung selbst wurden dann Originalwerk und Emulation nebeneinander ausgestellt. Jones zieht das ernüchternde Fazit einer Ausstellungsplanung, geprägt von konstanten ökonomischen und pragmatischen Abwägungen bzw. Entscheidungen. Das emulierte Werk enthielt viele Abweichungen, die den Look-and-Feel dramatisch veränderten. So reagierte das System beispielsweise viel zu schnell auf Eingaben des Betrachters.^[59]Jones, C.: Seeing Double: Emulation In Theory And Practice – The Erl King Case Study. In: Electronic Media Group Annual Meeting of the American Institute for Conservation of Historic and … Continue reading Ähnliche Beobachtungen im Zusammenhang mit elektronischer Kunst finden sich auch in [Besser 2001a].^[60]Besser, H.: Longevity of Electronic Art. In: ICHIM (2001).

Ökonomische Grenzen, die begrenzte Verfügbarkeit von Emulatoren sowie die fehlenden Nachbildungsmöglichkeiten der Originalumgebung scheinen einen entscheidenden Einfluss auf das Emulationsergebnis zu haben und werden im Folgenden näher untersucht. Um Abweichungen qualifizieren und pragmatische und technische Grenzen identifizieren zu können, muss die Funktionsweise und das Erstellungsumfeld von Emulatoren beleuchtet werden. Hierbei muss die für komplexe Objekte wie Computerspiele oder -kunst signifikante Abspielumgebung sowie relevante Aufführungspraxen ebenfalls mit einbezogen werden. Auffallend ist, dass keines der genannten großen Forschungsvorhaben eigene Emulatoren programmiert. Auf die verschiedenen Entwicklergruppen von Emulatoren wird in Abschnitt 4.3 genauer eingegangen.

3.3 Funktionserweiterungen durch Emulation

Die Möglichkeit, den Funktionsumfang eines komplexen digitalen Artefakts durch spezielle Funktionen des Emulators zu steigern, stellt einen weiteren Vorteil des Emulationsansatzes dar. Zwar scheint eine bewusste Veränderung der Interaktion mit dem zu bewahrenden Objekt das Ziel einer authentischen Bewahrung zu konterkarieren. Dennoch kann es unter gewissen Umständen sinnvoll oder sogar notwendig sein, Emulatoren mit Zusatzfunktionen auszustatten. Conley et al. berichten, dass insbesondere frei verfügbare Emulatoren der Community von Hobbyprogrammierern oft Funktionen besitzen, um das Spielerlebnis zu verbessern. Sie fügen Spielen vom Hersteller vergessene oder nicht vorgesehene Eigenschaften wie das Laden und Speichern des Spielstandes zu jeder Zeit (sogenannte save states), die Möglichkeit bestimmte Zwischensequenzen zu überspringen, oder Übersetzungen des Spiels in weitere Sprachen hinzu.^[61]vgl. Conley, J.; Andros, E.; Chinai, P.; Lipkowitz, E.; Perez, D.: Use of a Game Over: Emulation and the Video Game Industry: A White Paper. In: Northwestern Journal of Technology and Intellectual … Continue reading

Diese Möglichkeiten werden auch zunehmend von Spielherstellern erkannt, die Emulatoren nutzen, um eigene ältere Spiele auf aktuelle Plattformen zu portieren und somit neue Nutzergruppen zu erschließen sowie den wachsenden Markt an Retro-Gamern zu bedienen. Beispielsweise bietet Microsoft mit seinem Game Room die Möglichkeit, alte Arcadeautomaten-Spiele für PCs und Xbox 360-Konsolen zu erwerben, welche dann innerhalb eines von Microsoft zur Verfügung gestellten Emulators laufen. Dieser fügt u.a. die Möglichkeiten hinzu, Highscores mit anderen Spielern über das Internet zu vergleichen oder das Spiel mittels save states an jeder Stelle speichern zu können. Darüber hinaus ist es zudem möglich, den gesamten Spielverlauf zurückzuverfolgen und mittels einer „Vor- und Zurückspulfunktion“ an jede Stelle des erlebten Interaktionsverlaufes zu springen, den Spielverlauf zu beeinflussen oder noch einmal zu erleben sowie auch an andere Nutzer weiterzugeben (replay).^[62]Spiele können über die Xbox-Produktseite bei Microsoft erworben werden unter http://www.xbox.com/gameroom. Siehe auch Pressemitteilung unter http://www.ggsgamer.com/2010/03/25/game-room-released/. Mit dieser Funktion wird es möglich, exakt jede beliebige Stelle innerhalb des Spiels zu referenzieren, und dadurch eine Art der Zitierfähigkeit von Spielen zu erreichen.

Funktionserweiterungen sind zudem auch für Wissenschaft und Forschung von großem Interesse. Die Möglichkeit, den Zustand des Systems jederzeit speichern und analysieren zu können bzw. Audio-, Video- oder Bildschirmmitschnitte anzufertigen, sind für die Programmierung eines Emulators und zur Analyse des digitalen Objektes wichtige Funktionen. Des Weiteren können dem Nutzer über eine engere Integration mit dem Hostsystem – wie der Übernahme des Inhalts der Zwischenablage in das emulierte System oder der direkte Austausch von Dateien mit dem Hostsystem – zusätzliche Hilfen beim Umgang mit dem Archivgut geboten werden. Auch kann der intellektuelle Zugang durch eingeblendete Hilfetexte erleichtert und durch Angleichungen an aktuelle Interface-Metaphern die Folgen der stetigen Migration von Kulturtechniken teilweise kompensiert werden. Der Emulator kann dadurch aktuelle Bedienkonzepte für Nutzerschnittstellen obsoleter Systeme anbieten. Je weiter man in die Zukunft denkt, desto relevanter wird dieser Aspekt, da künftige Mensch-Rechner-Interaktionskonzepte und Schnittstellen sich signifikant von heutigen unterscheiden können. Bárány nennt u.a. den Übergang von der Bedienung über die Kommandozeile (command-line interfaces, CLI) zu graphischen Benutzerschnittstellen (GUI) als einen historischen Paradigmenwechsel in der Bedienung von Rechnern.^[63]vgl. Bárány, B.: Informationsverlust durch Digitalisierung. Saarbrücken: VDM Verlag Dr. Müller, 2006, S. 109. Derzeit ist, getrieben durch die steigende Verbreitung mobiler Endgeräte, eine Migration weg von der Bedienung über Maus und Tastatur als Eingabegerät, hin zur drucksensitiven Finger- oder Stiftbedienung zu beobachten. Ein Mensch-Rechner-Interface ist immer nur im Kontext kultureller Vorkenntnisse und dem Verständnis von Standards zur Zeiten des Originalsystems „intuitiv“ bedienbar.^[64]ebenda. Da der Emulator prinzipbedingt das dynamische Objekt in seinem historischen Kontext bewahrt, stellt die Migration von Kulturtechniken ein systemimmanentes Problem der Emulationslösung dar. Es kommt zu einer Verlagerung des Translationsproblems bzw. der Erhaltung der Interpretationsfähigkeit des dynamischen Objekts auf die konzeptuelle Ebene (siehe Kapitel 4). Ist das konzeptuelle Objekt für den Menschen nicht mehr „interpretierbar“, kann es nicht benutzt und damit rezipiert werden. Von der Dokumentation des Kontextes hängt das Gelingen der Überlieferung und damit der semantischen Erhaltung des dynamischen Objekts ab.

Rothenberg schlägt dazu ein in den Emulator integriertes „Helper“-Programm vor, dass den Nutzer bei der Benutzung obsoleter Systeme unterstützt. Dazu müssen jedoch Handbücher, sowie Metadaten und Dokumentation über die Funktionsweise des Originalsystems bzw. des Objekts sowie der obsoleten Ein-/Ausgabeschnittstellen bewahrt und in die Emulationsplattform dynamisch integriert werden.^[65]Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 61.

Emulatoren können also Zusatzfunktionen bieten, um die Interaktion mit dem Objekt für künftige Nutzer zu erleichtern oder teilweise notwendige Werkzeuge zur Analyse des Objektes bereitzustellen. Diese gewollten Abweichungen verändern jedoch gleichzeitig die ursprünglich erdachte Interaktion mit dem Objekt und müssen daher dem Nutzer in adäquater Weise zumindest kommuniziert werden.

3.4 Emulation mittels Software

Die Emulation obsoleter Rechner mittels eines Softwareprogramms setzt auf der Annahme auf, dass das von Intel-Mitgründer Gordon Moore aufgestellte „Mooresche Gesetz“ dauerhaft Bestand hat. Moore äußerte die Vermutung, dass sich die Komplexität von Prozessoren (und Schaltkreisen allgemein) in regelmäßigen Abständen (typischerweise alle ein bis zwei Jahre) verdoppelt. Zukünftige Rechnersysteme wären danach immer vorhersagbar „schneller“ als aktuelle Systeme. Dieser Umstand wird bei der Emulation zwingend benötigt, um die Geschwindigkeitsverluste durch die schrittweise Binärübersetzung durch den Emulator auszugleichen. Das Rechnersystem, auf dem der Emulator läuft, nennt man Hostsystem, das vom Emulator nachgebildete System wird mit Originalsystem bezeichnet.

Das Hostsystem muss dabei signifikant mehr Rechenleistung aufweisen und damit schneller arbeiten, als das Originalsystem, um dessen Emulation in Originalgeschwindigkeit zu ermöglichen.^[66]Je nach Literatur und Komplexität des Originalsystems wird ein Faktor von 10 bis 100 zwischen Host- und Originalsystem angenommen. Dieser Umstand war bereits Tucker bei IBM bekannt, weswegen dieser … Continue reading Zur Emulation komplexer dynamischer Objekte wie Computerspiele ist diese Echtzeitbedingung zwingend erforderlich, da sonst die Interaktion mit dem Spiel verändert oder sogar unmöglich gemacht werden würde. Der Ansatz, Emulation von Hardware mittels Software als Langzeitbewahrungsstrategie einzusetzen, kann nur aufrecht erhalten werden, solange diese Prämisse erfüllt bleibt.

Dabei können Software-Emulatoren auf verschiedenen Ebenen des Softwarestacks und der Systemhardware ansetzten und in unterschiedlichen technischen Abstraktions- bzw. Genauigkeitsstufen implementiert werden. Allerdings steigt der Schwierigkeitsgrad der Implementierung mit dem Genauigkeitsgrad. Ebenso nimmt die Emulationsgeschwindigkeit mit steigender implementierter Emulationsgenauigkeit ab. Hierbei muss zwangsläufig ein Kompromiss zwischen der zur Verfügung stehenden Geschwindigkeit des Hostsystems, technisch leistbarem Aufwand der Implementierung und gewünschter zu erreichender Emulationsgenauigkeit eingegangen werden. Im Folgenden werden daher die Ansatzebenen und technischen Abstraktionsebenen von Emulatoren genau aufgeschlüsselt und Auswirkungen auf die Authentizität des digitalen Artefakts aufgrund von Abweichungen und Kompromissen auf technischer Ebene herausgearbeitet.

3.4.1 Beschreibungsebenen in der Software-Emulation

Ein solcher Software-Emulator kann auf verschiedenen Ebenen des Systems ansetzen, je nachdem welche Teile des Originalsystems durch den Emulator nachgebildet werden. Zur Ausführung eines dynamischen Objekts sind grob folgende Elemente notwendig: Neben dem Objekt selbst, werden eine interpretierende Applikation (das Lese- bzw. Abspielprogramm, eventuell auch Teil des Objekts selbst) und gegebenenfalls weitere Hilfsprogramme benötigt. Diese werden wiederum auf einem Betriebssystem mit Treibern oder einem in Firmware implementierten Interpreter bzw. Basissystem ausgeführt. Dieses läuft auf einer Systemhardware bestehend aus CPU, Speicher, diversen Ein-/Ausgabeschnittstellen sowie eventueller Peripherie. Aus dieser Beschreibung ergibt sich eine implizite Einteilung in Schichten, die sich in ähnlicher Form in gängiger Literatur zum Thema wiederfinden lässt.^[67]vgl. beispielsweise Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999 [abgerufen 24.04.2008]; Borghoff, U. M.; Rödig, P.; … Continue reading Ein Software-Emulator kann auf jeder dieser Ebenen ansetzen.

Auf der Applikationsebene steht die Emulation der Programmierschnittstelle (API) eines Programms bzw. einer bestimmten Anwendung. Eine Ebene darunter liegt die Betriebssystemschicht. Emulatoren, die hier ansetzen sind Betriebssystem-Emulatoren (OS-Emulator) und sogenannte Virtualisierer, welche zusätzlich gewisse Teile der Hardware emulieren, um eine bessere Ressourcenverteilung zu erreichen. Eine vollständige Emulation aller Hardwarekomponenten und damit die Erfassung aller Schichten strebt die „Full-System“-Emulation an. Abbildung 3.1 veranschaulicht dieses Schichtenmodell und zeigt die Abdeckung der jeweiligen Schichten durch die verschiedenen Emulationsansätze (rechte Seite).

Eine Nachbildung der API bzw. der Funktionen eines Programms ist aufgrund der großen Anzahl an unterschiedlichen Programmen und möglichen Funktionen nicht sinnvoll. Im Bereich von dynamischen interaktiven Objekten wie Computerspiele wird in der Regel Individualsoftware verwendet. Eine Nachbildung wäre sehr komplex und ein Emulator immer nur für genau diese eine Anwendung benutzbar. Im Gegensatz zur Systemhardware ist Software nicht standardisiert, die Funktionsweise von APIs zumeist proprietär und nicht offengelegt. Die Hardwareschnittstellen müssen im Gegenzug jedoch offengelegt und standardisiert sein, um eine Erstellung von Applikationen überhaupt erst zu ermöglichen. Hinzu kommt, dass der überschaubaren Anzahl von Rechnerarchitekturen (siehe Abschnitt 3.7) eine ungleich größere Anzahl an Software gegenüber steht. Es ist daher sinnvoll, den Emulator auf der Hardwareebene anzusetzen. So ist ein einziger Emulator der Hardware eines C64 Heimcomputers theoretisch in der Lage, alle Programme, die für den C64 geschrieben wurden, auszuführen. Der Entwicklungsaufwand reduziert sich dadurch erheblich. Neuere Publikationen mit Best-Practice-Anweisungen gehen daher direkt von Emulatoren für die Langzeitbewahrung aus, die zumindest Teile der Hardware des Originalsystems erfassen.^[68]vgl. u.a. Neuroth, H. (Hrsg.); et al.: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung.Version 2.3. Erschienen im Rahmen des Projektes: nestor – Kompetenznetzwerk Langzeitarchivierung … Continue reading Rothenberg verwirft das Konzept der API-Emulation ebenfalls als zu komplex und kostenintensiv und spricht sich stark für die Emulation der gesamten Systemhardware aus.^[69]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 24–27. In der Tat ist die Konzentration auf wenige, meist genau definierte Rechnerarchitekturen, die einzig sinnvolle Möglichkeit zur ökonomischen Komplexitätsreduktion bei gleichzeitig größtmöglichem Nutzen.

Dennoch gibt es bekannte Beispiele für API-Nachbildungen. Dabei handelt es sich jedoch eher um Re-Implementierungen von Funktionalität, als um Emulation im klassischen Sinne. Ein Beispiel ist WINE, ein Programm, welches die Windows API unter Linux zur Verfügung stellt und so die Ausführung einiger Windowsprogramme unter anderen Betriebssystemen ermöglicht. WINE steht dabei bezeichnenderweise für Wine Is Not an Emulator.^[70]Siehe Website unter https://www.winehq.org/. Im Bereich von Spielen ist das ebenfalls quelloffene Programm SCUMMVM (Script Creation Utility for Maniac Mansion Virtual Machine) zu nennen, welches u.a. die Ausführung einer Reihe von Adventure-Spielen der Firma Lucas Arts (früher Lucasfilm Games) ermöglicht, die von der Firma unter einer gemeinsamen Interpretersprache namens SCUMM entwickelt wurden. SCUMMVM re-implementiert die Funktionen von SCUMM und stellt den Interpreter somit plattformunabhängig und für aktuelle Computersysteme zur Verfügung.^[71]Siehe Website bei SourceForge unter http://scummvm.sourceforge.net/.

Es lohnt sich daher, in diesem Zusammenhang nur Ansätze zu betrachten, die zumindest teilweise die Hardwarekomponenten des Originalsystems erfassen und nachbilden können.

3.4.2 Virtualisierung und OS-Emulation

Virtuelle Maschinen (VM) und Betriebssystememulatoren setzen eine Ebene tiefer als API-Emulatoren an. Dabei werden unter dem Begriff VM verschiedene Arten und Konzepte zusammengefasst. Zum einen werden darunter Methoden zur Ressourcenteilung eines Computers verstanden, die mithilfe eines virtualisierten Betriebssystems über eine Virtualisierungssoftware wie beispielsweise VMWare zur Verfügung ermöglich werden. Zum anderen versteht man unter VMs ein abstraktes Computersystem, welches durch einen Software-Interpreter wie z.B. die Java Virtual Machine implementiert wird.^[72]vgl. Supnik, R. M.: Simulators: virtual machines of the past (and future). In: ACM Queue, Volume 2, Number 5, Issue July/August 2004, S. 53–58. Ein frühes Beispiel aus dem Spielebereich ist die 1979 von Infocom entwickelte Z-Machine, die für die Ausführung von Textadventure-Spielen (ursprünglich das Spiel Zork) der Firma entwickelt wurde. Für die abstrakt definierte Z-Machine existieren Interpreter (Laufzeitumgebungen) für unterschiedliche Rechnerarchitekturen und Betriebssysteme.^[73]Technische Beschreibungen und Standards zur Z-Machine finden sich beispielsweise unter http://inform-fiction.org/zmachine/standards/.

Bei VMWare und anderen Virtualisierern werden Teile einer Rechnerarchitektur emuliert, um (mehrere) Gastbetriebssysteme auf einer Maschine laufen zu lassen. Dabei werden jedoch bestimmte Anfragen direkt an die Hardware des Hostsystems weitergeleitet. Insbesondere der Prozessor wird nicht emuliert, wodurch nur Systeme der gleichen Rechnerarchitektur innerhalb der Software zur Verfügung gestellt werden. Die verfügbaren Programme konzentrieren sich dabei auf die x86-Architektur als derzeit dominierende Systemarchitektur im Personal-Computer-Bereich. Der sogenannte „Hypervisor“ sorgt dabei für die Resourcenaufteilung zwischen Gast- und Hostsystem. Das Konzept geht auf die IBM zurück, welche das Konzept zur Ressourcenverteilung und Abwärtskompatibilität der IBM/360-Architektur nutzte.^[74]vgl. Tucker, S. G.: Emulation of large systems. In: Communications of the ACM, Volume 8, Number 12, 1965, S. 753–761. Moderne x86-Prozessoren von Intel und AMD besitzen inzwischen einen erweiterten Befehlssatz, der die Virtualisierung von Systemkernen auf Hardwareebene ermöglicht und so Softwarevirtualisierer stark beschleunigen kann. Ein Vergleich von Hard- und Softwaretechniken für x86-Virtualisierung findet sich in [Adams und Agesen 2006].^[75]Adams, K.; Agesen, O.: A comparison of software and hardware techniques for x86 virtualization. In: ASPLOS-XII: Proceedings of the 12th international conference on Architectural support for … Continue reading

Bekannte kommerzielle Beispiele sind die Programme der Firmen VMWare Inc. (Workstation, ESX und weitere)^[76]Siehe Produktinfos auf der Firmenwebsite unter http://www.vmware.com/. und Parallels Inc. (Desktop, Workstation, Server und weitere).^[77]Siehe Produktinfos auf der Firmenwebsite unter http://www.parallels.com/de/. Daneben existiert eine quelloffene Implementierung des Konzepts durch die Firma Oracle namens VirtualBox.^[78]VirtualBox kann unter https://www.virtualbox.org/ kostenlos heruntergeladen werden. Durch ihren Bekanntheitsgrad und den Einsatz im kommerziellen Umfeld gerieten diese Programme und das Konzept auch in den Fokus von Forschungsarbeiten im Kontext der Langzeitbewahrung, insbesondere im Rahmen von Fallstudien zur Emulation.^[79]vgl. u. a. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009.

Allerdings ist das Konzept aus verschiedenen Gründen für die Langzeitarchivierung mittel- bis langfristig nicht geeignet. In [von Suchodoletz 2009] wird dies exemplarisch zusammengefasst. Vor allem durch nur teilweise Emulation des Systems (also ohne Emulation des Prozessors) entsteht eine feste Bindung an die verwendete x86-Systemarchitektur. So ist es nicht möglich, Software bzw. Betriebssysteme anderer (künftiger) Rechnerarchitekturen auf einer x86-VM auszuführen. Die direkte Ausführung der meisten CPU-Befehle auf dem Host-Prozessor bildet damit die größte Einschränkung.^[80]vgl. ebenda, S. 124.

Zusätzlich optimieren kommerzielle Anbieter von VMs ihre Software nur für die Virtualisierung bestimmter, beliebter Betriebsysteme und Applikationen. Neuere Versionen stellen dabei häufig den Support für ältere, obsolete Betriebssysteme ein. Die aktuelle Version von VMWare ist beispielsweise nicht mehr in der Lage, Windows 3.1 und dessen Programme auszuführen. Genau dies ist aber das Kernziel jeder Langzeitbewahrungsinitiative. Kommerzielle Produkte bieten daher nur wenige Nutzungs- und Referenzumgebungen.^[81]Vgl. ebenda, S.124 und 141. Einen umfassender Vergleich und Analyse verschiedener Versionen der Produkte von VMWare Inc. im Kontext der Langzeitbewahrung findet sich ebenda in Kap. 5.3.

Ebenso können rechtliche Faktoren eine Rolle spielen. So verbot die Firma Apple in den Lizenzbedingungen ihres Desktop-Betriebssystems MacOS X bis Version 10.6 explizit die Ausführung in einer Virtuellen Maschine wie VMWare. Dieses Privileg blieb der teureren Serverversion von MacOS X vorbehalten.

Eine teilweise Emulation des Rechners bietet langfristig keine Alternative. Es ist vielmehr notwendig, die gesamte Hardware des Rechners durch den Emulator zu erfassen.

3.4.3 Full-System-Emulation

Auf der untersten Schicht des Computersystems setzt die Emulation der Hardwareebene an (siehe Abschnitt 3.4.1). Im Gegensatz zur Virtualisierung, welche Anfragen an Einzelkomponenten an die Hardware des Hostsystems durchreicht, werden bei der Emulation auf Hardwareebene alle zum Betrieb eines Computersystems notwendigen Hardwarekomponenten und Peripheriegeräte mittels Software emuliert. Es wird also das Gesamtsystem nachgeahmt, weswegen dieser Ansatz auch Full-System-Emulation genannt wird. Emulatoren, die auf dieser Schicht ansetzen, nennt man entsprechend Full-System-Emulatoren.

Dieser Ansatz bietet viele Vorteile. Durch die Nachbildung aller Komponenten des Originalsystems ist der Emulator – theoretisch – von der Architektur des Hostsystems unabhängig und damit sehr portabel. So können auch zukünftige unbekannte Computersysteme, deren Architektur sich signifikant von der des zu emulierenden Systems unterscheiden, unterstützt werden – im Hinblick auf die auf einen unbestimmten, möglichst langen Zeitraum ausgerichtete Langzeitbewahrung ein wichtiges Kriterium. Für Tijms besitzt dieses Verfahren daher den höchsten Grad an „Komplettheit“ (completeness).^[82]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 4.

Wie zudem an den vorangegangen Beispielen gezeigt, sind die anderen Ansätze, Emulation mittels Hardware sowie der Emulation von höheren Systemschichten mittels Software, aufgrund der Abhängigkeit von einer Rechnerarchitektur sowie Komplexitätsproblemen nicht praktikabel bzw. skalierbar anwendbar. Es ist daher sinnvoll die Emulation der (Gesamt-) Hardware getrennt von den höheren Softwareschichten zu betreiben. Die Vorteile liegen bereits für Rothenberg darin, den Softwarestack losgelöst von der Hardware zu betrachten, weil nur so die Authentizität der Software gewährleistet werden kann, da der Bitstrom des Objekts, des Leseprogramms, der optional notwendigen Treiber, Hilfsprogramme sowie des Betriebssystems bzw. der Firmware nicht verändert oder neu programmiert werden müssen.^[83]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 17. [abgerufen 24.04.2008] Rothenberg verwendet daher in späteren Werken Emulation synonym für Emulatoren auf Hardwareebene.^[84]vgl. u.a. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000 und Rothenberg, J.: An Experiment in Using Emulation to Preserve … Continue reading

In der Tat stellt die Full-System-Emulation in der Literatur die populärste Form der Emulation dar. Aktuelle Forschungsprojekte (siehe Abschnitt 3.2) setzen Full-System-Emulatoren ein bzw. erproben diese, erste positive Praxisergebnisse liegen vor. Dies spiegelt auch die Meinung von Borghoff wieder, der zudem pragmatische und ökonomische Gründe nennt: Es existieren erheblich mehr Kombinationen aus Betriebssystemen, Treibern, Abspielprogrammen und Artefakten als es Hardwarearchitekturen bzw. Computersysteme gibt. Es reicht also einen Full-System-Emulator für ein System zu schreiben, um alle auf diesem System existierenden Software-Kombinationen dieses Systems zu erfassen. Dies reduziert den benötigten Speicherbedarf und die Komplexität des Emulators erheblich.^[85]vgl. Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003, S. 67 sowie von Suchodoletz, … Continue reading Hinzu kommt das Hardwarekomponenten wohldefiniert beschrieben und standardisiert ist. Die Existenz eines präzisen Bauplans bzw. einer Systembeschreibung ergibt sich faktisch aus dessen Notwendigkeit zur Fertigung des Systems sowie als Grundlage zur Entwicklung von Software für das System. Ein zu entwickelnder Emulator kann daher auf ein Mindestmaß an Spezifikation und Dokumentation zurückgreifen, um Systemvorgänge nachahmen zu können. Im Gegensatz dazu unterliegt die Entwicklung von Software keinen allgemein gültigen Standards. Borghoff führt an, dass es auch nach Jahrzehnte langer Forschung nicht möglich ist, die Wirkung von komplexen digitalen Artefakten unabhängig vom Programmtext zu beschreiben.^[86]vgl. Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003, S. 67. Der Funktionsumfang von Hardware ist dagegen überschaubar und im Gegensatz zu Software (siehe Abschnitt 3.4.1) deutlich eingeschränkt.^[87]vgl. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, S. 71f.

3.4.4 Untersuchung der Full-System-Emulation

Die Emulation der gesamten Hardwareplattform bleibt daher die einzig praktikable Alternative, verspricht sie doch höchste Kompatibilität und durch die Loslösung von der Softwareumgebung sowie die Unabhängigkeit von der Architektur des Hostsystems ein gewisses Maß an Zukunftssicherheit. Die UNESCO-Richtlinien zur Bewahrung kulturellen Erbes klassifizieren Emulation als mittel- bis langfristige (long term nach CCSDS-Kriterien) Erhaltungsstrategie.^[88]vgl. UNESCO (Hrsg.): Guidelines for the Preservation of Digital He­ritage. Dokument CI-2003/WS/3, 2003, S. 122. Dementsprechend ist es auch der verbreitetste Ansatz. In der Literatur wird daher Emulation oft synonym mit Full-System-Emulation verwendet bzw. ist diese gemeint, wenn von Emulation als Bewahrungskonzept gesprochen wird.^[89]vgl. u.a. Rothenberg, J.: An Experiment in Using Emulation to Preserve Digital Publications. Den Haag: Koninklijke Bibliotheek (NEDLIB Report Series), 2000; Holdsworth, D.; Wheatley, P.: Emulation, … Continue reading Im Folgenden wird Full-System-Emulation in dieser Arbeit als primärer Untersuchungsgegenstand im Rahmen von Emulation als Bewahrungsstrategie behandelt.

Die Festlegung auf ein technisches Bewahrungsprinzip unterliegt prinzipbedingt gewissen Beschränkungen (engl. constraints), Sachzwängen und Grenzen, bietet aber auch entsprechende Möglichkeiten. Um diese besser ausloten zu können, ist zunächst eine genaue Betrachtung des Aufbaus und der technischen Funktionsweise eines solchen Emulatorprogramms vonnöten. Nur so lässt sich ermitteln, ob und wie sich technische Entscheidungen auf die originalgetreue Erhaltung der einzelnen Ebenen (siehe Abschnitt 2.2) eines Computerspiels bzw. dynamischen Objekts auswirken.

Auffallend ist, dass in der Literatur der Full-System-Emulation zwar ein hoher Grad an Genauigkeit bzw. Komplettheit zugeschrieben, dies jedoch größtenteils nicht weiter ausdifferenziert wird. So spricht unter anderem Borghoff einem Full-System-Emulator die Fähigkeit zu, das Verhalten eines anderen Computersystem lückenlos nachzubilden:

Er illustriert dies mit einer entsprechenden Grafik^[91]ebenda, S. 70, Abb. 4.7., in der er eine Isomorphie zwischen dem Originalsystem und einem Hostsystem mit einem entsprechenden Emulator für das Originalsystem postuliert. Nach dieser Darstellung sind zudem alle Implementierungen eines Emulator-Programms funktional äquivalent. Dies setzt implizit die Annahme der funktionalen Äquivalenz voraus und legt zeitgleich den Fokus auf die Deckungsgleichheit des Systemverhaltens. Es wird somit von einem verhaltensorientierten Ansatz ausgegangen, was sich auch in gängigen Definitionen wie beispielsweise von der UNESCO (“Emulation involves using software that makes one technology behave as another.”)^[92]UNESCO (Hrsg.): Guidelines for the Preservation of Digital He­ritage. Dokument CI-2003/WS/3, 2003, S. 140., nestor („[…] indem man die originale Umgebung der archivierten digitalen Objekte nachbildet“)^[93]Neuroth, H. (Hrsg.); et al.: Eine kleine Enzyklopädie der digitalen Langzeitarchivierung.Version 2.3. Erschienen im Rahmen des Projektes: nestor – Kompetenznetzwerk Langzeitarchivierung und … Continue reading oder Digital Preservation Coalition (“Emulation: […] by developing techniques for imitating obsolete systems”, “[r]ecreates the functionality,look and feel of the original”)^[94]Digital Preservation Coalition (Hrsg.): Preservation Ma­nagement of Digital Materials: The Handbook. November 2009, S. 25, 113. niederschlägt.

Um die Frage ob – und falls ja – wie genau (deckungsgleich) ein Full-System-Emulator das Verhalten des Originalsystem abbilden kann bzw. welche Implikationen ein auf das äußere messbare Systemverhalten abzielender Ansatz auf der technischen Ebene hat, ist es notwendig, zunächst eine Analyse der Softwaretechnik und Struktur eines solchen Emulators vorzunehmen.

3.5 Struktur eines Full-System-Emulators

Praktisch alle Computer- sowie dedizierte Videospielsysteme basieren – bis auf wenige Ausnahmen – in ihrem Konzept auf der Von-Neumann-Architektur, bestehend im Minimum aus (Haupt-) Prozessor mit Rechen- und Steuerwerk sowie einem gemeinsamen Speicher für Programme und Daten. Hinzu kommen zumeist verschiedenste (proprietäre) Chips zur Grafik- und/oder Tonausgabe oder zur Ansteuerung spezieller Ein- oder Ausgabehardware. Alle Komponenten sind dabei über einen gemeinsamen Datenbus verbunden und müssen den Zugriff auf selbigen koordinieren. Eine Ausnahme bilden ältere Spielhallenautomaten (Arcade-Systeme), deren Programmablauf direkt als Logikschaltung vorgegeben ist und die deswegen keine CPU besitzen bzw. benötigen. Auf diese und weitere Besonderheiten wird in Abschnitt 4.2 genauer eingegangen.

Das Herzstück der Von-Neumann-Architektur bildet der sogenannte Fetch-Execute-Zyklus. Der Prozessor führt hierbei nacheinander immer die gleichen Schritte aus: Der aktuelle Befehl wird über den Datenbus aus dem Speicher gelesen, dekodiert, der Befehlszähler erhöht und der Befehl ausgeführt. Dieser einfache Vorgang ermöglicht deterministische Programmabläufe und damit die Programmierung des Systems.^[95]vgl. Coy, W.: Aufbau und Arbeitsweise von Rechenanlagen. Eine Einführung in Rechnerarchitektur und Rechnerorganisation für das Grundstudium der Informatik. Braunschweig: Verlag Friedr. Vieweg … Continue reading Die Abarbeitung des Programms kann jedoch durch externe Geräte bzw. Ereignisse mithilfe eines „Interrupts“ unterbrochen werden. Die Abarbeitung des aktuellen Programms wird dabei gestoppt und eine definierte Subroutine zur Behandlung des Ereignisses angesprungen.

Der Prozessor arbeitet dabei Takt-getrieben. Gesteuert wird der Fetch-Execute-Zyklus durch einen zentralen Taktgeber, um Zugriffe auf den Systembus koordinieren und Arbeitsschritte in regelmäßigen, gleich langen Abständen auszuführen. Erzeugt wird dieser Systemtakt mittels eines Taktgenerators, der heutzutage im Allgemeinen direkt in den Prozessor integriert ist. So erlauben es aktuelle Prozessoren, den Systemtakt nach Auslastung bzw. Bedarf dynamisch anzupassen, um bei geringer Auslastung Strom zu sparen oder bestimmten rechenintensiven Applikationen eine höhere Verarbeitungsgeschwindigkeit zu bieten.^[96]Ein Beispiel hierfür ist die „Enhanced Intel SpeedStep Technology“, welche in Mobilprozessoren, wie dem Mobile Pentium 4, zum Einsatz kommt, um die Akkulaufzeit des Notebooks zu verlängern.

Anzumerken ist, dass auch hier das Bild eines zentralen Taktgebers eine idealisierte Darstellung ist, da z. B. die Prozessoren einer Grafikkarte wiederum eigene Taktgeber besitzen (können), die unabhängig vom zentralen Systemtakt agieren oder auf die unabhängig vom Takt mittels DMA-Zugriff (Direct Memory Access) von externen Komponenten auf den Systemspeicher zugegriffen werden kann.

Die Dekodierung des Maschinenbefehls (opcode) löst die Abarbeitung der dazu gehörigen Befehlssequenz – genannt Mikrocode – aus, in welcher die zur Durchführung des Maschinenbefehls notwendigen atomaren Schritte des Steuer- und Rechenwerks durchgeführt werden. Der Mikrocode stellt also das Befehlsprogramm des Prozessors dar. Während dieses bei CPUs der ersten Generation noch fest als Logikschaltung codiert war, so ist dieses spätestens seit x86-Prozessoren in einem eigenem ROM-Bereich, dem Mikroprogrammspeicher, abgelegt.

Aktuelle x86-Prozessoren verfügen zusätzlich über eine Funktion, um Mikrocode nachzuladen. Dadurch können auch nach Auslieferung entdeckte Fehler in der Abarbeitung eines Maschinenbefehls behoben oder die Ausführung einzelner Befehle effizienter gestaltet werden. Die entsprechenden Mikrocode-Patches werden dazu jedes Mal zum Zeitpunkt der Initialisierung des Rechnersystems aus dem BIOS des Rechners in den Prozessor nachgeladen und verbleiben dort temporär bis zum Abschalten des Systems.

Hinzu kommt, dass heutige Prozessoren in PCs und Spielkonsolen deutlich komplexer aufgebaut sind. Sie verfügen beispielsweise über mehrere parallel arbeitende Kerne (Multicore-Architektur) sowie ausgefeilte Caching-Mechanismen, welche den Komplexitätsgrad des idealisierten Fetch-Execute-Zyklus erhöhen. Aktuelle CPUs integrieren zudem diverse Zusatzkomponenten wie beispielsweise den numerischen Coprozessor, eine Speicherverwaltungseinheit (Memory Management Unit, siehe Abschnitt 3.5.2), Vektorarithmetikeinheiten (wie beispielsweise MMX, SSE bei Intel oder AltiVec bei PowerPC-Prozessoren) insbesondere für Grafikoperationen bis hin zu einem integrierten vollwertigen Grafikchip (beispielsweise bei Intels Core-Prozessoren) direkt auf dem Chip.

Ein Full-System-Emulatorprogramm muss diese zentralen Abläufe mit seinen Komponenten sowie zudem alle weiteren zum System gehörenden Hardware-Komponenten, insbesondere Module zur Steuerung der Ein- und Ausgabefunktionalität und Peripherie, nachbilden. Letztere hängen jedoch individuell vom Original- und Hostsystem ab und entziehen sich daher einer zusammenfassenden Betrachtung.

Um das technische Funktionsprinzip des Emulatorprogramms besser verstehen zu können, soll die Funktionsweise der einzelnen Bestandteile genauer untersucht werden. Der Emulator kann dazu in logische Einheiten zerlegt werden. In [van der Hoeven und van Wijngaarden 2005, S. 11]^[97]van der Hoeven, J.; van Wijngaarden, H.: Modular emulation as a long-term preservation strategy for digital objects. In: Proceedings of the 5th International Web Archiving Workshop (IWAW05), im … Continue reading identifizieren die Autoren in ihrem Plädoyer für modular programmierte Emulatoren dabei den CPU-Emulator, das Speichersubsystem, einen Ein-/Ausgabecontroller sowie diverse Sub-Emulatoren für gängige Hardwarekomponenten wie das Grafiksystem oder Massenspeicher. Eine ähnliche Einteilung der Hardwarekomponenten in Subsysteme ist auch in [Tijms 2000]^[98]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000. zu finden. Jedes Modul ist für die Nachbildung einer spezifischen Hardwarekomponente in Software zuständig. Zusammengeschaltet bilden diese Sub-Emulatoren das Gesamtverhalten des zu emulierenden Systems nach.

Diese logischen Module finden sich in aktuellen Emulatorprogrammen wie M.A.M.E. oder M.E.S.S. wieder, welche aus Gründen der Wartbarkeit und Komplexitätsreduktion, und Portabilität Emulatoren in Hochsprachen wie C, C++ oder Java geschrieben sind (siehe Abschnitt 3.7.2, Tabelle 1). Das Paradigma der Objektorientierung erlaubt dabei die Herausbildung von gekapselten Subsystemen, die lose gekoppelt miteinander interagieren.

Die Art der Implementierung bzw. der zugrunde liegende Abstraktionsgrad dieser Module hat Einfluss auf das Gesamtverhalten des Emulatorprogramms, insbesondere im Verhältnis von Emulationsgeschwindigkeit versus erzielbarer Genauigkeit zu den internen Abläufen des Originalsystems.^[99]vgl. Shaffer, J.: A Performance Evaluation of Operating System Emulators. Bachelorarbeit, Bucknell University, Lewisburg, PA, U.S.A., 2004 sowie Supnik, R. M.: Writing a Simulator for the SIMH … Continue reading

Im Folgenden werden diese Module zunächst in ihrer Funktionsweise abstrakt analysiert und danach konkrete Ausprägungen in bestehenden Emulatoren untersucht.

3.5.1 CPU-Emulator/-simulator

Dem CPU-Modul kommen, angetrieben durch einen simulierten externen Takt, zentrale Aufgaben der Systemsteuerung zu. Die in Abschnitt 3.5 beschrieben Elemente (Befehlsdekoder und Funktionsgruppen, Register, Rechen- und Steuerwerk) und Abläufe (Fetch-Execute-Zyklus) müssen daher vom CPU-Modul eines Emulators nachgebildet werden.

Angelehnt an diese Komponenten beschreibt beispielsweise Supnik^[100]ebenda. das interne Layout und die Aufgaben eines solchen CPU-Emulators anhand der technischen Dokumentation zur Implementierung eines neuen Emulator-Moduls für die SIMH-Plattform.^[101]SIMH steht für „Historic Simulators“ und ist ein Open-Source-Projekt zur modular erweiterbaren Emulation mehrerer Großrechner, u.a. der DEC-PDP-Reihe. Siehe auch: SIMH – Computer History … Continue reading Der Autor identifiziert als Grundfunktionen

• die Bereitstellung einer Zeitbasis (time-keeping),
• das Laden einer Instruktion aus dem Speicher (instruction fetching),
• die Adressdekodierung (address decoding),
• die Ausführung von Ein-/Ausgabe-unabhängigen Instruktionen (execution of non-I/O instructions),
• die Ausführung von Ein-/Ausgabeinstruktionen (I/O command processing) sowie
• die Abarbeitung von Hard- und Softwareinterrupts (interrupt processing).

Event-Loop

Die Abarbeitung dieser Schritte innerhalb das Fetch-Execute-Zyklus wird in der Regel innerhalb eines Event-Loops realisiert. Bevor die nächste Instruktion dekodiert wird, muss zunächst auf Ereignisse reagiert werden. Falls notwendig, müssen zeitlich festgelegte Ereignisse ausgeführt werden. Danach ist auf noch nicht bearbeitete Interrupts zu prüfen und diese sind abzuarbeiten. Falls angefallen, müssen zudem Prozessor-eigene Events wie z. B. Ausnahmebehandlungen durch traps, exceptions oder breakpoints ausgeführt werden. Im Anschluss kann die Abarbeitung des eigentlichen Fetch-Execute-Zyklus beginnen. Der Programm Counter (PC) wird erhöht und die nächste Instruktion aus dem Speicher gelesen. Falls notwendig, sind in Operanden enthaltene Adressen zu dekodieren. Zuletzt wird die gelesene Instruktion dekodiert und meist mittels einer Switch-Anweisung oder Funktionstabelle (Sprungtabelle) an die entsprechende Übersetzungsfunktion verteilt und ausgeführt.^[102]vgl. Supnik, R. M.: Writing a Simulator for the SIMH System. Revised 22-Sep-2008 for SIMH V3.8-1. Version vom 22. September 2008, S. 10f und Shaffer, J.: A Performance Evaluation of Operating … Continue reading

Der Ablauf lässt sich durch Pseudocode verdeutlichen:

BOOL finished = false;
REPEAT
    IF ( TIMED_EVENT ) ExecuteTimedEvents();
    FOR ( interrupt IN openInterrupts[] )
        ExecuteInterrupt(interrupt);
    IF ( PROCESSOR_EVENT ) ExecuteProcessorEvent();

    IP = IP++;
    command = FetchCommand(IP);
    opcode = command[0];
    operands[] = DecodeAddresses(command[]);
    SWITCH (opcode)
        CASE 01: ExecuteCommand01(operands);
        [...]
    END SWITCH
UNTIL (finished == true)

Diese prototypische Darstellung entspricht der logischen Funktionsweise aller gängigen Full-System-Emulatoren. Bei quelloffenen Emulatoren lässt sich ein entsprechender CPU-Teil leicht im Quellcode identifizieren. Dies wird in Abschnitt 3.7 benutzt, um die Funktionsweise und Abstraktionsebene der jeweiligen Implementierung genauer zu untersuchen.

Zeitbasis

Die CPU muss sich dabei an einer Zeitbasis orientieren, die für alle simulierten Komponenten des Systems gleich ist^[103]vgl. Supnik, R. M.: Writing a Simulator for the SIMH System. Revised 22-Sep-2008 for SIMH V3.8-1. Version vom 22. September 2008, S. 6., um einen künstlichen „Takt“ für das emulierte System bereitzustellen. Diese kann sich an der Realzeit des Hostsystems (z.B. durch Abfrage der eingebauten Uhr) orientieren, um beispielsweise Schritte im Nano-oder Millisekundentakt auszuführen oder aber ein arbiträres Zeitmaß wie CPU-Zyklen oder Instruktionen definieren. Wichtig hierbei ist, dass die Zeitbasis im Emulator nicht der Zeitbasis des Hostsystems entspricht, da auch die Taktzyklen der Original-CPU-Befehle nicht den Taktzyklen der implementierten Instruktionen im Emulator entsprechen. Oft sind die Taktzyklen des emulierten Systems auf der Host-CPU auch nicht trivial berechenbar. Ist der Emulator beispielsweise in Java geschrieben und wird auf der virtuellen Java-Maschine ausgeführt (JavaVM), so hängen die benötigten Taktzyklen auf der Host-CPU von der Implementierung der JavaVM ab.

Demgegenüber steht die notwendige Bedingung, die Geschwindigkeit des emulierten Systems gegenüber der Geschwindigkeit des Hostsystems konstant zu halten (in Takt pro Sekunde). Dies allein ist jedoch nicht ausreichend, um dynamische Objekte wie Computerspiele authentisch reproduzieren zu können. Ist der Takt des emulierten Systems an die Verarbeitungsgeschwindigkeit des Hostsystems gekoppelt, so laufen auf modernen Prozessoren die Prozesse innerhalb der emulierten Umgebung unter Umständen deutlich schneller ab. Ein zu hohes Tempo kann beispielsweise die Bedienung eines Spiels unmöglich machen, da der Spieler im Spielablauf nicht mehr rechtzeitig auf gegebene Situationen reagieren kann. Auch unterliegt die Tonausgabe der Echtzeitbedingung. Musik in einem Spiel kann z. B. nicht beliebig schneller oder langsamer abgespielt werden.

Wäre der Takt des emulierten Systems nur direkt an den des Hostsystems gekoppelt, führt dies unweigerlich zu einem Authentizitätsverlust, der dem Bewahrungsziel entgegensteht.

Howard Besser berichtet von einem Vortrag des Computerkünstlers und Informatikers Jaron Lanier auf der „Time & Bits Conference“, in dem Lanier sich von der Reanimation eines seiner frühen Computerspiele mittels eines (von einer Gruppe Interessierter programmierten) Emulators lossagt: “[…] he contended that this was not the game as he had designed it. Contemporary computer processors made the game run much faster, and that faster pacing transformed the piece into something he refused to accept as his work”.^[104]Besser, H.: Longevity of Electronic Art. In: ICHIM (2001), S. 268.

Ein wesentliches Merkmal eines Full-System-Emulators muss es daher sein, dass die äußere Ausführungsgeschwindigkeit des emulierten Systems auf dem Hostsystem der des originalen Systems entspricht. Technisch wird dies zumeist in einem vom Event-Loop unabhängigen Timer-Thread realisiert. Dieser dient zu Synchronisierung der beiden Instruktionsausführungszeiten und kann durch Abgleich mit der Echtzeituhr des Hostsystems den Takt pro Sekunde des emulierten Systems genau an den des Originalsystems anpassen. Der Timer-Thread ruft dazu pro simuliertem Takt das CPU-Modul und anschließend nacheinander die einzelnen Komponenten des emulierten Systems auf.^[105]Beispiel-Implementierung siehe Supnik, R. M.: Writing a Simulator for the SIMH System. Revised 22-Sep-2008 for SIMH V3.8-1. Version vom 22. September 2008, S. 6.

Ereignisssteuerung

Neben der Bereitstellung einer Zeitbasis und der Ausführung des Fetch-Execute-Zykluses wie oben beschrieben, müssen im Event-Loop die Hard- und Softwareinterrupts des Systems nachgeahmt werden. Hardwareinterrupts werden von Hardwarekomponenten des Systems zur Ereignissteuerung generiert (beispielsweise der Tastendruck auf eine Tastatur) und sind zumeist nicht maskierbar. Ihre Ausführung ist daher zeitkritisch. Zudem definieren die meisten CPUs die Möglichkeit, Interrupts durch Softwarebefehle generieren zu können.

Interrupts sind dabei in der Regel auf Instruktionsebene atomar, sodass ihre Abarbeitung vor dem Fetch-Execute-Zyklus erfolgt, diesen aber nicht mitten in der Ausführung unterbrechen (siehe Ablauf im Event-Loop-Pseudocode).

Als Zusatzkriterium muss die emulierte Umgebung in der Lage sein, externe, vom Nutzer ausgelöste Aktionen, die den Zustand des emulierten Systems ändern, zu berücksichtigen.^[106]vgl. ebenda, S. 9.

Nicht emuliert werden hingegen in der Regel interne Hardwareoptimierungen moderner CPUs wie multiple Pipelines, CPU-Caches sowie Sprungvorhersagemethoden (branch prediction), da diese zum einen aus Softwaresicht transparent sind und ihre Implementierung äußerst komplex ist. Hinzu kommen rechtliche Fragestellungen. So zählen diese Optimierungen in der Regel zu den Betriebsgeheimnissen der Hersteller und sind dementsprechend nicht offengelegt oder durch Patente geschützt, welche eine Re-Implementierung ohne Genehmigung des Herstellers unterbinden.

Für Mehrkernsysteme oder Systeme mit mehreren parallelen Prozessoren hingegen, wie beispielsweise Intels Core Duo Prozessoren oder die beiden Vektorprozessoren der PlayStation 2, muss hingegen jeder einzelne CPU-Kern emuliert werden, um die Abläufe des Originalsystems nachbilden zu können. So emuliert beispielsweise der PlayStation-2-Emulator PCSX2 zwei Prozessoren des Originalsystems durch zwei separate CPU-Threads.

Die schrittweise Interpretation, Abarbeitung und Übersetzung aller Befehle der CPU durch Software erfordert – im Vergleich zum Originalsystem – einen enormen Rechenaufwand. Die Verarbeitungsgeschwindigkeit des Hostsystems muss daher signifikant höher sein als, als die des Originalsystems. Die Wahl der Abstraktionsebene der Emulation ist daher von entscheidender Bedeutung – je genauer die Nachbildung, desto höher der Rechenaufwand. Das Problemfeld der Genauigkeit der Emulation versus Emulationsgeschwindigkeit wird im Rahmen der Implementierung der eigentlichen Binärübersetzung der CPU-Befehle in Abschnitt 3.6 genauer untersucht.

3.5.2 Speichersubsystem

Um den Speicher des Originalsystems nachzubilden, muss dieser auf den Speicher des Hostsystems abgebildet werden. Da sich Speichergröße, Adressierungsmodi, Byte-Reihenfolge (Big-Endian vs. Little-Endian) und das Layout des Systemspeichers auf dem Hostsystem in der Regel vom emulierten System in einem hohen Maß unterscheiden, kann keine direkte Zuordnung (mapping) vorgenommen werden. Es ist daher notwendig, innerhalb des Emulators eine eigene Speicherverwaltung zu implementieren. Dies geschieht über ein Speichersubsystem. Der Emulator muss dabei Datentypen verwenden, die mindestens genau so viel Bit kodieren können, wie die Wortlänge des Originalsystems.^[107]vgl. ebenda, S. 7.

Die einfachste Implementierung eines Speichersubsystems besteht darin, den Speicher des Originalsystems durch ein Array von der Länge des physischen Speichers des Originalsystems zu simulieren, um so einen fortlaufend adressierbaren Speicherbereich zu erhalten. Dies entspricht z. B. dem Layout vieler 8-bit-Heimcomputer und Konsolen der 70er- und 80er-Jahre mit einem MOS6502-Prozessor.^[108]Der 6502-Chip und Varianten wurde unter anderem im Apple I, Apple II, Commodore PET, C64 (Heimcomputer) sowie Atari 2600, Atari 5800, Atari 7800 und Nintendo Entertainment System (Spielkonsolen) … Continue reading Diese Systeme verfügten über einen einzigen zusammenhängenden linear adressierbaren physischen Speicher ohne Zugriffsschutz, wobei jedoch auch hier einzelne Speicherbereiche durch ROM-Bereiche überdeckt werden können (z. B. um beim Einschalten das integrierte Betriebssystem oder die Firmware zu laden). Der Emulator muss dies bei Schreibzugriffen berücksichtigen.

Spätestens mit dem Aufkommen von 16-bit-Architekturen hat sich jedoch eine komplexere Speicherverwaltungstechnik in Hardware etabliert, um die Grenzen des physischen Speichers zu überwinden und Applikationen dynamisch einem sogenannten virtuellen Speicher zuteilen zu können. Im PC-Bereich wurde dies beispielsweise in der x86-Architektur durch den „Protected Mode“ des Intel 286 und nachfolgender Prozessoren umgesetzt. Hierzu wird der Applikation ein von der physischen Arbeitsspeichergröße unabhängiger Adressraum, der über das Speicherverwaltungssystem des Prozessors (Memory Management Unit – MMU) und Betriebssystems zur Verfügung gestellt wird, zugeteilt. Die MMU sorgt dabei für die Umrechnung der logischen in die physische Adresse und verwaltet Speicherzugriffe (Zugriffsschutz), damit eine Applikation beispielsweise nicht den Speicherbereich einer anderen überschreiben kann.^[109]vgl. Coy, W.: Aufbau und Arbeitsweise von Rechenanlagen. Eine Einführung in Rechnerarchitektur und Rechnerorganisation für das Grundstudium der Informatik. Braunschweig: Verlag Friedr. Vieweg … Continue reading

Die Adresse des logischen Speichers unterscheidet sich also von der des physischen Speichers, wodurch prinzipiell ein beliebig großer Speicher realisiert werden kann, in dem Speicherbereiche durch das System dynamisch auf Sekundärspeicher wie Festplatten ausgelagert werden. Die Verwaltungsfunktion der MMU müssen vom Speichersubsystem oder CPU-Modul des Emulators nachgebildet werden. Da die Speicheraufteilung auf dem Hostsystem in der Regel auch virtuell erfolgt, werden Speicheranforderungen durch das Emulatorprogramm an das Host-Betriebssystem übergeben, das wiederum zusammen mit der Host-MMU eine Adresstranslation von virtuell nach physisch vornimmt. Abbildung 3.2 zeigt den Mehraufwand der doppelten Speicherverwaltung und Adresszuordnung im Hostsystem und emulierten System am Beispiel der Zuordnung von logischen zu physischen (in Segmente unterteilten) Speicherbereichen.

Unabhängig von der Speicherverwaltung müssen vom Emulator häufig Sonderfälle wie die Einblendung von ROM-Inhalten in lokale Speicherbereiche (s. o.) oder aber in Speicher abgebildete Ein-/Ausgabeports von Systemkomponenten berücksichtigt werden. In beiden Fällen werden Zugriffe vom Systemspeicher auf andere Komponenten umgeleitet und das Speichersubsystem muss die Anfrage an die entsprechende emulierte Komponente weiterreichen. Der Emulator muss also getrennte Prozeduren für Schreib- und Lesezugriffe implementieren.

Alle diese Betrachtungen setzen implizit einen bestimmten Abstraktionsgrad voraus, nämlich das die Hardwarecharakteristika, das interne Layout (Optimierungsschaltungen, Zugriffszeiten, Cell-Refresh, und weitere) und Schaltvorgänge innerhalb des physischen Speichers transparent und damit vernachlässigbar sind. Der Speicher wird lediglich als Ansammlung von les- und schreibbaren Bits verstanden. Ein solcher Grad der Emulation wird bei ergebnisorientierten funktionalen Full-System-Emulatoren jedoch nicht implementiert, da dies enorme Geschwindigkeitseinbußen zur Folge hätte. Zudem wird der Abstraktionsgrad in der Literatur zum Thema Langzeitbewahrung und Emulation nicht behandelt wird.^[110]vgl. u.a. Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003; Neuroth, H. (Hrsg.); et … Continue reading

Die Emulation von RAM-Charakteristika findet nur in speziellen Emulatoren für die Entwicklung und Optimierung von Speichermodulen wie beispielsweise DRAMSim oder DRAMSim 2 Anwendung.^[111]vgl. Wang, D.; Ganesh, B.; Tuaycharoen, N.; Baynes, K.; Jaleel, A.; Jacob, B.: DRAMsim: a memory system simulator. In: SIGARCH Computer Architecture News, ACM SIGGRAPH, Volume 33, Number 4, 2005, … Continue reading Hier wird – analog zum Abstraktionsgrad des CPU-Moduls – eine pragmatische Entscheidung zugunsten der Emulationsgeschwindigkeit und Komplexitätsreduktion getroffen. Ebenso wird der eigentliche Zugriffsweg einer CPU auf den RAM über die beiden Register MAR (Memory Address Register) und MDR (Memory Data Register) über den zentralen Datenbus des Systems aus Geschwindigkeitsgründen nur von sehr wenigen funktionalen Full-System-Emulatoren implementiert. Stattdessen wird der Zugriff vom Speichersubsystem abstrahiert und – ohne die Nachahmung des Systembusses – direkt durchgeführt.^[112]Siehe beispielsweise Supnik, R. M.: Simulators: virtual machines of the past (and future). In: ACM Queue, Volume 2, Number 5, Issue July/August 2004, S. 56 sowie Abschnitt 3.7.2, Tabelle 1.

3.5.3 I/O-Subsysteme

Neben dem CPU- und Speichersystem besitzt ein Full-System-Emulator in der Regel mehrere Ein-/Ausgabesubsysteme in Software zur Nachahmung der verschiedenen Hardwarekomponenten des Originalsystems. Diese dienen beispielsweise als Schnittstelle zu realen Hardwarekomponenten des Hostsystems (Mapping von realen Geräten wie CD-ROM, Ethernet oder Tastatur), zur Kommunikation mit der Außenwelt bzw. dem Nutzer sowie als Brücke zum Dateisystem des Hostsystem zur Emulation von Datenträgern über Image-Dateien oder Verzeichnisse. Die verschiedenen Subsysteme werden zumeist über ein zentrales Controller-Modul angesteuert, welches an das CPU-Modul angebunden ist und die Verteilung an die zuständigen Subsysteme übernimmt.

Zu den generellen Aufgaben des Controllers gehören laut [Supnik 2008, S. 8]^[113]Supnik, R. M.: Writing a Simulator for the SIMH System. Revised 22-Sep-2008 for SIMH V3.8-1. Version vom 22. September 2008, S. 8.

• die Identifikation des Ein-/Ausgabebefehls anhand der angesprochenen Geräte- bzw. Speicheradresse (identify),
• die Lokalisierung des entsprechenden Gerätes oder Subsystems (locate),
• die Vereinheitlichung des Befehls zur Übergabe an das Subsystem (breakdown)
• sowie der Aufruf des entsprechenden Prozessor-Moduls des Subsystems (call).

Jedes Subsystem übernimmt die Nachbildung einer Komponente und übersetzt die Ein- bzw. Ausgabedaten des emulierten Systems auf die Hardware-Ressourcen des Hostsystems. Die Aufgaben und Anzahl der Subsysteme wiederum sind entsprechend systemspezifisch und können nicht generalisiert beschrieben werden, sondern hängen von der Konfiguration des Originalsystems ab. Typische Komponenten sind Grafikausgabe, Tonausgabe, Eingabegeräte (Tastatur, Maus), Massenspeicher (dedizierte Chipsätze) und Netzwerkkarten (Ethernet-Controller, WLAN).

Für Subsysteme, die eigene Prozessoren (wie beispielsweise von Grafikkarten, HD-Controllern, etc.) nachbilden, gilt prinzipiell dasselbe Ablaufschema wie beim CPU-Modul, wobei jedoch systemspezifisch nicht immer alle Schritte notwendig sind oder aber zusätzliche Schritte zur Emulation bestimmter spezieller Hardwarefunktionen ausgeführt werden müssen. Der wesentliche Unterschied besteht darin, dass Hardwarekomponenten in der Regel über Interrupts wartende Ein-/Ausgabedaten signalisieren. Die Subsysteme generieren daher Interrupts, welche an das CPU-Modul weitergegeben werden. Das CPU-Modul muss in diesem Fall die Ausführung des aktuellen Programms unterbrechen und ein entsprechendes Interrupt-Programm ausführen (Interrupt Service Routine). Anschließend muss das unterbrochene Programm fortgeführt werden (siehe Abschnitt 3.5.1). Zudem ist es manchen Komponenten möglich, direkt auf Speicherinhalte zuzugreifen (DMA), ohne mit der CPU zu kommunizieren.

Im Gegensatz zur bereits sehr aufwendigen CPU-Emulation, ist die detailgenaue Emulation der Ein-/Ausgabeperipherie durch die Interaktion der Komponenten untereinander noch einmal deutlich komplexer. Wie bereits beschrieben, wird aus Gründen der Performanz der Datenbus des Systems zumeist nicht emuliert.^[114]Zur Untermauerung dieser These wird neben der Literaturrecherche in Abschnitt 3.7 eine vergleichende Analyse bestehender Emulationssysteme durchgeführt. In diesem Fall findet die logische Kommunikation direkt statt, wobei die einzelnen Subsysteme vom CPU-Modul jeweils als Sonderfall im Event-Loop betrachtet werden, der über das zentrale Controller-Modul abgearbeitet wird. Die Vernetzungsstruktur entspricht also nicht unbedingt der des originalen Hardwarebusses, zeitliche Abhängigkeiten der Kommunikation müssen in Software nachgebildet werden und sind wieder vom gewählten Grad der Abstraktion abhängig.

Dieses Problem wird bereits beim ersten Emulator der IBM in [Tucker 1965] beschrieben. So weist Tucker zum einen auf Performanzverluste durch in Software nachgebildete Ein-/Ausgaberoutinen hin.^[115]vgl. Tucker, S. G.: Emulation of large systems. In: Communications of the ACM, Volume 8, Number 12, 1965, S. 755. Zum anderen beschreibt er die komplexen zeitlichen Abhängigkeiten bei der Emulation eines Tape-Drives der IBM 7074 durch Anbindung an das 9-Track-Tape der IBM/360. Dieses hat eine höhere Lesegeschwindigkeit und basiert – im Gegensatz zum 6-bit-Satz der alten Systeme – auf einem 8-bit-Zeichensatz, wodurch bei jeder Operation 2 bit mehr gelesen und verarbeitet werden müssen. Tucker nennt diese Problematik das „Conversion Problem“ und zieht daraus den Schluss: “[a] time-dependent program can not be guaranteed to run on an emulator”^[116]ebenda. Auf das Problem der Emulation von Ein-/Ausgabe-Schnittstellen wird in Abschnitt 4.2 genauer eingegangen.

Die Genauigkeit der Nachbildung bzw. die gewählte Abstraktionsstufe hat also direkte Auswirkungen auf die Möglichkeiten und Grenzen des Full-System-Emulators. Es erscheint daher sinnvoll, auf diese näher einzugehen. Zu beachten ist dabei, dass die in der Literatur meist behandelte Genauigkeit des Emulators, in der Regel die gewählte Abstraktionsebene des CPU-Moduls und nicht unbedingt der Abstraktionsgrad der Prozessormodule der Ein-/Ausgabesubsysteme gemeint ist. Die nachfolgenden Abstraktionsgrade sind aber allgemeingültig und daher analog auch auf diese Subsysteme anwendbar.

3.6 Technische Abstraktionsgrade von Emulatoren

Wie am Beispiel des CPU-Moduls, Speichers und weiterer I/O-Subsysteme verdeutlicht, muss bei der Implementierung jeder Komponente ein entsprechender Abstraktionsgrad gegenüber dem Originalsystem gewählt werden. Diese zum Entwicklungszeitpunkt getroffene Entscheidung über den Detailgrad der Replikation der internen Zustände des Systems bedingt nachhaltig die mögliche Exaktheit der Emulation.

Supnik benennt für das SIMH-Projekt die Exaktheit der Emulation als eine Designmaxime, denn “[t]his stems from a simple observation: the more accurate the simulation, the more software it will run correctly”^[117]Supnik, R. M.: Simulators: virtual machines of the past (and future). In: ACM Queue, Volume 2, Number 5, Issue July/August 200, S. 56. Der Autor unterscheidet dabei zwischen der Abstraktionsebene (level of simulation) und dem Abstraktionsgrad (detail of simulation) des Emulators. Unter der Abstraktionsebene versteht man das Spannungsfeld zwischen funktionaler Nachahmung des äußeren Verhaltens des Originalsystems versus der exakten und originalgetreuen Reproduktion aller internen Zustände. Sie zielt auf die Gesamtstruktur des Systems. Die meisten existierenden Emulatoren verfolgen dabei – wie auch die SIMH-Emulatoren – den verhaltensbezogenen bzw. funktionalen Ansatz, bei dem nicht versucht wird, die internen atomaren Operationen des Systems zu modellieren.^[118]vgl. ebenda, S. 56.

Unter die Abstraktionsebene fallen beispielsweise die Nachahmung des Datenbusses gegenüber der direkten Verteilung an Subsysteme, die Modellierung des Speicherzugriffs über die MAR/MDR-Register gegenüber des direkten Zugriffes mittels Funktionsaufruf oder die Nachahmung des korrekten Zeitverhaltens, interner (Zwischen)zustände und Buszugriffe angeschlossener Systemkomponenten und Ein-/Ausgabesubsysteme (siehe Abschnitt 3.5).

Der Abstraktionsgrad hingegen beschreibt die Feingradigkeit, mit der die Binärübersetzung der CPU-Befehle sowie angeschlossener Prozessoren nachgeahmt wird. Der gewählte Grad hat dabei direkte Auswirkungen auf das interne und externe Zeitverhalten des Systems. Supnik fordert daher für das CPU-Modul von Emulatoren “[…] a very fine level of detail, or software will fail to run”^[119]ebenda, S. 57. Es ist daher notwendig, eine Qualifizierung der einzelnen Grade vorzunehmen.

Arjan Tijms versucht, eine Klassifikation von Emulatoren anhand des Abstraktionsgrades der Binärübersetzung vorzunehmen. Er beschreibt die Funktionsweise des Fetch-Execute-Zykluses, in dessen letzten Schritt, der Befehlsausführung, das emulierte System in einen „ähnlichen“ Zustand versetzt wird, wie das Originalsystem. Der Grad diese Ähnlichkeit steht für die Genauigkeit der Emulation. Tijms unterscheidet fünf Abstraktionsgrade in absteigender Reihenfolge der Reproduktionsgenauigkeit:^[120]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 2.

• Datenbus- und Pin-Genauigkeit (datapath accuracy)
• Zyklengenauigkeit (cycle accuracy)
• Instruktionsgenauigkeit/Taktgenauigkeit (instruction level accuracy)
• Blockgenauigkeit mittels dynamischer Rekompilierung (basic block und high/very high/ultra high level emulation/accuracy)

Nicht immer ist es – insbesondere in Anbetracht der benötigten Rechenleistung – notwendig oder möglich, den höchsten Grad der Datenbus- bzw. Pin-Genauigkeit zu implementieren. Für bestimmte Fälle können einige Zustände des Systems vernachlässigt werden oder sind für die exakte Nachahmung nicht relevant.^[121]vgl. ebenda, S. 2 sowie Beispiele S. 12f. Zum besseren Verständnis werden die genannten Grade zunächst näher beleuchtet und anschließend Gründe für die Auswahl eines Grades diskutiert.

Wenn es sinnvoll erscheint, geschieht dies am Beispiel des in vielen 8-bit-Heimcomputersystemen verwendeten 6502-Prozessors der Firma MOS Technology (später Commodore International), dessen Struktur, Assemblercode und Befehle intensiv untersucht wurden und dessen CPU-Implementierungen in allen Abstraktionsgraden existieren.^[122]Weitere Informationen mit einer Auflistung von Ressourcen zur 6502-Emulation finden sich auf http://6502.org/tools/emu/.

3.6.1 Blockgenauigkeit mittels dynamischer Rekompilierung

Bei der Blockgenauigkeit (von Tijms nach Länge der übersetzten Codeblöcke in basic block und high/very high/ultra high level emulation bzw. accuracy unterteilt^[123]ebenda, S. 3. wird die interpretative Ausführung des Programmcodes des klassischen Event-Loops (siehe Abschnitt 3.5.1) durch eine dynamische Vorabübersetzung größerer Instruktionsblöcke ersetzt. Dazu bedarf es dynamischer Translationstechniken, der sogenannten Just-In-Time-Rekompillierung (JIT). Die Idee besteht darin, ausführbaren Maschinencode aus den Instruktionen der emulierten CPU bei Bedarf zur Laufzeit des Emulators auf der Host-CPU zu erzeugen. Es werden also nicht einzelne Instruktionen interpretiert, sondern der Code analysiert, bestimmte Strukturen (Blöcke) identifiziert und dynamisch durch äquivalente Strukturen nativen Codes der Host-CPU ersetzt. Der Emulator wird somit zum Compiler. Dies erfordert zwangsweise eine Analyse (profiling) des Originalcodes. Die dynamische Rekompilierung kann daher kein statischer Teil des Emulators sein.^[124]ebenda. In der Regel wird versucht, häufig ausgeführte, standardisierte Programmteile wie Schleifen oder zusammengesetzte Rechenoperationen zu übersetzen. Der Emulator identifiziert diese in einem ersten Schritt, findet das dazu passende Äquivalent im nativen Code (wobei die Register der Original-CPU zwangsweise auf Register der Host-CPU abgebildet werden) und speichert diese in einem Puffer ab. Der Puffer wird – bis das Ende der Schleife bzw. des Blocks erkannt wird (z. B. durch eine Sprunginstruktion) – sukzessive erweitert. Anschließend wird der so erzeugte Maschinencode direkt auf der Host-CPU ausgeführt. Der eben erzeugte Maschinencode-Block wird zusammen mit anderen erkannten bzw. berechneten Blöcken zwischengespeichert (Cache). Somit steht der einmal übersetzte Code beim nächsten Auftreten bzw. Durchlaufen des gleichen Codeblocks sofort zur Verfügung und kann direkt ausgeführt werden.

Die high level emulation (HLE) verhält sich analog, wobei größere Blöcke ersetzt werden, die einer gewissen Semantik genügen. Die Identifikation dieser Blöcke kann hierbei nicht mehr automatisch bzw. transparent erfolgen, sondern erfordert mittels spezieller Entwicklungswerkzeuge im Vorfeld eine manuelle Analyse des auszuführenden Codes (programmgebunden). Es werden Blöcke gesucht, die eine High-Level-Funktionalität des Originalsystems – beispielsweise das Zeichnen eines Polygons oder die Dekomprimierung von Audio- oder Videoströmen – zum Ziel haben. Diese müssen dann in optimierter Form für die verschiedenen Prozessoren (Grafik, Audio, 3D oder CPU) des Hostsystems re-implementiert werden. Gewöhnlich werden dabei rechenintensive Grafik- und Audioroutinen übersetzt. Theoretisch ist es durch die Ansammlung vieler solcher übersetzter Routinen möglich, diese in einer Art Baukastenprinzip auch auf neue unbekannte Applikationen anzuwenden.^[125]vgl. ebenda, S. 3 sowie S. 8–10.

In beiden Fällen besteht das Ziel darin, eine drastische Steigerung der Ausführungsgeschwindigkeit gegenüber der Instruktionsweisen Interpretation der CPU-Befehle zu erreichen. Die Funktionsweise eines solchen Systems lässt sich in [Tedder 2011]^[126]Tedder, M.: JIT CPU Emulation: A 6502 to x86 Dynamic Recompiler (Part 1). In: #AltDevBlogADay, Artikel vom 12.6.2011, 2011. [abgerufen 14.10.2012] nachvollziehen. Tedder beschreibt darin die Implementierung seines 6502-Emulators mit Blockgenauigkeit für die x86-Architektur. Der zentrale Ablauf besteht in der Prüfung, ob im Block-Cache bereits ein übersetzter Block für die aktuelle Position des Programmcounters vorhanden ist. Falls dies der Fall ist, wird der zuvor übersetzte Block ausgeführt (Execute-Funktion). Ansonsten wird der auszuführende Code-Block rekompiliert und dem Cache hinzugefügt. Die Execute-Funktion überträgt den emulierten CPU-Zustand (Register, Flags) in die korrespondierenden x86-Register. Danach wird der native Codeblock aufgerufen. Anschließend wird der neue Zustand der x86-Register wieder in den emulierten CPU-Zustand übertragen (Zielzustand).

Durch die Ausführung großer Teile des Programms in nativem x86-Code kann eine Geschwindigkeit der Emulation nahe der des Hostsystems erreicht werden.^[127]vgl. ebenda.

Jedoch ist durch den Wegfall des Fetch-Execute-Zykluses keine deterministische Aussage über die Dauer der Ausführung möglich.^[128]vgl. Shaffer, J.: A Performance Evaluation of Operating System Emulators. Bachelorarbeit, Bucknell University, Lewisburg, PA, U.S.A., 2004, S. 12. Der Zustand des emulierten Systems kann zudem immer nur nach Ausführung eines Codeblocks angepasst werden. Dies hat dramatische Auswirkungen auf das Zusammenspiel mit den anderen Komponenten des Emulators und damit auf die erzielbare Genauigkeit. So können zeitliche Abhängigkeiten zu anderen Ein-/Ausgabesystemen nicht aufgelöst werden und keine stabile Zeitbasis für den Emulator geschaffen werden. Trotz dieser beträchtlichen Ausführungsgeschwindigkeit befindet Tijms diese Form der Emulation nicht als geeignet, das zu emulierende System mit hinreichender Genauigkeit nachzubilden.^[129]vgl. Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 9. Die Anwendungsmöglichkeiten liegen viel mehr in der Beschleunigung der Ausführung von interpretierten oder Skriptsprachen, wie Java, JavaScript oder PHP. Durch die Verwendung von dynamischer Rekompilierung ist die Implementierung des Emulators zudem an eine konkrete CPU-Befehlsarchitektur gebunden, was die Portabilität des Emulators einschränkt.

Für die Langzeitbewahrung dynamischer Objekte ist dieser Abstraktionsgrad gänzlich ungeeignet, da Emulatoren mit JIT-Kompilierung einen Großteil zeitkritischer interaktiver Software (wie Computerspiele) nicht oder nur mit Wiedergabefehlern ausführen können. Bei der Verwendung von Emulatoren mit optionalem JIT-Modul, muss dieses bei der Ausführung historischer Software deaktiviert werden.

3.6.2 Instruktionsgenauigkeit

Die nächste Stufe des Abstraktionsgrades ist die Instruktionsgenauigkeit. Durch die Interpretation der einzelnen Instruktionen des Programmcodes kann man hier erstmals von einem Full-System-Emulator mit Event-Loop sprechen. Bei der Instruktionsgenauigkeit modelliert das CPU-Modul jede einzelne Instruktion der Original-CPU in Software. Eine Instruktion entspricht dabei der atomaren Ausführung eines Emulationsschritts.^[130]vgl. ebenda, S. 2. Der Zustand von Registern, Flags, Programmcounter der CPU sowie Speicherinhalten wird nach jeder Instruktion angepasst und entspricht vor und nach der Ausführung entsprechend dem Zustand der CPU des Originalsystems. Dadurch wird eine Befehlskompatibilität (Opcodes) zur Original-CPU hergestellt – das zur erfolgreichen Emulation benötigte Minimum an Kompatibilität. Der Programmcounter wird erst nach Ausführung der Instruktion entsprechend um die Länge der Instruktion erhöht.

Die Dauer einer Instruktion in Takten hingegen ist nicht festgeschrieben und entspricht in der Regel nicht der Ausführungsdauer einer Instruktion auf der Original-CPU, wodurch Zeitabhängigkeiten mit Ein-/Ausgabesubsystemen nicht eingehalten werden können. Auch entsprechen die internen Schritte des emulierten Systems während der Instruktionsausführung nicht denen des Originalsystems. Die Implementierung ist nicht definiert. So können beispielsweise Befehle, die auch auf der Host-CPU vorhanden sind, direkt in einem Schritt ausgeführt werden. Dadurch können sehr optimierte Implementierungen vorgenommen werden, was zum einen zu einer Komplexitätsreduktion bei der Entwicklung und zum anderen zur Erhöhung der Ausführungsgeschwindigkeit des Emulators führen kann. Die Zeitbasis richtet sich nach dem Durchlauf des Event-Loops. Im einfachsten Fall benötigt jede Instruktion einen virtuellen Takt oder ist direkt an die Geschwindigkeit des Hostsystems gekoppelt.

Die folgenden zwei Instruktionen in 6502-Assembler führen eine einfache Berechnung durch und sollen zur Veranschaulichung dienen:

LDA #$42 // lädt den Hexadezimalwert 0x42 in den 
         // Akkumulator (Register)
AND #$23 // führt eine bitweise UND-Verknüpfung 0x23
         // und dem Akkumulator durch, wobei das
         // Ergebnis im Akkumulator gespeichert wird

Als Ergebnis hat der Akkumulator nach Ausführung der beiden Instruktionen den Wert „2“.

Ein Emulator mit Instruktionsgenauigkeit könnte die beiden Befehle LDA (LoaD Accumulator) und AND mit Immediate-Adressierung beispielsweise durch folgende zwei Prozeduren implementieren:

emulate_LDA_immediate(value) {
    accumulator = value;
}
emulate_AND_immediate(value) {
    accumulator = accumulator & value;
}

Diese würden dann durch die Sprungtabelle am Ende des Event-Loops aufgerufen und der Systemtakt nach dem Durchlauf um eins erhöht. Die Ausführungszeit jeder Instruktion würde also einen virtuellen Takt betragen, die Gesamtlaufzeit des Mini-Programms dementsprechend zwei Takte. Laut Spezifikation der 6502-CPU benötigen aber sowohl der LDA- als auch der AND-Befehl (Immediate-Adressierung) zwei Takte zur Ausführung (vgl. [Commodore 1985]). Das Programm müsste demnach vier Takte zur Berechnung benötigen. Der Emulator wäre jedoch schon nach der Hälfte der Zeit fertig. Steht diese Berechnung beispielsweise innerhalb einer Schleife und wird mehrfach durchlaufen, können sich so erhebliche Abweichungen bei der Programmlaufzeit ergeben.

Für Tijms ist die Instruktionsgenauigkeit für viele Fälle ausreichend, da die äußeren Zustände der Originalinstruktion modelliert werden, jedoch ohne Timing-Constraints einzuhalten.^[131]vgl. ebenda. Dies kann jedoch – insbesondere bei zeitkritischer Software – zu Abweichungen oder Race Conditions führen. So können beispielsweise Darstellungsfehler entstehen, wenn der Interrupt für die vertikale Synchronisation der Videoausgabe durch die veränderten Ausführungszeiten der Instruktionen an anderer als der im Originalsystem vorgesehenen Stelle ausgeführt wird.^[132]Beispiele und Implikationen hierfür werden in Abschnitt 3.8 erörtert. Als Zwischenlösung schlägt Tijms vor für bekannte Programme, die Probleme verursachen, fest codierte Ausnahmeregeln als Sonderfälle im Emulator zu implementieren (patches). Durch geschickte Implementierung soll so an bestimmten Problemstellen eine hinreichende Exaktheit der Emulation erzeugt werden, um zumindest die Ausführung der jeweiligen Software zu ermöglichen.^[133]vgl. Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 2. Dies setzt natürlich voraus, dass die entsprechende Problemstelle bei Tests entdeckt wurde, die Ausführung des Programms für wichtig genug erachtet wird, um den Emulator zu anzupassen und dass genug personelle und finanzielle Ressourcen zur Verfügung stehen, dieses Vorhaben durchzuführen. Darin steckt auch die implizite Annahme, dass alle für das Originalsystem geschriebenen Programme bekannt sind und es sich um ein sogenanntes „abgeschlossenes Sammelgebiet“ handelt, d. h. keine neuen Programme mehr für die Plattform entstehen. Die Testproblematik, ökonomische Faktoren sowie die an der Programmierung von Emulatoren beteiligten Akteure werden in Kapitel 4 genauer untersucht.

3.6.3 Zyklengenauigkeit

Eine weitere Steigerung gegenüber der Instruktionsgenauigkeit stellt die Zyklengenauigkeit dar. Bei einem zyklengenauen Emulator benötigen Instruktionen dieselbe relative Zeit wie auf dem Originalsystem, sowohl untereinander, als auch im Wechselspiel mit den anderen Komponenten des Systems.^[134]vgl. ebenda. Die Taktanzahl pro Befehl entspricht also der Taktanzahl auf der Original-CPU. Somit lassen sich auch unterschiedliche Taktanzahlen je nach Adressierungsart der Speichers für ein und den selben Befehl modellieren. Die LDA-Instruktion des 6502 benötigt beispielsweise in der Adressierungsart „Absolute“ vier Takte und sechs Takte in der Adressierung „Indirect,X“ (vgl. [Commodore 1985]). Um einen zyklengenauen Emulator für das Mini-Rechenbeispiel aus Abschnitt 3.6.2 zu implementieren, ist es zudem notwendig die internen Verarbeitungsschritte des Prozessors für jeden Takt zu kennen. Nach West und Makela^[135]West, J.; Makela, M.: Documentation for 6502/6510/8500/8502 instruction set. In: Commodore 64 emulator and Program Development System, 1994. führt der 6502 bei LDA und AND im ersten Takt (cycle) einen Lesezugriff auf dem Speicher aus, um den Opcode zu erhalten. Dieser liegt nun auf dem Datenbus an. Im zweiten Takt wird der Operand aus dem Speicher gelesen und die eigentliche Instruktion ausgeführt. Nach jedem Takt wird der Programmcounter um ein Byte erhöht. Für die Zyklengenauigkeit ist es jedoch nicht notwendig, den Speicherzugriff über den Datenbus bzw. den Datenbus selbst zu emulieren. Lediglich der Zustand des Prozessors muss nach jedem Takt mit dem der Original-CPU übereinstimmen.

Zyklengenaue Emulatoren sind dadurch in der Lage, zeitliche Abhängigkeiten der einzelnen Systemkomponenten einzuhalten. Gerade Computerspiele, welche die Hardware oft bis an die Grenzen ausreizen, sind auf das exakte Zusammenspiel angewiesen. Anzumerken ist, dass das für eine exakte Funktionsweise ebenfalls alle Prozessoren in den Subsystemen des Emulators zyklengenau emuliert werden müssen. Tijms attestiert, dass für die „akkurate“ Emulation eines Systems oft mindestens ein Emulator mit Zyklengenauigkeit benötigt wird.^[136]vgl. Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 2.

Die Entwicklung eines solchen Emulators ist im Gegenzug jedoch deutlich komplexer und erfordert detaillierte Kenntnisse der inneren Systemabläufe. Zudem ist die Ausführungsgeschwindigkeit durch die Nachbildung jedes einzelnen Taktes dementsprechend langsamer.

3.6.4 Datenbus- und Pin-Genauigkeit

Die größte Präzision der Emulation kann mittels Datenbus- bzw. Pin-Genauigkeit erreicht werden. Zusätzlich zur Zyklengenauigkeit werden die physischen Strukturen des Prozessors und angeschlossener Komponenten nachgebildet. Dies schließt den Weg der Daten über alle Systembusse (insbesondere den zentralen Datenbus und den Adressbus) mit ein. Sie bildet damit die höchste Stufe der Genauigkeit, da im Prinzip eine virtuelle Kopie des Chips erzeugt wird, bei der die Logik-Gatter und damit die Schaltlogik des Chips auf Transistorebene nachgeahmt werden. Zur Implementierung ist mindestens der komplette Schaltplan des Chips erforderlich.

Einen Schritt weiter gehen James und Silverman mit dem Projekt „Visual 6502“, in dem sie eine echtzeitbasierte interaktive Simulation und Visualisierung aller Schaltkreise des 6502 vornehmen.^[137]vgl. James, G.; Silverman, Barry; Silverman, Brian: Visualizing a Classic CPU in Action: The 6502. In: ACM SIGGRAPH 2010 Talks (SIGGRAPH ’10). ACM, New York, NY, U.S.A., Article 26. Die Logiksimulation wird dazu mittels hochauflösender Fotos mithilfe eines Mikroskops direkt aus der Chipstruktur extrahiert. Die Autoren fotografierten jede Schicht mit über 20000 Komponenten und extrahierten die Logikschaltung automatisiert mittels Bilderkennungsverfahren. Dabei wurden acht Fehler in den Aufnahmen entdeckt, die jedoch frühzeitig beseitigt werden konnten.^[138]ebenda. Die extrahierte Logik bildet das Herzstück des in Python implementierten Emulators. Zur Visualisierung existiert eine Brücke nach JavaScript. Dadurch ist der Emulator über einen Webbrowser aufrufbar und bietet die Möglichkeit eingegebene Programme Schritt für Schritt nachzuvollziehen.^[139]Visual6502-Projekt: Visual Transistor-level Simulation of the 6502 CPU and other chips!, Website. Abbildung 3.3 zeigt den Emulator bzw. den Zustand des Prozessors nach Ausführung des Mini-Rechenbeispiels aus Abschnitt 3.6.2. So sind deutlich die benötigten Zyklen, der Speicherinhalt, die Inhalte aller Register, des Daten- und Systembusses sowie die jeweils stromführenden Transistoren (rot eingefärbt) in jedem Schritt zu erkennen. Das Projekt hat sich zum Ziel gesetzt, mit dieser Methodik weitere Chips der 8-bit-Heimcomputergeneration simulieren zu wollen.

Die Autoren weisen ausdrücklich darauf hin, dass selbst diese Genauigkeitsstufe einer Abstraktion unterliegt. Nicht emuliert werden das analoge Verhalten der Widerstände, die Kapazität und Ableitung von Kondensatoren sowie das zeitliche Schaltverhalten der Transistoren.^[140]vgl. ebenda. Davon abgesehen liefert das Modell eine akkurate Nachbildung der Funktionsweise des Chips und ist für das Studium zur Implementierung weiterer Emulatoren für frühe Mikroprozessoren interessant – besonders im Falle fehlender oder abweichender Spezifikationen gegenüber der tatsächlichen Hardware.

Tijms hält Datenbusgenauigkeit jedoch für zu komplex. Dieser Genauigkeitsgrad kommt normalerweise nur für die Simulation von eingebetteten Systemen oder zum Design und zur Erprobung neuer Hardwarekomponenten zum Einsatz, bei dem konkrete zeitliche Eigenschaften der Hardware von Bedeutung sind.^[141]vgl. Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 2 sowie Wang, D.; Ganesh, B.; Tuaycharoen, N.; Baynes, … Continue reading

Die Ausführungsgeschwindigkeit des Visual6502-Emulators beträgt auf einem aktuellen x86-System lediglich 27 Hz.^[142]vgl. Visual6502-Projekt: Visual Transistor-level Simulation of the 6502 CPU and other chips!, Website. Der 6502-gesteuerte Rechner Apple I wurde 1976 dagegen bereits mit 1 MHz betrieben. Die Ausführungsgeschwindigkeit des Emulator (ohne den Visualisierungsanteil) beträgt also nur 0,0027 Prozent der des Apple I (rund 37000-fach langsamer). Auch scheint es wenig realistisch, von aktuellen Systemen Schaltpläne und dergleichen zu erhalten, da diese zumeist durch Patente geschützt sind und vom Hersteller nicht verbreitet werden. Für die Nutzung innerhalb des Langzeitbewahrungskontextes scheint dieser Genauigkeitsgrad daher (ökonomisch) ungeeignet.

Dennoch können diese Art von Emulatoren wichtige Hinweise für die Langzeitbewahrung von dynamischen Objekten geben, da sie die Eigenarten der Hardware nachahmen. So besitzt beispielsweise die 6502-CPU einen Fehler in den Schaltkreisen, der unter gewissen Umständen dazu führen kann, dass der Prozessor einen eigentlich nicht maskierbaren (unterdrückbaren) Interrupt übersieht. Der Visual6502-Emulator repliziert diesen Hardwarefehler exakt, da er die Schaltkreise nachbildet.

Solche Fehler haben dabei durchaus praktische Implikationen. Die Spielkonsole Sega Mega Drive (Sega Genesis im nordamerikanischen Raum) enthielt in den ersten beiden Hardwarevisionen ebenfalls einen Bug. Der Befehl TAS (Test And Set) des integrierten Motorola 68000-Prozessors, welcher in der Schreibphase den Datenbus reserviert, wurde nicht korrekt von Sega implementiert, wodurch zwar der Bus reserviert werden konnte, aber der Speicher nicht beschrieben wurde. Die Videospiele Gargoyles und Ex-Mutants nutzten dieses Fehlverhalten in ihren Programmen aus. Dementsprechend erwarten sie, dass der Befehl nicht in den Speicher schreibt. Sega hat diesen Fehler jedoch in der dritten Revision der Konsole (Genesis 3) behoben, wodurch diese Spiele inkompatibel mit der dritten Generation sind.^[143]Sega Wiki: Artikel Sega Mega Drive. Website. [abgerufen 15.10.2012]

Für Emulatoren ergeben sich hier neue praktische Fragestellungen. Welche konkrete Revision oder Konfiguration eines Systems soll emuliert werden? Sind Hardwarefehler Teil des Systems? Für eine exakte Emulation müssten auch alle Hardwarefehler eines Systems emuliert werden, da sie Teil des Designs sind und Software eventuell ihr Vorhandensein erwartet. Denn so wie Software- gehören auch Hardwarefehler zur Technikgeschichte. Ein Überblick findet sich in [Coy 2009].^[144]Coy, W.: Unsichtbar wird der Fehler, wenn sich alle daran gewöhnt haben. In: Kassung, C. (Hrsg.): Die Unordnung der Dinge. Eine Wissens- und Mediengeschichte des Unfalls. Bielefeld: … Continue reading Auch können solche Fehler in der Regel nur repliziert bzw. bei der Programmierung des Emulators berücksichtigt werden, wenn sie in der verfügbaren Dokumentation der Komponenten des Originalsystems (hinreichend) beschrieben sind.

3.6.5 Abwägungen bei der Auswahl des Abstraktionsgrads

Die Auswahl der Abstraktionsebene und des -grades bei der Implementierung eines Emulators ist eine zentrale Designentscheidung. Auf der technischen Ebene stehen die Anforderungen der Originalsoftware an das System und die Ausführungsgeschwindigkeit des Emulators im Vordergrund. Auch können Gegebenheiten des Originalsystems, wie das Vorhandensein spezieller Schaltkreise, Prozessoren sowie Besonderheiten der Architektur, existieren, denen durch einen höheren Detailgrad Rechnung getragen werden muss. Demgegenüber steht die Ausführungsgeschwindigkeit insbesondere im Verhältnis von Rechenleistung der Host-CPU gegenüber der Original-CPU. Letztlich kann auch die Komplexität der Software ein limitierender Faktor sein.

Für Tijms steht die Genauigkeit in Zusammenhang mit der Rechenleistung: “Naturally a higher accuracy makes for a more compatible emulation but it also requires a lot more processing power”.^[145]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 3. Bei der Datenbus-Genauigkeit kann die notwendige Rechenleistung mehrere 1000-fache der Originalleistung betragen, um die gleiche Ausführungsgeschwindigkeit zu erhalten. Er nennt Spielkonsolen und Arcade-Systeme geschlossene Umgebungen, für die in der Regel sehr optimiert entwickelt wurde und die daher in der Regel zur Ausführung von Software im Emulator strikte zeitliche Anforderungen (Zyklengenauigkeit) einzuhalten sind.^[146]vgl. ebenda. Interessanterweise besteht jedoch keine lineare Korrelation zwischen den beiden Geschwindigkeiten. Laut Tijms benötigt ein Emulator für das mit 3 MHz getaktete SNES (Super Nintendo Entertainment System, eine 16-bit-Spielkonsole) mindestens einen Pentium mit 550 MHz, um die Geschwindigkeit des Originalsystems zu erreichen. Ein Emulator mit 10 MHz deutlich schneller getaktete NeoGeo (ein Arcade-Videospielsystem) lediglich einen Pentium mit 350 MHz zur korrekten Ausführung. Tijms sieht dies in den vielen Spezialchips des SNES verortet, die einzeln – und durch komplexe Wechselwirkungen untereinander mit einem hohen Detailgrad – emuliert werden müssen.^[147]vgl. ebenda.

In [Schaffer 2004] führt der Autor eine Evaluation der Performanz von existierenden Emulatoren durch und vergleicht dabei die einzelnen Komponenten des Emulators sowie verschiedene Genauigkeitsgrade (interpretative Techniken der Binärübersetzung vs. dynamischer Rekompilierung) von Emulatoren. Das Ziel dieser Evaluation lag darin festzustellen, welche Faktoren den größten Einfluss auf die Ausführungsgeschwindigkeit haben und eventuelle Engpässe zu identifizieren, um bessere Emulatoren entwickeln zu können. Schaffer identifiziert das CPU-Modul als dasjenige, mit dem größten Einfluss auf die Gesamtgeschwindigkeit des Emulators.^[148]vgl. Shaffer, J.: A Performance Evaluation of Operating System Emulators. Bachelorarbeit, Bucknell University, Lewisburg, PA, U.S.A., 2004, S. 4. Zwar sind Systeme mit dynamischer Rekompilierung bis zu 100 Mal schneller,^[149]vgl. ebenda, S. 16. jedoch zu ungenau, um die meisten zeitgebundenen dynamischen Objekte wie Spiele auszuführen. Ein Full-System-Emulator mit interpretativen Techniken bleibt daher die einzige Lösung. Schaffer nennt Optimierungstechniken, die Instruktions- oder Zyklen-genaue Ausführung bleibt aber inhärent aufwendig und bietet daher kein großes Optimierungspotenzial.^[150]vgl. ebenda.

Neben diesen technischen Beweggründen stehen im Alltag aber wahrscheinlich eher pragmatische und ökonomische Entscheidungen im Vordergrund. Fehlen Spezifikationen und oder technische Dokumente des zu emulierenden Systems (z.B. aufgrund der rechtlichen Situation), so ist es ohne Kenntnis der Systeminterna nicht möglich, einen hohen Detailgrad zu implementieren. Auch stellt sich die Frage des Aufwands der Implementierung im Zusammenhang mit zeitlichen, finanziellen und personellen Ressourcen bzw. Beschränkungen.

Es scheint daher vonnöten – abseits der theoretischen Betrachtung – zu eruieren, welches Paradigma und welche Genauigkeitsstufe real existierende Emulatoren benutzen, die im Zusammenhang mit Langzeitbewahrung dynamischer Objekte in Erwägung gezogen werden. Im Folgenden soll daher eine vergleichende Untersuchung stattfinden.

3.7 Untersuchung von Emulatoren nach Abstraktionsgrad

Zur besseren Übersicht ist es sinnvoll, die zu untersuchenden Emulatoren in eine für Computerspiele relevante Einteilung von Generationen zu gruppieren. In [von Suchodoletz 2009, S. 80]^[151]von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, S. 80. identifiziert der Autor Rechnerplattformen bzw. -architekturen und fasst diese in die Klassen „frühe Großrechner“, „x86-Industriestandard“ sowie weitere Spieleplattformen zusammen. Diese werden in „Arcade“, „Konsolen“, „tragbare Konsolen“ und „Homecomputer“ unterteilt. Huth verwendet mit „Arcade-Spiele“, „Computerspiele“, „Videospiele“ und „tragbare Videospiele/Handyspiele“ vier ähnliche Hardwarekategorien.^[152]Huth, K.: Probleme und Lösungsansätze zur Archivierung von Computerprogrammen – am Beispiel der Software des ATARI VCS 2600 und des C64. Diplomarbeit, HU Berlin, 2004, S. 29f.

Eine Einteilung anhand gemeinsamer Hardwaremerkmale erscheint für die folgenden Betrachtungen sinnvoll. Es werden daher zusammengefasst folgende Kategorien verwendet: frühe Großrechner, Arcade-Systeme, Heimcomputer, PCs/Mac/x86, Spielkonsolen sowie mobile Geräte.

3.7.1 Untersuchte Emulatoren

Um im Kontext der Langzeitbewahrung behandelte bzw. benutzte Vertreter zu identifizieren, wurde eine Literaturrecherche durchgeführt. Dabei wurden alle in der Forschungsliteratur genannten Emulatoren – unabhängig von eventuell diskutierten Auswahlkriterien und Verwendung in Forschungsprojekten – einbezogen.^[153]In der Literatur aufgestellte Auswahlgründe für Emulatoren werden in Abschnitt 4.3.1 genauer behandelt. Bei Nennung mehrerer Vertreter des gleichen Systems innerhalb einer Quelle wurde der vom Autor / von der Autorin bevorzugte Emulator aufgenommen. Eine erste Recherche ergab folgende Nennungen:

• [Coy 2006, S. 59]^[154]Coy, W.: Perspektiven der Langzeitarchivierung multimedialer Objekte. [= Kompetenznetzwerk Langzeitarchivierung (Hrsg.): nestor-materialien, Nummer 5], 2006, S. 59.: Virtual PC
• [Guttenbrunner u. a. 2010, S. 80]^[155]Guttenbrunner, M.; et al.: Keeping the Game Alive: Evaluating Strategies for the Preservation of Console Video Games. In: Internatio­nal Journal of Digital Curation, Volume 1, Issue 5, 2010, S. … Continue reading: ZSNES, SNES9x, MESS, Gens32, KegaFusion, Dega, NeoCD, Nebula, O2EM, PCSX2 (Spielkonsolen)
• [Holdsworth und Wheatley 2001, S. 3]^[156]Holdsworth, D.; Wheatley, P.: Emulation, Pre­servation and Abstraction. CAMiLEON Project.In: RLG DigiNews, Volume 5, Issue 4, 2001, S. 3.: Virtual PC, SoftWindows^[157]Das Produkt wird seit 2001 endgültig nicht mehr angeboten. Es sind derzeit keine Informationen zum Programm verfügbar, weshalb es nicht in die Liste der Emulatoren aufgenommen wurde. (PC/ Mac)
• [Huth 2004, S. 111, 117]^[158]Huth, K.: Probleme und Lösungsansätze zur Archivierung von Computerprogrammen – am Beispiel der Software des ATARI VCS 2600 und des C64. Diplomarbeit, HU Berlin, 2004, S. 111, 117.: Stella (Spielkonsolen); VICE (Heimcomputer)
• [McDonough u. a. 2010]^[159]McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010.: M.E.S.S. (Heimcomputer); Virtual PC, VirtualBox, QEMU (PC/Mac)
• [Rothenberg 2000b, S. 75 f.]^[160]Rothenberg, J.: An Experiment in Using Emulation to Preserve Digital Publications. Den Haag: Koninklijke Bibliotheek (NEDLIB Report Series), 2000, S. 75f.: Virtual PC, SoftWindows^[161]SoftWindows wurde von Rothenberg aufgrund von Einstellung des Verkaufs durch den Hersteller nicht verwendet. (PC/Mac)
• [Supnik 2008]^[162]Supnik, R. M.: Writing a Simulator for the SIMH System. Revised 22-Sep-2008 for SIMH V3.8-1. Version vom 22. September 2008.: SIMH (Großrechner)
• [van der Hoeven u.a. 2007, S. 124, 129]^[163]van der Hoeven, J.; et al.: Emulation for digital preservation in practice: The results. In: The International Journal of Digital Curation, Volume 2, Number 2, 2007, S. 124, 129.: Virtual PC, QEMU, VMware, Dioscuri (PC/Mac)
• [van der Hoeven und van Wijngaarden 2005, S. 6]^[164]van der Hoeven, J.; van Wijngaarden, H.: Modular emulation as a long-term preservation strategy for digital objects. In: Proceedings of the 5th International Web Archiving Workshop (IWAW05), im … Continue reading: zusätzlich M.A.M.E. (Arcade); SIMH (Großrechner); PearPC (PC/Mac)
• [von Suchodoletz 2009, Kapitel 4.3]^[165]von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, Kapitel 4.3.: Bochs, Dioscuri, DOSBOX, DOSEMU, FAUmachine, JPC, Parallels Workstation, Plex86, QEMU, Virtual PC, VirtualBox, VMWare, PearPC, Mini vMac, Basilisk II (PC/ Mac); ARAnyM (Atari ST/TT/Falcon), Arnold (CPC), Hatari/WinSTon (Atari ST), JaC64, MESS, UAE (Heimcomputer); PCSX, SNES9x, vNES (Spielkonsolen); M.A.M.E. (Arcade); GNUBOY (mobile Geräte); Hercules, SIMH (Großrechner)
• [Welte 2009, S. 123]^[166]Welte, R.: Funktionale Langzeitarchivierung digitaler Objekte: Entwicklung eines Demonstrators zur Internetnutzung emulierter Ablaufumgebungen. Dissertation, Freiburg: Albert-Ludwigs-Universität … Continue reading: QEMU (PC/Mac)

Nicht bei allen genannten Emulatoren handelt es sich um Full-System-Emu-latoren. Mehrfachnennungen wurden entfernt. Auffallend ist das Fehlen neuerer Generationen von Spielkonsolen, wie beispielsweise Nintendo 64 und GameCube, Microsoft Xbox, Sega Saturn und Dreamcast, sowie die Unterrepräsentation der mobilen Geräte mit nur einem Eintrag für den Nintendo Game Boy. Um ein breiteres Bild zu erhalten, wurden daher der Liste populäre Emulatoren für die aufgeführten Konsolen (1964, Dolphin, nullDC, Yabause, cxbx) sowie ein Emulator für das mobile Nintendo DS (DeSmuME) hinzugefügt. Bei den Emulatoren M.E.S.S. und M.A.M.E. handelt es sich um Verbundemulatoren, die Emulatoren für verschiedene Systeme unter einer gemeinsamen Architektur und Oberfläche zusammenfassen.

Aufgrund der Vielzahl existierender Systeme erhebt die Liste keinen Anspruch auf Vollständigkeit, sondern soll vielmehr Trends und Implementierungen für konkret im Forschungskontext behandelte Emulatoren aufzeigen.

Die Emulatoren wurden in Kategorien und nach Originalsystem gruppiert in eine Tabelle eingetragen. Anschließend wurden die verwendete Programmiersprache sowie zentrale Eigenschaften wie Beschreibungsebene und Genauigkeitsgrad des CPU-Moduls und Zielplattform(en) ermittelt. Bei der Ermittlung des Genauigkeitsgrades wurde zunächst (falls vorhanden) die Angabe des Herstellers bzw. des Autors/der Autorin verwendet. Wurde keine Angabe gemacht (was überwiegenden der Fall war) oder bestanden Zweifel wurde der Genauigkeitsgrad durch Analyse des Quelltextes (Source-Code-Analyse) ermittelt. Dies war jedoch nur bei quelloffenen Emulatoren möglich. Das Ergebnis ist in Tabelle 1 erfasst.

3.7.2 Datenauswertung

Tabelle 1: Auflistung untersuchter Emulatoren mit Genauigkeitsgrad

Name (Vertreter)	Architektur	Originalsystem	Hostsystem	Sprache	Beschreibungsebene Abstraktionsgrad
SIMH	frühe Großrechner	diverse Mainframes	Windows, MacOS X, Linux, Unix	C	Full-System Zyklengenauigkeit
Hercules	frühe Großrechner	IBM S/360, S/370 ESA/390 z/Architecture	Windows, MacOS X, Linux, Solaris, FreeBSD	C	Full-System Instruktionsgenauigkeit
M.A.M.E.	Arcade-Systeme	>10000 Arcade-ROMs	Windows, MacOS X, Linux, Unix	C++	Full-System Instruktionsgenauigkeit* Zyklengenauigkeit* (*je nach Emulator)
ARAnyM	Heimcomputer	Atari ST/TT/Falcon	Windows, MacOS X, Linux	C++, C	Virtuelle Maschine dyn. Rekompilierung
Arnold	Heimcomputer	Amstrad CPC/CPC+	Windows, Linux, Unix	C	Full-System Zyklengenauigkeit
Hatari/ WinSTon	Heimcomputer	Atari ST	Windows, MacOS X, Linux, BeOS	C	Full-System Zyklengenauigkeit dyn. Rekompilierung
JaC64	Heimcomputer	Commodore C64	Windows, MacOS X, Linux, Unix	Java	Full-System Zyklengenauigkeit
VICE	Heimcomputer	Commodore C64	Windows, MacOS X, Linux, Unix, BeOS, Amiga	C	Full-System Zyklengenauigkeit
M.E.S.S.	Heimcomputer	multiple >250 Systeme	Windows, MacOS X, Linux, Unix	C	Full-System Instruktionsgenauigkeit* Zyklengenauigkeit* (*je nach Emulator)
UAE	Heimcomputer	Commodore Amiga	Windows, Linux, Unix	C	Full-System Zyklengenauigkeit dyn. Rekompilierung
DOSBox	PC / Mac / x86	PC-Dos (x86)	Windows, MacOS X, Linux, Unix, (OS/2, Solaris, BeOS)	C, C++	Full-System Instruktionsgenauigkeit dyn. Rekompilierung
Dioscuri	PC / Mac / x86	PC: x86 (≤ Windows 3.0)	Windows, MacOS X, Linux, Unix	Java	Full-System Instruktionsgenauigkeit
JPC	PC / Mac / x86	PC: x86	Windows, MacOS X, Linux, Unix	Java	Full-System Instruktionsgenauigkeit dyn. Rekompilierung
Parallels Workstation	PC / Mac / x86	PC: x86	Windows, Linux	k. A.	Virtuelle Maschine n. A.
Plex86	PC / Mac / x86	PC: x86	Linux	C	Virtuelle Maschine n. A.
QEMU	PC / Mac / x86	PC: x86, PowerPC, ARM, SPARC	Linux, Unix, MacOS X	C	VM / Full-System dyn. Rekompilierung
VirtualPC	PC / Mac / x86	PC: x86	MacOS X (PowerPC)	k. A.	Full-System k. A.
VirtualBox	PC / Mac / x86	PC: x86	Windows, MacOS X, Linux, Solaris	C	Virtuelle Maschine dyn. Rekompilierung
VMWare	PC / Mac / x86	PC: x86	Windows, Linux, MacOS X	k. A.	Virtuelle Maschine n. A.
PearPC	PC / Mac / x86	PC: PowerPC	Windows, Linux, FreeBSD	C++, C, Assemb- ler	Full-System dyn. Rekompilierung
Mini vMac	PC / Mac / x86	Mac: Classic Macs	Windows, MacOS X, Linux, DOS, OS/2	C	Full-System Instruktionsgenauigkeit
Basilisk II	PC / Mac / x86	Mac: 68000	Windows, MacOS X, Linux, BeOS	C++	Full-System Instruktionsgenauigkeit dyn. Rekompilierung
PCSX	Spielekonsolen	Sony PlayStation	Windows, MacOS X, Linux	C	Full-System Instruktionsgenauigkeit dyn. Rekompilierung
SNES9x	Spielekonsolen	Super Nintendo Entertainment System	Windows, MacOS X, Linux, PlayStation 3, GameCube, PSP, iOS, Android	C++, Assemb- ler	Full-System Instruktionsgenauigkeit
vNES	Spielekonsolen	Nintendo Enter- tainment System	Windows, MacOS X, Linux, Unix	Java	Full-System Zyklengenauigkeit
ZSNES	Spielekonsolen	Super Nintendo Entertainment System	MS-DOS, Windows, Linux, MacOS X (x86)	x86 Assemb- ler, C	Full-System Instruktionsgenauigkeit
Gens32	Spielekonsolen	Sega Genesis	Windows	x86 Assemb- ler, C, C++	Full-System Instruktionsgenauigkeit
Kega Fusion	Spielekonsolen	Sega Genesis Sega Master System	Windows, MacOS X	k. A.	Full-System k. A.
NeoCD	Spielekonsolen	SNK NeoGeo	Windows, Linux, BeOS	C	Full-System Zyklengenauigkeit
Nebula	Spielekonsolen	SNK NeoGeo	Windows	k. A.	Full-System k. A.
O2EM	Spielekonsolen	Magnavox Odyssey2	Windows	C	Full-System Zyklengenauigkeit
Dega	Spielekonsolen	Sega Master System	Windows	k. A.	Full-System k. A.
PCSX2	Spielekonsolen	Sony PlayStation 2	Windows, MacOS X, Linux	C++	Full-System Instruktionsgenauigkeit
Stella	Spielekonsolen	Atari 2600	Windows, MacOS X, Linux	C++	Full-System Zyklengenauigkeit
1964	Spielekonsolen	Nintendo 64	Windows	C	Full-System Instruktionsgenauigkeit
Dolphin	Spielekonsolen	Nintendo GameCube Nintendo Wii	Windows, MacOS X, Linux	C++	Full-System dyn. Rekompilierung
nullDC	Spielekonsolen	Sega Dreamcast	Windows, PlayStation 3	C++	Full-System dyn. Rekompilierung
Yabause	Spielekonsolen	Sega Saturn	Windows, MacOS X, Linux	C	Full-System Zyklengenauigkeit
cxbx	Spielekonsolen	Microsoft Xbox	Windows	C++	Full-System dyn. Rekompilierung
GNUBoy	Mobile Geräte	Nintendo Game Boy	Windows, Linux	C	Full-System Zyklengenauigkeit
DeSmuME	Mobile Geräte	Nintendo DS	Windows, MacOS X, Linux	C++	Full-System dyn. Rekompilierung

Tabelle 1: Auflistung untersuchter Emulatoren mit Genauigkeitsgrad

Insgesamt wurden 41 Emulatoren untersucht. Davon sind sechs allerdings keine Full-System-Emulatoren, sondern virtuelle Maschinen (siehe Abschnitt 3.4.2). QEMU verfügt über einen Dualmodus und lässt sich sowohl als virtuelle Maschine, als auch als Full-System-Emulator betreiben. Die Tabelle beinhaltet daher 36 Full-System-Emulatoren.

Von diesen 36 kann bei vier keine Aussage zum Detailgrad der Emulation gemacht werden, da der Quellcode nicht zur Verfügung steht und der Hersteller keine Angaben diesbezüglich gemacht hat.

Kein untersuchter Emulator implementiert Datenbus-Genauigkeit. Der Detailgrad der restlichen untersuchten Emulatoren teilt sich fast gleichmäßig auf Zyklengenauigkeit (14 Emulatoren), Instruktionsgenauigkeit (14 Emulatoren) sowie dynamische Rekompilierung (12 Emulatoren) auf, wobei sich bei einigen Emulatoren zwischen verschiedenen Detailgrad-Implementierungen umschalten lässt. Hatari, UAE, DOSBox, JPC, Basilisk II sowie PCSX bieten neben der interpretativen Ausführung (Instruktions- bzw. Zyklengenauigkeit) zusätzlich die Emulation mittels dynamischer Rekompilierung an. Bei M.A.M.E. und M.E.S.S. schwankt der Detailgrad je nach Implementierung des jeweiligen Modul-Emulators und kann nicht allgemeingültig angegeben werden. Durch Einsatz von dynamischer Rekompilierung bei zwölf Emulatoren sind diese (sofern sie nicht umschalten lassen) prinzipbedingt an eine bestimmte Prozessorarchitektur gebunden. Sie können nur auf Host-CPUs ausgeführt werden, für die der enthaltene Compiler Instruktionen generieren kann. Eine Portierung auf künftige Rechnerarchitekturen würde eine Re-Implementierung des Zielcompilers und damit des Emulators erfordern.

Die in der Liste enthaltenen Emulatoren sind – bis auf eine Ausnahme – allesamt für die Ausführung auf Hostsystemen mit x86-Architektur (moderne Personal Computer) konzipiert, wobei verschiedene Betriebssysteme in unterschiedlichem Umfang unterstützt werden. Nur vereinzelt existieren vom Hersteller bzw. Entwickler direkte Portierungen auf andere Architekturen wie beispielsweise mobile Geräte mit ARM-Architektur und Apple iOS oder Google Android als Betriebssystem. Dies macht PCs mit x86-Architektur zur de-facto Hostplattform alle untersuchten Emulatoren.

Die in der Stichprobe gewählten Emulatoren sind größtenteils (22 von 36 Emulatoren) komplett bzw. anteilig in der Programmiersprache C verfasst. Bei 13 Emulatoren wurde das objektorientierte C++ verwendet. Bei sechs Emulatoren findet sich keine Angabe zur Programmiersprache. Lediglich vier Emulatoren (11 %) verwenden die Plattform-unabhängige Sprache Java. Weitere vier beinhalten Teile von Assemblercode und binden sich damit fest an eine bestimmte Rechnerarchitektur. Ohne eine Re-Implementierung des Assemblerteils können diese Emulatoren nicht auf künftigen Rechnerarchitekturen verwendet werden.

3.8 Diskussion

Es konnte gezeigt werden, dass die Art der Implementierung und der zugrunde liegende Abstraktionsgrad der einzelnen Emulatormodule einen direkten Einfluss auf das Gesamtverhalten und das Verhältnis von Emulationsgeschwindigkeit und erzielbarer Genauigkeit des emulierten Systems gegenüber dem Originalsystem hat. Die Ergebnisse zeigen deutlich (systembedingte) Abweichungen der Emulatoren auf, wenn keine Datenbusgenauigkeit verwendet wurde.

Keiner der im Rahmen der Langzeitbewahrung von dynamischen Objekten und insbesondere von Computerspielen in der Literatur diskutierten Emulatoren jedoch implementiert diese Datenbus- bzw. Pin-Genauigkeit. Dies ist insofern bemerkenswert, da nur bei diesem Detailgrad die korrekte Abbildung der maschineninternen Abläufe theoretisch garantiert werden kann. Zumindest für die derzeit in der Literatur zum behandelten Emulatoren muss daher konstatiert werden, dass diese allein aufgrund ihrer technischen Beschaffenheit nicht in der Lage sind, jedwede theoretisch mögliche Software des Originalsystems abspielen zu können.

Darüber hinaus sind nur weniger als die Hälfte (39%) der untersuchten Emulatoren zyklengenau und erfüllen damit das von Tijms^[167]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000. geforderte Mindestmaß. Interessanterweise spricht sich Rothenberg aus pragmatischen Gründen für Emulatoren mit Instruktionsgenauigkeit aus. Für ihn reicht es aus, wenn ein Emulator die „äußeren“, logische Zustände (welche die Schnittstelle zum Programmierer bilden) des Systems nachahmt. Die Komplexität innerer Zustände (z.B. von Pipelines, Caches, Timing-Verhalten) muss für ihn nicht nachgebaut werden, da diese internen Zustände auf der logischen Zustandsebene transparent agieren.^[168]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 27. Dies hätte den Vorteil, dass die Komplexität der von Rothenberg propagierten abstrakten Emulatorspezifikation und Hardwarebeschreibung deutlich gesenkt werde würde (siehe Abschnitt 3.2.1). Programme, die auf die korrekte Nachbildung der inneren Zustände und des Zeitverhaltens des Systems angewiesen sind, sind seiner Meinung nicht sauber programmiert, fehlerhaft und können verworfen werden.^[169]vgl. ebenda, S. 27.

Rothenberg übersieht bei seinen Ausführungen jedoch vollkommen die Vielzahl der Programme für eingebettete und mobile Systeme, sowie den Konsolen- und Arcade-Videospielmarkt. Wie gezeigt, nutzen insbesondere Computer- und Videospiele häufig zur Leistungsoptimierung und zur Erzeugung spezieller Spieleffekte alle technischen Möglichkeiten eines Rechnersystems aus. Die Ausreizung der Grenzen und hardwarenahe Programmierung ist für Konsolensysteme mit begrenztem Leistungsspektrum eine übliche Vorgehensweise der Programmierung und keineswegs als Fehler anzusehen. Bei Verwendung von instruktionsgenauen Emulatoren könnte diese Klasse von Objekten aber nicht oder nur unvollständig erhalten werden.

Die Festlegung auf einen bestimmten Emulator und Emulatortyp bedeutet also gleichzeitig die implizite Festlegung der Klasse an zu erhaltenen Objekten. Dabei zeigt sich die technische Realität unabhängig von sekundären Merkmalen wie Popularität, Einfluss oder kultureller Bedeutung eines bestimmten Softwaretitels.

Die Wahl des Emulators ist vielmehr praktischen Gegebenheiten geschuldet, wobei ökonomische Abwägungen im Vordergrund zu stehen scheinen (siehe Abschnitt 4.3.1). Die untersuchten Emulatoren wurden ergebnisorientiert programmiert, wobei Unterschiede in der technischen Genauigkeit offenbar in Kauf genommen werden. Das Thema scheint durch die Auswahlkriterien auf technischer Ebene nicht in der notwendigen Tiefe berücksichtigt zu werden.

Die Tatsache, dass existierende Emulatoren prinzipbedingt und aufgrund von getroffenen technischen Entscheidungen nicht jedes dynamische Objekt korrekt wiedergeben können, unterscheidet sich jedoch deutlich von der propagierten Lehrmeinung des Emulationsansatzes bei der von einer essenziell exakten Reproduktion durch Emulatoren ausgegangen wird.^[170]vgl. u. a. Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003, Kapitel 4.

Als bisherige Schranken der Emulationsstrategie konnten die Zeitbasis, der Abstraktionsgrad von Prozessormodulen (CPU und Subsystemen) identifiziert werden. Diese werden im Verhältnis von Aufwand und Nutzen in den folgenden Kapiteln kritisch diskutiert. Die fehlende Genauigkeit bzw. Verluste durch die gewählte technische Abstraktionsebene schlägt dabei auf die konzeptuelle Ebene des Objekts durch und kann dramatische Auswirkungen auf Rezeption oder Spielbarkeit des Artefakts haben. Die Genauigkeit des CPU-Moduls kann dabei nicht als alleiniges Maß herangezogen werden. Seiteneffekte entstehen ebenfalls durch die gewählte Abstraktionsebene der weiteren I/O-Subsysteme sowie durch das Zusammenwirken und Zeitverhalten der einzelnen Komponenten. Die Durchschlagskraft auf die konzeptuelle Ebene kann an Realweltbeispielen beobachtet werden.^[171]Siehe unter anderem die Ausführungen in Supnik, R. M.: Simulators: virtual machines of the past (and future). In: ACM Queue, Volume 2, Number 5, Issue July/August 2004, S. 53–58 zur … Continue reading Zur Veranschaulichung soll ein Beispiel aus dem Bereich der Computerspiele dienen. In [bsnes 2011]^[172]byuu: bsnes :: Why Accuracy Matters. Artikel vom 28.2.2011. In: BSNES Homepage, 2011. [abgerufen 6.10.2012] listet der Autor der Software bsnes, einem Programm zur Emulation der Spielkonsole Super Nintendo Entertainment System (SNES), Beispiele für Abweichungen auf konzeptueller Ebene von SNES-Spielen bei der Ausführung in verschiedenen Emulatoren auf. Verglichen wird dazu bsnes, welches mit Zyklengenauigkeit sowohl für das CPU-Modul als auch für Submodule der Custom-Hardwarechips vom Autor implementiert wurde, mit dem (in der Liste der untersuchten Emulatoren vertretenen) Programm ZSNES. ZSNES arbeitet dabei nur mit Instruktionsgenauigkeit (siehe Tabelle 1). In Tests wurden dazu populäre Spiele des SNES-Systems auf beiden Emulatoren ausgeführt und Unterschiede festgehalten.

Durch die fehlende Implementierung von Mid-Scanline-Rastereffekten in ZSNES treten beispielsweise Verluste von Bilddetails durch Timing-Ungenauigkeiten auf. So erscheint der Schatten des vom Spieler gesteuerten Flugzeugs im Spiel Air Strike Patrol nur unter bsnes. Wie in Abbildung 3.4 zur sehen fehlt dieser jedoch bei der Ausführung unter ZSNES. Der Schatten des Flugzeugs erfüllt im Spiel allerdings die Funktion einer Zielsteuerung für den Bombenabwurf. Anhand des Flugzeugschattens kann der Spieler erahnen, wo abgeworfene Bomben auftreffen werden und dementsprechend den Feuerknopf des Joysticks betätigen. Sowohl die Interaktion als auch das Spielerlebnis sind damit durch die Art der technischen Implementierung verändert. Eine detaillierte Diskussion weiterer Beispiele findet sich in [bsnes 2011].^[173]ebenda.

Es ist daher wichtig, quantitative und qualitative Aussagen über die Leistungsfähigkeit und Abweichungen von Emulatoren machen und technische sowie pragmatische Grenzen klar benennen zu können. Auch sollte im Hinblick auf die Auswahlkriterien von Emulatoren das Umfeld der Entstehung von Emulatoren und weitere Schranken genauer betrachtet werden. Ferner sind die besonderen Anforderungen, die das Werk bzw. Medium des Computerspiels an die Bewahrungsebenen von dynamischen Objekten stellen zu berücksichtigen. Das folgende Kapitel soll das Phänomen der Abweichungen, die systembedingt oder aufgrund von pragmatischen oder ökonomischen Kompromissen getroffenen Entscheidungen entstehen, sowie weitere durch Emulation entstehende Schranken genau aufschlüsseln und eruieren. Die Funde werden anschließend systematisch und kritisch diskutiert.

→ 4. Translation Gap: Verluste durch Emulation