geschlossen . Diese Frage ist meinungsbasiert . Derzeit werden keine Antworten akzeptiert.

Kommentare

  • Ist ' nicht einfach nach Meinungen zu fragen? Schließlich sind alle Möglichkeiten in Bezug auf das, was sie als Benutzererfahrung hervorbringen können, im Wesentlichen gleich.
  • Dazu müssen Sie definieren, was Sie als technischen Grund betrachten. Es gibt keine Antwort ohne eine klare Definition, was gefragt wird.
  • @Raffzahn Auszug aus einer anderen Antwort: " Die Softwareemulation funktioniert möglicherweise recht gut, ist jedoch auf beschränkt Schnittstelle zur Hardware, über die der Emulator-Designer Bescheid weiß. Eine gute FPGA-basierte Wiederherstellung kann mit fast jeder Art von Vintage-Hardware verbunden werden, einschließlich Geräten, von denen der FPGA-Designer nichts weiß, und bietet gleichzeitig eine bessere Zuverlässigkeit als Vintage-Hardware. " Dies ist ein gutes Beispiel aus technischen Gründen. Ich glaube nicht, dass " technischer Grund " nicht spezifiziert ist. Es ist alles, was objektiv wahr ist, und nicht die eigenen Wahrnehmungen der Realität von ', die als " Meinungen .
  • Außer, dass ' kein technischer Grund, sondern ein impliziter Anwendungsfall ist, hier andere ' Hardware. Da dies immer ein Update erfordert (auch mit der realen Hardware, ist ' kein emulationsspezifisches Problem.
  • @Raffzahn: Bei Verwendung eines FPGA-Geräts Damit das ursprüngliche Verhalten auf Hardwareebene genau nachgebildet werden kann, ist kein Update erforderlich, um mit Hardware zu arbeiten, von der der FPGA-Programmierer nichts weiß.

Antwort

Ein Vorteil, den FPGA-Emulatoren im Allgemeinen mit Vintage-Hardware teilen, ist die Möglichkeit, Geräte zu verwenden, die auf sehr zeitabhängige Weise mit der Hardware interagieren. Wenn beispielsweise eine Spielekassette für das NES vorhanden ist Dies löst jedes Mal eine Unterbrechung aus, wenn die erste Datenzeile für ein bestimmtes Sprite abgerufen wird. Eine Konsole, die den Inhalt einer Kassette vorliest und dann emuliert, kann das Spiel nur dann korrekt spielen, wenn sie erkennt, was die Kassette ist Dies geschah mit der Interrupt-Leitung.

FPGA-basierte Hardware würde im Allgemeinen genauso gut funktionieren, wenn nicht sogar mehr zuverlässig als Vintage-Hardware, aber es gibt ein paar seltsame Macken zu beachten. Einige Prototyp-Erweiterungskassetten für den Atari 2600 stützten sich beispielsweise auf die Tatsache, dass das NMOS 6502, selbst wenn es versucht, den Datenbus hochzuziehen, nicht in der Lage ist, ein externes Gerät, das dies versucht, entweder zu überwältigen Ziehen Sie die Leine nach unten und beschädigen Sie sich beim Versuch nicht. Beachten Sie, dass das Gegenteil nicht der Fall ist: Ein NMOS-Gerät, das versucht, eine Leitung nach unten zu ziehen, während ein externes Gerät sie nach oben zieht, kann sich bei dem Versuch selbst beschädigen (RIP 2600jr). Wenn man ein NMOS-Gerät an ein modernes Erholungssystem anschließen würde, das auf der Fähigkeit beruht, Busdrähte zu übersteuern, und das System den High-Side-Ansteuerstrom an diesen Drähten nicht begrenzt, könnte es das externe Gerät beschädigen. Ich weiß nicht, inwieweit dies tatsächlich ein Problem wäre, aber da Geräte, die auf solchen Techniken basieren, wahrscheinlich selten sind, wäre es sehr bedauerlich, wenn sie beschädigt würden.

Ein weiteres potenzielles Problem ist, dass es sich um Vintage-Elektronik handelt Oft reagiert es nur langsam auf Signale. Wenn ein Gerät ein Signal sehr kurz auf einem Kabel ausgibt, wird es wahrscheinlich ignoriert. Einige alte Elektronikgeräte gaben manchmal kurze Störimpulse aus, wenn sich eine Kombination von Eingängen zwischen einem Zustand, in dem der Ausgang niedrig sein sollte, und einem anderen Zustand, in dem der Ausgang niedrig sein sollte, änderte. Wenn eine FPGA-Neuerstellung nicht darauf ausgelegt ist, solche Impulse zu ignorieren, können sie zu fehlerhaften Vorgängen auf der neu erstellten Hardware führen, obwohl sie auf dem Original keine Probleme verursacht hätten.

Persönlich denke ich, dass FPGAs der beste Weg sind Vintage-Hardware ist cool, aber Zuverlässigkeit ist oft problematisch. Software-Emulation funktioniert zwar recht gut, beschränkt sich jedoch auf die Schnittstelle mit Hardware, die der Emulator-Designer kennt. Eine gute FPGA-basierte Wiederherstellung kann mit fast jeder Art von Vintage-Hardware verbunden werden Hardware, einschließlich Geräte, von denen der FPGA-Designer nichts weiß , und bietet gleichzeitig eine bessere Zuverlässigkeit als herkömmliche Hardware.

Antwort

Vorwort: Die Frage scheint nach Meinungen zu fragen, da es sich um eine Meinung handelt, wenn jemand eine Emulation akzeptiert. Egal, ob Software auf einer CPU oder auf einem FPGA, genau wie das Original oder nicht.


Fragen Sie sich, ob Sie ein Auto mit moderner Technologie fahren, das aufgemotzt ist wie ein SSK das gleiche wie das Fahren der realen Sache? Möchten Sie einen BMW aus den 1950er Jahren mit all seinen Geräuschen, Gerüchen und Vibrationen (und all den Bastelarbeiten, die erforderlich sind, um ihn am Laufen zu halten) oder ein 2020-Elektrofahrrad fahren, das wie eines aussieht und Ihnen den klassischen Sound eines eingebauten iPod bietet? ?


Ich bin gespannt, was die Unterschiede zwischen der Verwendung einer echten Hardware, FPGA-basierten Hardware-Emulatoren wie MiSTer und der großen Menge an Software sind Emulatoren für verschiedene Systeme, die auf modernen Windows-, MacOS- und Linux-Computern ausgeführt werden.

Wenn Sie nur ein Benutzer sind, der von der Verwendung Ihrer modernen Tastatur und modernen Maus überzeugt ist Wenn Sie ein Bild auf Ihrem 4k-Bildschirm verarbeiten, das wie 640 x 400 aussieht, ist Software alles, was Sie brauchen. Bereits eine FPGA-Version ist übertrieben, da sie dieselben modernen Geräte verwendet.

Auf der anderen Seite Wenn die Bildgebung nicht ausreicht, Sie aber die sperrige Atari-Maus, die wackelige Amiga-Tastatur oder den sperrigen C64-Joystick spüren möchten, die alle mit echter CRT-Blendung versehen sind, gibt es keinen anderen Weg

Eine Sache, die mir in den Sinn kam, war, dass sowohl Software- als auch Hardware-Emulatoren nicht präzise genug sein konnten

Inzwischen sind sie es. in jedem Detail. Moderne Hardware ist schnell genug, um die Verwendung von HLL-Software zu ermöglichen, um das genaue Timing des Zyklus zu ermitteln. Vor allem, wenn All-In und Output sowieso emuliert und modernen Geräten zugeordnet werden.

Dies scheint mir jedoch etwas zu sein, das von der Qualität der Implementierung abhängt, die dies kann variieren zwischen verschiedenen Emulatoren und verbessern sich im Laufe der Zeit aufgrund von Fehlerbehebungen, jedoch nicht als grundlegendes Problem.

Eine verzögerte Programmierung und Wartung macht den Ansatz nicht ungültig. Für alle Zwecke, außer für echte Hardware, gibt es keinen Unterschied.

Auch ich höre von dem Latenzproblem mit den Software-Emulatoren, aber ich „Ich bin wenig überrascht, dass so etwas wirklich auf einem Computer zu spüren ist, der wahrscheinlich millionenfach schneller ist als die emulierte Maschine.

Vielleicht hundertmal, Wenn überhaupt. Denken Sie daran, dass die meisten Hauptkomponenten nicht so viel schneller geworden sind – und das meiste davon wurde von größeren Geräten und Datenanforderungen aufgefressen.

Das Problem der Latenz ist etwas, das gibt es seit wie immer. Es wird immer einige geben, die sagen, dass sie den Unterschied sehen / fühlen können. Während dies in einigen, sehr engagierten Situationen der Fall sein mag, ist es meistens Müll. Zu behaupten, ein paar Mikrosekunden zu fühlen, wenn ein Joystick bereits mehr kostet, ist einfach Fantasie.

Gibt es wirklich einen technischen Grund, echte Hardware- oder FPGA-basierte Emulation gegenüber Software-Emulation zu bevorzugen?

Was ist ein technischer Grund? an sich ist der Begriff an sich nicht klar, wenn man vollständig verschiedene Implementierungen vergleicht.

oder dies ist nur eine Nostalgiesache, die durch den Wunsch verursacht wird, sich wie Sie zu füllen Sind Sie wirklich zurück in den 80ern oder 90ern?

Haben Sie jemals vor einer der alten Maschinen gesessen? Es ist überraschend, wie Unterschiedliche Tastaturen fühlen sich beim Verlassen der heutigen standardisierten Geräte an.


Und dann gibt es natürlich das Hardware-Basteln – kein wirklicher Spaß mit Emulatoren, da hier das Hinzufügen einer Schnittstelle nur ein paar Zeilen hinzufügt Code – oder einfach nur konfigurieren in einigen Fällen auf. Kein Layout, kein Ätzen, kein Löten und vor allem kein Fluchen und Patchen, bis es funktioniert.

Antwort

Ich möchte Klären Sie den in der Frage erwähnten Begriff „FPGA-Emulation“.

Zunächst gibt es natürlich eine Software-Emulation. Nehmen wir als Beispiel einige (mehr oder weniger) exakte Software-Emulatoren der 6502-CPU . Sie versuchen, alle externen Artefakte der realen CPU zu emulieren, z. B. die Anzahl der Zyklen pro Befehl, die Adressen der Speicherzugriffe und sogar den „internen Status“ (eher nur den Status der für Software sichtbaren Register). Es hat jedoch nichts Vergleichbares mit der realen CPU, beginnend mit dem Punkt, dass es sich um reine Softwarematerie handelt, nicht um Hardwaregeräte.

Wenn eine neue Funktion des echten 6502 entdeckt wird (wie neue undokumentierte Opcodes oder Flags oder Ausführungsdetails) ) wird es wie „eine weitere zu implementierende Funktion“ in den Software-Emulator eingefügt. Keine Funktionen der realen Sache würden im Software-Emulator emegre, wenn sie dem Implementierer unbekannt sind.

