Accuracy takes power: a 3GHz quest to build a perfect SNES emulator (2010)
arstechnica.com
arstechnica.com
1 year ago: http://news.ycombinator.com/item?id=3987660
2 years ago: http://news.ycombinator.com/item?id=2864531
> What worries me is if future generations will be able to enjoy the games of today. Will it ever be feasible to emulate a PS3 to the level demanded here? Will my grandchildren in 50 years be able to play GTA 6 on a PS4 emulator? Processing power does not appear to scale to allow this, and there will barely by any of today's consoles still alive by then (also, I doubt 2060s television sets will have HDMI input).
My response would be the trend towards more PC-like architectures (more traditional x86 systems vs something like http://en.wikipedia.org/wiki/Cell_(microprocessor)) and the fact it's already easy to build a similarly priced ($400-$500) PC with superior performance already (historically rare at release than the new set of consoles) may mean it's easier to accurately run these games in future than a Nintendo 64 or SNES. On the other hand, the original Xbox (circa 2000) was a traditional x86 system running an only slightly modified Windows with DirectX that as far as I know isn't emulated well.
I think the search for accuracy will probably be achieved in the coming decades by producing accurate and cheap clone hardware "dongles" to offload processing and interfacing them to a computer via some future fast bus.
It runs a few commercial games, but probably not all that well. I wonder why not a lot of people bothered to contribute.
Complete speculation, but most emulator devs probably just see it as a waste of time considering how few good games exist for the system.
Personally I always found it frustrating when new versions of MAME would make games unplayably slow on my system in the name of accuracy.
The really important question is are we trying to preserve the games or the hardware? If we're trying to preserve the games than fast emulation with special case hacks for games that need them seems like the way to go. There were a limited number of games released for each system so accurate emulation is just a waste of time.
But I don't think accuracy is a waste of time. Accuracy can even be the easier method if you have proper specifications for the chips, with the difficulty moving into optimization.
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.
On an unrelated note, does anyone here have a sense of how useful semi-specialized hardware could be for emulators. Obviously emulating a specific system in hardware is easy (at least in principle). However, would it be possible to create hardware specialized for emulators in general. This would probably be multi-core devices that could synchronize between cores at a configurable rate. The obvious downside to any hardware approach is that if the assumptions are wrong, it is likely far more difficult to patch the problem with sacrificing most of the benefits hardware gives you.
I wonder if memristors[1] would be able to enable an even more powerful way; just download the model for the chip to emulate and have the memristors configure themselves accordingly.