AccuracyCoin: 146 NES accuracy tests on a single NROM cartridge

146 tests packed into one NROM cartridge

AccuracyCoin is a single NROM cartridge image, AccuracyCoin.nes, containing 146 accuracy tests for the NES. The tests cover the 6502 processor inside the console, and the behaviour of the surrounding hardware: RAM mirroring, program counter wraparound at the end of the address space, flag semantics for PHP, BRK, IRQ and NMI, and the presence or absence of dummy read and write cycles on the CPU bus. On the PPU side the list includes open bus behaviour, the exact number of writes that read-modify-write instructions make to $2006, and the bytes returned when the data bus is read while floating. The tests print PASS or FAIL on screen, and when a test fails the ROM displays an error code. That distinction is the point of the project. A cartridge that only reported success would tell you that something is broken, while the error code tells you which numbered behaviour inside that test went wrong. There are also 5 tests labelled DRAW. Those do not test anything at all, they simply print information on screen, so they are excluded from any pass or fail accounting. The repository is written in Assembly and carries an MIT licence, and the source file AccuracyCoin.asm is the readable form of what the cartridge executes.

Driving the menu with the D-Pad, A and B

The ROM is a menu driven program, so the controller is the entire interface. Use the D-Pad to move the cursor up and down the list of tests. Pressing A runs the highlighted test. Pressing B marks the highlighted test to be skipped, and pressing B again clears that mark, so skipping is reversible rather than a one way trip. The stated purpose of the skip mark is practical: a test that is crashing a console or an emulator can be excluded so the results table still renders for everything else. The list is paged. When the cursor sits on the page index at the top of the screen, pressing left or right scrolls to another page of tests, pressing A runs every test on the current page, and pressing B marks every test on the current page to be skipped. Pressing Start while the cursor is on the page index runs all tests on the ROM and then draws a table of results. Because the run is a table rather than a stream of screens, the outcome survives long enough to be read and photographed. In the results table, any test that has multiple acceptable passing behaviours is drawn with a light blue number over it, which tells you the test was passed in a way the author considered valid but not the only valid way.

The Select debug menu reads RAM, not a register dump

After a test finishes, pressing Select reveals a debug menu that prints bytes on screen. This exists for the situation the author describes as not having a way to view everything in RAM, so the screen becomes the memory viewer for a test that failed in a way whose cause is not obvious from the printed output. The layout is fixed. The topmost row prints the values from address $20 to $2F, which the documentation identifies as the values used in the unofficial instruction tests. The second row prints $50 to $6F, used by a handful of other tests. The remaining eight rows print every byte from $500 to $5FF, which is typically where a test stores the bytes it needs. That range allocation is itself a design fact worth knowing, because if you write your own test or patch one in, you need to know where it is safe to place scratch data. The menu has an honest limit. It does not apply to every test, since many tests do not write anything to RAM, and in other cases the values written are not relevant to what went wrong. Seeing a page of zeroes here may mean nothing at all. The documentation suggests simply using some form of memory viewer if you have one, and the in ROM menu is the fallback for when you do not.

Error codes that name the behaviour, not just the test

The error code list is where the project is most useful to someone debugging a 6502 core or a PPU implementation, because each entry describes a rule rather than a symptom. The CPU Behaviour page includes a test that writing to ROM should not overwrite the byte stored in ROM. RAM Mirroring checks that reading from a 13-bit mirror of a RAM address returns the same value as the 11-bit address, and that writing to the mirror lands on the original address. PC Wraparound checks that executing an instruction at $FFFF takes its operand bytes from $0000 and $0001. The Decimal Flag test expects the 6502 Binary Coded Decimal flag to have no effect on ADC or SBC on the NES, while still being pushed by PHP and BRK. The B Flag test enumerates nine separate cases for how the B flag and bit 5 of the processor status should be set by PHP, BRK, IRQ and NMI, including a check that an IRQ actually occurred. Dummy read cycles are broken out per instruction, with separate codes for LDA $20F2, X, STA, X, and the indexed and indirect forms of load and store, distinguishing a missing dummy read from one performed on the wrong address. Each code is a small assertion you can turn into a unit test.