Schauen wir uns dann 6502-kompatible HDL-Kerne an.Sie stellen nun tatsächlich ein echtes digitales Logikgerät dar – oder ein Modell davon (falls die HDL simuliert wird, nicht in der realen Hardware wie FPGA oder ASIC implementiert). Sie haben jetzt einen echten Flipflop- (oder Latch-) Speicher für die CPU-Register, sie könnten echte CPU-Bussignale implementieren und sogar anstelle des ursprünglichen 6502 in den Retro-Computer eingefügt werden. Dennoch werden sie (mehr oder weniger) „von Grund auf neu“ hergestellt. mit den Spezifikationen der CPU sollen sie ersetzen, nicht deren interne Struktur. Und dennoch würden ihnen Funktionen fehlen, die in diesen Spezifikationen nicht beschrieben sind, die in einer echten Retro-CPU vorhanden sind, dem Implementierer jedoch noch unbekannt sind.

Eine weitere Ebene der Rekonstruktion könnte das HDL-Design sein, das auf folgende Weise erstellt wurde:

  1. echte Retro-CPU wird entkappt und fotografiert
  2. , dann werden Schaltpläne auf Netzlisten- und Transistorebene neu erstellt (entweder von Hand oder mit einigen mehr oder weniger automatisierten Werkzeugen)
  3. Die Netzliste wird in die Schaltpläne auf Gate-Ebene und dann in die HDL-Beschreibung konvertiert, die wiederum in FPGA oder ASIC implementiert ist.

