FPGA statt Emu?

[Hallo]

Hi, ist ne sehr spezielle Frage.
Ich frage mich seit ner Weile ob man (z.B.) ein Mega Drive in einen FPGA "stecken" könnte. Das Teil muss sich wie die echte HW verhalten.

Das Problem mit Emus ist V-Sync On = Lag. Off = Tearing.

Soweit ich weiss gab es zu 8/16 Bit- Zeiten keinen Frame Buffer, die "gpu" wusste zu jeder Zeit bei welchem Pixel sich der CRT-Elekronenstrahl befindet.

Heute ist das anders. Auch wäre es interessant den 68000er völlig zu überdrehen.
Kann man überhaupt ein System wie das MD innen FPGA "fest verdrahten" ?

[Rooter]

Kann man überhaupt ein System wie das MD innen FPGA "fest verdrahten" ?Warum denn nicht?

Wurde auch schon gemacht:
http://www.sega-portal.de/blog/1037/mega-drive-portable-bei-aldi-sud-fur-2999-euro/

EDIT: Okay, ob da jetzt wirklich ein FPGA drin steckt kann man wohl bezweifeln.

MfG
Rooter

[THEaaron]

Da dürfte der Preis widersprechen. FPGAs sind afaik schweineteuer. Es gibt einen FPGA NES der wahnsinnig teuer ist.

https://arstechnica.com/gaming/2016/08/the-500-nes-remake-gets-a-bit-smaller-and-more-affordable/

[Ganon]

Es gibt diverse Projekte die alte Hardware in FPGAs nachstellen. Diese lösen aber die von dir genannten Probleme nicht, da man auch einen Emulator so einstellen/bauen kann, dass dieser an einem CRT ohne Input-Lag funktioniert. Denn selbst Originalhardware lagt an einem Flachbildschirm wie blöde (~100-200ms Delay).

Emulatoren in FPGA sind weiterhin Emulatoren. Dort wird nicht 1:1 die alte Hardware nachgebildet, sondern man gießt nur den Emulator in Hardware.

[Hallo]

