Emulator

Ein Emulator ist ein Programm, das einen Computer (meist ältere Heimcomputer) inklusive Prozessor, Speicherverwaltung, Sound, Grafik und dessen Peripherie nachbildet. Damit kann man die Programme des emulierten (also nachgebildeten) Computers auf einem anderen (meist neueren) Computer unter einem anderen Betriebssystem nutzen, zum Beispiel den C64 Heimcomputer auf einem AMIGA oder PC. In einer sogenannten Bare-Metal-Emulation eignen sich auch Einplatinencomputer dazu (sofern ausreichend performant), einen entsprechend portierbaren Emulator zu betreiben.

Simulatoren sind im Vergleich zu Emulatoren nicht so strikt oder tiefgreifend und beschränken sich in der Regel auf die Nachbildung gewisser Aspekte wie Kommandozeilen-Interface, GUI oder BASIC-Dialekt, also auf einer höheren Ebene, ohne jedoch tatsächlich die "Maschine" zu emulieren. Dem Benutzer wird dennoch das Gefühl vermittelt, es handle sich um das simulierte System, allerdings mit entsprechenden Einschränkungen in Bezug auf die Ausführbarkeit von Originalprogrammen und die Kompatibilität zum System an sich. Emulatoren dagegen versuchen völlig exakt einem laufenden Programm das Vorhandensein einer realen Hardware vorzugaukeln.

Siehe auch das Portal und die Kategorie zu den Emulatoren.

Ansätze für Emulation des C64[Bearbeiten | Quelltext bearbeiten]

Zur Emulation des C64 muss die CPU 6510, die CIAs, der VIC-II, der SID, die PLA sowie RAMs und ROMs und ggf. weitere Hardware wie Floppy (inkl. Gerätemechanik, RAM/ROM und so weiter) in Software nachgebildet werden. Es gibt verschiedene Ansätze, die insbesondere unterschiedlich rechenaufwendig sind.

So lassen sich die Opcodes der CPU MOS 6510 "naiv" nachbilden, z.B. so, dass ein STA $C000,X per mem($c000+x) = accu; cycles += 5 (Pseudocode, verkürzt) im Emulator ausgeführt wird. Das funktioniert auch in den meisten Fällen und ist auf dem Host-System sehr schnell ausführbar, ist jedoch nicht das, was der 6510 des C64 tatsächlich macht, was in etwa wie folgt aussieht:

Takt 1: Ein Bytes des Operanden holen
Takt 2: Nächstes Byte des Operanden holen
Takt 3: Operand/X-indizierte Speicherstelle lesen (-256, falls Seitengrenze überschritten wurde): Dummy-Read
Takt 4: Schreiben des Akku-Inhalts
Takt 5: Nächsten Befehl holen

Die exakte Emulation dieser Schritte ist in vielen Fällen nicht nötig, wird jedoch wichtig, sobald z.B. Effekte im Zusammenhang mit dem VIC programmiert werden, der im Gleichtakt mit dem Prozessor läuft, abwechselnd auf das RAM zugreift und dessen Konfiguration während des Bildaufbaus durch die CPU geändert werden kann. Selbst die Dummy-Zugriffe können dann relevant werden, da sie von manchen Programmen z.B. zum Bestätigen von IRQs des VIC (Dummy-Write bei INC $D019) genutzt werden. Werden die Dummy-Zugriffe also nicht emuliert, wird die meiste C64-Software auf dem Emulator immer noch funktionieren, manche aber eben nicht mehr.

Noch aufwendiger ist die korrekte Emulation des Videochips VIC-II MOS 6569: Der VIC-II zeichnet pro Sekunde über 6 Millionen Pixel (403 horizontale Pixel x 312 Zeilen x 50 Bilder/Sek). Eine naive Emulation könnte sich einfach jede 50stel-Sekunde den Bildschirmspeicher, das Farbram und die Register des VIC anschauen, die Sprites "drübermalen" und das Bild ausgeben. Allerdings wäre das erzeugte Bild dann schon bei den meisten simplen Spielen nicht mehr korrekt, wenn z.B. ein Splitscreen genutzt und entsprechend der VIC mitten im Bildaufbau durch "gut getimtes" Beschreiben eines VIC-Registers durch die CPU von Grafik- auf Textmodus umgestellt wird. Noch komplizierter wird es, wenn Ändern der VIC-Register z.B. zum Öffnen des Bildschirmrahmens (Hyperscreen) oder durch einen Sprite-Multiplexer emuliert werden soll. Schon die Bildschirmhintergrundfarbe muss nicht im Verlauf der Darstellung des Bildschirminhalts konstant bleiben.

Frühere Emulatoren bzw. PCs hatten gar nicht die Rechenleistung, das alles korrekt zu emulieren. Entsprechend wurden Tricks angewendet, z.B. hat VICE lange Zeit eine zeilenweise Emulation des VICs umgesetzt. Die Emulation hat die VIC-Register dabei vereinfacht gesagt nur am Anfang einer Bildschirmzeile ausgewertet und die ganze Zeile in einem Rutsch berechnet. Änderungen der VIC-Register durch ein Programm innerhalb der Zeile wurden erst in der nächsten Bildschirmzeile wirksam. Dies war nicht "Faulheit" oder Unkenntnis der Programmierer: z.B. hatte ein 200MHz-PC schlicht nicht die Rechenleistung, jede Sekunde die oben erwähnten sechs Millionen Pixel zu zeichnen, denn die dann pro C64-Pixel zur Verfügung stehenden rund 33 PC-Taktzyklen sind nicht genug, alle an der Grafikerzeugung beteiligten Speicherstellen zu lesen, zu verarbeiten und auch noch für jeden einzelnen Pixel potenziell acht Sprites zu berechnen (und Kollisions-Flags für die Sprites zu setzen, selbst wenn sie durch andere Sprites verdeckt sind).

Erst nachdem CPUs mit mehreren GHz zur Verfügung standen, wurden sogenannten "zyklenexakte" Emulatoren möglich, die die Hardware weitestgehend so emulieren, wie sie tatsächlich funktioniert. Zyklenexakte Emulatoren sind dabei häufig sogar einfacher aufgebaut als frühere Emulatoren, bei denen meist Spezialfälle berücksichtigt werden mussten, damit in ihrem jeweiligen vereinfachten Modell trotzdem bestimmte hardwarenahe (VIC-)Effekte funktionierten.

Emulatoren für den C64[Bearbeiten | Quelltext bearbeiten]

Befehle des Spectrum Simulators auf C64

GW-BASIC Emulator
MS-DOS Simulator
Spectrum Simulator
Apple-1: Green Delicious Apple-1 von Aleksi Eeben
Basil: PET Emulator von Aleksi Eeben
Tomy Tutor: The Tutti von Cameron Kaiser
Chip-8: Joseph Weisbeckers Telespiel-VM von Per Olofsson
Commodore
- PET Emulator von Commodore http://cbm.ficicilar.name.tr/commodore/pet-emulator-for-the-c64
- vic-emulatorC64 von Fausto Ibarra Download bei zimmers.net
Asteroids Emulator keine Portierung von Norbert Kehrer
HP-35/45/55/80 Emulatoren keine Portierung von Norbert Kehrer
Sprint 1 Emulator keine Portierung von Norbert Kehrer
KIMplement von Cameron Kaiser
CP/M: Software-Version von Commodores CP/M V2.2 (verschiedene Versionen in Umlauf)
CP/M "O.O.B." von Forum64-User M.J.