NTSC and RP2C02G assumptions decide what runs at all

The ROM was designed for an NTSC console with an RP2A03G CPU and an RP2C02G PPU. The documentation says plainly that some tests might be automatically skipped on hardware with a different revision. This is the sharpest constraint in the project and it is easy to miss. A test that checks the exact behaviour of a PPU revision will not tell you anything useful on a different revision, and the cartridge handles that by skipping rather than by producing a misleading failure. The practical consequence is that a clean run on a PAL console is not evidence that the PPU is correct, because the checks that would prove it never executed. The same applies to a Famicom with a different PPU, or to an emulator configured for a region the ROM was not written against. The B Flag test also asserts that an IRQ should have occurred, which depends on the console actually generating that interrupt in the way the test expects. Before trusting any result, confirm which hardware the emulator is emulating, and read the skip marks in the results table rather than assuming that an absent test was passed.

Building AccuracyCoin.nes from AccuracyCoin.asm

The repository ships the assembled cartridge, the assembler source, the graphics, and the assembler itself, so the project does not need a separate build step to be useful. The top level of the repository contains AccuracyCoin.asm, AccuracyCoin.nes, Sprites.pcx, Tiles.pcx, nesasm.exe, a LICENSE file, a README and a .gitattributes file. AccuracyCoin.nes is the artefact you load; AccuracyCoin.asm is the source you read when the error code list is not enough, and the documentation points you there for more information on any given failure. The two .pcx files are the tile and sprite graphics that the menu and the result screens draw with. The assembler is supplied as a Windows executable named nesasm.exe, and the repository does not document a build command line, so if you want to rebuild the ROM you should use the assembler the way its own documentation describes and confirm that the resulting cartridge matches the checked in AccuracyCoin.nes. There is no package manager entry, no Docker image and no release pipeline in this repository, and the project has no GitHub releases. Upgrade therefore means pulling a newer commit of the source rather than installing a versioned binary, which makes it worth checking what changed in AccuracyCoin.asm before you rebuild over a ROM you already trust.

Where AccuracyCoin is the wrong tool

AccuracyCoin is a diagnostic cartridge, not a test harness for a game, and the difference matters if you are picking a tool for a project. It never runs a game, never loads a save file, and never checks that a title boots. If what you need is confidence that your own game still works after a change to the emulator core, this ROM will not give you that. It is also a poor fit for a developer who wants a machine readable report, because results live on screen and in a table drawn by the cartridge. Anyone without a usable controller input path, whether that is a real pad or an emulator front end you cannot pause, will struggle to reach the full test set, since the run all command is reached through the menu and a specific cursor position. Finally, the results are specific to the 6502 and PPU, so the cartridge says nothing about APU behaviour, controller timing, or any non NES target. The README also points out that for a deeper look at a failing test, reading the fully commented assembly is the intended next step, which tells you the audience for this project: people who already read 6502 assembly and want to compare an implementation against the rules rather than against a passing score.

Editorial conclusion

AccuracyCoin fits emulator authors, hardware testers and 6502 developers who need to see which specific 6502 or PPU behaviour a core gets wrong, and its per test error codes make it far more useful than a single pass or fail result. It is the wrong tool for a game developer looking for a general regression suite, for anyone without a way to watch the test screen, and for PAL or Dendy consoles, because the ROM targets an NTSC unit with an RP2A03G CPU and RP2C02G PPU. Before committing, open AccuracyCoin.asm, check that the assembler setup on your machine matches the bundled nesasm.exe, and confirm that your emulator lets you read the text screens without an input lag you cannot pause.

Frequently asked questions

Official sources

1. 100thCoin/AccuracyCoin on GitHub
2. Issues
3. License: MIT
4. README