Im Gegensatz zu früheren Fällen sind jetzt fast alle Funktionen der realen CPU vorhanden „nativ“ implementiert werden, weil die Struktur der resultierenden HDL mehr oder weniger der Struktur der realen Sache entspricht (auf der Ebene von Logikgattern und Flipflops).

Dennoch könnte es Probleme geben, zum Beispiel 6502 hat einige Anweisungen, die sich unregelmäßig verhalten, und ich habe das Gefühl, dass ein solches Verhalten in HDL nicht auf natürliche Weise auftreten würde.

Im Allgemeinen denke ich Alles über dem „Reverse Engineering, dann HDL neu erstellen“ ist tatsächlich eine Emulation , entweder in Software oder Hardware, während der letztere Weg nicht ist.

Mit anderen Worten, betrachten wir die Erhaltung der alten Software. Wir könnten es auf moderner Hardware ausführen, aber wenn es nicht verfügbar ist, kommen Software-Emulatoren ins Spiel, aber das alte Software-Teil, mit dem sie ausgeführt werden, ist immer noch genau das gleiche.

Jetzt möchten wir Beibehaltung der alten Hardware (CPU), aber die authentische Implementierung ist nicht verfügbar. Daher erstellen wir sie mit neuerer Technologie neu, aber die logische Struktur der CPU bleibt genau gleich.

