Wow, on HN again. While I'm proud of that answer, the real bummer was that I edited it too many times (started with a tiny answer and filled it in from there) and it became Community Wiki. I got all of 4 or 5 upvotes before it went CW, so got 40-50 rep out of it instead of the 5290 I would've gotten otherwise. Glad people have found it useful, though.
I had the great opportunity in my undergrad college compiler class to write an entire ecosystem to understand better how some of this stuff works. We didn't just write a compiler, we wrote an emulator for a simple, notional architecture. The whole thing was simple enough that we could write the compiler toolkit, the system emulator/VM and run it in a few days.<p>Then for extra credit we could rewrite the whole thing (or part of it) in another language. And/or get a guaranteed A if we could make the whole shebang self-hosting.<p>It was a really great way of understanding the basics of a system architecture.<p>As for the emulator, it was pretty primitive, but basically it loaded the compiled program code into memory, then would read an operation's worth of bytes, look the operation up in some kind of lookup table (or similar) that mapped the emulated system's instructions to local system instructions say, x86, and execute that operation.<p>Sometimes the mapping resulted in several operations on the host side the emulated system might execute in one.<p>eg.
ADD R1, R2, R3<p>might add the contents of registers r2 and r3, then put the result into r1. In x86 it would be more like<p><pre><code> ADD AX, BX
MOV CX, AX
</code></pre>
or some such.<p>(actually we did it a little higher level then that, but that's the idea).<p>So an emulator needs to provide all of the various registers and operations and such so that the code can execute, it likely has to have the ability emulate the memory architecture and translate I/O appropriately. Some older systems for example could only output to a printer terminal, or to a simple status display, on a modern system you have to translate calls to those output devices to equivalent ones on your system (like the screen).<p>More complex system may need to emulate several processors. The SNES and Amiga for example have a handful of chips that not only need to be emulated, but much of the software assumes a particular timing in the interaction of those components that can be very challenging to get right and keeping track of all that and running at reasonable performance can require fast hardware.<p>These days though, not many emulators use the simple execution mechanism I outlined above. Many of them have sophisticated code profiling and execution caches that can significantly speed up the emulation.<p>In these terms, emulating a system, or a VM (like Java) or some other runtime environment (like Javascript and the V8 runtime for example) isn't really all that different and there's huge crossover in the theoretical concepts between these areas.
<a href="http://www.romhacking.net/" rel="nofollow">http://www.romhacking.net/</a> is an amazing resource if you want to find documents on the inner workings of older game consoles.<p>The SO post already links to bsnes, which does an excellent job of balancing readability and accuracy. It's still a little hard to grok the code, but leagues easier than tackling something like SNES9x.<p>I would also recommend glancing through the vNES source code; it's much simpler than bsnes and is very easy to understand for the most part: <a href="http://www.thatsanderskid.com/programming/vnes/index.html" rel="nofollow">http://www.thatsanderskid.com/programming/vnes/index.html</a>
Invariably been linked before, but <a href="http://imrannazar.com/GameBoy-Emulation-in-JavaScript:-The-CPU" rel="nofollow">http://imrannazar.com/GameBoy-Emulation-in-JavaScript:-The-C...</a> also addresses basics of emulator design.
I find undocumented opcodes most interesting. They were literally holes in the 6502 circuitry. People used them on the C64 to get more speed out of their assembly code. Early C64 emulators couldn't cope with those games/demos. Luckily, they are documented in disk magazines, etc, so they've been implemented now.
Previous discussing of the same link: <a href="http://news.ycombinator.com/item?id=1350343" rel="nofollow">http://news.ycombinator.com/item?id=1350343</a>