Mein Gedanke ist alles in einen FPGA zu simulieren "festverdrahtet" nicht emulieren. Das Teil muss 15KHz RGB (320x224p) ausgeben in Realtime nicht framebuffered oder V-Synced. Nen shmup in MAME mit V-Sync geht garned :(

Das LCDs laggen ist klar, das Problemchen ist, der Emulator mit V-Sync On lagged ebenfalls ob CRT oder LCD.

Ich denke das grosse Problem ist die diversen ICs nachzubilden. Klar der Z80 und der 68000er sind gut dokumentiert aber der (MegaDrive) VDP und div. andere Sachen sind es wohl nicht...

Wobei ich mich frage wie man eine Model3 PCB so perfekt emulieren kann?? Woher wissen die Freaks (big respect) wie die beiden Real-3D Pro 1000 GPUs funzen??

Das Ding muss 100% innen FPGA gegossen sein, sprich sich so verhalten wie das echte Teil.

[Mr.Magic]

Nen shmup in MAME mit V-Sync geht garned :(

Das LCDs laggen ist klar, das Problemchen ist, der Emulator mit V-Sync On lagged ebenfalls ob CRT oder LCD.

Mame + G-Sync läuft perfekt.

https://www.youtube.com/watch?v=2CeZ0xbtfDo

[Hallo]

Du Knuschperflocke:freak:

Nicht jeder hat G-Sync ;) Aber good for you! Ich hab nur nen 1000€ Eizo der das leider nich' kann...

Ausserdem zweifle ich stark was bei dir perfekt bedeutet...zock mal Mushihimesama Futari (oder Cave Shooter nach Wahl) Und dann aufm CRT! Tag und Nacht. Selbst mein Pana Plasma kommt da nich' mit...

Und wozu brauchste G-Sync bei ner Emu?? Die Dinger laufen alle oberhalb 60fps. Schaltet G-Sync die V-Sync Verzögerung aus? Glaub' eher nicht...

Line-Buffering ist wohl schwer nachzubilden mit LCDs.

[Ganon]

Mein Gedanke ist alles in einen FPGA zu simulieren "festverdrahtet" nicht emulieren. Das Teil muss 15KHz RGB (320x224p) ausgeben in Realtime nicht framebuffered oder V-Synced. Nen shmup in MAME mit V-Sync geht garned :(

Ein CRT+GroovyMAME und du hast keinen Lag. ;) MAME gibt generell das Signal so aus, wie es ursprünglich war.

Das Ding muss 100% innen FPGA gegossen sein, sprich sich so verhalten wie das echte Teil.

Wie gesagt. Ein Gerät kann sich nur wie das Echte verhalten, wenn du 1:1 die Chips nachbaust die dort verbaut waren. Das macht man aber mit FPGAs nicht. Man gießt eben nur einen Emulator in einen FGPA (bzw. schreibt einen Emulator in Verilog oder VHDL). Statt, dass dann eine CPU den Kram rechnet, rechnet es eben der FPGA aus.

Das Prinzip ist das Gleiche und auch dein normaler Emulator ist in der Lage das korrekte Signal auszugeben.

[Sam Pau]

Wie gesagt. Ein Gerät kann sich nur wie das Echte verhalten, wenn du 1:1 die Chips nachbaust die dort verbaut waren. Das macht man aber mit FPGAs nicht.
...

Wenn ich Zugriff auf alle technischen Daten und die ISA habe, warum nicht?

[Rooter]

Wenn ich Zugriff auf alle technischen Daten und die ISA habe, warum nicht?Eben. Zumal die Logik auch deutlich einfacher wäre als die eines Emulators.

MfG
Rooter

[Ganon]

In dem Fall müssten aber diverse FPGAs zum Einsatz kommen, die allesamt mit unterschiedlichen Taktraten laufen, um die Hardware 1:1 nachstellen. Das tut man aber schlicht nicht. Es ist in der Regel ein FPGA mit einer festen Taktung, der "in-Hardware" die alte Hardware emuliert/nachahmt.

Emulatoren machen ja am Ende nichts anderes, nur eben in Software. Auch ein Software-Emulator muss die ISA und technischen Daten kennen, sonst würde der auch nicht funktionieren.

[Sam Pau]

Wieso hat ein FPGA nur einen Takt?
Ich kann mir doch die passende Takte aus der PLL und passender Logik zusammenbasteln, kommt ja nur auf das Dev-Board drauf an.
Ich kann dann auch auf einem FPGA Chip meine Softcore CPU,GPU,CoProzessoren etc. implementieren und passend verdrahten.

Ein Emulator ist eine Software, die auf einer festen vorgegebenen Hardwarebasis (z.B. eine X86er CPU) versucht eine andere Hardware zu emulieren.

Bei einem FPGA kann ich mir einfach die Hardwarebasis 1:1 nach meinem gewünschten Vorbild bauen.

Hardware Design ist nicht gleich Software Design.

[Ganon]

Macht MAME aber auch nicht anders. Sie implementieren die Bausteine (CPU, GPU, Sound, ...) einzeln und schalten diese hinterher für das zu emulierende Gerät passend zusammen (diverse Geräte nutzen ja gerne die gleiche Bausteine) mit entsprechend vorgegebener Taktung.

Ob da nun eine FPGA-Logik, oder eine Software-Logik das kooperative Zusammenarbeiten aller Komponenten überwacht ist unterm Strich egal. Ein FPGA bietet hier keine reellen Vorteile. Es ist eben nur eine andere Art der Emulation.

[Hallo]

Ein CRT+GroovyMAME und du hast keinen Lag. ;) MAME gibt generell das Signal so aus, wie es ursprünglich war.