Antwort

Um nur als Emulatorautor eine Antwort auf die Latenzfrage zu geben:

Ausnahmen gibt es zuhauf, aber die allgemeine Regel für Originalhardware der 80er Jahre und später In den frühen 90er Jahren können Änderungen an Joypad- und Tastatureingaben von der Hardware fast unmittelbar nach ihrem Auftreten erkannt werden, und wenn Video und Audio von der Maschine ausgegeben werden, erreichen sie den Benutzer fast sofort – z. B. bei einem klassischen CRT-Fernseher den Pegel des Rasters Das Malen im Moment ist fast die Live-Ausgabe der Maschine.

Mit Hardware wird die Eingabe jetzt im Allgemeinen durchlaufen Es handelt sich um einen Bluetooth- oder USB-Stack, der möglicherweise nur in einem bestimmten Intervall vom Host-Betriebssystem überprüft wird. Wenn etwas passiert ist, teilt er dies dem interessierten Prozess mit, der je nach Planer möglicherweise sofort erfolgt oder nicht.

Viele Emulatoren implementieren auch eine Hauptschleife, die so aussieht, wie Sie ein Spiel entwerfen könnten:

  1. sammelt alle neuesten Eingaben und leitet sie an die emulierte Maschine weiter;
  2. Führen Sie die Maschine für einen Frame aus;
  3. malen Sie den nächsten Frame der Ausgabe in einen unsichtbaren Puffer;
  4. stellen Sie ihn in die Warteschlange, damit er beim nächsten vsync und Block angezeigt wird.
  5. li> wiederholen.

Stellen Sie sich aus Gründen der Argumentation vor, Ihre moderne Maschine ist sehr schnell und die Schritte 2 und 3 erfolgen sofort. Dann:

  • gibt es durchschnittlich einen halben Frame Eingangslatenz plus alle Bluetooth / USB-Signale und das hinzugefügte Betriebssystem – Eingaben, die unmittelbar nach dem Anfang eines Frames erfolgen, werden nicht weitergeleitet Bis zum Beginn des nächsten wird alles, was direkt am Ende auftritt, fast zum richtigen Zeitpunkt mitgeteilt, und der Bereich der dazwischen liegenden Latenzen ist linear, sodass der Durchschnitt auf halbem Weg dazwischen liegt. und
  • gibt es einen festen zusätzlichen Frame für die Ausgabelatenz, da Sie einen Frame für die Präsentation beim nächsten vsync veröffentlichen und dann warten, bis es Zeit ist, angezeigt zu werden.

