Wouldn't a better approach to this problem involve some sort of FPGA expansion card (or OpenCL code to get the GPU to mimic one) programmed at runtime, for each game, with the traces of the original chips composing it?
Wouldn't a better approach to this problem involve some sort of FPGA expansion card (or OpenCL code to get the GPU to mimic one) programmed at runtime, for each game, with the traces of the original chips composing it?
I believe OpenCL is the way to go. I did a very simple Sega Genesis emulator and basically what you do is control with a very slow CPU a very fast hardware that does very simple things like drawing tiles.
You control the tile with something like a pointer with the CPU but it is draw by hardware. Same with sound.
It is not hard to do, it just takes time.
In particular, you extract all the performance in OpenCL from knowing how to manage memory. We talk about orders of magnitude difference(100x-200x times faster).
This memory management is hell for anybody trained with garbage collectors, Object oriented constructors and so on. It is way harder than pure c and the feedback loop is way longer(unless you invest a lot in hardware).
Then you'd "flash" the trace of the chips you want emulated to this virtual FPGA, just as if you were deploying it to a real one.
Our computers pretend to run hundreds to thousands of processes simultaneously using only one to eight physical cores (numbers common for personal use at this point in the historical record).
It's easy to pretend to be parallel when you are operating at 2 microseconds per loop.