Wie gesagt. Ein Gerät kann sich nur wie das Echte verhalten, wenn du 1:1 die Chips nachbaust die dort verbaut waren. Das macht man aber mit FPGAs nicht. Man gießt eben nur einen Emulator in einen FGPA (bzw. schreibt einen Emulator in Verilog oder VHDL). Statt, dass dann eine CPU den Kram rechnet, rechnet es eben der FPGA aus.

Das Prinzip ist das Gleiche und auch dein normaler Emulator ist in der Lage das korrekte Signal auszugeben.

Groovy?? Muss ich testen, danke.

1:1 Chips "nachbauen" ist doch der Trick eines FPGAs, oder? Darum geht es doch. Emulation (nachahmen) ist nicht Simulation (nachbilden) ;) Schonmal gewundert wieso MAME bei bestimmten Spielen abschpackt?

Wenn Groovy sich so mit nem CRT verhält (15KHz RGB SCART) wie echte HW ist meine 20 jährige Emu-Reise endlich beendet :)

Edit:

Wieso nen Emu innen FPGA giesssen wenn mann den kompletten Chip giessen kann, wenn man kann...Verdrahte einfach den MD VDP in FPGA. Wo ist das Problem? Die Schaltkreise verhalten sich wie das echte Ding, Denkfehler meinerseits?

Danke für den Groovy Tipp, bin immer noch mit MAME UI FX 164 unterwegs. Ich werd alt, haha!

[Ganon]

1:1 Chips "nachbauen" ist doch der Trick eines FPGAs, oder? Darum geht es doch. Emulation (nachahmen) ist nicht Simulation (nachbilden) ;) Schonmal gewundert wieso MAME bei bestimmten Spielen abschpackt?

Wenn du glaubst ein FPGA-"Emulator" sei zu 100% kompatibel mit der Original-Hardware, dann muss ich dich da leider enttäuschen. ;)

Selbst bei uralter Hardware wie einem GameBoy sind noch nicht sämtliche "Tücken" der Hardware bekannt. Also kannst du sie auch kaum in einem FPGA-Projekt jetzt plötzlich lösen. Da fehlt einfach das KnowHow über die echte Hardware, die sowohl für einen Software-Emulator als auch etwas Hardware-basiertes erst ermittelt werden muss.

Das trifft auf so ziemlich alle Konsolen der Welt zu.

[Hallo]

Schau mal, mein Gedanke ist das man einen IC komplett innen FPGA nachbaut. Somit verhält sich das Ding wie das echte, oder?


Das grosse Problem ist das die Dokumentation eines (zweier) Sega Saturn VDPs nicht völlig dokumentiert ist...es sei denn du machst nen Decap mit Elektronenmikroskop und baust den Kram in FPGA nach.

[Sam Pau]

Macht MAME aber auch nicht anders. Sie implementieren die Bausteine (CPU, GPU, Sound, ...) einzeln und schalten diese hinterher für das zu emulierende Gerät passend zusammen (diverse Geräte nutzen ja gerne die gleiche Bausteine) mit entsprechend vorgegebener Taktung.

Software ist Software und Hardware ist Hardware.


Ob da nun eine FPGA-Logik, oder eine Software-Logik das kooperative Zusammenarbeiten aller Komponenten überwacht ist unterm Strich egal. Ein FPGA bietet hier keine reellen Vorteile. Es ist eben nur eine andere Art der Emulation.

Wieso ist denn ein Chip eine Emulation?
Nehmen wir doch mal als Beispiel den N64.
Meines Wissens nach werkelt da ein modifizierter 64 Bit MIPS rum.
Wenn ich nun die alten HDL Sachen von Nintendo habe und diese auf einen FPGA packe, ist das für dich auch eine Emulation?
Solange die selben Taktraten erreicht werden, ist doch das Ergebnis identisch zum ASIC.

Da fehlt einfach das KnowHow über die echte Hardware, die sowohl für einen Software-Emulator als auch etwas Hardware-basiertes erst ermittelt werden muss.

