Building a CHIP-8 emulator from scratch

If you've ever wanted to understand what a CPU is doing underneath all the abstractions, write an emulator. CHIP-8 is the ideal starting point: 35 opcodes, 4KB of memory, a 64x32 monochrome display, and no undocumented behavior to trip over.

The machine, in full

CHIP-8 is small enough to hold in your head:

• 4096 bytes of memory, programs loaded at 0x200
• 16 8-bit registers (V0 - VF), where VF doubles as a flag
• A 16-bit index register and a program counter
• A stack for return addresses, plus delay and sound timers

The fetch-decode-execute loop

Everything reduces to one loop. Read two bytes at the program counter, combine them into a 16-bit opcode, advance the counter, then switch on the high nibble.

cppuint16_t opcode = memory[pc] << 8 | memory[pc + 1];
pc += 2;

switch (opcode & 0xF000) {
    case 0x6000: // 6XNN: set VX = NN
        V[(opcode & 0x0F00) >> 8] = opcode & 0x00FF;
        break;
    case 0xA000: // ANNN: set I = NNN
        I = opcode & 0x0FFF;
        break;
    // ...
}

The gotcha everyone hits

The draw instruction (DXYN) XORs sprites onto the screen and sets VF if any pixel flips from on to off - that's your collision detection. Get the XOR wrong and every game looks like static. Get the VF flag wrong and nothing collides. Test it with the IBM logo ROM before you touch anything else.

What you walk away with

Once Pong runs, the mystery is gone. A CPU is a loop reading numbers and acting on them, and "execution" is just a very fast switch statement. Everything bigger - a real ISA, a JIT, an out-of-order pipeline - is that same idea wearing more clothes.