Emulator programmieren

  • Emulator programmieren

    Ich spiele seit einiger Zeit mit dem gedanken mir zu lernen wie Mann einen C64 Emulator schreibt.
    Mein Ziel wäre damit zweifach:

    - Ich bin einfach neugirieg wie so ein Emulator normaler weise funktioniert.
    - Möchte mehr über das Innerleben des C64 lernen

    Ich habe dazu zwei Fragen:

    1. Ich nehme an, das der Quellecode für Vice das beste Ausgangspunkt ist den ich finden werde. Richtig?

    2. Um den Lernprozess interessanter zu gestallten, und weil ich zur Zeit auch gerne Python lernen möchte, erwege ich es zu versuchen einen Emulator in Python zu implementieren...
    Ich weiß, daß es wahscheinlich sehr langsam wird, aber wäre es machbar? Die Rechner heutzutage sind immerhin ziemlich schnell...
  • Das wird von der Geschwindigkeit schon passen.
    Ich persönlich würde das Projekt allerdings recht unbefriedigen finden. Denn das endprodukt wäre etwas, das es schon gibt - und vermutlich in besserer ausführung.
    Ich fände es besser wenn Du das so abwandelst, dass es wirklich was neues für die community wäre. Also etwas das es noch nicht gibt.
    Beispiele:
    Ein bare metal Cevi Emulator fürs Raspberry (gibts zwar, aber nur rudimentär).
    Ein bare metal Cevi Emulator fürs arduino mit Expansionsport.
    Eine Drop in Emulation von Cevi Chips auf dem Arduion. (Da ich da jetzt mit den CIA anfange, schlage ich vor Du nimmst Dir mal den VIC II vor ;) )
    Eine Cevi Emulation für IOS oder Android.
    Eine Cevi Emulation in VHDL ( gibts zwar schon aber nicht open source).
    CIA and Co have reached the C64 - see the proof in the Hack Attack Trailer
  • Einige von deinen Vorschlegen sind ziemlich interessant, aber ich bin mir leider nicht sicher ob ich der "richtiger Mann" für sie bin, so zu sagen.
    Ich bin zwar Softwareentwickler vom Beruf her, aber ich kenne mich mit Hardwareinnereinen und "Low Level" Sprachen nicht so gut aus. (Meistens arebeite ich mit C#)

    Etwas Brauchbares zu bauen, was auch für die Community nützlich wäre, ist schon eine schöne Idee, aber da ich mit diesen Sachen ein totaler Anfänger bin, ist es unwahrscheinlich, daß ich "nähster" Zeit etwas produzieren könnte was wirklich auch für Andre von nutzen ist und nicht nur zum lernen dient. Die Idee mit Python ist mir eigentlich nur gekommen, da ich zur Zeit es gerne lernen würde, aber es ist immer schwerig eine neue Sprache zu lernen ohne einen richtigen Projekt zu haben. Da liest Mann nur etliche Bücher und dann vergißt Mann auch gleich wieder alles. Deshalb habe ich gedacht die beiden Interessen zu verbinden.

    Vom Arduino und RPi weiß ich leider überhaupt nichts.

    Für iOS zu programmieren wäre interessant. Das ist auch einer der Dinge die ich gerne lernen würde. Aber wenn ich mich recht erinnere erlaubt Apple keine Emulatoren...

    VHDL ist auch interessant. FPGAs haben mich schon immer fasziniert. Da würde ich auch gerne einsteigen. Leider habe ich auch keine technische Ausbildung dafür, und ich fürchte, daß ich da esrt so einiges über Komputerarchitektur usw. lernen müßte, das wahscheinlich eine Ewigkeit dauern würde...
  • bjavor schrieb:

    1. Ich nehme an, das der Quellecode für Vice das beste Ausgangspunkt ist den ich finden werde. Richtig?

    2. Um den Lernprozess interessanter zu gestallten, und weil ich zur Zeit auch gerne Python lernen möchte, erwege ich es zu versuchen einen Emulator in Python zu implementieren...
    Ich weiß, daß es wahscheinlich sehr langsam wird, aber wäre es machbar? Die Rechner heutzutage sind immerhin ziemlich schnell...
    Zu 1.: Falsch. VICE ist, bedingt durch seine Anlagen als "eierlegende Wollmilchsau" für Leute, die nicht tief im Code drin sind, kaum zu durchschauen. Man braucht ohne Erfahrung auf dem Gebiet Ewigkeiten, bis man die Details und ihre Abhängigkeiten untereinander durchschaut hat. VICE ist ein guter Ansatzpunkt, wenn man schon verstanden hat, wie so ein Emulator funktionieren kann und was man dafür alles braucht...

    Zu 2.: Kann man machen. Dir ist ja schon klar, daß das keine Rakete wird, also wird sich die Enttäuschung in Grenzen halten ;) Übrigens, die Wahl der Programmiersprache entscheidet weniger über die Machbarkeit eines Projekts. Zum Lernen sollte man das nehmen, mit dem man sich wohl fühlt. Umsteigen, um schneller zu werden, kann man ja immer noch. Es sei denn, man hat´s eilig ;)

    Ich würde erst mal mit den üblichen Spielereien beginnen, die man so im Internet findet. "Minimal-Maschinen" in Software nachbilden und so. Wikidings mit dem Stichwort "Emulation" müßte da schon weiterführende Links anbieten.

    Zaadii schrieb:

    Eine Cevi Emulation für IOS oder Android.
    *hust* VICE *husthust*

    Ich finde den Ansatz, zu Lernzwecken "das Rad neu erfinden" eigentlich besser, als gleich etwas bisher nie Gemachtes anzugehen. Letzteres führt meiner Erfahrung nach schnell zu extremem Frust. Man versteht anfangs die Zusamenhänge oft nicht und verzettelt sich sehr schnell in Details, die man dann, mangels Erfahrung (und aufgrund hoher Komplexität des Problems, weil ja neu) nicht geklärt kriegt. Erst mal mit einzelnen Schritten beginnen, wenn man Rennen will.
  • iOS kannst du gleich wieder vergessen, Apple erlaubt keine Emulatoren im Appstore. Denn darüber kann man ja ungenehmigte Software ausführen.

    Ob man einen Emulator vollständig versteht, in dem man existierenden Jahre lang gewachsenen Emulator-Quellcode liest, wage ich zu bezweifeln. Da sind von vornehrein so viele Sonderbehandlungen für spezielle Situationen drin, dass man die Grundfunktionalität völlig aus den Augen verliert.

    Ich kenne eine Firma (jeder hier kennt die auch, und man traut denen so ein Knowhow erstmal garnicht zu), die wollten das auch machen, weil sie ein altes Gerät aus der eigenen Firma mit sehr spezieller Software auf dem Nachfolgegerät emulieren wollten. Das Altgerät lief auf 68000 Basis, das neue auf Arm. Also haben sie sich UAE und einen im Quellcode vorliegenden ST-Emulator (weiß nicht mehr welchen) genommen und da rein geschaut. Da waren dann von vorne herein so viele #Defines für alle möglichen Hardware-Register von Amiga und ST Hardware drin, dass sie den 68000 Code dazwischen nicht mehr richtig erfassen konnten. Das war zu aufwändig. Sie haben dann 10 Mann hingesetzt, 6 Monate und bei 0 angefangen. Sie waren zwar nach 6 Wochen noch nicht fertig, doch die spezielle Software lief schonmal und konnte auch schon auf die spezielle "Alt-Peripherie" zugreifen, für die das Altgerät gedacht war. Sie mussten nur noch an der Performance rumschrauben, damit die Emulation gewisse Sachen in Echtzeit tat, wie das alte Originalgerät.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von 1ST1 ()

  • bjavor schrieb:

    - Ich bin einfach neugirieg wie so ein Emulator normaler weise funktioniert.
    In erster Näherung ist es ein Bytecodeinterpreter ;)

    1. Ich nehme an, das der Quellecode für Vice das beste Ausgangspunkt ist den ich finden werde. Richtig?
    Wenn ich mich recht entsinne, war der Quellcode von Frodo nicht ganz so schlimm wie der von VICE

    Ich weiß, daß es wahscheinlich sehr langsam wird, aber wäre es machbar?
    Machbar ist es in jeder turingvollständigen Programmiersprache, das Ergebnis muss ja nicht unbedingt in Echtzeit laufen

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Fake6502 ist ziemlich lehrreich, finde ich. Und schön aufgeräumt und super strukturiert und kommentiert. Ist zwar C, müßte aber trotzdem gut verständlich sein. Wenn das ganze Zeiger-Geraffel nicht behagt, das kann man in anderen Sprachen sicher kapseln. Es soll ja Menschen geben, die C-Zeiger-Phobie haben :D
  • Der Vice ist ein Top Emulator, aber der Quelltext ist wirklich nicht gerade leicht zu verstehen. Ich würde empfehlen, mit dem Projekt anzufangen, ohne zu viel in anderen Quelltexten abzulesen. Desweiteren die Ziele nicht zu hoch zu stecken, sondern Schritt für Schritt gehen. ^^ So habe ich es damals gehandhabt. Ich wollte, genau wie du, einfach mal wissen, wie mann einen Emulator programmieren könnte.

    Falls es dich interessiert, wie ich da ran gegangen bin:
    Ich habe damit angefangen, den RAM nachzubilden (ein Byte-Array mt 64K) das war natürlich nicht schwer. Dann habe ich einfach Kernal und Basic-Rom in den RAM kopiert. Also ROM-Switching erstmal völlig ignoriert, das habe ich dann erst viel später gemacht. Nach dem der RAM und die Rom's vorhanden war, habe ich angefangen, die CPU zu machen. Angefangen habe ich dabei mit Variablen für die Register, dann habe ich die normalen (nicht die illegalen) Opcodes umgesetzt. Erstmal nur die Funktionen der Opcodes nachgebildet, das mitzählen der Cycels, die jeder Opcode benötigt, habe ich auch erst später hinzugefügt. Dann habe ich den Programmcounter auf den Kernal-Start gesetzt, und in eine Endlosschleife Befel für Befehl abgearbeitet.
    Um zu sehen, ob ich die Opcodes richtig programmiert habe, habe ich bei meinen Emulator einen Befehl ausgeführt, das selbe mit einem anderen fertigen Emulator im Debugger gemacht, und dann die Register und / oder Speicherinhalte der beiden Emulatoren verglichen. Es dauerte zwar etwas, aber so bin ich gut voran gekommen. Als nächstes habe ich eine einfache Grafikausgabe gemacht-. Keine richtige VIC-Emulation, sondern einfach die darzustellenden Zeichen aus dem RAM gelesen, den Char-Rom gelesen, und die Pixel gezeichnet. 25 mal pro Sekunde den aktuellen Bildschirm gezeichnet. Es war zwar simpel, aber für den Anfang OK. Sowas wie Sprites, Badlines, Rasterposition u.s.w. wurde zu dem Zeitpunkt auch erstmal ignoriert. Hauptsache, mann konnte erstmal etwas auf dem Bildschirm sehen. ^^ Naja, und als dann der C64-Startbildschirm kam, war das schon ein verdammt geiles Gefühl. ^^

    Deine Idee, einen Emulator zu machen, ist gut. Das macht verdammt viel Spaß, benötigt aber auch etwas Zeit. Je weiter du fortschreitest, destso besser lernst du auch den C64 kennen.^^
    Ich wünsche dir auf jeden fall viel Erfolg bei deinem Projekt.
  • Finde die Vorgehensweise von @Felmar Loyd klingt ganz gut, so in etwa wuerde ich selbst auch vorgehen. Und auch ich wuerde nicht in anderen Quelltexten rumlesen, lieber erstmal "naiv" selbst dransetzen und Stueck fuer Stueck die einzelnen Komponenten entstehen lassen. Ich denke das sollte durchaus schaffbar sein. Und bzgl. Python haette ich jetzt auch nicht unbedingt Bedenken. Einfach mal loslegen :)
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • Felmar Loyd schrieb:

    Der Vice ist ein Top Emulator, aber der Quelltext ist wirklich nicht gerade leicht zu verstehen. Ich würde empfehlen, mit dem Projekt anzufangen, ohne zu viel in anderen Quelltexten abzulesen. Desweiteren die Ziele nicht zu hoch zu stecken, sondern Schritt für Schritt gehen. ^^ So habe ich es damals gehandhabt. Ich wollte, genau wie du, einfach mal wissen, wie mann einen Emulator programmieren könnte.

    Falls es dich interessiert, wie ich da ran gegangen bin:
    Ich habe damit angefangen, den RAM nachzubilden (ein Byte-Array mt 64K) das war natürlich nicht schwer. Dann habe ich einfach Kernal und Basic-Rom in den RAM kopiert. Also ROM-Switching erstmal völlig ignoriert, das habe ich dann erst viel später gemacht. Nach dem der RAM und die Rom's vorhanden war, habe ich angefangen, die CPU zu machen. Angefangen habe ich dabei mit Variablen für die Register, dann habe ich die normalen (nicht die illegalen) Opcodes umgesetzt. Erstmal nur die Funktionen der Opcodes nachgebildet, das mitzählen der Cycels, die jeder Opcode benötigt, habe ich auch erst später hinzugefügt. Dann habe ich den Programmcounter auf den Kernal-Start gesetzt, und in eine Endlosschleife Befel für Befehl abgearbeitet.
    Um zu sehen, ob ich die Opcodes richtig programmiert habe, habe ich bei meinen Emulator einen Befehl ausgeführt, das selbe mit einem anderen fertigen Emulator im Debugger gemacht, und dann die Register und / oder Speicherinhalte der beiden Emulatoren verglichen. Es dauerte zwar etwas, aber so bin ich gut voran gekommen. Als nächstes habe ich eine einfache Grafikausgabe gemacht-. Keine richtige VIC-Emulation, sondern einfach die darzustellenden Zeichen aus dem RAM gelesen, den Char-Rom gelesen, und die Pixel gezeichnet. 25 mal pro Sekunde den aktuellen Bildschirm gezeichnet. Es war zwar simpel, aber für den Anfang OK. Sowas wie Sprites, Badlines, Rasterposition u.s.w. wurde zu dem Zeitpunkt auch erstmal ignoriert. Hauptsache, mann konnte erstmal etwas auf dem Bildschirm sehen. ^^ Naja, und als dann der C64-Startbildschirm kam, war das schon ein verdammt geiles Gefühl. ^^

    Deine Idee, einen Emulator zu machen, ist gut. Das macht verdammt viel Spaß, benötigt aber auch etwas Zeit. Je weiter du fortschreitest, destso besser lernst du auch den C64 kennen.^^
    Ich wünsche dir auf jeden fall viel Erfolg bei deinem Projekt.
    Wow! Das ist wahnsinnig hilfreich! Vielen Dank! Und es klingt so einfach wenn Du es so formulierst :)

    Die Sache ist die: Der Grund warum ich in beireits existierenden Quelltexten rumwühlen wollte ist, daß ich nicht mal eine Vorstellung hatte wie Mann die Sache angehen sollte. Aber deine Bescheibung ist sehr hilfreich! Ich tendiere dazu Sachen zu viel im Voraus planen zu wollen und es dadurch überzukomplizieren. Deine Methode scheint aber viel Sinn zu machen. Der andere Grund weshalb ich Vice (oder andere Emulatoren) studieren wollte ist, weil ich halt nichts über Zyklen und OpCodes usw. weiß. Oh, ich habe natürlich von ihnen gehört und von manchen habe ich sogar eine Vorstellung was sie tun, aber meistens eher nicht. Das ist ja gerade worüber ich lernen wollte. Und ich dachte, daß durch studieren von anderen Emulatoren werde ich da wenigstens einein Überblick bekommen.

    Ich weiß natürlich, daß ich auch die Dokumentation der einzellnen Chips usw. mir ansehen kann und Sachen von denen lernen kann. Was ich aber nicht weiß, da ich nie Komputerarchitektur studiert habe, wie die einzelnen Komponenen ein funktionierendes Ganzes bilden. Hier zum Beispiel wäre ich wieder sehr daran interessiert zu verstehen wie Zyklen funktionieren usw. Ich weiß, Google ist mein Freund... Aber ich habe eben noch nicht mit dem Projekt angefangen, und am scheerigsten ist es zu wissen, was ich alles nicht weiß :) (Und folglich nachlesen muß)
  • Ein kurzer Ausstecher, da vorher VHDL und FPGAs erwehnt wurden:

    Wie ich es schon angedeutet habe, finde ich die Konzept von FPGAs faszinierend. Es würde wahrscheinlich wahnsinnig viel Spaß machen wenn ich es lernen könnte wie Mann zum Bespiel einen Core für den Chameleon entwickel könnte. Leider habe ich mir immer gedacht, daß mir mindestens fünf Jahre fachtechnisches Studium fehlt um zu verstehen wie Mann Mikrosprozessoren und ähnliches entwrift/implementiert, was Timings sind usw. Täusche ich mich da? Kennt jemand gute Kurse, Bücher, Resourcen oder was auch immer aus den Mann es auf autodidaktische Weise selber lernen kann?
  • für die kleine Kaffepause..

    Für eine Einarbeitung in FPGA/HDL brauchst Du mind. 6 Monate, eher 1 Jahr.
    Alleine die Entwicklungsumgebung braucht einiges an Zeit. Entscheide Dich
    also für Emulator oder FPGAs.

    Emulator: Zerlege doch mal ein kleines Prozessorsystem in seine Komponenten.
    In Clock, RAM/ROM, I/O und CPU (Floppy/HD/SD erstmal weglassen). Wie würdest
    Du diese Komponenten beschreiben, wie arbeiten diese zusammen. Wenn Du
    das verstanden hast, dann kannst Du Dich an die Umsetzung in Software machen.
    Setzte dazu erstmal einzelne Komponenten in Software um.
    In Hardware/FPGA ist's einiges anspruchsvoller, ich z.B. bin seit JAHREN in meiner
    Freizeit dran, einen C64 nachzubauen. Habe alle wesentlichen Komponenten
    umgesetzt, werde aber noch zig Jahre reinstecken müssen, nur damit Du mal
    eine Vorstellung von einer Umsetzung hast.
  • Da kommt so oder so kein 'konkurrenzfaehiger' Emulator bei raus.
    Muss ja auch nicht.
    Von Baremetal rate ich Dir stark ab (so cool ich das finde).
    Python ist doch super dafuer. Es gibt fertige 6502 implementierungen.
    Dann musst Du nicht GANZ bei 0 anfangen aber die CPU ist bei jedem Rechner das geringste Problem.
    Wenn Du dann das RAM abbildest, womoeglich mit Ausgabe des ScreenRAMs als erstes (pygame?) dann bist Du schon einen ersten Schritt gegangen.
    Danach dann eben echtes Auslesen aus dem Character ROM und nach und nach die VIC-Register emulieren.
    Vielleicht reicht es anzustreben, dass der Emulator FRAME-exakt wird. Nicht opcode exakt und schon gar nicht cycle exakt.
    Dann koennten $LEUTE sogar hinterher prima damit ihre Routinen testen (soetwas wie das Sprite drehen bei der Compo aktuell zB)
  • Obwohl ich keine FPGA-Erfahrung habe, wuerde ich auch erstmal dazu raten, mit dem Software-Emulator anzufangen. Immerhin sagtest Du ja, Du hast eh keine Ahnung, wie so ein System aufgebaut ist, ich glaube aber, dass genau das essentiell ist, wenn man sich mit FPGA beschaeftigt. Aus diesem Grund wuerde ich erstmal einen Software-Emulator schreiben um das alles zu verstehen. Vielleicht faellt Dir dann in der Zukunft die FPGA-Sache deutlich leichter.
    SHOTGUN - 4-Player Death Match - Website / CSDb / X-Mas
    FROGS - 4-Player Frog Pond - Website / CSDb
  • bjavor schrieb:

    Leider habe ich mir immer gedacht, daß mir mindestens fünf Jahre fachtechnisches Studium fehlt um zu verstehen wie Mann Mikrosprozessoren und ähnliches entwrift/implementiert, was Timings sind usw. Täusche ich mich da?

    Ja, unter 10 Jahren Studium geht da gar nichts. ;)

    Nee, ernsthaft: Eine hilfreiche Grundlage für FPGA-Entwurf ist es, wenn man zumindest die Grundlagen von digitalen Logikschaltungen kennt - denn sowas ist im Prinzip die unterste Ebene eines FPGAs und egal wie man seinen VHDL-/Verilog-Code schreibt, das Synthesetool konvertiert den Code dahin. Es ist aber eine vollständig andere "Baustelle" als ein Software-Emulator, mit deutlich anderer Herangehensweise.

    Wenn es speziell um einen Prozessor geht, hilft natürlich das Wissen um den grundlegenden Aufbau eines solchen sehr - zB die einzelnen Phasen, in die man die Abarbeitung eines einzelnen Befehls aufteilen kann. Kenntnisse von Assembler von mindestens einer CPU-Architektur sollte vor so einem Projekt auch vorhanden sein, sonst hat man ja keine Ahnung was man da überhaupt bauen will.

    Kennt jemand gute Kurse, Bücher, Resourcen oder was auch immer aus den Mann es auf autodidaktische Weise selber lernen kann?

    Einführungen in FPGA-Design wüsste ich gerade nicht so richtig viele - bei Büchern über VHDL oder Verilog muss man immer etwas darauf achten, ob die Synthese oder Modellierung/Simulation als Schwerpunkt haben, da nicht alle simulierbaren Sprachkonstrukte synthetisierbar sind. Wenn das Buch nicht spezifisch auf die Entwicklungsumgebung eines Herstellers eingeht lohnt sich natürlich zusätzlich der Blick in deren Doku und Tutorials, um den Umgang mit den gewählten Werkzeugen zu erlernen.

    Ein paar Dinge, über die ich gelegentlich positives gehört habe (auch wenn ich keines davon selbst gelesen habe):
    • FPGAs! Now What? - auf Synthese für Xilinx-Chips und eine spezifische Platine ausgerichtet, aber evtl. trotzdem interessant. Verwendet leider std_logic_unsigned, was heutzutage verpönt ist
    • Peter Ashenden, The Designer's Guide to VHDL - Umfangreiche Einführung in VHDL, geht aber davon aus, dass man Erfahrung im Digital-Logik-Bereich hat. Ursprünglich mit Schwerpunkt auf Modellierung geschrieben, aber meines Wissens inzwischen auch mit Würdigung der Synthese und ihrer Einschränkungen aktualisiert
    • Hennessy & Patterson, Computer Architecture: A Quantitative Approach - gilt als ein Standardwerk im Bereich der Computerarchitektur, auch wenn ich ein paar Leute kenne, die es nicht mögen und "irgendwann" mal was besseres schreiben wollen =)


    Wenn man mit einer oft eher theoretischen Herangehensweise kein Problem hat, kann sich auch eine Suche im Web nach Vorlesungsmaterial über diese Themenbereiche (Hardwaresynthese, Rechnerarchitektur) lohnen.

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • Lern gerade verilog und bastle an z80 Kram. Eines der größten Probleme ist, dass es C so ähnlich sieht, aber halt nicht seriell ausgeführt wird.

    Aber man kann es sich schon allein beibringen. Vorher bisserl mit Arduino spielen schadet aber nicht.
    Hier könnte ihre Signatur stehen!