Ach darum geht es dir, ich weiß jetzt woran ich denke und woran du denkst.
Für dich ist alles Emulation, solange es nicht 1:1 identisch zum ASIC ist.
Für mich ist Emulation alles was Software ist.

Noch ein weiteres Beispiel:
Ich baue mir ein eigenes Design, welches die MIPS-Architektur implementiert.
Als Vorbild habe ich einen fertigen ASIC.
Ich erreiche mit meinem Design dieselben taktraten und zyklenakkurate Ergebnisse wie der ASIC.
Ich realisiere das Design einmal als CMOS-Logik, TTL und auf einem FPGA.
Nehmen wir an, alles ist ideal und ich erreiche auf allen drei Technologien dasselbe Ergebnis.

Alles Emulation? Ich bin grad selber etwas verwirrt. ;D

[Ganon]

Schau mal, mein Gedanke ist das man einen IC komplett innen FPGA nachbaut. Somit verhält sich das Ding wie das echte, oder?


Das grosse Problem ist das die Dokumentation eines (zweier) Sega Saturn VDPs nicht völlig dokumentiert ist...es sei denn du machst nen Decap mit Elektronenmikroskop und baust den Kram in FPGA nach.


Meine Aussage dazu ist eben, dass du das dann genauso gut in einem Emulator nachbauen kannst. Das Wissen wie die Hardware funktioniert musst du so oder so erlangen. Wie die Umsetzung dann ist, ist egal. Ein FPGA mit falschen Annahmen wird genauso viel Blödsinn erzeugen wie ein Emulator mit falschen Annahmen. Es fällt nicht plötzlich das gesamte Hardware-KnowHow 30 Jahre alter Hardware vom Himmel, nur weil man jetzt in VeriLog programmiert, statt in C. Gerade Hardware-Timings sind halt einfach da und ein Fakt und nicht irgendwo dokumentiert, weil es eben niemand aktiv so entschieden hat. Da hilft auch die Implementierung der Z80-ISA nichts, wenn sie zu schnell arbeitet.

Es hat eben auch mit genau deinem Problem nicht viel zu tun. Wenn du deinen PC so konfigurierst, dass er 15Khz, 240p ausgibt, dann tut er das auch. Ist auch mit einem Raspberry Pi über Composite möglich und RGB über ein Addon-Board.

Und dann wird auch (Groovy-)MAME das Spiel so ausspucken wie damals.

[Ganon]

Wenn ich nun die alten HDL Sachen von Nintendo habe und diese auf einen FPGA packe, ist das für dich auch eine Emulation?

Was in deiner Grundannahme schon mal so nicht funktionieren wird. Du kannst nicht die HDL von der MIPS-CPU, dem Reality-Co Prozessor und allem anderen Kram einfach in einen FPGA packen und dann denken, dass jetzt alles so funktioniert wie auf dem N64. Da musst du schon in der gleichen Fertigung wie damals das N64 Board nachbauen. Weil sonst zerhaut es dir die Signal-Timings und die Emulation/Simulation funktioniert hinten und vorne nicht.

Nehmen wir mal als Beispiel das NES. Dort wurden teilweise Prozessoren mit auf dem Spielmodul ausgeliefert, die das Spiel dann einfach nutzt (oder auch SuperFX beim SNES). Nach der Logik, dass der FPGA ja 1:1 die Hardware nachbildet, müsste man das Spiel einfach einstecken können und der Zusatzprozessor im Modul funktioniert.

Funktioniert aber eben nicht. Der FPGA fängt die Spielebefehle ab und leitet sie an seine eigene Implementierung dazu.

[Hallo]

@Ganon

Timings, das ist das grosse Übel aller Emus.

Frage: Wenn man den kompletten Kram Intus hat, sprich VDP, I/O, 68k, Z80, Ram... kann man die Timings nicht "nachbilden" ?? Ist wohl ein grosses Prob bei Emus.

