Wie im letzten Kapitel gezeigt, können – entgegen der bisherigen Ergebnisse in der einschlägigen Literatur – bei der Emulation von multimedialen Objekten bereits durch technische Implementierungsstrategien systembedingte Abweichungen vom Originalobjekt und gegebenenfalls sogar Informationsverluste auftreten. Ob und in welchem Umfang diese Abweichungen zum Tragen kommen, hängt von der ausgeführten Software ab und ist nicht von vornherein absehbar. Es sind intensive Vergleichstests mit dem Originalsystem notwendig, um mögliche Probleme aufzudecken.^[2]Die erfolgreiche Durchführung eines Kompatibilitätstests ist jedoch kein Beweis für die Abwesenheit von Reproduktionsfehlern. Dabei können die entstehenden Abweichungen unter Umständen vernachlässigt werden. Hier ist eine Abwägung zwischen Kosten und Nutzen vonnöten. Dazu ist es jedoch notwendig, diese zu klassifizieren. In jedem Fall aber sollten sie dem Betrachter kommuniziert werden.

Nach der ersten Recherche (siehe Abschnitt 3.7.1) werden bei Langzeitbewahrungsprojekten fast ausschließlich bereits existierende Emulatoren bevorzugt bzw. verwendet. Es hat sich dabei gezeigt, dass sowohl Designentscheidungen als auch die Auswahl von Emulatoren größtenteils aus pragmatischen (Realisierbarkeit bestimmter Detailgrade vs. Aufwand) und ökonomischen (zur Verfügung stehende Ressourcen) Gesichtspunkten getroffen werden. In diesem Kapitel werden daher mögliche Abweichungen sowie Entstehungsfaktoren qualifiziert benannt und untersucht.

Eine systematische Aufstellung und Kategorisierung soll es ermöglichen, den ökonomischen Aufwand zu beziffern, Beschränkungen des jeweiligen Bewahrungsprojektes zu identifizieren und (technische) Anforderungen an Emulatoren der Zukunft zu stellen. In diesem Zusammenhang stellt sich die Frage nach der angestrebten Authentizität einer Emulationslösung und wie sich diese klassifizieren lässt. Rothenberg versucht dies in Experimenten mit der Koninklijke Bibliotheek der Niederlande durch die Aufstellung von fünf allgemeinen Anforderungsgraden gegenüber dem Originalobjekt: “same for all intents and purposes”, “same functionality and relationships to other publications”, “same ‘look-and-feel’”, “same content (for any definition of the term)” sowie “same description”.^[3]Rothenberg, J.: An Experiment in Using Emulation to Preserve Digital Publications. Den Haag: Koninklijke Bibliotheek (NEDLIB Report Series), 2000, S. 72.

„Same for all intents and purposes“ stellt den höchsten Anforderungsgrad dar und bedingt eine faktische Gleichheit mit dem Originalobjekt. Rothenberg sieht hier die Herausforderung in der Entwicklung von “[…] specification techniques that can describe all relevant attributes of hardware computing platforms in sufficient detail to allow them to be emulated on future platforms”.^[4]ebenda, S. 83. Vergleicht man dies mit den Anforderungen an die korrekte Reproduktion und Aufführung von Computerspielen (auch im Hinblick auf ihre Dualität als Kunstobjekt und kommerzielle Ware), ist nur dieser höchste Anforderungsgrad geeignet, das Wesen komplexer dynamischer Objekte wie Computerspiele zu erhalten. Die anderen Grade reichen für die vollständige Erhaltung von Computerspielen nicht aus. Bewahrungsziele, Faktoren und Abweichungen müssen daher immer gegenüber diesem Höchstmaß an Authentizität gemessen bzw. beschrieben werden. Andersherum kann man der Authentizität eines Objekts anhand der entstehenden Lücke zwischen angestrebtem und tatsächlich realisiertem bzw. realisierbaren Detailgrad beschreiben.

Hierzu wird der Begriff der Translation Gap eingeführt, der als Maß für die Authentizität der Reproduktion eines dynamischen Objektes den Grad bzw. die Anzahl der Abweichungen beschreibt. Mithilfe der so entstehenden Skala sollen im Folgenden Abweichungen quantifiziert und entscheidende Faktoren erfasst werden.

4.1 Definition Translation Gap

In der Sprachwissenschaft wird mit dem Begriff Translation Gap die semantische Lücke bei der Übersetzung von Texten einer natürlichen Sprache in eine andere bezeichnet. Diese entsteht beispielsweise durch Spracheigentümlichkeiten oder Redewendungen für die es keine (exakte) Entsprechung in der Zielsprache gibt. Vielmehr müssen zur Übersetzung sinngleiche, semantisch ähnliche Konzepte in der Zielsprache gefunden sowie in den jeweiligen kulturellen Kontext des Rezipientenkreises eingebettet werden. Bei historischen Texten ist zudem die Anpassung von nicht mehr gebräuchlichen Idiomen notwendig.

In Anlehnung an dieses Konzept werden in diesem Werk mit Translation Gap alle Abweichungen bezeichnet, die bei der Rezeption eines komplexen digitalen Artefakts innerhalb einer Emulationsumgebung sowie bei der Interaktion mit der Emulationsumgebung gegenüber der Rezeption und Interaktion mit der Originalumgebung des Artefakts bestehen. Dabei ist zwischen Abweichungen auf physischer, logischer und konzeptueller Ebene des Objektes (siehe Abschnitt 2.2) zu unterscheiden und eine prinzipielle Unterteilung der Entstehungsfaktoren vorzunehmen.

Komponenten und Ebenen

In Kapitel 3 wurde auf die technische Dimension des Emulationskonzeptes fokussiert. Es konnten bisher Abweichungen auf der konzeptuellen Objektebene aufgrund technischer Ungenauigkeiten des gewählten Abstraktionsgrads des Emulators auf der nachgeahmten physischen Ebene identifiziert werden. Dieser technische Faktor hatte Einfluss auf die Interaktionserfahrung, wobei die Auswirkungen auf inhaltlicher Ebene jedoch nicht allgemein abschätzbar waren. So können eine Vielzahl Artefakte – von kaum merkbaren visuellen Abweichungen oder Unterschieden in der Ablaufgeschwindigkeit – bis hin zum vollständigen Verlust der Reproduzierbarkeit einer Klasse von Objekten auftreten. Der Abweichungsgrad kann für diese Fälle jedoch immer nur mittels Vergleichstests für das konkrete Objekt bestimmt werden. Es wurde zudem gezeigt, dass neben technischen auch pragmatische bzw. ökonomische Abwägungen Einfluss auf die Implementierung hatten.

Von Interesse ist zudem, dass ein Emulator in der Literatur entweder als bereits gegeben oder als von externen Dienstleistern zu entwickeln angesehen wird. Hierbei kommt es zu einer impliziten Kompetenzverschiebung der Entscheidungsgewalt über die Objekterhaltung von Gedächtnisorganisationen hin zu technischen Dienstleistern bzw. Softwareentwicklern. Die an der Entwicklung von Emulatoren beteiligten Personenkreise scheinen also eine weitere wichtige Komponente in der Entstehung und Beurteilung von Abweichungen zu sein. Es ist zu klären, welche Gruppen unter welchen Bedingungen Emulatoren entwickeln, um Gründe für getroffene Designentscheidungen und deren Auswirkungen nachvollziehen zu können.

Um weitere Komponenten und Entstehungsfaktoren für Abweichungen zu finden, müssen die grundlegenden Merkmale des Untersuchungsgegenstands Computerspiele bzw. komplexe dynamische Objekte betrachtet werden. Erste Anhaltspunkte können sich aus dem Wesen des Mediums Computerspiel selbst, dessen Benutzungsarten und dessen dualen Charakters als Kunstobjekt und kommerziellen Massenprodukt ergeben. Für interaktive Objekte (insbesondere Spiele) scheint es notwendig, den Geltungsbereich der Rezeptionsumgebung – bestehend aus Software-, Hardware- und Interaktionskomponenten – zu erfassen und ihre intrinsischen Eigenschaften zu berücksichtigen.

