Emulation 101

Operation Code Red
So how does it all work? What spooky imps are called upon to transmogrify computer to console at the click of a button?

Fortunately there are no Gremlins, Mogwai or other beasties required. What you do need, is a solid understanding of the machine to be emulated, the language to perform the emulation and large unmarked shipping crates of patience.

Research the engine you want to emulate. Trawling through official (and un-official) documentation, reverse engineering information and occasionally SDKs is the only way to achieve this. Know thy console before attempting to render it on a completely different platform.

It’s this need for detailed technical information which has stifled or at least prolonged the creative process of emulating many newer consoles, as most companies don’t employ a position of laying bare the inner workings of their hardware.

With this in mind, the road to understanding emulation is best started by tackling an older system, something in the 8-bit range. Due to their age, there’s a wealth of information and documentation available online to get you started.

Although more recent consoles use custom architecture in the form of specialized components performing specific functions, the CPU is still the central point from which all emulation code springs and in order to emulate a conventional system you need to grasp Opcodes (Operation Codes).

Opcode is the term for a CPU instruction, basically a segment of machine code that relates to an operation to be carried out. These opcodes are defined in the instruction set architecture (ISA) of a CPU or in some cases a more specialized processing unit.

Understanding and mapping out these opcodes is considered a good first step towards emulating them on a different platform, in essence allowing one platform to copy the programmatic tricks of another via duplicating functionality of these opcodes. The particular programming tools used aren’t important in theory; just about any language you’re competent in can be used to write emulator code. But be warned, an emulator can be written in both C++ and Visual Basic, but it’s unlikely to perform well if the latter language is employed.

Most authors taking those tentative first steps into emulator creation tend to focus on a machine with relatively simple functions to write emulation for. The ‘Chip8’ language – designed in the 1970s for ‘kit’ computers like the Telmac 1800 - is a perfect candidate for a project to get your feet wet.

With just 35 opcodes to emulate, monochROMe graphics and 12 bit addressing the Chip8 is the perfect way to break your emulation virginity. Sure, it’s been done before – but it’s not about that, it’s about learning the concepts behind emulation without turning into a gibbering wreck as you try to re-create the ‘emotion engine’.

Want your Chip8 emulator to clear the screen? Just duplicate the functionality of opcode 00E0. Need to set the sound timer? Write some code that functions like opcode FX18.

As a perfect example, let’s take a gander at opcode 8XY4 in Chip8, which is responsible for adding the value of two registers together and setting the carry flag should the total overflow the 8-bit limit. If you wanted to emulate Chip8 in C and run it on Windows, you might replicate the function of this opcode as follows,

[code]
void MathAdd(){ //8XY4 VX = VX + VY, VF = carry
if((Register[x] + Register[y]) > 0xFF) { // Is the result of Register X + Register Y greater than 0xFF (255, which is the limit for 8bit)
SetVF; //Set the carry bit if result is greater than 0xFF
} else {
ClearVF; //If it is less, clear the carry bit
}

Register[x] = Register[x] + Register[y]; // Do the operation, add register y to register x
}

[/code]

Easy huh? Well sort of, at least at this level.

If you wanted to start reverse engineering the original Nintendo, you’re looking at 135 opcodes, 255 for the SNES and the complexity grows from there. Keep in mind this is just dealing with the CPU emulation, you then have to consider branching out to the audio, video and other subsystems.

Suddenly the prospect of creating a PlayStation 3 Cell emulator on your Celeron box isn’t looking so likely.

You too can turn your flashy PC into one of these! Huzzah!

Once you’ve mapped out your plan in theory and coded it accordingly, the end result should be an emulation loop that can load a ROM image into memory and begin executing opcode after opcode and produce output from the various emulated components, while the end user happily destroys wave after wave of pixelated aliens.

Most emulation is tested first by using ‘homebrew’ applications - those written by the authors to test functionality, with the end target that of running full commercial quality games at the same speed and quality as the native environment. Once you can achieve that, you’re in emulator nirvana.

Pulling apart an engine like PlayStation 2 becomes an infinitely more complex affair than the humble Chip8. The use of dynamic translators, complex memory management schemes and component synchronization means if you want to play with the ‘big guns’ you had better do your homework.

So – how’s Chip8 looking again?

If you want a more in depth look at the emulator code for Chip8 emulation through C++, be sure to grab a complete copy here:

http://djxander.artists.mpfspromotions.com/RefChip8.rar

(Special thanks to Alex ‘Refraction’ brown for the source).