Hello, Guest the thread was called4.4k times and contains 136 replays

last post from ZeHa at the

Unterschiede zwischen Emulator (Software) und FPGA (Hardware) bei Nachbildung von Systemen --> Vor- und Nachteile

  • Der Nachteil davon ist allerdings, dass es extrem langsam ist, durchaus auch mal im Bereich von Stunden pro Millisekunde oder Mikrosekunde, wenn man den kompletten FPGA-Inhalt simuliert und nicht nur das interessante Stück.

    Im Alter wird man geduldiger. Lass uns noch paar Jahre warten und dann nochmal übers Thema "Geschwindigkeit" reden. Schneller werden die PC "von alleine". :)

  • Spätestens wenn es darum geht, die Daten vom emulierten Videochip auf einen geeigneten Monitor (=Röhre) auszugeben, ist eine FPGA Implementierung klar im Vorteil. Nur in FPGA kann man eine Verzögerung vollständig eliminieren.

    Aber diese Verzögerung (die übrigens bei modernen Spielen genauso vorhanden ist und da stört das irgendwie kaum jemanden...) liegt doch hauptsächlich am Overhead des Betriebssystems. Das ist ja nichts, was der Softwareemulation per Definition innewohnt. Wenn ich meinen Chip schnell genug emulieren kann und direkten Zugriff auf die Videohardware habe (z.B. unter DOS/VGA), dann ist das zwar nicht dasselbe wie mit einem FPGA, sollte aber vom Ergebnis her nicht unterscheidbar sein. Aber natürlich ist das nur theoretisches Gebrabbel...die Situation haben wir so ja nicht.

  • Mal abgesehen von den "Glaubensfragen" - Eine Emulator wie z.B. Vice ist kostenlos und praktisch weil ich ihn an meinem Rechner wie alles andere benutzen kann. Ein U64 kostet Geld, bringt aber dadurch das er in einem originalen Gehäuse ist die Retro Haptik rüber. Und du kannst alte original Hardware anschließen.

    Mein Tipp: nimm einem Emulator und wenn du wie viele hier (ich auch) zum Freak wirst, dann kannst immer noch nen U64 kaufen.

  • Genau das meinte ich. Daher ja auch gefuehlter Unterschied.

    Naja, was gefühlte Echtheit angeht, tickt wohl jeder anders. Im U64 kann ich auch die Busse zwischen CPU, CIAs, VIC, SID usw. nicht mehr sehen oder gar durchmessen. Das entfinde ich nicht als echter oder falscher als eine Variable oder ein Array in einem Emulator.

  • Genau das meinte ich. Daher ja auch gefuehlter Unterschied.

    Naja, was gefühlte Echtheit angeht, tickt wohl jeder anders. Im U64 kann ich auch die Busse zwischen CPU, CIAs, VIC, SID usw. nicht mehr sehen oder gar durchmessen. Das entfinde ich nicht als echter oder falscher als eine Variable oder ein Array in einem Emulator.

    Kritisch wird es erst, wenn man solange am Emulator bzw. FPGA dran war, dass sich ein realer C64 plötzlich "unecht" anfühlt. :)

  • Ich hab jetzt nur kurz drübergeschaut, aber es wurde anscheinend noch gar nicht erwähnt, dass FPGA-basierte Emulatoren wenigstens prinzipiell timingkritische Original-Hardware (Floppy, Steckmodule) "ganz normal" unterstützen können (Floppy anschließen, fertig).


    Software-Emulatoren müssen da passen, können aber natürlich auch ggf. diese Hardware komplett in Software emulieren, wobei das Handling und die Möglichkeiten aber natürlich andere sind. Diskette "in echt" bekommen, in PC einlegen und in VICE "LOAD" tippen ist halt nicht.

  • Software-Emulatoren müssen da passen,

    Nein, müssen sie nicht. Ich kann auch in Software einen Bus ansprechen, an dem ein Altgerät hängt. Natürlich muss ich irgendeine physische Lösung zum Anschluss schaffen. Aber das muss ich beim FPGA auch. Ich kann mit Vice z.B. eine echte 1541 ansprechen, wenn sie an einem X1541 oder XU1541 hängt. Wie gut das läuft, das weiß ich nicht aus eigener Erfahrung. Aber es gibt zumindest keinen technischen Grund, wieso das bei einem Emulator nicht gehen sollte. Mit einem Orignal-PC-Laufwerk geht es nicht, weil die das 1541-Format so nicht lesen/schreiben können.

  • Ich kann auch in Software einen Bus ansprechen, an dem ein Altgerät hängt.

    Du hast dan aber viel grössere Probleme, das Original-Timing einzuhalten. Normale Software-Emulatoren machen das nur bei recht grober Betrachtung, d.h. typischerweise auf Frame-Level. Um Originalhardware mit Originaltiming anzusprechen, muss das Timing in der Gegend von Mikrosekunden eingehalten werden.


    Ich kann mit Vice z.B. eine echte 1541 ansprechen, wenn sie an einem X1541 oder XU1541 hängt. Wie gut das läuft, das weiß ich nicht aus eigener Erfahrung.

    Die Implementierung in VICE ist technisch betrachtet eine oberflächlich emulierte 1541, die Kommandos an das Originallaufwerk durchreicht. Damit funktioniert kein Fastloader.

  • Du hast dan aber viel grössere Probleme, das Original-Timing einzuhalten. Normale Software-Emulatoren machen das nur bei recht grober Betrachtung, d.h. typischerweise auf Frame-Level. Um Originalhardware mit Originaltiming anzusprechen, muss das Timing in der Gegend von Mikrosekunden eingehalten werden.

    Das ist mir schon bewusst. Hier ging es ja aber initial mal um die Frage, was die Unterschiede zwischen FPGA- und Softemulation sind. Und nicht um eine konkrete Implementierung (muss ja nicht einmal C64-spezifisch sein, wir könnten auch über DOSBox reden). Und da kann einfach nicht sagen, dass Software-Emulation keine Orginalhardware ansprechen kann. Das mag im Einzelfall sicher so sein, aber es ist keine generelle Regel, dass Software bei sowas passen muss. Auf Basis der Implementierung könnte ich sonst auch sagen, FPGA kann keine Savestates...weil das U64 das nicht kann. Der Spektrum Next kann es aber z.B.

  • Naja ist ja gut dass drueber diskutiert wird. Prinzipiell kann Software-Emulation das also auch, exakter und vielleicht auch einfacher ist es wohl bei FPGA. In der Theorie kann Software natuerlich exakt das gleiche - die Prozessoren muessen nur schnell genug sein und genuegend Cores haben. Ungefaehr so, wie "digital" in der Theorie auch alles kann was "analog" kann. In der Praxis gibt es aber Huerden, und diese hier zu erwaehnen, das ist denke ich im Sinne des Threads bzw. der Ur-Frage.

  • Naja ist ja gut dass drueber diskutiert wird. Prinzipiell kann Software-Emulation das also auch, exakter und vielleicht auch einfacher ist es wohl bei FPGA. In der Theorie kann Software natuerlich exakt das gleiche - die Prozessoren muessen nur schnell genug sein und genuegend Cores haben.

    Genau. Mehr wollte ich eigentlich gar nicht sagen...;)

  • Wie schaut's denn mit der Emulation des Hardware-Expansionsports aus, EgonOlsen? Gibt es *irgendeinen* Software-Emulator, der selbst mit Extra-Hardware den C64-Expansionsport tatsächlich emulieren kann? Nein. Da braucht man Latenzen im Sub-Mikrosekundenbereich, und das bringt nunmal kein PC mit normalem Betriebssystem. Mit FPGAs wiederum ist das kein Problem, sie sind quasi dafür gebaut.


    Wie das evtl. in 10 Jahren und mit absurdem Hardware-/Softwareaufwand aussieht, ist vermutlich in diesem Thread kein Thema. Klar könnte man ggf. auf einem 20GHz-PC mit einem latenzarmen Betriebssystem (DOS...) ggf. was in der Richtung machen.

  • Wie schaut's denn mit der Emulation des Hardware-Expansionsports aus, EgonOlsen? Gibt es *irgendeinen* Software-Emulator, der selbst mit Extra-Hardware den C64-Expansionsport tatsächlich emulieren kann? Nein. Da braucht man Latenzen im Sub-Mikrosekundenbereich, und das bringt nunmal kein PC mit normalem Betriebssystem. Mit FPGAs wiederum ist das kein Problem, sie sind quasi dafür gebaut.

    Das stimmt im konkreten Fall sicherlich. Da bräuchtest du vermutlich min. eine Zusatzhardware, wenn ein Emulator damit sprechen soll (die es aktuell nicht gibt und vermutlich auch nie geben wird). Das kann auch ein FPGA sein. Oder du müsstest einen extra Rechner bauen, auf dem dann dein Emulator läuft. Klar, das ist alles theoretisch und hilft hier vermutlich nicht viel weiter. Ich diskutiere trotzdem gerne mal drüber.

  • Gibt es *irgendeinen* Software-Emulator, der selbst mit Extra-Hardware den C64-Expansionsport tatsächlich emulieren kann?

    Der Einsatzbereich, dass echte Hardware auf einem Nachbau (Emulator oder FPGA) genutzt wird, dürfte eher überschaubar sein.


    Da ist es eher noch wahrscheinlich, dass die entsprechende Hardware gleich mitsimuliert wird.

  • @EgonOlsen der Spaß mit "Interface-Hardware" ist, dass sie Timingprobleme nicht wegzaubern kann. Nehmen wir an, Du hast ein Steckmodul, dass nach einem Schreibzugriff (das kann auf C64-Seite ein simples STA sein) für drei Mikrosekunden an einer bestimmten Speicherstelle eine Antwort verfügbar macht (und nicht länger). Im Emulator auf dem PC wird das STA ausgeführt und das Signal über irgendeine Interface-Hardware an das Steckmodul gelegt. Das Steckmodul hält jetzt für 3µS das Ergebnis vor. Der Emulator ist gerade preempted, weil der MP3-Player ein paar Zyklen will, und läuft erst nach 100µS wieder weiter. In dem Moment ist das Ergebnis des Steckmoduls schon nicht mehr verfügbar, egal, was der Emulator macht. Selbst "intelligente" Interface-Hardware hilft da nichts, es sei denn, sie bringt spezielles Wissen über das angesteckte Modul mit ("nach diesem einen speziellen STA muss das-und-das Register gesichert werden") - de facto müsste die Interface-Hardware also einen Teil der C64-Software mit striktem Timing emulieren bzw. nachbauen (genau das ist das, was z.B. sd2iec macht). Das ist dann aber nicht mehr generisch, sondern die Interface-Hardware bräuchte auf die jeweiligen Module zugeschnittene Firmware (so wie sd2iec für jeden neu unterstützten Fastloader neue Firmware braucht). Will man das Problem lösen, hat man am Schluss einen FPGA in der Interface-Hardware, der die komplette Emulation des C64 macht und den PC nur noch als Monitor/Tastatur benutzt. (wobei eventuell auch mehrere Mikrocontroller statt einem FPGA funktionieren könnten; es gibt Sachen wie Pi1541, eventuell ginge auch sowas wie Pi6510. Ist halt irrer Aufwand gegenüber einem FPGA.).

  • Das mag im Einzelfall sicher so sein, aber es ist keine generelle Regel, dass Software bei sowas passen muss

    Wenn das stur von der "es ist aber theoretisch möglich"-Seite beleuchtet wird können wir uns die Diskussion aber auch komplett sparen, weil Software und Hardware die gleiche Klasse von Problemen berechnen können und daher weder ein FPGA noch ein Software-Emulator einen Vorsprung hat.


    Klar könnte man ggf. auf einem 20GHz-PC mit einem latenzarmen Betriebssystem (DOS...) ggf. was in der Richtung machen.

    Protip: Lass die Caches weg und verwende lieber kleine und schnelle RAMs, deren Inhalt stets vorhersagbar ist um den Beweis der Einhaltung der Echtzeit-Bedingungen zu vereinfachen ;)


    Der Einsatzbereich, dass echte Hardware auf einem Nachbau (Emulator oder FPGA) genutzt wird, dürfte eher überschaubar sein.

    Im MiSTer-Dunstkreis wird das zumindest mit Controllern gerne gemacht, weil die direkte Abfrage davon weniger Latenz hat als die erst via USB zu tunneln - insbesondere bei komischen Lösungen wie dem 6-Button-Megadrive-Pad, welches vom Protokoll her schon darauf ausgelegt ist, nur einmal pro Frame abgefragt zu werden.


    Selbst "intelligente" Interface-Hardware hilft da nichts, es sei denn, sie bringt spezielles Wissen über das angesteckte Modul mit

    Da geht schon etwas mehr mit einem generischen "Echtzeit-Hardware-Interface" - es bricht aber an der Stelle zusammen, wo die Zugriffe auf die externe Hardware nicht mehr weit genug vorberechenbar sind, um die maximale Verzögerung der Software-Emulation zu verbergen. Das kann zB passieren, wenn Code direkt aus einer extern angeschlossenen Hardware ausgeführt wird oder allgemeiner der Kontrollfluss der emulierten Software zu stark von den externen Daten abhängt, um alle möglichen Pfade vorab weit genug durchzurechnen.


    (oh, und Interrupts sind... potentiell schwierig, wenn sie zyklenexakt sein sollen)

  • Gefällt mir die Diskussion. Wie bei einer Erörterung, von welcher Route man einen Gipfel erreicht. Klar, geht von der einen wie auch von der anderen Seite. Es ist aber immer auch die Frage, mit welchem Aufwand dies geht.

    Der FPGA-Ansatz lebt eben davon, dass das Realzeitverhalten die Vorgabe ist. Von der anderen Seite kommend die Emulation in Software, die aber inhärent damit zu kämpfen hat, seine Funktion mit der Realzeit zu synchronisieren.

    Wir sind uns also einig, dass

    1. der Gipfel von unterschiedlichen Seiten auf unterschiedlichem Weg erreicht werden kann,
    2. die Wege den Gipfel zu erreichen unterschiedliche Eigenschaften aufweisen.

    Diese beiden Dinge kann man jeweils für sich diskutieren, aber mit dem einen das jeweils andere zu begründen oder in Frage zu stellen, passt irgendwie nicht. ;)

  • Ich kann nur sagen: FPGA fühlt sich viel besser an als Emulatoren.

    C64, Amiga, ST, NES, SNES und auch viele Arcades... Ein Traum auf meinem MiSTer.

    Habe lange gesucht und hier ne PS4 mit Hack stehen, weil ich immer hoffte, dass da Homebrew bzw Mame und andere Emus mal drauf laufen...

    Brauch ich alles nicht mehr.

    Es hat alles seine Daseinsberechtigung, aber für mich ist FPGA vom Feeling her einfach viel schöner und "näher dran" :)

    Kann man aber hier nicht ausdiskutieren, das muss man ausprobieren...

  • FRauANtje stimmt, fühlt sich iwie besser an, finde ich auch.


    Habe mal n ganz interessanten Artikel gelesen (weiss leider nicht mehr, welche Seite), da wurde dem "FPGA-ist-besser" etwas der Wind aus den

    Segeln genommen - da ich selbst mit Begsisterung U64 und MiSter nutze, dachte ich mir mit Skepsis 'ach, wieder son fpga-ist-übertrieben-bericht'.

    Tatsächlich wurde da aber ganz sachlich und fair über Vor-und Nachteile beider Seiten gesprochen,

    die mir als "non-coder" weitestgehend gut verständlich und nachvollziehbar erschienen. In meinen Worten würde ich es ungefähr so zusammenfassen:

    Es ist nicht automatisch FPGA besser, was die akkurate Nachbildung angeht, da gibt es auf beiden Seiten Gutes und weniger Gutes,

    und es kommt schlichtweg auf die Programmierung an.

    Der direkte Vorteil eines FPGA ist wohl die Ein- und Ausgabe, die quasi verzögerungsfrei geschieht, wie bei den echten Geräten.

    Was bleibt, wäre dann der Vergleich Software Emulation <-> FPGA core, halt in Bezug auf Genauigkeit.


    Persönlich würde ich immer die FPGA-Variante bevorzugen - wenn's was f. C64 zum spielen oder testen gibt -> Ultimate 64.

    Konsolenspiele (bis zu ner bestimmten Generation) deckt der MiSTer recht gut ab, und es wird immer besser und mehr..WOW! :D