Run CHIP-8 Test ROMs and Verify Correctness

Topic Overview

CHIP-8 Test ROMs

Passing opcode tests is how emulator authors prove correctness. Community ROMs exercise every instruction and expose COSMAC VIP quirks modern interpreters handle differently.

Suites and Quirks

Popular ROMs:

• corax89/chip8-test-rom: visual pass/fail per opcode family
• Timendus/chip8-test-suite: documented tests for shift, jump, and memory behavior

Known divergences:

• 8XY6/8XYE shifts: VIP shifted \`VY\` into \`VX\`; many emulators shift \`VX\` directly
• BNNN jump: VIP used \`V0\`; some tests expect \`VX\`
• DXYN clipping: sprites clip at edges instead of wrapping

For example, a failing shift test often means your \`8XY6\` updates the wrong register.

Validation workflow:

1. Load ROM at \`0x200\`
2. Run until display shows pass pattern or halt
3. Compare against reference screenshot or hash
4. Fix opcode, rerun

Design Notes

When a ROM fails, isolate one opcode family at a time using Timendus subtests. Fixing shift behavior before jump behavior avoids chasing multiple bugs from one failing display pattern.

For This Exercise

This exercise asks you to document test ROM usage and quirk tables. You will explain how to validate your emulator against community suites and reconcile VIP versus modern behavior.

You will use the same mental model here when reading production interpreter source later in the track. Sketch one concrete input on paper, predict the outcome, then confirm with code. That discipline catches logic errors early and makes debugging far faster when you extend the implementation in follow-on tasks.

Your Task

Real CHIP-8 test ROMs (Timendus' quirks test, corax89's opcode test) exist because "CHIP-8" means several slightly different machines. Add the five classic quirk switches and the platform profiles to your interpreter. Then build a test harness: it loads small probe programs, runs each to its jump-to-self halt, and checks registers, memory and pixels against expectations, printing PASS/FAIL like a ROM test report.

Quirks

The profiles:

Everything else is the CHIP-8 core from the previous task: flags written after the result, the font at 0x050, the program at 0x200, and the timers ticking every 10 instructions.

Input

cCopy
Loading…

# starts a comment. Expectation items:

• V3=0A (hex register)
• I=302
• M300=07 (the memory byte at hex address 300)
• px=X,Y (the pixel is lit) and dark=X,Y (the pixel is unlit), in decimal

Output

cCopy
Loading…

• Runs: a test runs until a jump-to-self. Any other halt (an unknown opcode, a stack error, cycle limit 10000 reached, …) is a FAIL with that reason.
• Mismatches are listed in item order, separated by ; . Values print as %02X, and I as %03X.
• Errors:
  • unknown profile X
  • unknown quirk setting X Y
  • bad expectation X (the item is skipped)
  • bad program word: X
  • test NAME: missing expect (at the end of input; it counts as a failed test)
• The final line is always P/T tests passed.

Example

Input:

cCopy
Loading…

Output:

cCopy
Loading…

Requirements

1. Implement each quirk as a flag checked inside the affected opcode, never as a separate interpreter.
2. The harness only observes the final machine state. It must not peek at the trace or special-case test names.

Hidden tests cover the schip and xochip profiles, toggling single quirks, sprite wrap versus clip, abnormal halts, and bad profile, quirk and expectation input.