Bei dieser einfachen Schleife beträgt die Verzögerung zwischen dem Drücken von etwas und der Reaktion des Bildschirms bei idealer Hardware im Durchschnitt etwa 1,5 Frames mehr als bei echter Hardware. Dies gilt nur, wenn Host- und emulierte Computer mit derselben Framerate ausgeführt werden

Puristen argumentieren, dass einige Originalspiele nach der angemessenen Anzahl von Teststunden und Optimierungen am Tag so fein abgestimmt sind, dass 1,5 Frames sie benachteiligen, die sie erkennen können.

FPGAs sind normalerweise * Emulationen, unabhängig davon, wie sie „verkauft“ werden, da sie normalerweise eine Person sind, die eine Spezifikation in einer Hardwarebeschreibungssprache auf hoher Ebene neu implementiert. Sie versuchen jedoch, so viel von dieser Latenz wie möglich wegzulassen – bei guter Qualität wird die Videopufferung vollständig weggelassen, der Rest des Systems in Echtzeit ausgeführt und die Eingabe mit minimaler Verzögerung eingegeben.

* Qualifizierung hinzugefügt gemäß der Korrektur von @lvd unten. Siehe seine Antwort für mehr Farbe.

Natürlich ist es nicht schwer, die meisten Softwareprobleme in der Software zu beheben:

  • Eingaben häufiger weiterleiten;
  • nicht Verwenden Sie vsync, um eine neue Ausgabe für vsync auszulösen. und
  • verwenden Sie keinen doppelten Puffer.

Im Extremfall können Sie das Raster sogar auf eine ähnliche Ausgabelatenz wie ein FPGA einstellen – wenn Sie bereits einen hohen Wert haben -Frequenzschleife für häufige Eingaben, und wenn die Basishardware irgendeine Ausgabe unterstützt, die zu Bildschirmrissen führen kann, dann haben Sie die Werkzeuge.

Leider wurden solche Ansätze normalerweise nicht von Emulatoren in der Vergangenheit, insbesondere bevor die Latenz zu einem so viel diskutierten Thema wurde und ein negatives Bild hängen geblieben ist.

Kommentare

  • FPGA ist nicht immer ein Emulation, zumindest in Ihren Begriffen " eine Person, die eine Spezifikation in einer Hardwarebeschreibungssprache auf hoher Ebene erneut implementiert "
  • annst du genauer sagen, um die Antwort zu verbessern? Ich ' kenne ein Experiment, bei dem eine von VisualChips aus einem Real extrahierte Netzliste verwendet wurde (wenn Speicher dient) ) TIA, aber wenig darüber hinaus. EDIT: nein, Warten Sie, ich sehe Sie ' haben eine separate Antwort gepostet. Danke!

Antwort

Viele Aspekte von HW vs SW wurden hier in anderen Beiträgen behandelt, also werde ich es tun nicht berühren. Stattdessen möchte ich das Problem LATENCY aus meiner Sicht zusammen mit den Erfahrungen erläutern, die ich beim Codieren meiner Emulatoren für verschiedene Plattformen gesammelt habe …

Das Erstellen eines SW-Emulators auf modernen Computern ist unter Latenzgesichtspunkten viel schwieriger als in den direkten E / A-Zugriffszeiten. Für Heimcomputer und Spielekonsolen müssen wir Ton, visuelle Ausgabe und Benutzereingabe so genau wie möglich simulieren / emulieren. Das größte Problem ist der Ton. Das liegt daran, dass unser Gehör viel besser ist als jeder andere unserer Sinne und wir den Unterschied fühlen / hören können, wenn der Ton nur um wenige ms oder . Wenn der Bildschirm um 1 oder 2 Frames ausgeschaltet ist, können wir den Unterschied nicht erkennen. Auch wenn die Eingabe ein wenig verzögert ist, ist dies in Ordnung (für die meisten Menschen).

