Gameboy Emulator Development - Part 03

CPU instruction execution architecture (C code refactor)

• Introduces a new source file: cpu_proc.c to handle instruction processing/execution.
• Updates cpu.h to add:
  • A function pointer type for instruction handlers:
    • Returns void
    • Takes a cpu context* parameter
  • inst_get_processor to map an instruction’s type to the correct handler function.
• Implements an array of function pointers (conceptually a map/hash map, but implemented as an array) as the dispatch table:
  • Default handlers are null
  • Only implemented instruction handlers are assigned
  • Includes a proc_none handler that errors/exits when an unimplemented instruction is encountered
  • Adds placeholder handlers such as proc_ld (TODO)

Jump instruction support with flag-based conditions

• Adds proc_jp to implement jump instructions, including conditional jumps.
• Uses CPU flags (from “CPU registers and flags”):
  • Z (zero) flag = bit 7
  • C (carry) flag = bit 4
• Implements a helper: check_condition() based on the instruction’s condition type, including:
  • always
  • if carry
  • if not carry
  • if zero
  • if not zero
• When performing a jump:
  • Updates the CPU program counter (PC) to the fetched data value
  • Notes that jump timing must be coordinated with PPU/timer (cycle synchronization)

Instruction dispatch / runtime execution flow

In the CPU step (or equivalent execution function):

• Calls inst_get_processor(current_instruction.type) to retrieve the handler function pointer.
• If the handler is null, the program exits (or terminates execution).
• Otherwise, the handler is invoked with the CPU context.
• Fixes/handles issues around:
  • ctx pointer correctness
  • missing/undefined inst_get_processor

Debugging improvements: logging and tracing executed instructions

• Adds a logging format that prints, per instruction:
  • PC
  • instruction name (via an instruction-name lookup array/map)
  • opcode byte
  • the next operand bytes (reads pc+1, pc+2) for visibility
  • register values such as A, B, C
• Improves fetch error handling:
  • Initially adds a check for current_instruction == null (as a “hack”)
  • Later removes it after troubleshooting to improve error visibility
• Error reporting covers cases like:
  • “unknown instruction/addressing mode”
  • encountering an opcode such as F3 identified as DI (disable interrupts)

Incremental instruction coverage

• Adds NO-OP support via a handler that does nothing.
• Implements a default implied addressing mode:
  • Undefined instructions now default to implied addressing, improving handling/logging.
• Implements DI (opcode F3):
  • Adds int master enabled to the CPU structure and sets it to false when DI executes.
  • Maps F3 to the DI instruction with implied addressing.
• Runs ROM tests:
  • DI appears to execute early
  • Execution continues until unimplemented instructions occur (e.g., load stack pointer)
  • Eventually reaches Tetris, where XOR is encountered

Implementing XOR and flag updates

• Implements XOR A, <operand>:
  • Used by ROM behavior
  • Opcode AF referenced as XOR in the discussion sample
• XOR handler logic:
  • A = A XOR fetched_data (masked with 0xFF for the relevant byte)
• Updates flags using a planned helper:
  • Creates/uses cpu_set_flags
  • Sets Z if the result is zero
  • Clears/sets N/H/C appropriately (set to zeros for the XOR case)
• Fixes XOR behavior to confirm it changes register A (example: A changes from 0x01 to 0x00)

Stated design rationale

The author contrasts this dispatch-table approach with a giant switch statement.

• Prioritizes readability and debuggability over maximum speed.
• Notes that modern compiler optimizations should still be “fast enough” for emulation.

Main speakers / sources

• Single speaker/author: the creator of the “low-level … Game Boy Emulator Development” series.
• No other distinct sources mentioned.