Dolphin Progress Report: August 2016
dolphin-emu.org
dolphin-emu.org
Traditional game console architectures don't usually have a lot of memory protection for the GPU - in fact, both the 360 and the 3DS were at various points in times hacked by subverting the GPU to do writes to global memory.
It was where the product code was stored, as I recall - so every now and again you'd find some junk in some random string, starting with your title's product code, and it would be time to track down another missing NULL check...
> <the emulator> should never, ever trust the software it is running to be sane.
Console games always does weird things the only way to check is real hardware, that's why writing a good emulator is hard, because you must have a way to quickly test a particular behavior on hardware.
But the reality is that most (though certainly not all!!) of them are primarily there for a paycheck. They're expected to work on new systems with poor debugging capabilities, and get games out as fast as possible. So naturally, they end up having lots of gross hacks and erroneous code just to get things working and ship the game.
My favorite bug so far was a game that read from a write-only register in a loop until a certain bit was set. That bit could never have been set under normal conditions, so it was freezing in emulators. Turns out that the game had a DMA channel running during each scanline, and after a few million iterations of the loop, the stars would align and the DMA channel would read a byte from memory that had the required bit set, and that value would be floating on the bus, followed immediately by reading from said undefined memory location. Since nothing would respond to it, it would reuse that DMA byte fetch, and exit the loop.
Even more fun, to test on real hardware, I was using a copier device. But said copier device pulled the data bus lines low whenever an unmapped region was accessed, which effectively broke the game on the copier as well. It took me two weeks of full-time work to track down that bug and exhaust all other possibilities for what was happening.
I can't begin to imagine why that loop was in the shipped game, nor why it only ever triggered once during hitting one of many buttons (this one required to finish the level), in stage 6-2 of the game.
See also the speedrunning community which often relies on all sorts of "fun" little bugs.
I'm also always amazed at the hardware reqs for emulators. They suggest at least an i5 or i7 and recommend a dedicated gpu! For a gamecube! Released 15 years ago!
But it works well enough for most games even with an integrated Intel GPU, as long as you don't try to improve on the base game too much (resolution, filtering, etc..)
The emulators that exist today don't have to emulate a single CPU, that would be trivial, but the surrounding hardware.
Here's an example of someone trying to emulate a 6502-based computer (BBC Micro) and the problems they encountered when trying to run Elite, just one game: https://www.youtube.com/watch?v=RiE5pTisEd8
Older games used any optimization they could get, and they'd often exploit quirks in the hardware if it made things work better. Elite flips video modes part-way through the rendering of the screen since it was made in an era of CRTs. Trying to reproduce that effect in a frame-buffer type system is hell.
So most of the emulators out there have to fake a lot of things in order to get software and games to run properly, or at all.
Not really. The emulators for recent systems don't try to emulate the hardware anymore, they emulate the outcome of the system calls and convert them to OpenGL most of the time (HLE).
That's actually necessary for stuff like the PSP. Sony made multiple revisions of the hardware over the course of the PSP life, and therefore relies on such a system anyway to maintain the output identical despite the hardware changes.
You're calling it "emulating the outcome" but that usually means in practice "approximating what the original system does by faking it."
As for performance: Using software to implement behavior equivalent to specific hardware is almost inherently inefficient. JIT-style processing of the opcodes helps, but you're still going to use multiple operations on the host CPU for each one that you execute from the guest code. Plus emulation of device synchronization that would've originally been done in hardware and that don't have direct equivalents on the host hardware.
Yeah, to anyone who has tried to optimize a CPU interpreter before; dynamic recompilers are nothing short of magical.
You'd be quite talented to emulate just a 50 MIPS interpreter core from a sufficiently awkward CPU at 100% speed on modern processors. Let alone all the other parts of the emulator, and synchronization between components.
Of course, dynamic recompilers sacrifice huge amounts of synchronization precision in return for that raw speed. But it's very much a necessary evil -- otherwise we wouldn't have playable modern emulators at all. The developers of dynarecs deserve extra special praise for being willing to give up both idealism and portability when writing them.
If you're saying they hit it at 100% Wii U CPU load at fullspeed, then that's really impressive! :)
And that's still nowhere near the requirements for cycle-accurate emulation. I'm not sure you can even run a cycle-accurrate N64 emulator on a standard machine.
Unlike Dolphin, it's currently closed source & Patreon backed though.
decaf is fully open source: https://github.com/decaf-emu/decaf-emu
I'm completely willing to believe that they asm2c'd quite a lot of system libraries instead of properly reimplementing them. And I wouldn't be surprised if that's a prime reason why their software is not open source. But that's a step away from "stolen code" in my opinion.