In der modernen Maschinenarchitektur wird alles gepuffert (insbesondere Ton). Um Sound auszugeben, müssen wir also PCM -Daten erstellen, die an den Soundchip gesendet und über DMA + DAC . Dazu werden üblicherweise 2 kreisförmige oder viele kleine lineare Puffer verwendet. Um störungsfreie Sounds zu erzeugen, müssen die Puffer groß genug sein. Zum Beispiel unter Windows überprüfe ich beim letzten Mal, wenn WAVEOUT mindestens 20-80 ms. DirectSound benötigt >400 ms

Wenn das emulierte Programm jetzt angepasst wird Die Tonausgabe wird erst ausgegeben, nachdem der bereits angeforderte Ton abgespielt wurde.

Das Gleiche gilt für die E / A-Eingabe auf einigen Plattformen, sodass sich die Verzögerungen summieren.

Wenn Sie FPGA Dann haben Sie direkten Zugriff auf die Tonausgabe ohne Pufferung. Gleiches gilt für die Eingabe.

Die Eingangslatenz des Spiels (Tastatur, Joystick) hat jedoch normalerweise nichts mit der Latenz des Hostsystems zu tun. . Die übliche Ursache ist, dass die meisten Emulatoren Clock-Tics verwenden, um emulierte Geschwindigkeiten aufrechtzuerhalten. Sie simulieren also die CPU oder was auch immer und erreichen einmal die gewünschte Anzahl simulierter Takte pro Ruhezustand, bis der nächste Timer ausgegeben wird oder was auch immer. Je schneller der Host-Computer ist, desto weniger Zeit wird für die Emulation benötigt, sodass die Simulation die meiste Zeit in Echtzeit nicht reagiert.

Nehmen wir beispielsweise an, dass unsere Simulation 100-mal schneller als die ursprüngliche Geschwindigkeit des emulierten Computers ausgeführt werden kann. Das bedeutet, dass die Simulation nur 1% der Zeit etwas tut und der Rest nur Sleep() ist. Während des Schlafes kann die Emulation auf nichts reagieren. So können Tastenanschläge, Feuerklicks usw. übersehen werden. Um Abhilfe zu schaffen, verwenden einige Emulatoren möglicherweise erneut Pufferung, was zur Latenz führt, anstatt Eingaben zu ignorieren. Es gibt auch verschiedene Arten der Zeitsteuerung, die dieses Problem vollständig beseitigen. Weitere Informationen zu diesem Thema finden Sie unter:

Antwort

Vintage NTSC-Maschinen (und CRT-Macs usw.) können ihre Grafikausgabe während der Aktualisierung der CRT-Anzeige (teilweise) ändern (vertikales Raster), wodurch das Bild als Reaktion auf Echtzeit-Eingaben zerrissen wird.

Emulatoren, die Nicht-CRT-Monitore verwenden, können dies nicht in Echtzeit tun und können nur ein zerrissenes Raster im nächsten fälschen Rahmen oder Feld.

Und der einzige Weg, um zu testen, ob eine Emulation genau ist, kann mit der tatsächlichen (Grundwahrheit) Vintage-Hardware verglichen werden. Überprüfen Sie, ob unter den verschiedenen ASIC-Chipschichten undokumentierte versteckte Logikfallen (Defusion usw.) oder analoge Layoutfehler vorhanden sind.

Kommentare

  • _ " .. kann nur fälschen … " _Wo ist der Unterschied? Ist ' keine Emulation, bei der es darum geht, das Ganze zu fälschen?
  • Nicht auf einem Nicht-CRT-Display. Ein LCD (et al.) Aktualisiert ' nicht in 2 verschachtelten Feldern mit 30 Bildern, in denen abwechselnde Linien sowie die Ober- und Unterseite eines Fensters zu unterschiedlichen Zeiten über 10 ms angezeigt werden in Echtzeit auseinander. Vielleicht wäre ein FPGA, das einen alten CRT-Monitor speist, genauer als ein Emulator.
  • Nichts hindert die Emulatorsoftware daran, dasselbe zu tun. und einige tun es. Immerhin sind 60-Hz-Bildschirme mittlerweile Standard, sodass das gleiche Flimmern wie bei einer CRT übertragen werden kann. Hier ist keine FPGA-basierte Software oder CRT erforderlich.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.