Also mein Verständniss ist das ein FPGA genau die Schaltkreise nachbildet in HW und genauso funzt?? Oder liege ich falsch?

[Mr.Magic]

Und wozu brauchste G-Sync bei ner Emu?? Die Dinger laufen alle oberhalb 60fps. Schaltet G-Sync die V-Sync Verzögerung aus? Glaub' eher nicht...

Das Ruckeln kommt bei Emulatoren davon, dass die Hz nicht übereinstimmen. Wenn die Ausgabe z.B. für 54.706840Hz gedacht ist, ruckelt es auch bei 200Hz noch, wenn auch nicht so extrem wie bei 60Hz. Selbst wenn man manuell eine Auflösung einrichtet wird es noch ruckeln, a) weil man sie nie genau trifft, b) weil die Analogfrequenzen idR einstellig variabel sind.
Mit G-Sync verwendet der Monitor einfach die Frequenz, die der Emulator vorgibt. Kein Ruckeln.

https://www.blurbusters.com/gsync/gsync101-input-lag/
"Much like strobing methods such as LightBoost & ULMB permit “1000Hz-like” motion clarity at attainable framerates in the here and now, G-SYNC provides input response that rivals high framerate V-SYNC OFF, with no tearing, and at any framerate within its range."

[Ganon]

@Ganon

224p ;) Aber ich habe dich verstanden.

Kommt halt auf das Spiel an.

Raiden läuft in 256x224 @ 59.6Hz
Raiden 2 läuft in 320x240 @ ~55Hz
DoDonPachi läuft in 320x240 @ ~57Hz
Parodius läuft in 288x224 @ 60Hz
Gunbird 2 läuft in 320x224 @ 60Hz
Armed Police Batrider läuft in 320x240 @ ~59Hz

und und und. An einem modernen Bildschirm hilft hier wirklich nur G-Sync / Adaptive-Sync. Ansonsten eben ein CRT.

[Hallo]

Das Ruckeln kommt bei Emulatoren davon, dass die Hz nicht übereinstimmen. Wenn die Ausgabe z.B. für 54.706840Hz gedacht ist, ruckelt es auch bei 200Hz noch, wenn auch nicht so extrem wie bei 60Hz. Selbst wenn man manuell eine Auflösung einrichtet wird es noch ruckeln, a) weil man sie nie genau trifft, b) weil die Analogfrequenzen idR einstellig variabel sind.
Mit G-Sync verwendet der Monitor einfach die Frequenz, die der Emulator vorgibt. Kein Ruckeln.

https://www.blurbusters.com/gsync/gsync101-input-lag/
"Much like strobing methods such as LightBoost & ULMB permit “1000Hz-like” motion clarity at attainable framerates in the here and now, G-SYNC provides input response that rivals high framerate V-SYNC OFF, with no tearing, and at any framerate within its range."


Echt jetzt? Das wäre ja super. Dumm nur das ich das Zeugs dazu nicht hab. Und dann hätten wir immer noch LCD-Lag. Neulich Sturmwind auf DC aufm 1084 Monitor gezockt. Himmel, so fühlen sich 0ms Lag an, das war damals Normalität.

Kommt halt auf das Spiel an.

Raiden läuft in 256x224 @ 59.6Hz
Raiden 2 läuft in 320x240 @ ~55Hz
DoDonPachi läuft in 320x240 @ ~57Hz
Parodius läuft in 288x224 @ 60Hz
Gunbird 2 läuft in 320x224 @ 60Hz
Armed Police Batrider läuft in 320x240 @ ~59Hz

und und und. An einem modernen Bildschirm hilft hier wirklich nur G-Sync / Adaptive-Sync. Ansonsten eben ein CRT.

Haha, ein Kenner! Damals hatte ich meinen Eizo CRT per NV-Treiber gezwungen die 55Hz auszuspucken. Das Beste keine Schmiererei wie bei LCDs, was ne kack tech....