Die höchsten Anforderungskriterien sind dabei im Bereich der digitalen elektronischen Kunst zu finden. Howard Besser beschreibt in [Besser 2001a] Problemfelder der Langzeitbewahrung elektronischer Kunst, die aufgrund der speziellen Eigenschaften des Kunstobjekts entstehen. Neben den auch für konventionelle digitale Objekte geltenden Problemen der rapiden Obsoleszenz von Dateiformaten sowie der Datenträgeralterung (vom Autor viewing problem genannt^[5]vgl. Besser, H.: Digital Preservation of Moving Image Material. In: The Moving Image – Journal of the Association of Moving Image Archivists, Volume 1, Issue 1, 2001, S. 264., identifiziert Besser zudem ein inter-relational problem und ein translation problem. Das inter-relational problem beschreibt die Verbindungen zwischen digitalen Objekten z.B. bei rekontextualisierender Webkunst. In Seiten eingebettete Inhalte wie Video oder Hyperlinks können mit der Zeit ungültig werden, Server abgeschaltet oder Inhalte verändert oder gelöscht werden. Dies verändert die Gesamtkomposition und Interaktion mit dem Objekt.^[6]vgl. ebenda, S. 265.

Das translation problem beschreibt Veränderungen in der Bedeutung (meaning) bzw. im Sinngehalt des Kunstwerks durch Migration der Ein- und Ausgabeschnittstellen der Rezeptionsumgebung in eine andere Form. So wurde unter anderem eine Vielzahl früher elektronischer Kunst auf CRT-Röhrenmonitoren oder Fernsehern gezeigt. Würden diese bei einem Defekt durch aktuelle Flachbildschirme (LCD, TFT, o.Ä.) vorgeführt, so würde das Werk dadurch verändert, da Flachbildschirme andere Ausgabecharakteristika (Farbe, Helligkeit, Bildwiederholfrequenz, Auflösung usw.) als Röhrenbildschirme besitzen.^[7]vgl. ebenda, S. 266. Traditionell ist jedoch die Ausstellung eines elektronischen Kunstwerks mit dem Medium eng verbunden, auf dem es der Künstler erstellt hat. Eine Veränderung wird daher häufig als eine Verschlechterung der Reproduktion angesehen. So verbot u.a. Gary Hill – einer der Pioniere der Videokunst – explizit der Tate Gallery of Modern Art, bei seinen Werken CRTs durch LCDs zu ersetzen.^[8]vgl. ebenda.

Die Migration von Schnittstellen und Änderungen der Rezeptionsumgebung stellen eine weitere Komponente für Abweichungen auf der konzeptuellen Ebene des Objektes dar. Besser nennt Jaron Lanier als weiteres Beispiel. Dieser sah die Emulation eines seiner Spiele, welche auf neuerer Hardware schneller ablief, nicht mehr als sein Originalspiel an.^[9]vgl. ebenda, S. 267f. sowie Abschnitt 3.5.1. Für Besser ist es daher essenziell, formale Aspekte des Werkes und seiner Umgebung (Aspekt-Ratio, Geschwindigkeit, Formate, etc.) in Zusammenarbeit mit dem Künstler festzuhalten.

Zuletzt muss auch der Charakter des Emulators und dessen Einbettung in die Emulation als Bewahrungsstrategie berücksichtigt werden. Zum einen ist der Emulator selbst ein komplexes dynamisches Objekt, das für künftige Rechnergenerationen bewahrt werden muss. Dieser rekursive Bewahrungsprozess muss auf mögliche Abweichungen bei der Reproduktion sowie prinzipbedingte Grenzen untersucht werden. Auch ist zu beachten, dass bei der Emulationsstrategie der erste Bewahrungsschritt der Transfer der digitalen Objektes vom Originalmedium und die Umwandlung in ein für den Emulator geeignetes logisches Format (Datenträgerabbilder, sogenannte Images) durchzuführen ist. Da Computerspiele durch technische Maßnahmen wie DRM oder Kopierschütze gesichert sein können, kann es bei diesem Prozess zu Abweichungen auf technischer Ebene kommen.

Zusammengefasst konnten die Interaktion mit der Emulationsumgebung, die Migration von Ein- und Ausgabeschnittstellen (siehe Abschnitt 4.2), das personelle Entstehungsumfeld des Emulators, betroffene Entwicklergruppen und deren Agenda (siehe Abschnitt 4.3) sowie im Kontext der Bewahrungsstrategie der Datenträgertransfer und die Erstellung, Bewahrung und der Charakter des Emulators selbst (siehe Abschnitte 4.4 und 5.3) als Entstehungsfaktoren für Abweichungen identifiziert werden.

Diese sollen im Folgenden untersucht, klassifiziert und die Ergebnisse anschließend systematisiert aufgestellt werden. Abweichungen können dabei Auswirkungen auf den Objektebenen physisch, logisch, konzeptuell und das Zusammenspiel aus Software, Hardware und Umgebung haben. Die Gründe können prinzipbedingt oder technischer, pragmatischer und ökonomischer Natur sein. Abschließend sind Auswirkungen und Gründe nach ihrem Grad von vernachlässigbar, semantischer Abweichung, Änderung der Interaktion, Verlust der Interaktion bis hin zum Verlust der Reproduzierbarkeit des Objektes zu beurteilen. Bei der Frage nach der Authentizität muss zwischen dem was prinzipiell, sinnvoll, und was teilweise erhalten werden kann unterschieden werden.

4.2 Translationsprobleme der Schnittstellenmigration

Das von Besser angesprochene Problem der Schnittstellenmigration beinhaltet zwei Aspekte. Einerseits besteht dasselbe Problem der Wahl des Authentizitäts- bzw. Abstraktionsgrads zur Modellierung der Schnittstelle des Emulators wie schon beim CPU-Modul demonstriert (siehe Abschnitt 3.6). Andererseits entsteht ein Translationsproblem beim Übergang der Daten von einer bzw. in eine sinnlich wahrnehmbare Form mithilfe der Ein- und Ausgabehardware. Da die Interaktion mit dem dynamischen Objekt nur über die analogen Eigenschaften der Schnittstellen stattfindet, verändert jede Änderung dieser Eigenschaften die Art, wie das Objekt rezipiert wird. Bei der Emulation obsoleter Hardwaresysteme müssen Schnittstellen jedoch zwangsweise durch kontemporäre Versionen (wie am Beispiel des Übergangs vom Röhren- zum Flachbildschirm) oder durch auf dem Hostsystem vorhandene Alternativen (z.B. PC-Tastatur anstelle eines Spielkonsolen-Joysticks) ersetzt werden.

Abstraktionsgrad der Schnittstellenemulation

Der erste Aspekt umfasst dabei die Anbindung der Schnittstellen an das Rechnersystem durch Hardwarecontroller. Am Beispiel der Grafikausgabe wären dies die Chips der Grafikkarte, nicht jedoch der Monitor bzw. die Darstellung auf Selbigem. Hier muss – wie in Abschnitt 3.5.3 beschrieben – bei der Implementierung des entsprechenden I/O-Subsystems der entsprechende Abstraktionsgrad festgelegt werden. Ist die Schnittstelle komplex, d. h. stellt sie selbst eine von-Neumann-Architektur mit Prozessor, Speicher, etc. dar (z. B. bei Grafikkartenprozessoren, Netzwerkkarten, System-on-a-Chip), dann muss zur vollständigen Repräsentation ein eigener Emulatorkern entwickelt werden, wodurch sich die Komplexität des Gesamtsystems deutlich erhöht. Zudem stellen Hardwarecontroller dem System eine eigene Abstraktionsebene zur Verfügung, da sie die interne Schnittstellenlogik, Eigenarten der spezifischen Hardware sowie deren Komplexität vom Computersystem verbergen und den Zugriff auf die Hardwarekomponente transparent über eine genormte Schnittstelle zur Verfügung stellen. So stellen beispielsweise die Festplatteninterfaces (S)ATA oder SCSI eine solche Abstraktionsebene dar, während die dahinter liegenden physischen und physikalische Gegebenheiten der Festplatte, wie extra Bereiche für defekte Sektoren, Anpassung der Drehgeschwindigkeit durch wärmebedingte Ausdehnung der Magnetscheibe oder interne Fehlerkorrekturmechanismen, verborgen werden.^[10]Anderson, D.: You Don’t Know Jack about Disks. In: ACM Queue, Volume 1, Issue 4, 2003, S. 20–30. Nicht immer sind diese Informationen durch den Hersteller offengelegt. Es muss also wieder eine Auswahl nach pragmatischen Gesichtspunkten zwischen Implementierbarkeit, vorhandener Dokumentation und benötigter Systemgeschwindigkeit getroffen werden.

Dieser Aspekt findet ausführliche Betrachtung in [Phillips 2010].^[11]Phillips, G.: Simplicity betrayed. In: Communications of the ACM, Volume 53, Issue 6, 2010, S. 52–58. Der Autor beschreibt darin das Verhältnis zwischen Genauigkeit der Implementierung von I/O-Subsystemen und deren Abbildung auf der Hardware des Hostsystems am Beispiel des Heimcomputers TRS-80. Im Text werden erste Hinweise zum Implementierungsaufwand einer möglichst originalgetreuen Nachbildung anhand eines selbst entwickelten Emulators gegeben. Phillips zieht dazu die Analogie zur Arbeit mit einer Programmierschnittstelle (API) aus der Softwareentwicklung. Ein Emulator kann zwar die Vorgänge einer CPU emulieren, simuliert aber lediglich die Ein-/Ausgabe-Hardwarekomponenten und reicht die Anfragen an diese übersetzt an das Hostsystem weiter. Der Emulator stellt dadurch Programmierschnittstellen in Form von simulierten Hardwareschnittstellen zur Verfügung, welche mit den Programmierschnittstellen der Hardware des Hostsystems in Deckung gebracht werden müssen.^[12]vgl. ebenda, S. 52.

Das TRS-80-System verfügt über einen Textmodus mit 16 Zeilen und 64 Spalten. Die Ausgabe erfolgt auf einem Fernsehbildschirm. Neben dem ASCII-Zeichensatz bietet das System zudem einen Satz aus grafischen Sonderzeichen an, mit denen jede mögliche aus 2 × 3 Pixeln bestehende binäre Blockkombination darstellbar ist. Insgesamt ergibt sich somit eine Auflösung von 128 Pixeln horizontal und 48 Pixeln vertikal. Der Bildschirmspeicher wird dabei in den Hauptspeicher des Systems abgebildet, auf den Programme des Rechners direkt zugreifen können. Jedes Byte entspricht einem auf dem Bildschirm dargestellten Zeichen.^[13]vgl. ebenda. Phillips entwickelt zunächst ein auf der Spezifikation des Systems basierendes einfaches API-Modell zur Erfassung der Grafikausgabe. Ein Update des Bildschirminhalts erfolgt alle 1/60 Sekunden.^[14]Dies entspricht der Bildwiederholfrequenz von 60 Hz amerikanischer TV-Geräte mit NTSC-Norm. Der Emulator muss dazu den Bildschirmspeicher auslesen, das entsprechende Bild auf den Zeichen des Originalsystems rendern und auf dem Bildschirm des Hostsystems darstellen^[15]vgl. ebenda, S. 53.. Dieses Verfahren funktioniert laut Phillips für die Mehrheit der untersuchten Programme. Die Ausgabe auf dem Emulator ist hinreichend ähnlich zu der auf der Hardware des Originalsystems. Der Autor bemerkte jedoch eine Abweichung bei einem seiner Testprogramme. Soll der Bildschirminhalt von komplett schwarz nach komplett weiß gefüllt werden, so dauern die entsprechenden Schreibzugriffe auf den Bildschirmspeicher länger als 1/60 Sekunden. Deshalb entsteht kurzzeitig ein Zwischenbild, auf dem der Bildschirm nur zur Hälfte gefüllt ist.

Beim nächsten 1/60 Intervall ist der Bildschirm dann komplett weiß gefüllt. Jedoch unterscheidet sich die Darstellung dieses Zwischenbildes im Emulator von der auf dem Originalsystem. Der Übergang zwischen schwarzen und weißen Pixeln ist im Emulator rechteckig, beim Originalsystem jedoch ein Dreieck.^[16]vgl. ebenda, S. 54. Ein Vergleich der Darstellung des Zwischenbildes im Emulator und auf dem Originalsystem ist in Abbildung 4.1 zu sehen.

Obwohl der Emulator vermeintlich nach kompletter und korrekter Spezifikation^[18]anders als beispielsweise bei der fehlenden Implementierung von Mid-Scanline-Rastereffekten in Abschnitt 3.8. programmiert wurde, gab es eine Abweichung. Der Spezifikation lag eine fehlerhafte Abstraktion zugrunde, sie war dadurch nicht ausreichend genug. Das Updateintervall unterlag der Annahme, dass ein Zeichen entweder im Speicher steht oder nicht, also eine atomare Größe darstellt, und ein Update des Bildschirms instantan alle 1/60 Sekunden erfolgt. Das Originalsystem stellt den Bildschirminhalt allerdings nicht Zeichen- sondern Zeilenweise da. Das Zeichen kann sich dementsprechend während des Bildschirmaufbaus ändern. Der Bildaufbau auf der Originalhardware ist an die Ausgabehardware geknüpft und erfolgt kontinuierlich, dem Elektronenstrahl des Fernsehgerätes folgend, alle 86,8 Mikrosekunden pro Zeile (bei 192 Zeilen). Während bei den ersten Zeilen des Schwarz/weiß-Übergangs noch das alte „schwarze“ Zeichen im Speicher steht, wechselt dieses durch den abgeschlossenen Schreibzugriff auf den Bildschirmspeicher für die weiteren Zeilen. Die charakteristische Dreiecksform entsteht.^[19]vgl. ebenda, S. 54.

Sowohl der Fetch-Execute-Zyklus, als auch das I/O-Subsystem für die Grafikausgabe mussten unter erheblichem Aufwand entsprechend angepasst werden. Phillips bemerkt, dass “[a] rather small test case required a considerable change in the program”^[20]ebenda, S. 55. Phillips entwickelte daraufhin weitere Testszenarien, um Abweichungen insbesondere bei der Pixeldarstellung zu finden. Die entwickelten Testprogramme verhielten sich allerdings auf dem Originalsystem nicht so wie erwartet. Die Zeitverhältnisse entsprachen nicht den errechneten. Der Fehler konnte durch den Autor nur durch Zuhilfenahme des Hardwareschaltplans des Originalsystems gefunden werden. Eine Recherche ergab, dass aufgrund der CPU-Clock nicht wie erwartet 60 Bilder pro Sekunde, sondern nur 59.185 Bilder gezeichnet werden – mit drastischen Auswirkungen bei der Darstellung komplexer Animationen^[21]vgl. ebenda. Der Emulator musste erneut angepasst und die API der simulierten Grafikhardware präzisiert werden.

Phillips führte weitere Iterationen mit spezifischen Testszenarien durch und stellte bei jeder weitere gravierende Abweichungen zwischen der Spezifikation des Emulators und dem Originalsystem fest. Beispielsweise verursachte eine Zeitverschiebung des Synchronisationsinterrupts um nur einen CPU-Zyklus einen Verlust der Bildschirmsynchronisation.^[22]vgl. ebenda, S. 57. Auch verursachte die Sperrung des Grafikspeichers durch die CPU bei Zugriffen über die CPU unter bestimmten Bedingungen zu „Löchern“ in der Darstellung auf dem Originalsystem.^[23]vgl. ebenda, S. 58.

Die Tests und Erweiterung bzw. Re-Implementierung des Grafik-Subsystems stellten sich – trotz der auf den ersten Blick Grafikfähigkeiten des TRS-80 – als extrem aufwendig heraus. Für Phillips sind sie zur originalgetreuen Darstellung von dynamischen Objekten jedoch unerlässlich, da selbst kleinste Abweichungen der Spezifikation die Interaktion mit dem Objekt deutlich verändern: “The result is not tiny differences only of interest to experts but extremely visible differences in program behavior between precise and sloppy emulators”.^[24]ebenda.

Auch zeigt sich, dass Tests dieser Komplexität nur manuell durch einen Menschen durchgeführt werden können bzw. sogar zwingend müssen. Dies widerlegt Rothenbergs frühe Vermutung, das Emulatoren mittels automatisierter Softwaretests auf Kompatibilität zum Originalsystem geprüft werden können. Dem liegt die Annahme zugrunde, dass allein das erfolgreiche Durchlaufen (Starten) der Originalsoftware unter dem Emulator eine Kompatibilität zum Originalsystem begründet.^[25]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 22 [abgerufen 24.04.2008] Im Lichte von Phillips Experimenten muss diese Annahme jedoch deutlich relativiert und automatisierte Tests als nicht ausreichend angesehen werden.

Migration der Ein- und Ausgabehardware

Der zweite Aspekt der Abbildung der simulierten Hardware auf die vorhandenen Hardwarekomponenten des Hostsystems scheint sich hingegen einer Softwarelösung gänzlich zu entziehen. Der Emulator emuliert das obsolete Originalsystem und transformiert dabei die Ein- und Ausgabeschnittstellen des Originalsystems auf die (ebenfalls abstrahierten) Schnittstellen des Hostsystems. Die jeweiligen I/O-Submodule führen also eine „Just-In-Time-Migration“ der Schnittstellen aus. Wie bei jeder Migration (siehe Abschnitt 2.4.3) können hier Abweichungen und Verluste durch Inkompatibilitäten bzw. fehlende Funktionalität auftreten, je nachdem, wie stark sich die Hardware des Original- und Hostsystems voneinander unterscheiden und welche Möglichkeiten sie bietet. Auf die physischen Eigenschaften der Ein-/Ausgabehardware hat der Emulator jedoch prinzipbedingt keinen Einfluss.

Tijms fasst dieses Dilemma unter dem Begriff outside environment (Außenumgebung bzw. Rezeptionsumgebung) zusammen: “One point even a complete system emulator does not address is the characteristics of the environment outside of the digital system”^[26]Tijms, A.: Binary translation: Classification of emulators. Leiden Institute for Advanced Computer Science, Universität Leiden, 2000, S. 8. Für Tijms sind dies in erster Linie die audiovisuellen Signale, die der Nutzer wahrnimmt. Die intrinsischen – und für die Interaktion mit dem Objekt zu beachtenden – Eigenschaften der Rezeptionsumgebung bzw. Hardware sind dabei schwer zu definieren. Tijms nennt sowohl die spezifischen Eigenschaften von Röhrenmonitoren wie die Auflösung, Bewegungsunschärfe oder das Nachleuchten der Phosphore als auch die unterschiedliche Klangerzeugung durch verschiedene Audio-Synthesizer in Soundkarten als Beispiele, die auch bei einem Emulator mit Datenbus-Genauigkeit (siehe Abschnitt 3.6.4) außerhalb des Abbildungsraums liegen. Insbesondere bei Computerspielen der 80er- und 90er-Jahre wurden jedoch oft insbesondere diese Eigenschaften von Röhrenbildschirmen und Audiochips ausgenutzt, um bestimmte Spielobjekte und -artefakte zu erzeugen. Der Transfer auf einen Monitor mit deutlich höherer Auflösung führt zu einer starken „Verpixelung“ der Grafik des Originalsystems, sodass Artefakte verzerrt erscheinen und unter Umständen bestimmte Spielobjekte gar nicht mehr zu identifizieren sind.^[27]vgl. ebenda. Das Ziel des Emulators, ein Höchstmaß an Authentizität zu erreichen, wird durch diesen Umstand ebenfalls verfehlt. “In this particular case the emulator would be useless […]”^[28]ebenda. ist das vernichtende Fazit von Tijms, falls die Design-Maxime der authentischen Nachbildung der audiovisuellen Signale des Systems (und damit des Spielerlebnisses) nicht erreicht werden kann.

Phillips hat diesen Aspekt ebenfalls in die Betrachtung der Abweichungen seines TRS-80-Emulators gegenüber dem Originalsystem einfließen lassen. Zentral für seine Untersuchung waren die Eigenschaften des Fernsehbildschirms. Pixel auf Röhrenbildschirmen bestehen aus weichen Ovalen, bedingt durch die Phosphore auf der Frontscheibe und sehen damit gänzlich anders aus, als die eckigen Pixel moderner LCD-Flachbildschirme. Die Pixel eines Fernsehschirms sind zudem nicht distinkt, sondern überlappen in ihrer Ausleuchtung ein wenig. Darüber hinaus sind sie auch nicht unabhängig voneinander, sondern erscheinen unterschiedlich, je nach Anzahl der in einer Reihe aufleuchtenden Pixel. Der erste Pixel einer Zeile erstrahlt bedingt durch die Charakteristik des Elektronenstrahls heller.^[29]Phillips, G.: Simplicity betrayed. In: Communications of the ACM, Volume 53, Issue 6, 2010, S. 57.

Alle diese subtilen Unterschiede summieren sich zu einem deutlich abweichenden Bild mit sichtbaren visuellen Artefakten, welche von einigen grafischen Programmen des Systems ausgenutzt wurden. Zwar hat ein Emulator keinen Einfluss auf die physischen Eigenschaften des Hostsystems, dennoch schlägt Phillips für sein Beispiel eine Teillösung vor. Der Emulator kann sich den o.g. Eigenschaften des TV-Bildschirms durch komplexe Grafikberechnungen annähern und somit das Verhalten und Aussehen der Pixel nachahmen. Dies erfordert jedoch noch einmal deutlich mehr Rechenzeit, um das über 30 Jahre alte System nachzubilden. Der Autor warnt, dass selbst die Rechenleistung aktueller Systeme nicht ausreichend sein kann, alle Facetten älterer Computersysteme in einem ausreichenden Detailgrad nachzubilden.[]vgl. ebenda.[/ref]

Systematische Aufstellung der Rezeptionsumgebung

Es ist notwendig, sich dieser Problematik systematisch zu nähern, um das Spannungsfeld zwischen Schnittstellenabweichungen und nicht (sinnvoll) migrier- bzw. konvertierbarer Sensorik zu ergründen. Phillips vertritt die These, dass die Hardware eines Originalsystems nur vollständig im Zusammenhang anhand ihrer Verwendung durch das Korpus von existierender Software für das System beschrieben werden kann.^[30]vgl. ebenda, S. 52. Emulatoren für die Langzeitbewahrung sind von ihrem Bestimmungszweck rückwärtsgerichtet: Es soll eine abgeschlossene Menge existierender Software erhalten werden. Der Blick ist also nicht auf die Entwicklung und das Testen neu zu erstellende Software gerichtet. In diesem Kontext ist es sinnvoll, den Vorschlag von Phillips aufzugreifen und die für die authentische Nachbildung und Interaktion mit dem Objekt erforderlichen Eigenschaften eines Hardwaresystems sowie seiner Umgebung anhand der konkreten Anforderungen der zu erhaltenden Software zu betrachten.

Die enge Anbindung des digitalen Objektes an die analogen Komponenten bildet einen wichtigen Teil der Interaktion mit dem Objekt. Die zu bewahrende Rezeptionsumgebung umfasst daher alle Komponenten, die zur authentischen Interaktion mit dem dynamischen Objekt notwendig sind. Dazu können neben den Hardware-Systemkomponenten auch die Beschaffenheit des Systems selbst, dessen Standort, die Aufführungspraxis sowie alle weiteren analogen Objekte, die in die Interaktion einfließen, gehören.

Durch das in der Literatur diskutierte technische Schichtenmodell der Emulation (siehe Abschnitt 3.4.1 und Abb. 3.1) bleiben (durch die Beschränkung auf die „digitale Welt“) diese zentralen relevanten Merkmale jedoch vollständig unberücksichtigt. Das Modell muss entsprechend – insbesondere für den Bereich Spiele und Computerkunst – um eine „Schicht“ bestehend aus Rezeptionsumgebung und Aufführungspraxis ergänzt werden.

Besonders bei Computerspielen wurden die vielfältigen Möglichkeiten der Verknüpfung von analogen Artefakten mit dem digitalen Spielverlauf einerseits intensiv genutzt, um das immersive Erlebnis zu steigern (siehe Abschnitt 4.2), aber gleichzeitig auch, um Rechtsgüter vor unberechtigter Vervielfältigung zu schützen. Zu den bekanntesten Beispielen zählt die von Ralf Baer erfundene Spielkonsole Odyssey. Dieses 1972 von der Firma Magnavox verkaufte System gilt als erste kommerziell vertriebene Videospielkonsole und bot die Möglichkeit, vom Spielablauf sich unterscheidende Spiele wie Tennis, Skifahren, Hockey oder Autorennen auf dem TV-Bildschirm zu spielen.^[31]vgl. u.a. Loebel, J.-M.: Erhaltung virtueller Realitäten. Restauration eines Virtual-Reality-Simulators für das Computerspielemuseum Berlin – ein Projektbericht. In: Sieck, J. (Hrsg.): Kultur … Continue reading Die Hardware der Konsole selbst war jedoch nur in der Lage, einige wenige weiße Quadrate und Striche auf dem Bildschirm zu erzeugen. Die eigentliche Differenzierung des Spiels entstand durch transparente farbige Plastikfolien, die vom Nutzer als Auflage auf dem Bildschirm angebracht werden mussten (siehe Abbildung 4.2). Die Auflagen erzeugten den Spielkontext und stellten somit eine vitale Erweiterung der Ausgabeschnittstelle des Systems dar. Um die sinnvolle Interaktion mit dem System zu erhalten, muss ein Emulator diese Folien ebenfalls reproduzieren und dynamisch über die eigentliche Grafikausgabe des Systems projizieren bzw. in diese einbetten – obwohl die Folien nicht Teil der Hard- und Softwarespezifikation des Systems im eigentlichen Sinne sind.

Ein weiteres Beispiel ist das Krimi-Abenteuerspiel Murders in Venice der Firma CobraSoft aus dem Jahr 1989 für den Commodore Amiga Heimcomputer. Der Verpackung lagen Replika der im Spielgeschehen vorzufindenden Objekte bei, die vom Spieler untersucht werden mussten, um im Verlauf der Spielhandlung einen Mordfall aufzuklären. Die enthaltenen Artefakte (u.a. eine Schere, ein benutztes Taschentuch, ein Portemonnaie und eine Filmrolle) enthielten dabei Hinweise auf den Täter, die nur in der analogen Version, nicht aber in ihrem digitalen Pendant zu finden waren. Die physische Untersuchung durch den Spieler steigerte dabei die Immersion in das Spielgeschehen. Gleichzeitig wurde das Anfertigen von Kopien der Software verhindert, da das Spiel ohne die analogen Artefakte nicht bis zum Ende durchgespielt werden konnte.

Es handelt sich hierbei um eine ungewöhnliche Form eines Kopierschutzes durch die Verknüpfung mit physischen Objekten. Die zugrundeliegende Idee jedoch wurde insbesondere in den 1980er- und 1990er-Jahren von Spieleherstellern mittels sogenannter „Handbuchabfragen“ verfolgt. Oft musste zu Beginn des Spiels ein vom Spiel zufällig ausgewähltes Wort auf einer bestimmten Zeile und Seite des Handbuches durch den Nutzer eingegeben werden. Wurde diese Abfrage falsch beantwortet, startete das Spiel nicht. Das Computerspiel Wasteland lagerte sogar für den Spielverlauf wichtige Teile der Handlung in das Handbuch aus, sodass das Spiel ohne Selbiges nicht benutzbar war. Frühe Abenteuerspiele der Firma Lucasfilm Games (später Lucas Arts) wie u. a. The Secret of Monkey Island oder Indiana Jones and the Fate of Atlantis benutzten dem Spiel beigelegte Coderäder als Kopierschutzabfrage.^[33]Es handelte sich hierbei um gegeneinander verdrehbare Pappräder (ähnlich einer Parkscheibe) auf denen verschiedene Kombinationen von Codewörtern oder -symbolen angebracht waren. Der Nutzer wurde zu Beginn des Spiels aufgefordert, eine bestimmte Kombination auf seinem Coderad einzustellen und das abgelesene Ergebnis einzugeben. Die digitale Bewahrung der Software allein reicht in diesen ebenfalls Fällen nicht aus, die Interaktion mit dem Spiel zu erhalten.

Neben dieser direkten Verknüpfung spielen wie gezeigt die physischen Eigenschaften der Ein-/Ausgabehardware bei der Interaktion mit dem Spiel eine zentrale Rolle. Guttenbrunner et al. versuchen sich der Problematik systematisch durch eine gewichtete Ontologie essenzieller Hardware-Elemente von Konsolenspielen zu nähern. Die Autoren erstellen einen kategorisierten nach Ein- und Ausgabemedium sortierten Anforderungsbaum der Hardwarekomponenten. Die Autoren kommen zu dem Schluss, dass die Gewichtung ebenfalls nur anhand konkreter Hardware und Spiele erstellt werden.^[34]vgl. 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, … Continue reading kann. Durch die unüberschaubar große Anzahl verschiedener Systeme und Schnittstellen kann eine Betrachtung nicht abstrakt erfolgen. Eine abschließende Klassifizierung ist aufgrund der ständigen Weiterentwicklung von Hardware nicht möglich und auch nicht zielführend. Im Vordergrund muss vielmehr die Fallbetrachtung der konkreten Softwaresammlung stehen. Erste Hinweise für Langzeitbewahrungsprojekte können der TOTEM-Datenbank (siehe Abschnitt 3.2.3) entnommen werden.

Im Folgenden sollen daher exemplarisch gängige Hardwarekomponenten der in Abschnitt 3.7 aufgestellten Klassifizierung von historischen Computersystemen im Zusammenhang mit bestehenden Emulatoren (siehe Abschnitt 3.7.1) untersucht und – falls vorhanden – Beispiellösungsansätze, welche die Translation Gap minimieren, vorgestellt werden. Als übergeordnete Kategorien konnten bei den bisherigen Betrachtungen die Bildschirmausgabe (Übergang vom Röhren- zum Flachbildschirm), die Tonausgabe (Verwendung unterschiedlicher Audiosynthesizer), verschiedene Eingabegeräte (Interaktion mit dem Spiel), eventuelle Netzwerkkonnektivität und weitere Peripherie identifiziert werden. Die festgestellten Abweichungen werden anschließend auf ihre Auswirkungen auf die Interaktion mit der Rezeptionsumgebung und eine eventuelle veränderte Immersion des Spielers untersucht.

4.2.1 Bildschirmausgabe

Die visuelle Ausgabe des dynamischen Objekts auf einem Fernseher oder Bildschirm bildet den bilanzmäßig größten Anteil an der Rezeption des Objekts. Während die ersten Rechnersysteme aufgrund der begrenzten Speicherkapazität noch Vektorbildschirme (direkte Steuerung des Kathodenstrahls) benutzten, hat sich allgemein der Rasterbildschirm als dominante Technologie durchgesetzt. Bei Rasterbildschirmen wird der Bildschirminhalt in ein Punktraster unterteilt – die sogenannten Pixel. Für Heimcomputer und Spielkonsolen wird dabei traditionell der Fernseher als Ausgabegerät benutzt, da er in fast jedem Haushalt direkt zur Verfügung steht. Demgegenüber stehen Monitore mit deutlich höherer Auflösung, wie sie für PCs verwendet werden. Die Bildschirmtechnologie hat sich dabei in den letzten Jahren vom Röhrenschirm hin zu Flachbildgeräten (LCDs, Liquid Crystal Displays) weiterentwickelt.

Neben der Auflösung ist insbesondere für mobile Plattformen ein Trend zu höheren Pixeldichten zu beobachten. Bei PC-Monitoren liegt diese typischerweise bei 72 PPI (Pixels per Inch, engl. für Pixel pro Zoll). Bei Apple iPads mit „Retina“-Display beträgt diese hingegen 264 PPI.^[35]Siehe Produktspezifikation unter http://support.apple.com/kb/SP662. Auflösung, Pixeldichte, Seitenverhältnis und physische Bildschirmgröße bilden zentrale Merkmale der Bildschirmausgabe.

Darüber hinaus sind die spezifischen Eigenschaften von Fernsehgeräten, insbesondere älteren Geräte mit Kathodenstrahlröhre für Systeme von Belang, die den Fernseher als primäres Ausgabemedium nutzten. Wie im Bereich der Videokunst (siehe Abschnitt 4.1) besteht eine starke Verbundenheit zwischen Spielkonsole bzw. Heimcomputer und Fernsehbildschirm.^[36]vgl. detaillierte Fallstudien am Beispiel des Atari 2600 bei Montfort, N.; Bogost, I.: Racing the Beam: The Atari Video Computer System (Platform Studies). Cambridge: MIT Press, 2009.

In einem Vergleichstest der Systeme C64 und Atari 2600 von Huth zeigten sich deutliche Unterschiede zwischen der Darstellung auf dem Originalsystem und der im Emulator. Huth verwendete für das Hostsystem einen PC-Monitor mit 800 × 600 Pixel Auflösung. Als besonders problematisch erwiesen sich Unterschiede in der Farbdarstellung, dem Kontrast, der Helligkeit und Bildschärfe des Monitors im Gegensatz zum Fernseher.^[37]vgl. 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. Dem PC-Monitor fehlten die typischen Artefakte des Fernsehbildschirms, was zu einer „besseren“ Darstellung führte. Aus den Übertragungsstandards PAL und NTSC für Fernsehprogramme resultieren Einschränkungen für die Farbdarstellung und den Bildaufbau. Das verwendete 4:2:2-YUV-Farbmodell enthält beispielsweise nicht für jeden Pixel eine vollständige Farbinformation in jedem Kanal. Der Bildaufbau erfolgt durch zwei – jeweils zeilenversetzte – Halbbilder. In Verbindung mit den physischen Eigenschaften von Röhrenbildschirmen wie dem Nachleuchten der Phosphore bei Ansteuerung durch den Elektronenstrahl, entstehen in der Bildschirmdarstellung des rechnerisch erzeugten Bildes lassen Artefakte, welche teilweise von Programmieren des Originalsystems für graphische Effekte oder Spielmechaniken ausgenutzt wurden. Bei Rezeption auf LCD-Monitoren gehen diese Darstellungsartefakte verloren. Es kommt zu Abweichungen auf konzeptueller Ebene des Spiels.

Bogost fasst die Fernsehdarstellung zusammen.^[38]Bogost, I.: A TELEVISION SIMULATOR – CRT Emulation for the Atari VCS. In: Ian Bogost – Videogame Theory, Criticism, Design, Website, 2012. Er identifiziert dabei die spezifische Textur (texture) des Fernsehers mit Bewegungsunschärfe, Nachbilder auf der Netzhaut des Betrachters (afterimage), das Farbbluten (color bleed) sowie Bildrauschen (noise) und Bildaufbau aus Halbbildern (scan lines). Die Hintergrundtextur von Röhrenmonitoren ergibt sich aus dem Hintergrundleuchten, welches entsteht, wenn der Elektronenstrahl auf das Fokusgitter hinter den Phosphoren trifft. Nachbilder entstehen durch die Wechselwirkungen mit der Netzhaut im Auge des Menschen und dem Licht, das vom Bildschirm auf die Netzhaut auftrifft. Insbesondere diese Eigenschaft wurde benutzt, um Spieleffekte zu erzeugen: “Atari programmers took advantage of this feature to ‘flicker’ objects between frames”^[39]ebenda.. Das charakteristische „Farbbluten“ von Röhrenbildschirmen bzw. -fernsehern entsteht durch Helligkeitsüberstrahlungen zwischen benachbarten Pixeln, was einerseits zur Weichzeichnung harter Kanten (Übergang zwischen farbigen und schwarzen Pixeln) und andererseits zu Farbmischungen zwischen den Phosphoren benachbarter Pixel führte. Hinzu kommt ein Bildrauschen durch die Konvertierung und Übertragung und Modulierung des Ausgabesignals auf Fernsehnormen.^[40]vgl. ebenda.

Die Summe dieser Effekte erzeugen bei der Darstellung durch einen Emulator auf einem PC-Monitor die von Huth identifizierten deutlichen Abweichungen. Um diese Veränderungen in der Darstellung auszugleichen, entwickelte Bogost zusammen mit der Georgia Tech Computer Science Capstone Group zur Berechnung von Bewegungsunschärfe komplexe digitale Filterroutinen und Algorithmen. Diese Routinen wurden anschließend in den Open-Source-Emulator Stella (siehe Tabelle 1) eingebaut und der Quellcode zur freien Verfügung veröffentlicht. Vergleichstest mit dem Originalsystem zeigten nun eine nahezu identische Darstellung durch den Emulator.^[42]vgl. Bogost, I.: A TELEVISION SIMULATOR – CRT Emulation for the Atari VCS. In: Ian Bogost – Videogame Theory, Criticism, Design, Website, 2012. Im Gegenzug erhöhte sich jedoch der Rechenaufwand erheblich. Die Bilddarstellung mit und ohne die entwickelten Filterroutinen ist in Abbildung 4.3 exemplarisch anhand eines vergrößerten Bildausschnitts des Spiels Pac-Man verdeutlicht.

Eine Simulation der Artefakte durch einen Emulator ist also möglich. Es muss allerdings auch hier wegen der aufwendigen Berechnungen eine Abwägung zwischen Emulationsgenauigkeit und Ausführungsgeschwindigkeit durchgeführt werden. Weitere Berechnungen können notwendig sein, um unterschiedliche Pixelgrößen und -verhältnisse (quadratische vs. rechteckige Pixel) auszugleichen.^[43]Phillips, G.: Simplicity betrayed. In: Communications of the ACM, Volume 53, Issue 6, 2010, S. 52–58. Darüber hinaus kann es sinnvoll sein, Merkmale der Ausgabehardware im Zusammenhang mit der Rezeptionsumgebung zu erhalten. So ahmt beispielsweise der Cathode Terminal Emulator für MacOS X die Bildschirmwölbung, Verzerrungen und Spiegelungen eines Röhrenbildschirms nach.^[44]Siehe Website des Herstellers unter http://www.secretgeometry.com/apps/cathode/.

Darüber hinaus muss der Emulator die deutlich geringere Grafikauflösung älterer Systeme auf die Auflösung aktueller Systeme transformieren, damit die Grafikausgabe auf dem Hostsystem ebenfalls bildschirmfüllend erfolgen kann.^[45]Diese Problematik besteht bereits bei digitalen bzw. digitalisierten Filmaufnahmen. Eine Einführung bietet Besser, H.: Digital Preservation of Moving Image Material. In: The Moving Image – … Continue reading So beträgt die Auflösung des TRS-80 beispielsweise (siehe Abschnitt 4.1) mit 128 × 48 Pixeln nur 0,29 Prozent der Auflösung des aktuellen Apple iMacs (1920 × 1080 Pixel).

Zur Skalierung auf heutige Bildschirmauflösungen kommen verschiedene Filteralgorithmen zum Einsatz. Sie basieren auf der Fouriertransformation und konvertieren die Abtastrate des Bildes, welches anschließend über Rekonstruktionsfilter an die Zielauflösung angepasst wird. Bei der Interpolation von Rastergrafiken entstehen Qualitätsverluste, es kommt zu einer „Verpixelung“ des Bildes durch die Vergrößerung des Rasters. Um diese Effekte zu minimieren benutzen die Rekonstruktionsfilter bestimmte Techniken bei der Anpassung in das Zielraster, mit direktem Einfluss auf die optische Anmutung des Ergebnisses. Häufig verwendete Rekonstruktionsfilter sind die einfach Pixelwiederholung (nearest neighbour) sowie die bilineare und bikubische Interpolation. Bei der Erhöhung der Auflösung handelt es sich um eine gewollte Funktionsveränderung durch den Emulator (siehe Abschnitt 3.3). Die durch die Skalierung erzeugten Artefakte und somit veränderte optische Anmutung der Pixelgrafik werden in Kauf genommen, da die Darstellung in Originalauflösung zu einer erheblich kleineren Repräsentation des Objektes auf aktuellen Bildschirmen führen würde. Die Immersion in das Spielgeschehen würde durch die Verkleinerung der physischen Bildgröße erheblich beeinflusst. Eine Skalierung mittels Rekonstruktionsfiltern wird dementsprechend – wenn notwendig – von allen in Tabelle 1 gelisteten Emulatoren in unterschiedlichen Abstufungen unterstützt.^[46]Teilweise sind solche Rekonstruktionsfilter auch als optionale Bibliotheken für bestehende Emulatoren verfügbar z. B. beim „Emulator Enhancer“ von Richard Bannister (verfügbar unter … Continue reading

4.2.2 Tonausgabe

Charakteristisch für den polyphonen Klang von 8-bit-Heimcomputern war der MOS 6581 Soundchip SID (Sound Interface Device). Er wurde unter anderem im Commodore C64 verbaut, der als meist verkaufter Heimcomputer aller Zeiten gilt.^[47]Schätzungen gehen von ca. 30 Millionen verkaufter Geräte aus. Vgl. Bagnall, B.; Forster, W.; Kretzinger, B.: Volkscomputer. Utting: Gameplan-Verlag, 2011. Weitere Computer mit SID-Chip waren der Commodore CPM-II, C128 und VC-10. Der SID-Chip prägte somit das Klangerlebnis vieler Spiele dieser Zeit, trug wesentlich zum Erfolg des C64 bei und findet noch heute in einem Subgenre computergestützter Musikerzeugung – den sogenannten Chiptunes – breite Anwendung.^[48]vgl. Dittbrenner, N.: Soundchip-Musik: Computer- und Video­spiel­musik von 1977–1994.Osnabrück: Verlag Universität Osnabrück, 2007, S. 24–28. Klangbeispiele von Chiptunes aus [Dittbrenner … Continue reading Der Chip fungierte als Mini-Synthesizer und war in der Lage, drei unabhängige Stimmkanäle zu erzeugen. Eine systematische Untersuchung weiterer Soundchips von Heimcomputern und Konsolen von 1977 bis 1994 und ihrer technischen Merkmale findet sich in [Dittbrenner 2007].^[49]Dittbrenner, N.: Soundchip-Musik: Computer- und Video­spiel­musik von 1977–1994.Osnabrück: Verlag Universität Osnabrück, 2007. Eine Besonderheit des SID ist seine hybride Bauweise unter der Verwendung von kombinierbaren analogen Filtern (u.a. Tiefpass und Bandpass) während andere Elemente digital angesteuert wurden. Diese analogen Filter waren integraler Bestandteil der Musikerzeugung, lassen sich jedoch mittels Digitaltechnik heutiger volldigitaler Soundkarten nur mit erheblichem Rechenaufwand approximieren. Ein identischer Klang kann in der Regel nicht erreicht werden. Die Berechnungen könnten zudem zu Geschwindigkeitseinbußen des Emulators führen. Für Schallwellen darf jedoch die Echtzeitbedingung nicht verletzt werden. Die Emulationsgeschwindigkeit darf nicht geringer sein als die des Originalsystems, da es sonst zu Verzerrungen der Klangausgabe kommen würde.

Als Lösung werden in Emulatoren sogenannte Samples verwendet, digitalisierte Ausschnitte eines analogen Audiosignals. Es handelt sich also um gespeicherte Tonaufnahmen des Originalchips. Dazu wird die Wiedergabe gewisser Grundfrequenzen unter Anwendung der analogen Filter aufgenommen, über Analog-Digital-Wandler digitalisiert und kann dann im Emulator für die gewünschte Ausgabefrequenz transponiert wiedergegeben werden. Diese Technik wird z.B. im C64-Emulator VICE (siehe Tabelle 1) verwendet.^[50]Siehe VICE-Handbuch unter http://www.cs.cmu.edu/~dsladic/vice/doc/html/vice_6.html. Analoge Klangerzeugung wurde ebenfalls vielfältig in frühen Arcade-Automaten eingesetzt, da bestimmte Effekte mit der damaligen Digitaltechnik nicht zu realisieren waren. Die Verwendung von Samples für diese Automaten ist daher ebenfalls integraler Bestandteil des M.A.M.E.-Emulators (siehe Tabelle 1). Trotz digitaler Neuberechnung und der Verwendung von Samples ist es nicht möglich, den analogen Klang der Originalchips vollständig zu reproduzieren.

Ein weiteres Beispiel für komplexe Klangerzeugung ist der Systemlautsprecher (PC-Speaker) früher x86-PCs. Dieser Lautsprecher ist ein Standardbestandteil aller IBM-kompatiblen PCs und stellte bis etwa Anfang der 1990er-Jahre die einzige Möglichkeit dar, auf einem PC Töne zu erzeugen. Abgelöst wurde diese Technik durch das Aufkommen und die breite Verfügbarkeit von dedizierten Soundkarten. Diese bestanden zumeist aus zwei Teilen, einem Analog-Digital- und einem Digital-Analog-Wandler zur Aufnahme bzw. Wiedergabe von 8- und 16-bit-Samples und einem MIDI-konformen Synthesizer mit eingebauten Samples für die entsprechenden Instrumente. Der Systemlautsprecher verfügte hingegen nur über die Zustände „an“ und „aus“, physisch repräsentiert durch die verschiedenen Extrema der Membran des Lautsprechers. Prinzipiell können also nur angenäherte Rechteck-Schwingungen erzeugt werden. Entgegen dieser Spezifikation fanden Programmierer eine Möglichkeit mittels komplexer Timingsteuerung über die Systemuhr des PCs digitalisierte 6-bit-Klänge über den Systemlautsprecher abzuspielen und andere Wellenformen zu erzeugen. Dazu wurde der Lautsprecher bzw. dessen Membran über Interrupts schneller angesteuert, als sie sich physisch bewegen konnte. Diese Technik wurde von mehreren Spielen dieser Zeit aufgegriffen, um Musik und digitalisierte Sprache ohne die Verwendung von Soundkarten abzuspielen.^[51]Für eine detaillierte Beschreibung sowie Klangbeispiele siehe http://www.oldskool.org/sound/pc/#digitized.

Eine Emulation dieses Verhaltens ist auf die korrekte Nachahmung der PC-Uhr und komplexer Timing-Strukturen angewiesen. Der Emulator DOS-Box (siehe Tabelle 1) ist beispielsweise in der Lage, diese Klänge wiederzugeben. Dabei ist jedoch zu beachten, dass moderne Soundkarten und angeschlossene Lautsprecher nicht die Beschränkungen des Systemlautsprechers aufweisen. Eine Wiedergabe im Emulator führt daher zu einem deutlich besseren Klangbild mit weniger Verzerrungen, als dies über den damaligen Systemlautsprecher physisch möglich war.

Diese ausgewählten Beispiele verdeutlichen die Grenzen der Reproduktion analoger Klangerzeugungssysteme und spezifischer Hardwareeigenheiten. Samples sind in der Lage, diese Abweichungen zu verringern. Das Klangbild in der emulierten Umgebung entspricht in den oben genannten Fällen jedoch nicht dem der Originalumgebung. Die konzeptuelle Ebene des Objektes wird also verändert.

4.2.3 Eingabegeräte

Um Nutzereingaben entgegenzunehmen, wurden insbesondere im Spielebereich eine Vielzahl von Eingabegeräten entwickelt. Diese reichen von aus dem Arcade- und Konsolenbereich bekannten Joysticks und Joypads bis hin zu Spezialanfertigungen für ein bestimmtes bzw. eine bestimmte Klasse von Spielen wie Mikroschalter-gesteuerte Snowboards, druckempfindliche Tanzmatten, Laserpistolen, Karaoke-Mikrofone, Tasten-„Gitarren“, VR-Helme (Virtual Reality) und Gestensteuerung über 3D-Kameras. Die Interaktionsmöglichkeiten sind dabei vielfältig und immer auf das Spiel und dessen Ereignisverlauf zugeschnitten. Zwar bleiben grundlegende physische Interaktionsmöglichkeiten zwischen Mensch und Rechner relativ stabil, da sie an die Funktionsweise der Sinnesorgane des Menschen gekoppelt sind, welche im Prinzip ebenfalls stabil sind. Dennoch lassen sich die konkreten Ausprägungen künftiger Interaktionskonzepte in Hardware kaum vorhersagen.

Mobile Plattformen, wie die Apple iOS-Geräte iPad, iPhone und iPod touch, besitzen 3-Achsen-Beschleunigungssensoren und einen Gyrokompass mit dessen Hilfe Spiele für diese Systeme die Lage, Bewegung und Orientierung des Gerätes im Raum feststellen können. Eine weitere Kategorie bilden spezielle Controller, die durch Aktoren wie Elektromotoren physische Rückmeldung (ein sogenanntes „Force-Feedback“) an den Spieler ermöglichen und damit gleichzeitig Ausgabegerät sind.^[52]vgl. 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, … Continue reading In jüngster Zeit ist ein Trend zu 3D-Fernsehern und -Bildschirmen sowie zu kombinierten VR-Systemen wie beispielsweise Oculus Rift zu beobachten.^[53]Siehe Produktwebsite von Oculus VR unter http://www.oculusvr.com/.

Aufgrund dieser so unterschiedlichen Eingabemöglichkeiten, ist eine generelle Kategorisierung der Eigenschaften nicht sinnvoll. Es muss vielmehr das Eingabegerät im Zusammenhang mit der Spielinteraktion betrachtet werden, um signifikante Eigenschaften festzuhalten. Diese können sich allerdings an allgemeinem physischen Beschreibungsmerkmalen wie z.B. der Anzahl der möglichen Freiheitsgrade, der Erfassung von Position, Orientierung, Kraft oder Drehmoment orientieren.

Für die Kommunikation mit dem Rechnersystem findet eine Abstraktion statt. Die physischen Eingabegeräte werden rechnerintern durch logische Eingabegeräte abstrahiert, die über Programmierschnittstellen (API) zur Verfügung gestellt werden. Die Software des dynamischen Objekts kommuniziert nur mit dieser API und damit mit dem logischen Gerät. Ein Emulator kann die API und Hardwareschnittstelle dieses logischen Geräts nur auf logische Geräte des Hostsystems transferieren. Diese abstrahieren ihrerseits an das Hostsystem angeschlossene physische Geräte.

Die Hardwareschwelle kann in Software natürlich nicht überbrückt werden. Ein Software-Emulator ist somit nicht in der Lage, die prinzipiellen Hardwareeigenschaften der Eingabegeräte des Originalsystems nachzuahmen.

Die Erhaltung der signifikanten physischen Eigenschaften ist jedoch essenziell, da es sonst zu einem veränderten Spielerlebnis und damit zu einer abweichenden konzeptuellen Reproduktion kommen kann. Abweichungen können u. a. durch ein verändertes haptisches Feedback entstehen. So waren beispielsweise diverse populäre Sportspiele (wie California Games oder die Olympischen Simulationen Winter Games bzw. Summer Games) für den C64 auf die Benutzung mit Mikroschalter-gesteuerten Joysticks ausgelegt. Die Spielfigur bewegte sich dabei nur durch eine schnelle mechanische abwechselnde Seitenbewegung des Joysticks bis zum Einrasten des Mikroschalters vorwärts. Dadurch sollte bei diesen sogenannten Joystick-„Rüttelspielen“ durch den physischen Aufwand der Bewegung, die „Anstrengung“ der Spielfigur simuliert werden. Für diese Spiele existieren Emulatoren für iOS-Geräte wie das iPad. Da dieses jedoch ohne physische Knöpfe, sondern nur durch Berührung mit den Fingerkuppen (Touch-Bedienung) und Lagesensoren gesteuert werden kann, ist dieser Aspekt der Interaktion mit dem dynamischen Objekt nicht adäquat abbildbar. Die Touch-Bedienung erlaubt wesentlich schnellere Antwortzeiten, als es mit einem Joystick möglich gewesen wäre. Das haptische Erlebnis geht aber vollständig verloren.

Die einzige Möglichkeit, die signifikanten physischen Merkmale dieser Eingabeschnittstellen zu erhalten, liegt in deren Nachbau oder – falls möglich – im Anschluss der Originalgeräte an das Hostsystem und damit außerhalb des Einflussbereichs des Software-Emulators. So existieren Bemühungen alte Eingabegeräte durch ähnliche Hardwarenachbauten, die mit aktuellen Hostsystemen zusammenarbeiten, nachzuahmen.

Beispiele hierfür sind das iControlPad der Firma iControlPad Ltd. oder der JOYSTICK-IT Arcade Stick der Firma ThinkGeek sowie der Fling-Aufsatz der Firma Ten One Design für das iPad.^[54]Siehe Produktwebseiten unter http://www.icontrolpad.com, http://www.thinkgeek.com/product/e75a/ sowie http://tenonedesign.com/fling.php. Beim iControlPad handelt es sich um einen Bluetooth-Controller in Form eines Joypads. JOYSTICK-IT und Fling sind Saugnapfaufsätze für den Touchscreen des iPads, die dem Nutzer einen Joystick bzw. ein Joypad zur Steuerung des iPads zur Verfügung stellen. Die iPad-Joysticks sind in Abbildung 4.4 dargestellt. Die Abhängigkeit von physischen Geräten stellt somit eine weitere prinzipbedingte Grenze von Software-Emulatoren dar.

Für den Fall, dass adäquate Hardwaregeräte nicht zur Verfügung stehen, schlagen Guttenbrunner et al. vor, den Grad der Abweichungen als Metadatum im Langzeitarchiv festzuhalten. Aus einer Ontologie essenzieller Elemente erstellen die Autoren über Gewichte ein systematisches Schema. Anhand von Fallstudien werden die Ebenen „Recreated Controls with Standard PC Hardware“, „Recreated Controls with Game Hardware“ und „Support for Original Physical Layer“ unterschieden, um den Authentizitätsgrad der Emulationsumgebung zu quantifizieren.^[56]vgl. 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, … Continue reading

4.2.4 Diskussion der Translationsprobleme

Die Translation von Ein-/Ausgabeschnittstellen auf die Hardware des Hostsystems bedingt eine Veränderung der Rezeptionsumgebung. Allen Abweichungen gemein ist die damit einhergehende Veränderung der Interaktion mit der Rezeptionsumgebung und dem dynamischen Objekt auf konzeptueller Ebene. Besonders für komplexe dynamische Objekte wie Computerspiele kann dies Auswirkungen unterschiedlichen Grads auf das Spielerlebnis und die Immersion in das Spielgeschehen haben, da Immersion und Rezeptionsumgebung in enger Verbindung stehen. Wie im Bereich der Computerkunst müssen Aspekte der Aufführungspraxis berücksichtigt werden, sofern sie signifikant zum Spielerlebnis beitragen. Das Bestreben der Erhaltung bzw. Nachbildung der physischen Merkmale der Rezeptionsumgebung ist auch bei anderen Medien zu finden und besitzt eine Tradition als konservatorisches Mittel. So gibt es beim Fernsehsender ZDF.kultur den Programmbereich „ZDF.kult“, in der beliebte Fernsehsendungen der 1970er- und 1980er-Jahre (wie Dalli Dalli) wiederholt werden. Der Sender veränderte die Ausstrahlung dieser Sendungen mit Digitalfiltern, welche das Bild verzerren und wölben, und fügte des Weiteren einen schwarzen Rahmen ein. Damit sollte die ursprüngliche Rezeption mittels Röhrenfernsehern auf heute gängigen Flachbildfernsehern simuliert werden, um der historischen Aufführungspraxis dieser Sendungen näher zu kommen. Zentral ist für den Sender die Wahrnehmung durch den Zuschauer.^[57]vgl. Huber, J.: Simulanten-Fernsehen. Aus dem Archiv ins Museum. In: Der Tagesspiegel, Artikel vom 15.5.2011, Online-Ausgabe, 2011.

Im Fall von Arcade-Spielen, welche auf in Spielhallen aufgestellten Automaten rezipiert wurden, können auch Umgebungsgeräusche zu den signifikanten Eigenschaften der Rezeptionsumgebung gehören, wie vom Bewahrungsprojekt Arcade Ambience Sound Project verdeutlicht.^[58]vgl. Hofle, A.: Arcade Ambience Project Intro. Website, 2009.

In den vorangegangen Abschnitten wurden für die Ein- und Ausgabeschnittstellen von Rechnersystemen Beispiellösungen in Hard- und Software vorgestellt, welche in der Lage sind, das Problem der Translation Gap abzumildern. Im Bereich der Bild- und Tonausgabe werden dafür zumeist Digitalfilter in der Emulationssoftware eingesetzt, um signifikante Eigenschaften des Originalsystems nachzuahmen. Die dazu notwendigen Berechnungen sind jedoch komplex und erhöhen die Rechenlast auf dem Hostsystem. Für die physischen Eigenschaften von Eingabegeräten gibt es keine solche Entsprechung in Software. Zur Erhöhung der Authentizität werden hier Hardware-Nachbauten^[59]Für Arcade-Spiele existieren im Internet – getrieben durch die Retro-Computing Community – diverse Anleitungen zum Nachbau der entsprechenden Arcade-Automaten in Verbindung mit … Continue reading oder Konverter zum Anschluss der Originalperipherie eingesetzt.

Technisch handelt es sich bei beiden Strategien um Skeuomorphismen (von griech. skeuos für „Utensilien“ und morphê für „Form“), materielle Metaphern, die funktional bzw. strukturell inhärente Eigenschaften von zur Funktion notwendigen und intrinsischen Komponenten des Originalsystems in der Emulationsumgebung nachbilden. Dabei verlieren diese ihren originären Zweck und nehmen einen schmückenden Charakter an. Ziel ist immer die Minimierung von Abweichungen in der Wahrnehmung von Original- und Zielsystem bzw. Objekt.^[60]vgl. Gessler, N.: Skeuomorphs and cultural algorithms. In: Porto, V. W.; et al. (Hrsg.): Evolutionary Programming VII, Proceedings of the 7th International Conference (EP98), San Diego, CA, … Continue reading

Sowohl bei Hard- als auch Softwarelösungen bilden ein Spannungsfeld zwischen Komplexität und technischer sowie ökonomischer Machbarkeit. Hier müssen pragmatische Fallentscheidungen getroffen werden. Wo eine Erhaltung bzw. Nachahmung ökonomisch nicht umsetzbar oder sinnvoll ist, können technische Abweichungen in den Metadaten festgehalten werden. Auch hier wurden Kriterien und Beispiellösungen vorgestellt.^[61]Für eine systematische Aufarbeitung des Translationsproblems unter pragmatischen und technischen Gesichtspunkten anhand einer Fallstudie am komplexen Virtual-Reality-3D-System Cybermind sei auf … Continue reading

Das Translationsproblem ist jedoch eine systemimmanente Komponente der Emulationslösung. Je weiter sich die Schnittstellen bzw. Hardware des Hostsystems in ihren intrinsischen Eigenschaften von denen des Originalsystems unterscheiden, desto größer werden Abweichungen und eventuelle Verluste der Reproduktion. Skeuomorphismen können diese nur bis zu einem gewissen Grad abmildern. Eine Langzeitprognose zur Erhaltung des Kontexts erscheint schwierig, da künftige Interaktionskonzepte und ihre technischen Ausprägungen in Hardware schwer vorherzusagen sind. Auch konnte gezeigt werden, dass bisher keine generische Verfahrensweise zur Identifikation signifikanter Eigenschaften und deren technischer Umsetzung existiert. Vielmehr haben sich Best-Practice-Lösungen anhand von Fallstudien etabliert.

Da Skeuomorphismen im Emulator implementiert sind, werden Abwägungen und Entscheidungen zur Minimierung der Translation Gap faktisch bereits bei Erstellung des Emulatorprogramms getroffen und sind bedingt durch die technische Komplexität eines Software-Emulators nur unter hohem Aufwand reversibel. Guttenbrunner und Rauber sehen die Anpassung der Daten-Ein- und Ausgabemethoden auf die Gegebenheiten künftiger Systeme als eine zentrale Designentscheidung bei der Entwicklung von Emulatoren.^[62]vgl. Guttenbrunner, M.; Rauber, A.: Design Decisions in Emulator Construction: A Case Study on Home Computer Software Preservation. In: Proceedings of the 8th International Conference on … Continue reading Es ist daher wichtig, Bezugsquellen und Entwicklergruppen von Emulatoren näher zu untersuchen, um Entscheidungskompetenzen und Motivationen aufschlüsseln zu können. Dies soll in den folgenden Abschnitten geschehen.

Implizit hat sich durch die Translationsproblematik eine neue (verdeckte) Anforderung an Software-Emulatoren herauskristallisiert. Der Emulator muss zur Erzeugung von Skeuomorphismen weitere Funktionen bzw. Funktionalitäten übernehmen, die programmatisch nicht Teil des Originalsystems waren. Nur so kann eine Annäherung an eine originalgetreue Wiedergabe der dynamischen Objekte erreicht werden. Die technische Umsetzung z. B. komplexer digitaler Filter stellt vielmehr eine Zusatzanforderung an die Software dar und bildet für Emulatoren im Kontext der Langzeitarchivierung einen neuen Teilaspekt, der bei der Auswahl bzw. Implementierung von Emulatoren zu berücksichtigen ist.

Dies findet in der Literatur zum Thema jedoch zur Zeit noch keine Beachtung.^[63]So findet beispielsweise im „Preserving Virtual Worlds“-Abschlussbericht in McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010 keine technische Ausdifferenzierung der … Continue reading Diese Problematik sowie weitere im Folgenden diskutierte Faktoren führen jedoch dazu, dass es nach wie vor Architekturen bzw. Systeme gibt, für die kein Emulator existiert.

4.3 Entwicklergruppen und Bezugsquellen für Emulatoren

Die Archivierung und Bewahrung von born-digital-Material und komplexen digitalen Objekten ist für Bibliotheken, Archive und anderen Gedächtnisorganisationen immer noch ein großes Problem, da keine durchgängige technologische Methodologie existiert.^[64]vgl. Cohen, P.: Fending Off Decay, Bit by Bit. In: New York Times, New York Edition, Jg. 2010, 16.3.2010, Section C1. Soll zur Bewahrung des Archivs Emulation eingesetzt werden, so sind diese Organisationen auf externe Computerspezialisten und Entwickler angewiesen, da in der Regel weder die personellen oder finanziellen Ressourcen noch die technische Kompetenz zur Entwicklung eines Emulators im Haus vorhanden ist.^[65]vgl. ebenda. Selbst in internationalen Forschungsprojekten zu diesem Thema ist es größtenteils nicht möglich, eigene Emulatoren zu entwickeln. Stattdessen werden bestehende Emulationsprogramme evaluiert und verwendet (siehe Abschnitt 3.2). Die Menge der erhaltbaren Objekte, die Genauigkeit der Erhaltung und dadurch der Bewahrungserfolg hängen somit maßgeblich von einer extern erstellten Komponente ab (siehe Abschnitt 3.8) und liegen nur bedingt im Einflussbereich der kulturbewahrenden Institution.

Huth erkennt hier eine effektive Kompetenzverschiebung. Der Emulator wird zum Arbeitsmittel der digitalen Bibliothek, der Bibliothekar hat jedoch nicht die nötigen Fachkenntnisse, diesen zu erstellen. Der Ersteller des Emulators entscheidet damit faktisch über das erhaltbare Archivgut und trifft die technischen Entscheidungen, welche – einmal in Software gegossen – schwer wieder umkehrbar sind.^[66]vgl. 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. 73. Es ist deshalb wichtig, die Bezugsquellen von Emulatoren und die Beweggründe bzw. Ziele der Programmierer zu kennen.

In [van der Hoeven und van Wijngaarden 2005]^[67]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 werden Beweggründe hinter der Entwicklung verfügbarer Emulatoren analysiert. Die Autoren bestimmen dabei die Entwicklung zur Emulation von game computer platforms und aus nostalgischem Interesse an der Funktionsweise alter Computer (historic computing) durch Hobbyprogrammierer als einen Grund. Eine weitere Kategorie bildet die kommerzielle Entwicklung durch Firmen für Zwecke der business efficiency, üblicherweise im Bereich der Virtualisierung, Ressou centeilung oder für Applikationstests.^[68]vgl. ebenda, S. 6].

Auch bilden Forschung und Wissenschaft eine weitere Gruppe von Akteuren. Mit Dioscuri (siehe Abschnitt 3.2.1) wurde ein erster Emulator speziell für die Anforderungen der digitalen Langzeitarchivierung entwickelt. In der Tat lassen sich drei Kategorien von Entwicklerkreisen identifizieren: Nostalgisch getriebene, kostenlose Emulatoren einer Hobby-Community; kommerzielle Emulatoren der Wirtschaft vorwiegend zur Virtualisierung von Betriebssystemen; schließlich Emulatoren aus Forschung und Wissenschaft zum Zwecke der Langzeitbewahrung.

Die einzelnen Akteure sollen im Folgenden näher beleuchtet werden, um eine Gegenüberstellung der jeweiligen Entwicklungsziele der Gruppen zu den Anforderungen im Rahmen der Langzeitbewahrung zu ermöglichen. Zunächst soll dazu die Gewichtung der Gruppen anhand der Auswahl von in aktuellen Projekten verwendeten Emulatoren ermittelt werden.

4.3.1 Auswahlkriterien für Emulatoren in aktuellen Projekten

Es stellt sich die Frage, nach welchen Kriterien Emulatoren für Langzeitbewahrungsprojekte ausgewählt werden. Wie bereits beobachtet, kommen bei derzeitigen Forschungsprojekten und Bewahrungsinitiativen (siehe Abschnitt 4.3) fast ausschließlich bereits existierende Emulatorprogramme zum Einsatz. Bewahrungsprojekte sind damit direkt auf die Erstellung und Pflege durch Dritte angewiesen. Dementsprechend orientieren sich Auswahlkriterien an technischen Kriterien wie modularen und nach modernen Software-Engineering-Methoden entwickelten Programme sowie an organisatorischen und lizenzrechtlichen Eigenschaften wie der Bereitstellung als Open-Source unter einer gängigen freien Lizenz, um einer größtmöglichen Zahl von Programmierern aus den entsprechenden Communities den Zugriff und die Weiterentwicklung des Emulators zu ermöglichen und diese zu fördern. In [von Suchodoletz 2009]^[69]von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009. werden Kriterien anhand von Nutzungsszenarien identifiziert. Von Suchodoletz nennt die „Vollständigkeit“ der Nachbildung des Originalsystems durch den Emulator, die Anforderungen an das zur Verfügung stehende Hostsystem, Datenim- und -exportmöglichkeiten des Emulators sowie Zusatzfunktionen bei der Benutzerinteraktion (siehe Abschnitt 3.3) als wichtige technische Leitlinien.^[70]vgl. ebenda, S. 77. Hinzu kommen ökonomische Abwägungen bei der Wahl zwischen kommerziellen und Open-Source-Emulatoren. Die initiale Auswahl kann dann anhand von vier Kenngrößen – Kosten, Langzeitverfügbarkeit, Nutzerkreis, Archivgröße – weiter eingeschränkt werden. Von Suchodoletz nennt zudem Tauglichkeit, Nutzbarkeit, Zuverlässigkeit, Performance, Portabilität, verwendete Programmiersprache, Relevanz und Marktdurchdringung als weitere sachlich-pragmatische Anforderungen an den Emulator.^[71]vgl. ebenda, S. 98.

Die Autoren des Abschlussberichtes des auf die Bewahrung von komplexer interaktiver Objekte ausgelegten „Preserving Virtual Worlds“-Projektes stellen einen ähnlichen Kriterienkatalog auf. Der Emulator soll darin ebenfalls auf frei verfügbarem Quelltext mit einer entsprechenden Lizenz basieren und zudem aktiv gepflegt und weiterentwickelt werden. Das Programm muss zudem eine Reihe von aktuellen Hostbetriebssystemen unterstützen und portabel sein. Des Weiteren muss ausreichend interne und externe Dokumentation für das Projekt vorhanden und der Emulator auch von Nicht-Technikern leicht zu bedienen sein. Ebenfalls genannt wird die Wichtigkeit einer vergleichbaren Genauigkeit der Spielerfahrung zum Originalsystem sowie der originalgetreuen Nachahmung einer Vielzahl von Peripheriegeräten.^[72]vgl. McDonough, J.; et al.: Preserving Virtual Worlds – Final Report. 2010, S. 64.

Wiederkehrende zentrale Forderungen sind also die Vollständigkeit bzw. Genauigkeit der Emulation, die Fehlerfreiheit und Entwicklung des Emulators nach modernen technischen Standards sowie eine Bevorzugung von quelloffenen und kostenfreien Emulatoren.

Um diese Anforderungen den Motivationen der jeweiligen Entwicklergruppen gegenüber stellen zu können, ist es sinnvoll, zunächst diejenige mit dem größten Anteil an derzeit verwendeten Emulatoren zu identifizieren. Anschließend sollen die Ziele der einzelnen Akteure genauer untersucht und gegenübergestellt werden.

4.3.2 Untersuchung von Emulatoren nach Entwicklergruppe

Zur Ermittlung der Gruppenanteile wurden die in Abschnitt 3.7.1 aus der Literatur identifizierte Stichprobe von Emulatoren im Hinblick auf Autorgruppe (Community, kommerzieller Hersteller, Forschung und Wissenschaft), Quelloffenheit bzw. verwendete Lizenz und damit eventuell verbundener Kosten sowie auf den Wartungsstatus der Software bzw. die Aktivität des Projektes kontrolliert. Die Ergebnisse sind tabellarisch in Tabelle 2 zusammengefasst.

Tabelle 2: Auflistung untersuchter Emulatoren nach Lizenz und Status

Name (Vertreter)	Gruppe	Architektur	Lizenz	Aktiv?, (seit)	letzte Version vom (Datum)
SIMH	Community	frühe Großrechner	modifizierte X-Windows Lizenz	ja, (1993)	2012-05-03
Hercules	Community	frühe Großrechner	Q Public Licence	ja, (1999)	2010-03-10
M.A.M.E.	Community	Arcade-Systeme	MAME Lizenz non-profit	ja, (1997)	2012-09-17
ARAnyM	Community	Heimcomputer	GPL v2	ja, (2002)	2012-10-04
Arnold	Community	Heimcomputer	GPL	nein, (2001)	2004-01-11
Hatari/WinSTon	Community	Heimcomputer	GPL	ja, (2001)	2012-06-24
JaC64	Community	Heimcomputer	GPL	nein, (2006)	2007-12-31
VICE	Community	Heimcomputer	GPL	ja	2011-02-26
M.E.S.S.	Community	Heimcomputer	MAME Lizenz non-profit	ja, (1998)	2012-02-07
UAE	Community	Heimcomputer	GPL	ja, (1995)	2012-05-09
DOSBox	Community	PC / Mac / x86	GPL v2	ja, (2002)	2010-05-12
Dioscuri	Forschung	PC / Mac / x86	GPL v2	ja, (2006)	2011-01-19
JPC	Community	PC / Mac / x86	GPL v2	ja, (2007)	2010-05-24
Parallels Workstation	kommerziell	PC / Mac / x86	kommerziell	ja	2011-11-08
Plex86	Community	PC / Mac / x86	GPL	nein	2003-12-19
QEMU	Community	PC / Mac / x86	GPL v2	ja	2012-09-05
VirtualPC	kommerziell	PC / Mac / x86	kommerziell	nein	2011-02-10
VirtualBox	Community	PC / Mac / x86	GPL v2	ja	2012-09-13
VMWare	kommerziell	PC / Mac / x86	kommerziell	ja	2012-09-10
PearPC	Community	PC / Mac / x86	GPL	ja	2011-07-13
Mini vMac	Community	PC / Mac / x86	GPL v2	ja	2012-08-06
Basilisk II	Community	PC / Mac / x86	GPL	nein	2001-05-31
PCSX	Community	Spielekonsolen	GPL	nein, (2000)	2003-05-12
SNES9x	Community	Spielekonsolen	nicht-kommerziell	ja, (1997)	2011-04-25
vNES	Community	Spielekonsolen	GPL	nein, (2008)	2011-06-09
ZSNES	Community	Spielekonsolen	GPL v2	ja, (1997)	2007-01-24
Gens32	Community	Spielekonsolen	Gens: GPL Gens32: Closed Source	ja, (2005)	2009-12-23
Kega Fusion	Community	Spielekonsolen	nicht-kommerziell Closed Source	ja	2010-03-07
NeoCD	Community	Spielekonsolen	nicht-kommerziell	nein	2005
Nebula	Community	Spielekonsolen	nicht-kommerziell Closed Source	nein	2007-02-18
O2EM	Community	Spielekonsolen	Artistic Licence	nein	k. A.
Dega	Community	Spielekonsolen	nicht-kommerziell	nein	2004-04-14
PCSX2	Community	Spielekonsolen	GPL	ja	2012-08-01
Stella	Community	Spielekonsolen	GPL v2	ja	2012-06-10
1964	Community	Spielekonsolen	GPL	ja	2012-06-01
Dolphin	Community	Spielekonsolen	GPL v2	ja	2011-12-24
nullDC	Community	Spielekonsolen	GPL v3	nein	2011-08-21
Yabause	Community	Spielekonsolen	GPL	ja	2011-11-27
cxbx	Community	Spielekonsolen	GPL	nein	2004-09-06
GNUBoy	Community	Mobile Geräte	GPL	nein	2001-12-08
DeSmuME	Community	Mobile Geräte	GPL	ja	2012-04-09

Tabelle 2: Auflistung untersuchter Emulatoren nach Lizenz und Status

Die Angaben zur Lizenz, dem Erscheinungsjahr der ersten und zum Datum der aktuellen Version, der 41 gelisteten Emulatoren, wurden – soweit verfügbar – direkt von der Projektseite, bzw. der Seite des Herstellers übernommen. Stand der Daten ist der 5. Oktober 2012. Der größte Anteil (37 von 41, entspricht 90 Prozent) der diskutierten Emulatoren wurde dabei von Hobbyprogrammierern aus der Emulatorencommunity entwickelt. Drei Emulatoren stammen von kommerziellen Herstellern. Bei ihnen handelt es sich ausnahmslos um Virtualisierer. Lediglich ein Emulator (Dioscuri) stammt aus dem Bereich Wissenschaft und Forschung. Bis auf drei Ausnahmen ist der Quelltext der 37 Community-Emulatoren frei verfügbar. Etwa zwei Drittel (24 von 37, entspricht 65%) dieser Emulatoren stehen unter einer Version der GNU General Public Licence (GPL), einer Lizenz der Free-Software-Foundation, mit dem Ziel, die Software und alle daraus entstandenen Derivate dauerhaft nicht kommerziell und quelloffen zu vertreiben.^[73]Siehe Lizenzvereinbarung auf der Projektseite unter http://www.gnu.org/licenses/gpl.html. Ob ein Projekt noch aktiv gepflegt wird, lässt sich bei Community-Projekten nicht unbedingt aus dem Erscheinungsdatum der letzten Version ableiten. Da die Emulatoren als Hobby in der Freizeit entwickelt werden, können zwischen zwei Version oft lange Zeitabstände liegen. Auch ändern sich die Rechtsverhältnisse oft, wenn eine andere Entwicklergruppe die Arbeit eines oft kleinen Teams oder einer Einzelperson übernimmt (sogenannte Maintainer). Auch ermöglicht die Quelloffenheit die Abspaltung in Teilprojekte (sogenannte Forks). Diese Seitenstränge mit getrennter Funktionserweiterung, wie beispielsweise beim vNES-Emulator machen es schwer, die „beste“ Version zu ermitteln. Zum Status des Projekts wurde daher immer den zusätzlichen Angaben auf der Projektseite vertraut. Etwa die Hälfte der gelisteten Emulatorprojekte ist noch aktiv.

Die Anzahl vertretener kostenloser Open-Source-Emulatoren – häufige Merkmale von Community-Emulatoren – korreliert mit den Anforderungen der Kriterienkataloge. Eine Community von Hobbyprogrammierern bildet somit den „Hauptlieferanten“ der Emulatoren für viele Langzeitbewahrungsprojekte dynamischer Objekte. Es ist daher wichtig, insbesondere die Motivation und Zielsetzung dieser Gruppe zur Entwicklung von Emulatoren zu verstehen und Verbindungen zwischen den Akteuren aufzubauen, wie es das KEEP-Projekt versucht hat (siehe Abschnitt 3.2.3).

4.3.3 Open-Source und „Community“-Emulatoren

Wie gezeigt, wird der größte Anteil verwendeter Emulatoren von einer am Thema „retro-computing“ interessierten Gemeinde von technisch versierten Hobbyisten entwickelt. Für diese Gruppe dienen Emulatoren dazu, obsolete Video- und Computerspiel-Plattformen auf modernen Computersystemen wieder erlebbar zu machen.^[74]vgl. Rothenberg, J.: Using Emulation to Preserve Digital Documents. Den Haag: Koninklijke Bibliotheek (RAND-Europe), 2000, S. 27. Dabei stehen der nostalgische Aspekt und das Interesse an alten Computerplattformen im Vordergrund. Insbesondere mit den Computerspielen der Kindheit und Jugend werden meist intensive und positive Erlebnisse verbunden, woraus ein Bedürfnis entwächst, diese Erinnerungen wieder aufleben zu lassen. Das Hauptaugenmerk bei der Emulatorentwicklung richtet sich daher darauf, diese (zumeist populären) Spiele möglichst authentisch wiedergeben zu können. So soll das „Gefühl“ und die Immersion des damaligen Spielerlebnisses in die heutige Zeit transformiert werden. Rothenberg sieht darin einen erwünschten Nebeneffekt für die Genauigkeit der programmierten Emulatoren, “[…] because computer games are notorious for placing heavy demands on their supporting hardware and on being highly dependent on the idiosyncrasies of this hardware, including interface devices, displays, execution and interaction timing, etc.”.^[75] ebenda, S. 29.

Das aus der Motivation entstehende Entwicklungsziel begünstigt Emulatoren mit hoher technischer Genauigkeit und einem Fokus auf authentischer Reproduktion der Rezeptionsumgebung. Dabei wird versucht, möglichst jedes audiovisuelle Detail der damaligen Interaktion nachzuahmen. Dies schließt nicht nur das digitale Artefakt selbst mit ein, sondern kann insbesondere auch die Eigenarten der Hardwareplattform und der Rezeptionsumgebung selbst erfassen (siehe auch Abschnitt 4.2). So kann z.B. der Amiga-Emulator UAE das Ladegeräusch des Amiga-Diskettenlaufwerks beim Betrieb nachbilden. Die charakteristischen Geräusche blieben vielen Spielern beim Warten auf den Beginn des Spiels und beim Nachladen von Spielsequenzen im Gedächtnis und trugen nach Meinung der UAE-Entwickler zur Spielerfahrung bei.

Im Zentrum der Bewahrungsinitiativen stehen somit populäre Spiele und Systemarchitekturen, die Teil eines „kollektiven Gedächtnisses“ sind. Programme und Systeme mit geringer Verbreitung oder andere Einsatzzwecke (z.B. Software aus dem Geschäftsalltag) werden nicht explizit getestet bzw. bei der Emulatorentwicklung berücksichtigt. Dies hat Auswirkungen auf die Menge der erhaltbaren Objekte und widerspricht dem umfassenden Sammlungs- und Bewahrungsziel von Gedächtnisorganisationen.

Conley et al.^[76]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 beschreiben den Auswahlprozess und Faktoren für die Wahrscheinlichkeit der Erstellung eines Emulators durch die Community. Obwohl Emulatoren für eine Vielzahl von Systemen zur Verfügung stehen, existieren insbesondere für seltene und technisch anspruchsvolle Systeme keine Emulatoren. Die Autoren nennen drei Einflussfaktoren. Ein Faktor ist die Popularität des Systems (console popularity), welche in direktem Zusammenhang zur Nachfrage nach einem Emulator steht. Ein weiterer ist die Verfügbarkeit detaillierter technischer Informationen über die Hard- und Software des Systems, welche zur Implementierung des Emulators benötigt wird. Letztlich spielt ebenso die Komplexität und der Schwierigkeitsgrad der Emulatorentwicklung für das jeweilige System eine Rolle.^[77]vgl. ebenda, S. 264.

Dies konnte vom Autor dieser Arbeit in einem begleitenden Forschungsseminar mit dem Computerspielemuseum Berlin zum Thema Softwarearchäologie anhand einer Fallstudie zur Restaurierung des 3D-Spielesystems Cybermind SU 2000 (1994) empirisch nachvollzogen werden. Für dieses System existiert aufgrund der geringen Verbreitung, der fehlenden Dokumentation, der speziellen Hardwarechips sowie der Schwierigkeiten bei der Nachbildung der komplexen 3D-Sensoren und -Aktoren kein Emulator. Nachfragen an die Community und der Versuch einer Zusammenarbeit blieben im Rahmen des Seminars ebenso erfolglos. Die Ergebnisse sind in [Loebel 2011b] veröffentlicht.^[78]Loebel, J.-M.: Erhaltung virtueller Realitäten. Restauration eines Virtual-Reality-Simulators für das Computerspielemuseum Berlin – ein Projektbericht. In: Sieck, J. (Hrsg.): Kultur und … Continue reading

Bei populären Systemen, für die vom Hersteller keine technische Dokumentation veröffentlicht wurde oder diese durch Patente geschützt ist, werden stattdessen Methoden des Reverse-Engineerings angewandt, um Emulatoren zu schreiben. Es kann daher nur beobachtbares Verhalten des Systems nachgeahmt werden, wobei nur Vermutungen über die interne Implementierung bestimmter Chips angestellt werden können. Dadurch kann ein unvorhersagbares Wechselspiel der Systemkomponenten entstehen, das Abweichungen auf der konzeptuellen Ebene des Objekts begünstigt.

Diese Nachkonstruktion anhand des beobachtbaren Systemverhaltens hat zudem direkten Einfluss auf die Entwicklungszeit, den Schwierigkeitsgrad und die erreichbare Vollständigkeit der Implementierung.^[79]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 Die Autoren sehen insbesondere in den Anti-Piraterie-Funktionen neuerer Konsolensysteme eine deutliche Hürde bei der Erstellung von Emulatoren für diese Systeme.^[80]vgl. ebenda. Ebenso werden eventuell nicht alle Funktionen bzw. Schnittstellen des Originalsystems emuliert, wenn diese Funktionen nicht von Spielen genutzt wurden. Dazu zählen u.a. proprietäre Erweiterungsports und häufig serielle und parallele Schnittstellen des Systems.

Die Retro-Computing-Szene bildete sich in größerem Maßstab durch die Vernetzung über das Internet. Diese beginnt bereits Ende der 80er-Jahre durch den Austausch in Newsgroups wie beispielsweise comp.emulators.game-consoles, und verlagert sich mit Aufkommen und allgemeinen Verfügbarkeit des WWW für Privatpersonen auf Webseiten und Webdiskussionsforen. Es entstehen viele Projekte in Zusammenarbeit zwischen den einzelnen Nutzern. Zu den bekanntesten zählen der Arcade-Emulator M.A.M.E. (Multiple Arcade Machine Emulator) und M.E.S.S. (Multi Emulator Super System),^[81]Siehe http://mamedev.org/ bzw. http://www.mess.org/. mit dem populäre Heimcomputersysteme der 1980er- und 90er-Jahre emuliert werden können. Es bildet sich eine aktive Gemeinschaft um die Themengebiete Retro-Gaming bzw. Retro-Computing. In der Tat kommen Emulatoren als Bewahrungswerkzeuge hier erstmals zum Einsatz.

Die zur Verfügung gestellten Emulatoren sind fast ausschließlich quelloffen (Open-Source), nicht kommerziell und privat entwickelt. Die Szene lebt vom gemeinsamen Erfahrungsaustausch und der Weiterentwicklung durch Freiwillige. Den hohen Anteil von frei verfügbaren Emulatoren aus der Community erkennen auch Borghoff et al., finden dies „ermutigend“ und sehen Verwertungsmöglichkeiten in der Langzeitarchivierung.^[82]vgl. Borghoff, U. M.; Rödig, P.; Scheffczyk, J.; Schmitz, L.: Langzeitarchivierung. Methoden zur Erhaltung digitaler Dokumente. Heidelberg: dpunkt.verlag GmbH, 2003, S. 66.

Sowohl in Deutschland, als auch international herrscht inzwischen großes Interesse in der Bevölkerung rund um das Thema Retro-Computing bzw. Retro-Gaming.^[83]vgl. 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, … Continue reading Es entstehen Vereine wie beispielsweise der RetroGames e.V.^[84]Siehe Vereinswebsite unter http://retrogames.info/. Es haben sich sogar eigene Festivals und jährliche Veranstaltungen, wie die deutsche Retrobörse^[85]Siehe http://www.retroboerse.de/retroboerse.htm. oder das Vintage Computer Festival (Europe)^[86]Siehe http://www.vcfe.org/. etabliert. Seit 2004 existiert ebenfalls eine erste, monatlich erscheinende, Zeitschrift namens „Retro Gamer“.^[87]Siehe Website des Verlags unter http://www.retrogamer.net/. Seit 2012 ist auch ein deutscher Ableger im Handel, siehe http://shop.heise.de/zeitschriften/sonstige/retrogamer. Mit zunehmender Popularität steigt auch das Interesse an kommerziellen Verwertungsmöglichkeiten alter Spiele durch die Rechteinhaber. Es handelt sich um ein nicht zu unterschätzendes soziales Phänomen, wobei jedoch zwischen der deutlich kleineren Gruppe der Emulatorprogrammierern und den Rezipienten von emulierten Spielen unterschieden werden muss.

So ist es diese Teilgruppe, der technisch versierten Programmierer, die sich für Pflege und Weiterentwicklung von Emulatoren verantwortlich zeigt. Rothenberg erkennt hier das Problem, dass der Blick der Community „nach innen“ gerichtet ist und außerdem nicht langfristig geplant wird. Somit sind scheinbar Emulatoren der Community nur eine kurzfristige pragmatische Lösung zur Erhaltung dynamischer Objekte.^[88]vgl. Rothenberg, J.: Avoiding Technological Quicksand – A Report to the Council on Library and Information Resources. 1999, S. 32. [abgerufen 24.04.2008]

Tatsächlich stellt sich die Frage, ob es sich um ein zeitlich begrenztes soziales Phänomen handelt, dass von der Nostalgie einer bestimmten Zielgruppe gesteuert ist. Die Frage, ob die nächste Generation von Programmieren ebenfalls kostenlos unter erheblichem Freizeiteinsatz Emulatoren für Systeme ihrer Kindheit entwickeln wird ist berechtigt, kann aber leider nur unbeantwortet bleiben. Wartung und Pflege der Emulatoren können auf diese Weise nicht auf Lange Sicht sichergestellt werden. Die Quelloffenheit bedingt zudem durch sich vom jeweiligen Hauptentwicklungszweig abspaltende Gruppen eine Reihe von Seitenentwicklungen der Software (forks). Fehlerbehebungen erfolgen nach internen, intransparenten Kriterien.

Guttenbrunner et al. bemerken zudem, dass Emulatoren aus der Community wichtige Eigenschaften, wie die Unterstützung von Metadatenformaten oder Automatisierungsfunktionen fehlen, was die Einbindung in einen institutionellen Bewahrungsworkflow erschwert.^[89]vgl. Guttenbrunner, M.; et al.: Evaluating strategies for the preservation of console video games.In: iPRES 2008 – conference proceedings, London, 2008. Das KEEP-Projekt versucht an genau dieser Stelle anzuknüpfen und Brücken zu schlagen (siehe Abschnitt 3.2.3).

4.3.4 Kommerzielle Emulatoren

Bei der Entwicklung kommerzieller Emulatoren sind zwei Bestimmungszwecke auszumachen. Zum einen wird – in Form von virtuellen Maschinen wie VMWare und dedizierten Systememulatoren – Software für den Servermarkt und zur Applikationsentwicklung (Sandboxumgebung, Debug-Tests) angeboten. Virtuelle Maschinen sind dabei besonders innovationsgetrieben und orientieren sich an den Anforderungen der Industrie. Eine langfristige Unterstützung obsoleter oder exotischer Betriebssysteme und Hardware ist explizit nicht vorgesehen, wie in Abschnitt 3.4.2 beschrieben. Die Systeme sind in der Regel proprietär und der Quellcode nicht verfügbar. Bei Evaluationen von VM-Programme zum Zwecke der Langzeitarchivierung von PC-Software wird daher ein negativer langfristiger Ausblick gegeben.^[90]vgl. u.a. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009 und van der Hoeven, J.; et al.: Emulation for … Continue reading Die Programme eignen sich allenfalls zum kurzfristigen pragmatischen Einsatz, da Hersteller zumindest für die Produktlaufzeit Funktionsgarantien geben und in Form von Updates Fehlerbeseitigungen durchführen. Daneben existieren in entsprechenden Entwicklerkits vorrangig für mobile Plattformen wie Smartphones dedizierte Systememulatoren. Apple liefert im Rahmen des iOS-SDK (Software Development Kit) einen „iPhone Simulator“ mit, der es zusammen mit dem Entwicklungstool XCode ermöglicht, in der Entwicklung befindliche iOS-Programme direkt auf einem Mac auszuführen, um Entwicklungszeit zu sparen.^[91]Das iOS-SDK kann nach Registrierung als Apple-Entwickler unter https://developer.apple.com/devcenter/ios/index.action heruntergeladen werden. Ähnliche Emulatoren liegen den Entwicklerkits für Googles Android- und Microsofts Windows Phone-Betriebssystem bei.^[92]Siehe Android Emulator unter http://developer.android.com/tools/help/emulator.html sowie Windows Phone Emulator unter http://msdn.microsoft.com/de-de/library/hh134796(v=expression.40).aspx. Die Verwendung ist dabei strikt an die jeweiligen Entwicklerlizenzen geknüpft und die Emulatoren jeweils für die aktuelle Version der mobilen Betriebssysteme konzipiert. Eine Verwendung für Langzeitbewahrungszwecke ist daher, wie bei den VM-Programmen zuvor, nicht ratsam und gegebenenfalls auch rechtlich nicht möglich.

Die steigende Anzahl mobiler „Apps“ gepaart mit proprietären Vertriebswegen und der Nichtverfügbarkeit von Emulatoren von mobilen Systemen verhindert für Gedächtnisorganisationen derzeit größtenteils effektiv die Sammlung, Erhaltung und Aufbereitung dieser Programme.

Darüber hinaus finden Emulatoren zunehmend Verwendung in der Unterhaltungsindustrie. Sie werden dabei vorwiegend zur Zweitverwertung des eigenen Softwareportfolios aus Computer- und Videospielen eingesetzt, um diese für aktuelle Systeme neu herausbringen zu können. Die Industrie hat dabei den wachsenden Markt von Retro-Gamern erkannt, und knüpft mit der kommerziellen Verwertung der „Spieleklassiker“ an die Retro-Computing-Welle an. Die Hersteller von Spielekonsolen haben den Vorteil, dass sie über die internen Hardwarespezifikationen, Schaltpläne und eine umfangreiche Dokumentation der Konsole verfügen. Sie besitzen somit das Know-how einen genauen, speziell für ihre Produkte abgestimmten Emulator zu schreiben. Dies steht im Gegensatz zu den Möglichkeiten der Emulatoren-Community (siehe vorheriger Abschnitt), die nur Emulatoren mit einer extern verfügbaren Dokumentation oder durch Reverse-Engineering erstellen kann, soweit dies lizenzrechtlich nicht verboten wurde.

Ein bekanntes Beispiel ist die Virtual Console, ein Download-Portal und Softwarepaket der Firma Nintendo für die Hauseigene Spielekonsole Wii. Mithilfe der Virtual Console können Nutzer verschiedene Spiele älterer Konsolen beispielsweise von Nintendo, Sega sowie Spiele von 8-bit-Heimcomputern wie dem C64 erstehen und auf der Wii ausführen. Dazu enthält die Virtual Console diverse Emulatoren.^[93]Siehe Produktwebsite unter http://www.nintendo.de/Wii/Virtual-Console/Virtual-Console-Spieleklassiker-auf-die-Wii-herunterladen-Wii-Nintendo-Deutschland-626429.html. Einen ähnlichen, auf Arcade-Spiele ausgerichteten, Dienst bietet auch Microsoft mit dem Microsoft Game Room für das eigene Windows-Betriebssystem an (siehe Abschnitt 3.3). Des Weiteren existiert eine Vielzahl kommerzieller Emulatoren von Heimcomputern und Konsolen der 1980er- und 90er-Jahre für mobile Plattformen wie das iPhone oder iPad, welche über den Apple App Store erhältlich sind.

Für die Langzeitarchivierung dynamischer Objekte sind diese Emulatoren jedoch – trotz potentiell hoher technischer Genauigkeit der Implementierung – ebenfalls nicht geeignet. So sind die Emulatoren aus markttechnischen Gründen häufig an die aktuelle Vermarktungsplattform des Herstellers gebunden und nicht portabel bzw. plattformunabhängig programmiert. Durch den Fokus auf kommerziell verwertbare „Klassiker“ unterstützen die Emulatoren zudem nur ein bestimmtes Softwareangebot. Die Entscheidungsgewalt liegt allein beim Anbieter und nicht bei den bewahrenden Institutionen. Die Pflege des Emulators ist markttechnischen Gesetzmäßigkeiten unterworfen. Sobald keine Verwertungsmöglichkeiten mehr gegeben sind, wird die Unterstützung für das Produkt in der Regel eingestellt.^[94]vgl. von Suchodoletz, D.: Funktionale Langzeitarchivierung digitaler Objekte. Dissertation, Freiburg: Albert-Ludwigs-Universität Freiburg, 2009, Kapitel 5.3.

Durch das konkurrierende Angebot von frei verfügbaren Community-Emulatoren in Verbindung mit illegal über das Internet verbreiteten Spielekopien, wird die Wertschöpfungskette der Hersteller gestört. Bei der Durchsetzung von Urheberrechtsansprüchen kommt es entsprechend zu komplexen Wechselwirkungen zwischen Industrie und Community. Conley et al. führen die Debatte Pro/Kontra Emulation aus Sicht der Akteure und fordern die Industrie auf, mit der Emulatorencommunity zusammenzuarbeiten und gemeinsames Know-how zu nutzen, anstatt langwierige und kostspielige Gerichtsprozesse zu führen.^[95]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 Aus Angst vor einer rechtlichen Verfolgung könnte sonst die Entwicklung freier Emulatoren unterbleiben.

Ein Beispiel für die erfolgreiche Zusammenarbeit von Industrie und Community ist die kommerzielle Website „Good old Games“ (GOG), welche legale, von den Herstellern lizenzierte Versionen, alter DOS-Spiele vertreibt.^[96]Siehe Firmenwebsite unter http://www.gog.com/. Diese werden zusammen mit dem Open-Source-Emulator DOSBox (siehe Liste der untersuchen Emulatoren) als Paket zum kostenpflichtigen Download angeboten. Die Betreiber der Website sind damit ebenfalls auf die Weiterentwicklung des Emulators durch die Community angewiesen.

4.3.5 Emulatoren aus Forschung und Wissenschaft

In der Wissenschaft findet das Problem der Abhängigkeit von extern entwickelten Emulatoren inzwischen Berücksichtigung. Gedächtnisorganisationen stellen zwar in Zusammenarbeit mit wissenschaftlichen Institutionen (zumeist technisch ausgerichtete) Kriterienkataloge auf, sind aber in der Regel sowohl technisch, personell als auch finanziell nicht in der Lage, diese umzusetzen. Daher werden Studien vorwiegend anhand existierender Emulatoren durchgeführt (siehe Tabelle 2).

Einen ersten Versuch, diesen Missstand zu beheben und einen Emulator speziell für die Anforderungen von langzeitbewahrenden Prozessen zu entwickeln, stellt der an der Koningklijke Bibliotheek der Niederlange entwickelte Emulator Dioscuri dar. Eine erste öffentliche Version ist seit 2007 verfügbar. Dioscuri bildet zudem die technische Basis des PLANETS-Projekts (siehe auch Abschnitt 3.2.1 in Verbindung mit Abschnitt 3.2.4).

In [van der Hoeven u. a. 2007]^[97]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. fassen die Projektmitglieder die Designziele und Ergebnisse der Entwicklung zusammen. Das Ziel war es, einen Emulator zu entwickeln, der in der Lage ist, die x86-PC-Plattform zu emulieren und Methoden zur Anbindung an digitale Archive bereitzustellen. So werden Metadaten unterstützt und Funktionen zum Datentransfer zwischen der emulierten und der Host-Umgebung angeboten.^[98]vgl. ebenda, S. 125. Designmaxime war insbesondere die Modularität und Haltbarkeit (durability) des Emulators. Im Programmcode sind die Emulator-typischen Module als gekapselte Softwareobjekte realisiert. Dioscuri ist in Java programmiert, um ein gewisses Maß an Plattformunabhängigkeit zu bieten und nicht auf eine konkrete Rechnerarchitektur angewiesen zu sein. Das Konzept zur Steigerung der Haltbarkeit besteht dabei aus fünf Schichten. An unterster Stelle steht eine virtuelle Maschine, realisiert durch die Java Virtual Machine. Darauf läuft der modulare Emulator (Dioscuri), bestehend aus einer Komponentenbibliothek, Controllern und einem Emulator-Spezifikationsdokument, wie es Rothenberg vorgeschlagen hatte.^[99]vgl. ebenda, S. 126. Die emulierten Hardwarekomponenten lassen sich durch dieses Dokument frei zusammenstellen, um verschiedene virtuelle PC-Konfigurationen zu realisieren.

Zwei Jahre später im Jahr 2009 hat Long^[100]Long, A. S.: Long-Term Preservation of Web Archives – Experimenting with Emulation and Migration Methodologies [= International Internet Preservation Consortium (IIPC) (Hrsg.): Report], … Continue reading Dioscuri im Rahmen eines Vergleichstests mehrerer Emulatoren evaluiert und kam dabei allerdings zu einem ernüchternden Fazit. Nach seiner Einschätzung besitze Dioscuri nur eine sehr begrenzte Funktionalität (“very limited capabilities”) und befinde sich immer noch in der Entwicklungsphase. Vor allen Dingen fiele die erreichbare Ausführungsgeschwindigkeit im Vergleich zu Community-Emulatoren weit zurück. Der Emulator arbeite sehr langsam.^[101]vgl. ebenda, S. 39.

Die geringe Performanz mag zum Teil auf die mehrfache Kapselung und die Verwendung der interpretierten Sprache Java zurückzuführen sein.

Long bestätigt dem Emulator eine sehr geringe Leistungsfähigkeit im Umgang und der Wiedergabe von multimedialen Objekten. Im Ausblick wird auf die Weiterentwicklung und Verbesserungen gehofft, da Dioscuri als Paradebeispiel für Forschungsemulatoren gilt.^[102]vgl. ebenda.

Es bleibt festzustellen, dass trotz einer Entwicklung nach Stand der Forschung und Technik und der Verwendung modernster Software-Engineering-Standards, ein Produkt entstanden ist, das technisch Emulatoren aus der Community weit unterlegen ist.

Da Dioscuri zudem nur mit Instruktionsgenauigkeit (siehe Tabelle 1) arbeitet, wird die Menge an durch den Emulator darstellbaren Objekten weiter eingeschränkt. In Verbindung mit der langsamen Ausführungsgeschwindigkeit und der schlechten Unterstützung multimedialer Objekte kann nur eine negative Prognose für die Erhaltung von komplexen dynamischen multimedialen Objekten durch den Emulator abgegeben werden. Dioscuri ist für diese Klasse von Objekten ungeeignet. Es bleibt zu hoffen, dass Dioscuri im Rahmen der Weiterentwicklung durch die KB weiter verbessert wird. Die technische Entscheidung zur Instruktionsgenauigkeit ist aber nur unter erheblichem zeitlichen und programmatischen Aufwand umkehrbar.

Da Dioscuri bisher der einzige Forschungsemulator ist, bleiben Gedächtnisorganisationen, besonders für die Erhaltung von komplexen Objekten, zumindest kurz- bis mittelfristig auf externe Emulatoren angewiesen. Ökonomische Faktoren spielen dabei die größte Rolle. Kein derzeit aktives Forschungsprojekt zum Thema Langzeitbewahrung entwickelt eigene Emulatoren (siehe Abschnitt 3.2).

4.3.6 Diskussion

Es konnte dargelegt werden, dass Bibliotheken, Archive und Museen, welche Emulation als Bewahrungsstrategie einsetzen, derzeit zu einem Großteil auf extern programmierte Emulatorprogramme angewiesen sind. Dabei wird vorwiegend auf freie verfügbare „Community“-Emulatoren aus dem Internet zurückgegriffen. Die Interessen und Motive Dritter erhalten somit plötzlich Relevanz für die definierten Aufgaben von Gedächtnisorganisationen. Es entsteht das faktische Problem, die nicht deckungsgleichen Interessen in Einklang zu bringen. Einen ersten Versuch des Brückenschlags zur Retro-Gaming-Community unternimmt das KEEP-Projekt (siehe Abschnitt 3.2.3). KEEP arbeitet dazu gezielt mit Programmierern der Community zusammen, um Emulatoren an die Bedürfnisse eines Langzeitarchivs und dessen organisatorischen Workflow anzupassen.

Long sieht als weitere Kritikpunkte zudem die Benutzerunfreundlichkeit bei der Verwaltung, die Komplexität der Einrichtung der Emulationsumgebung für technisch nicht versierte Nutzer und mögliche lizenzrechtliche Probleme.^[103]vgl. Long, A. S.: Long-Term Preservation of Web Archives – Experimenting with Emulation and Migration Methodologies [= International Internet Preservation Consortium (IIPC) (Hrsg.): Report], … Continue reading

Zur Beurteilung der Qualität von Emulatoren sind aufwendige Vergleichstests mit der Originalumgebung notwendig, die Abhängigkeiten von einzelnen Softwarekomponenten sind dabei komplex.

Eine langfristige ökonomische Durchführbarkeit der Emulationsstrategie hängt wesentlich von der Verfügbarkeit geeigneter Emulatoren ab. Diese kann sowohl für kommerzielle, als auch von frei verfügbaren Community-Emulatoren nicht dauerhaft garantiert werden (siehe Tabelle 2). Kommerzielle Emulatoren sind marktgesteuert, Community-Emulatoren werden auf freiwilliger Basis und ohne Support-Garantien zum Selbstzweck entwickelt. Auch ist unklar, ob es sich bei der Retro-Computing-Community um ein zeitlich begrenztes soziales Phänomen handelt. Eine mögliche Lösung bieten Emulatoren, die direkt für Zwecke der Langzeiterhaltung entwickelt wurden. Bislang steht mit Dioscuri jedoch nur ein im Produktiveinsatz befindliches Fallbeispiel zur Verfügung. Es ist anzumerken, dass trotz mehrjähriger Entwicklungsarbeit, der Funktionsumfang und die Genauigkeit der Emulation von Dioscuri deutlich geringer sind, als bei vergleichbaren Community-Emulatoren. Es ist eine Diskrepanz zwischen den von Gedächtnisorganisationen aufgestellten Anforderungskatalogen bzw. -kriterien (siehe Abschnitt 4.3.1) und den Anforderungen an die Genauigkeit der Emulation für dynamische Objekte festzustellen. Der technische Abstraktionsgrad wird beispielsweise derzeit nicht berücksichtigt, Dioscuri arbeitet mit Instruktionsgenauigkeit. Die Auswahl von Emulatoren richtet sich vielmehr nach sekundären Merkmalen wie Verfügbarkeit, Plattformunabhängigkeit und Lizenz. Zudem bedürfen die Test- und Entwicklungsmethoden von Community-Emulatoren einer genaueren Analyse.

Festzustellen bleibt, dass bei gleichbleibendem sozialen Geflecht der Akteure und Verteilung finanzieller Ressourcen eine stetige Versorgung mit Emulationsprogrammen nicht dauerhaft gesichert ist. Für einen Zeithorizont von 50 bis 100 Jahren können daher keine verlässlichen Aussagen getroffen und damit Planungssicherheit geschaffen werden.

4.4 Programmfehler in Emulatoren

Aufgrund der starken Abhängigkeit von extern programmierten Emulatoren ist es auch notwendig, sich mit dem technischen Erstellungsprozess zu befassen, um so Aussagen über die Softwarequalität treffen zu können. Zwar beinhalten gängige Kriterienkataloge die Anforderung einer Entwicklung nach (nicht näher spezifizierten) Software-Engineering-Methoden. Zusätzlich sollen durch modulare Programmierung Programmfunktionen gekapselt werden, um die Codequalität und Wartbarkeit der Software zu erhöhen. Das Programmierkonzept soll durch gekapselte Elemente eine dynamische Konfiguration sowie eine hohe Portabilität und Wiederverwendbarkeit der Softwarebasis gewährleisten.^[104]vgl. u.a. 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. Daraus allein lassen sich jedoch keine Rückschlüsse auf die Qualität und Fehlerfreiheit der programmierten Emulatoren ziehen. Stattdessen sind quantitative und qualitative Analysen erforderlich.

Hunter und Choudhury testeten in einer Fallstudie das Open-Source-Programm Basilisk II.^[105]Siehe Homepage unter http://basilisk.cebix.net/. Es handelt sich dabei um einen Emulator zur Reproduktion alter, auf dem Motorola 68000-Prozessor basierender, Apple Macintosh-Computer. Die Forscher stellten fest, dass der Emulator selbst auf höchster einstellbarer Kompatibilitätsstufe nur etwa zwei Drittel der getesteten Multimedia-Software korrekt wiedergeben konnte. Fehler in der Implementierung verhinderten die Ausführung einiger Titel oder führten zu fehlerhaften Grafikausgaben.^[106]vgl. Hunter, J.; Choudhury, S.: Implementing Preservation Strategies for Complex Multimedia Objects. In: Koch, T.; Sølvberg, I. T. (Hrsg.): Research and Advanced Technology for Digital Libraries, … Continue reading Der Rest war aufgrund von Softwarefehlern nicht zugänglich, der Emulator somit nicht zur Erhaltung dieser Dokumente geeignet.

Rothenberg führte am Bestand der KB eine ähnliche Fallstudie durch.^[107]Rothenberg, J.: An Experiment in Using Emulation to Preserve Digital Publications. Den Haag: Koninklijke Bibliotheek (NEDLIB Report Series), 2000. Er stellte fest, dass manche Software bei Ausführung im Emulator abstürzte (crashed) oder „stecken blieb“ (hung). Um festzustellen, ob es sich um Fehler bei der Originalsoftware oder beim Emulator handelte, wurde ein Vergleichstest mithilfe des noch zur Verfügung stehenden Originalsystems durchgeführt. Dabei wurde jedoch festgestellt, dass die gleichen Fehler und Abstürze auch auf dem Originalsystem auftraten. Diese Unsicherheit macht also ein aufwendiges Testverfahren notwendig, um Fehler der Emulationssoftware ausschließen zu können.^[108]vgl. ebenda, S. 78f.

Auch in [Thibodeau 2002] wird auf die Problematik, dass Software Fehler enthalten kann, die nicht immer behoben werden oder werden können, eingegangen.^[109]vgl. Thibodeau, K.: Overview of technological approaches to digital preservation and challenges in coming years. In: The State of Digital Preservation: An International Perspective – conference … Continue reading Das Problem ist dabei systembedingt. Der Emulator ist selbst ein komplexes dynamisches Objekt. Implementierungsfehler sind eine systemimmanente Komponente jeder Softwareentwicklung und kommen desto mehr zum Tragen je komplexer eine Software ist. Die bis heute andauernde „Software-Krise“ der 1960er-Jahre hat gezeigt, dass Softwaredesign, -entwicklung, und -bewertung komplexe Vorgänge sind und (Programmier-)Fehler nicht ausgeschlossen werden können. Zudem haben sich die Produktionszyklen zwischen zwei Versionen einer Software in der letzten Dekade von Jahren auf Monate verkürzt. Dies gilt auch für Emulatorprogramme.^[110]vgl. Herrmann, D. S.: Software Safety and Reliability. Los Alamitos, CA: IEEE Computer Society Press, 1999, S. 5.

Zwar existieren Methodiken zur Sicherstellung der Korrektheit von Programmen, diese sind jedoch sehr aufwendig und auf die Bereiche von Software beschränkt, in denen sie aufgrund von gesetzlichen Regelungen angewandt werden müssen. Dies ist in der Regel der Fall, wenn die Sicherheit von Menschenleben vom Gebrauch der Software abhängt wie beispielsweise im Automobilbereich, Flugzeugbau und Raumfahrt sowie bei Nuklearanlagen, im militärischen Bereich oder in der Medizintechnik.^[111]vgl. u.a. ebenda, S. 79, 83, 100, 158, 165, 229, 275. Dort existieren wohldefinierte Standards und Arbeitsmethoden. Im Falle der Emulatoren, welche im Grunde eine Alltagssoftware (Gebrauchssoftware) für jedermann darstellen, sind diese allerdings weder praktikabel noch mit vertretbarem wirtschaftlichen und zeitlichen Aufwand anwendbar. Diese Klasse von Software enthält daher prinzipbedingt Fehler. Ob und wie diese sich insbesondere auf die Reproduktion der Emulationsumgebung auswirken, kann nicht vorhergesagt werden. Die Zuverlässigkeit einer Software unterliegt dabei keiner zeitlichen Komponente. Vielmehr tritt ein bestimmter Fehler erst auf, wenn die entsprechende Stelle im Code bzw. ein bestimmter Codepfad aufgerufen wird.^[112]vgl. ebenda, S. 27.

Die Entstehungsgründe für Implementierungsfehler werden in [Herrmann 1999]^[113]Herrmann, D. S.: Software Safety and Reliability. Los Alamitos, CA: IEEE Computer Society Press, 1999. aufgelistet. Implementierungsfehler sind dabei systematisch und können in zwei Kategorien aufgeteilt werden: Entweder wurde unterlassen (vergessen), etwas zu implementieren (“error of omission”), oder etwas wurde falsch implementiert (“error of commission”).^[114]vgl. ebenda, S. 25. Herrmann nennt für Unterlassungsfehler hauptsächlich fehlende Systemspezifikationen sowie Missverständnisse bei der Anforderungsanalyse als auslösende Gründe.^[115]vgl. ebenda, S. 28. Dies ist insbesondere für Community-Emulatoren von Bedeutung, die oft nur auf unzureichende Spezifikationen zurückgreifen können.

Die Anwesenheit von Fehlern – nicht aber deren Abwesenheit – kann dabei nur mittels entsprechender Tests nachgewiesen werden. In [Supnik 2005]^[116]Supnik, R. M.: Bug, Feature, or Code Rot? Adventures in OS Debugging. Teil des SIMH-Archivs zu „Simulation and Historic Systems“, Version vom 26. Januar 2005. werden pragmatische Grenzen systematischer Tests am Beispiel der Entwicklung des SIMH-Emulators für Großrechner (siehe Abschnitt 3.6 und Tabelle 1) vorgestellt. So ist unter anderem das Austesten sämtlicher Konfigurationen ist in der Regel nicht leistbar. Für Supnik ist die Suche nach Fehlern, das Auffinden des Grundproblems und die anschließende Beseitigung “[…] one of the most difficult challenges in simulator^[117]Gemeint sind Emulatoren. Supnik verwendet simulators hier als Produktbezeichnung für Komponenten seines SIMH-Projekts (siehe Abschnitte 3.5.1 und 3.6). debugging”.^[118]Supnik, R. M.: Bug, Feature, or Code Rot? Adventures in OS Debugging. Teil des SIMH-Archivs zu „Simulation and Historic Systems“, Version vom 26. Januar 2005, S. 10.

Zur Analyse der Zuverlässigkeit existieren seit den 1980er-Jahren quantitative Methoden, welche auf die Anzahl vorhandener Fehler fokussieren, die bei Tests gefunden wurden.^[119]vgl. Herrmann, D. S.: Software Safety and Reliability. Los Alamitos, CA: IEEE Computer Society Press, 1999, S. 23. Um ein Gefühl für die Fehleranzahl und Komplexität der in Abschnitt 3.7.1 aufgelisteten 41 Emulatoren zu bekommen, soll daher im Folgenden eine erste quantitative Analyse erfolgen.

4.4.1 Analyse von Fehlerzahl und -quellen bestehender Emulatoren

Als Metrik zur Beurteilung der Komplexität der untersuchten Emulatoren wurde die Anzahl der Quellcodezeilen (Lines of Code, LOC) verwendet. Diese bietet eine ungefähre Messgröße für das Wachstum der Komplexität eines Programms, wobei jedoch unterschiedliche Programmiersprachen und Stile das Ergebnis beeinflussen können. Als Referenz sind die verwendeten Programmiersprachen des Emulators in Tabelle 1 aufgelistet. Kommentarzeilen wurden für weitere Berechnungen herausgerechnet. Der Quellcode des Programms wurde in der jeweils aktuellen Version heruntergeladen. Es konnten nur die Codezeilen von quelloffenen Emulatoren gezählt werden, da kommerzielle Anbieter den Quellcode nicht freigeben. Die Emulatoren VMWare, VirtualPC, Parallels Workstation sowie die nicht im Quellcode angebotenen Community-Emulatoren Nebula, Kega Fusion, Gens32 wurden daher von der Untersuchung ausgenommen und aus der Ergebnistabelle entfernt. Von mini vMac ist ebenfalls kein aktueller Quellcode verfügbar. Von den 41 ursprünglichen Emulatoren wurden 34 anschließend einer weiteren Analyse unterzogen.

Zur Berechnung der Lines of Code wurde das Open-Source-Programm CLOC in der Version 1.56 verwendet, welches Codezeilen nach Programmiersprache auflistet und Kommentarzeilen gesondert erfasst.^[120]Das Programm kann auf SourceForge unter http://cloc.sourceforge.net/ bezogen werden. Die vollständigen Ausgabeprotokolle, Links zu den Emulatoren sowie weitere Zusatzinformationen finden sich auf der Übersichtsseite „Lost In Translation“  unter http://translation-gap.de/.

Mithilfe dieser Kenngröße wurden weitere Werte berechnet. Dazu wurden zunächst die Anzahl der veröffentlichten Versionen eines Programms sowie die Gesamtzahl dokumentierter und behobener Fehler gezählt. Die Angaben dazu wurden den jeweiligen Webseiten der Projekte entnommen. Es wurden drei verschiedene Arten der Fehlererfassung vorgefunden. Zumeist verwendeten die Projekte zur systematischen Erfassung eine Bug-Tracking-Software. Bei Verwendung der Open-Source-Plattform SourceForge wurde dieses Werkzeug vom Plattformbetreiber kostenlos zur Verfügung gestellt. Eine solche Software bietet den Vorteil, dass Nutzer/-innen des Emulators Fehler melden können. Die Anzahl der entdeckten Fehler ist so meist höher. Daneben gab es eine unsystematische Erfassung durch Nutzer/-innen sowie die rein interne Erfassung durch die Programmentwickler. In den letzten beiden Fällen wurden die Angaben – soweit möglich – der Projektdokumentation (Changelog, Release Notes) entnommen. Die Angaben können daher ungenau sein. Mit den so ermittelten Werten wurde ein Mittelwert der Fehler pro Version errechnet, um eine Vergleichsgröße zwischen den einzelnen Softwareprojekten herzustellen.^[121]Aufgrund der lückenhaften Daten sind genaue statistische Auswertungen naturgemäß nicht möglich. Es geht bei diesen Berechnungen ausdrücklich darum, eine Vergleichsbasis zu schaffen und daraus … Continue reading Wenn auf den Projektseiten angegeben wurde zudem die als noch nicht behobener Fehler in der aktuellen Version erfasst. Die Ergebnisse sind in Tabelle 3 zusammengeführt.

Tabelle 3: Auflistung der Emulatoren nach gemeldeter Fehleranzahl im Verhältnis zur Anzahl der Versionen und Quellcodezeilen

Name (Vertreter)	Architektur	Release-/Versionsnr. Datum	Lines of Code (inkl. Kommentare)	Anzahl Releases	Anzahl Bugs total	Anzahl Bugs / Release	# offene Bugs *STAND: Oktober 2012
SIMH	frühe Großrechner	v3.9-0 2012-05-03	216821 (262615)	76	1094	14	5
Hercules	frühe Großrechner	v3.07 2010-03-10	237656 (292661)	63	2172	34	k. A.
M.A.M.E.	Arcade-Systeme	v0.147 2012-09-17	2574562 (3156063)	201	4701	23	1487
ARAnyM	Heimcomputer	v0.913 2012-10-04	147740 (167596)	37	2136	58	6
Arnold	Heimcomputer	v2004-01-04 2004-01-11	75484 (90349)	6	74	12	k. A.
Hatari/WinSTon	Heimcomputer	v1.6.2 2012-06-24	131757 (154392)	29	414	14	82
JaC64	Heimcomputer	v1.1 beta 2007-12-31	20675 (25006)	6	k. A.	k. A.	3
VICE	Heimcomputer	v2.3 2011-02-26	467531 (569656)	42	1236	29	15
M.E.S.S.	Heimcomputer	v0.145 2012-02-07	2574562 (3156063)	86	1593	19	k. A.
UAE	Heimcomputer	v2.4.1 (Win) 2012-05-09	98348 (107413)	25	2542	102	k. A.
DOSBox	PC / Mac / x86	v0.74 2010-05-12	114681 (128657)	16	382	24	75
Dioscuri	PC / Mac / x86	v0.70 alpha 2011-01-19	866638 (915404)	19	92	5	25
JPC	PC / Mac / x86	v2.41 2010-05-24	78626 (90992)	2* (ab v2.4)	k. A.	n. A.	8
Plex86	PC / Mac / x86	v0.1 2003-12-19	236636 (308366)	k. A.	k. A.	n. A.	k. A.
QEMU	PC / Mac / x86	v1.2.0 2012-09-05	1037936 (1250180)	54	684	13	430
VirtualBox	PC / Mac / x86	v4.2.0 2012-09-13	3241880 (4069156)	62	805	13	k. A.
PearPC	PC / Mac / x86	v0.5.0 2011-07-13	128396 (152194)	8	109	14	k. A.
Basilisk II	PC / Mac / x86	v0.9.1 2001-05-31	116712 (139071)	2	101	51	k. A.
PCSX	Spielekonsolen	v1.5 2003-05-12	36572 (41623)	12	k. A.	n. A.	k. A.
SNES9x	Spielekonsolen	v1.53 2011-04-25	157436 (193383)	79	1266	16	k. A.
vNES	Spielekonsolen	v2.15 2011-06-09	10044 (12178)	k. A./ Forks	32 (seit v2.10)	n. A.	k. A.
ZSNES	Spielekonsolen	v1.51 2007-01-24	187394 (197480)	19	1720	91	36
NeoCD	Spielekonsolen	v0.3.1 2005	40825 (44016)	k. A.	k. A.	n. A.	k. A.
O2EM	Spielekonsolen	v1.1.8 k. A.	7081 (460)	k. A.	k. A.	n. A.	k. A.
Dega	Spielekonsolen	v1.12 2004-04-14	8582 (10319)	k. A.	k. A.	n. A.	k. A.
PCSX2	Spielekonsolen	v1.0 2012-08-01	1043092 (1281993)	k. A.	k. A.	n. A.	k. A.
Stella	Spielekonsolen	v3.72 2012-06-10	102874 (124087)	54	912	17	k. A.
1964	Spielekonsolen	v r146 2012-06-01	275600 (299276)	k. A.	k. A.	n. A.	k. A.
Dolphin	Spielekonsolen	v3.0 2011-06-24	802264 (977819)	k. A.	k. A.	n. A.	k. A.
nullDC	Spielekonsolen	v1.0.4 2011-08-21	104683 (104683)	k. A.	k. A.	n. A.	k. A.
Yabause	Spielekonsolen	v0.9.11 2011-11-27	154057 (187811)	26	166	6	67
cxbx	Spielekonsolen	v0.8.0 2004-09-06	207721 (273195)	32	85	3	k. A.
GNUBoy	Mobile Geräte	v1.0.3 2001-12-08	21614 (24190)	26	257	10	k. A.
DeSmuME	Mobile Geräte	v0.9.8 2012-04-09	1447211 (1712281)	15	228	15	k. A.

Tabelle 3: Auflistung der Emulatoren nach gemeldeter Fehleranzahl im Verhältnis zur Anzahl der Versionen und Quellcodezeilen

4.4.2 Datenauswertung der Codeanalyse

Die untersuchten Emulatoren weisen durchschnittlich mehrere 100000 Zeilen an Quellcode auf. Auffallend ist Dioscuri, der mit knapp 900000 Quellcodezeilen deutlich komplexer und umfangreicher ist als ein Großteil der anderen getesteten Emulatoren. Dabei ist kein signifikanter Anstieg der Lines of Code bei Emulatoren für neuere komplexere Systeme festzustellen. Dies ist vermutlich auf die steigende Verwendung von Standardbibliotheken für Multimediafunktionen (wie z. B. SDL)^[122]Simple DirectMedia Layer, eine freie quelloffene Multimediabibliothek. Siehe Website unter http://www.libsdl.org/. zurückzuführen, in die sonst selbst entwickelte Routinen ausgelagert werden. Diese Bibliotheken gehören streng genommen zum Emulator, wurden aber bei der Zählung des Quellcodes nicht berücksichtigt. Die Verwendung von Standardbibliotheken gegenüber Eigenentwicklungen ist generell zu begrüßen.^[123]vgl. Herrmann, D. S.: Software Safety and Reliability. Los Alamitos, CA: IEEE Computer Society Press, 1999, S. 38.

Bildet man den Mittelwert über alle Emulatoren, so enthält ein Community-Emulator durchschnittlich 27 entdeckte Fehler pro Version. Die Annahme, dass komplexe Software wie Emulatoren eine Reihe von Implementierungsfehlern enthält, konnte bestätigt werden. Zur Fehlerbehebung sind die meisten Projekte auf Nutzerhinweise angewiesen. Emulationsprogramme können daher per Definition nicht in allen Fällen korrekt arbeiten bzw. korrekte Ergebnisse liefern.

Implementierungsfehler stellen somit eine weitere Quelle für mögliche Reproduktionsfehler und Abweichungen auf konzeptueller Ebene von dynamischen Objekten dar. Die Auswirkungen der Softwarefehler können jedoch nicht quantifiziert werden. Sie müssen allerdings als fester Bestandteil der Emulationsstrategie berücksichtigt werden.

4.5 Zusammenfassung der Ergebnisse

In diesem Kapitel wurden Ausprägungen des Translation Gap-Phänomens untersucht. Es konnten drei Komponenten mit unterschiedlichen Entstehungsfaktoren ausgemacht werden, deren Auswirkungen in der Lage sind die Interaktion mit dem dynamischen Objekt auf konzeptueller Ebene zu verändern.

Die Translationsprobleme der Schnittstellenmigration teilen sich in den Abstraktionsgrad der Schnittstellenemulation und die Migration der Ein- und Ausgabehardware auf die Komponenten des Hostsystems auf. Die Wahl des Abstraktionsgrads bei der Implementierung des Emulators stellt eine technische Entscheidung dar. Sie ist abhängig von der Verfügbarkeit technischer Dokumentation, der Komplexität der Implementierung im Zusammenhang mit der Ausführungsgeschwindigkeit und den zur Verfügung stehenden finanziellen und personellen Ressourcen. Anhand von Fallstudien konnte gezeigt werden, dass zur korrekten Implementierung in der Regel die Entwicklung von Testszenarien sowie Vergleichstests mit dem Originalsystem vonnöten sind. Dieser zeitliche Aufwand ist jedoch in den meisten Fällen nicht wirtschaftlich realisierbar. Es kommt daher wie auch bei den anderen Submodulen des Emulators (siehe Abschnitte 3.5 und 3.6) gegenüber der Systemspezifikation zu Abweichungen, welche die Auswahl an durch den Emulator erhaltbarer Objekte einschränken.

Die Migration bzw. Translation der Schnittstellen auf die Hardwarekonfiguration des Zielsystems stellt hingegen eine inhärente Eigenschaft und damit prinzipbedingte Grenze von Software-Emulatoren dar. Typische Ein-/ Ausgabeschnittstellen eines Rechnersystems wurden als Teil der Rezeptionsumgebung systematisch aufgestellt und Abweichungen anhand von Fallbeispielen diskutiert. Je weiter sich die signifikanten Eigenschaften der Schnittstellen von Original- und Hostsystem unterscheiden, desto größer ist die Abweichung der Interaktion und damit der Authentizität der Reproduktion, bis hin zum Verlust interaktionsentscheidender Merkmale. Durch die Verwendung von Skalierungs- bzw. Rekonstruktionsfilter sowie weiterer digitaler Filter die Video- und Tonausgabe und bei Ton zusätzlich der Einsatz von Samples ist es möglich, bestimmte Eigenschaften des Originalsystems nachzuahmen und dadurch Abweichungen bis zu einem gewissen Grad zu reduzieren. Dies funktioniert jedoch nur so lange, wie die Ausgabetechnologie auf demselben Grundprinzip (zweidimensionales Raster) basiert. Das prinzipielle Problem bleibt bestehen, was sich anhand fehlender gleichwertiger Hilfstechnologien für Eingabegeräte zeigt. Das Schnittstellenproblem führt systembedingt immer zu Abweichungen und kann langfristig eine sinnvolle Interaktion mit dem dynamischen Objekt unmöglich machen. Die Entwicklung von Interaktionskonzepten und Schnittstellen ist jedoch nur bedingt vorhersagbar. Der höchste von Rothenberg aufgestellte Anforderungsgrad (siehe Abschnitt 4) kann hier nicht erreicht werden. Stattdessen müssen signifikante Eigenschaften der Interaktion (z. B. in den Metadaten) festgehalten werden, um künftigen Nutzern einen Eindruck des Interaktionskonzeptes vermitteln zu können.

Gleichzeitig wurde eine neue Anforderung für Emulatoren auf technischer Ebene identifiziert. Diese müssen alle derzeit gängigen Techniken der Minimierung des Migrationsproblems von Schnittstellen implementieren, um das höchst mögliche Maß an Authentizität zu bieten. Anforderungskataloge für Emulatoren im Kontext der Langzeitarchivierung müssen dahingehend überarbeitet werden.

Es konnte eine deutliche Abhängigkeit der Gedächtnisorganisationen von extern erstellten Software-Emulatoren nachgewiesen werden. Da Bibliotheken und Archiven meist das technische Know-how sowie die personellen Ressourcen zur Erstellung und Pflege entsprechender Emulatorprogramme fehlt, müssen diese extern in Auftrag gegeben oder aus frei zugänglichen Quellen besorgt werden. Damit kommt es zu einer effektiven Kompetenzverschiebung der Entscheidung über das zu bewahrende Archivgut, da die Klasse erhaltbarer Objekte maßgeblich von der technischen Struktur des Emulators abhängt. Die in Kapitel 3 ermittelte Stichprobe von 41 in der Langzeitarchivierung verwendeter Emulatoren wurde benutzt, um die betragsmäßig größte Gruppierung zu ermitteln. Die am häufigsten verwendeten Emulatoren entstammen einer Community von Hobby-Programmieren. Obwohl das Thema Retro-Computing in den letzten Jahren an kultureller Bedeutung gewonnen hat, ist nicht bestimmbar, ob es sich um ein zeitlich begrenztes soziales Phänomen handelt. Die einseitige Abhängigkeit von dieser Gruppe stellt mittel- bis langfristig eine ernstzunehmende Gefahr für archivtechnisch notwendige Erhaltung und Pflege von Emulatoren dar. Soziale Dependenzen zu bestimmten Entwicklergruppen sollten daher aufgelöst oder alternativ die Kooperation aktiv verstärkt werden. Im Hinblick auf die ökonomische Realität in Gedächtnisorganisationen ist ein Ausbau der Beziehungen und der Aufbau von Kooperationen anzuraten. Einen ersten Schritt in diese Richtung bildet das KEEP-Projekt (siehe Abschnitt 3.2.3). Es handelt sich hier um eine Kette aus sozio-ökonomischen Faktoren, die technisch-pragmatische Entscheidungen bedingen, die wiederum Abweichungen auf der konzeptuellen Ebene des Objekts zur Folge haben.

Zuletzt konnte mittels statistischen Analysewerkzeugen der Quellcode der quelloffenen Emulatoren untersucht werden. Als Metrik für die Komplexität des Programms diente dabei die Anzahl der Codezeilen. Diese wurde im Verhältnis zu entdeckten (gemeldeten) Implementierungsfehlern betrachtet. Jeder Implementierungsfehler führt zur Abweichungen von der Systemspezifikation, welche sich auch auf konzeptueller Objektebene niederschlagen können. Hierbei handelt es sich um ein inhärentes Problem jeder Softwareentwicklung, das bei so komplexen Programmen nicht vermieden werden kann. Insbesondere können Fehlertests nur die Anwesenheit, nicht jedoch die Abwesenheit von Fehlern überprüfen. Entdeckte Softwarefehler führen – sofern das Programm aktiv gewartet wird – zu regelmäßigen Updates, die in das Langzeitarchiv eingepflegt werden müssen. Die Gedächtnisorganisation ist bei der Meldung von Fehlern auf die Nutzer und bei der Behebung auf den Ersteller bzw. Hersteller des Emulators angewiesen. Hier existieren wiederum komplexe Abhängigkeiten. In jedem Emulator enthaltene Softwarefehler können gravierende Auswirkungen auf vorgeschlagene Erhaltungsstrategien für den Emulator selbst haben. Diese und weitere Probleme im Kontext der Emulationsstrategie werden im nächsten Kapitel ausführlich behandelt.

Es bleibt festzuhalten, dass bisherige (technische) Anforderungskataloge an Emulatoren nicht ausreichend sind und die hier identifizierten Anforderungen ergänzt werden müssen. Dennoch scheint es unter ökonomischen, pragmatischen und technischen Gesichtspunkten nicht möglich einen Emulator zu erstellen, der die höchste Anforderungskategorie same for all intents and purposes dauerhaft erfüllen kann. Software-Emulatoren unterliegen prinzipbedingten Beschränkungen, die eine hundertprozentige Authentizität der Reproduktion nicht gewährleisten kann.

→ 5. Weitere Grenzen und offene Fragestellungen