Hi @olduf - thanks for the detailed report. I'm new to the emulation space but as far as I can tell this is a real issue. addresses 308 (0x134) and 4404 (0x1134) map to the same physical CPU RAM address.

Apologies for the long time with no input; I'm very wishy-washy on this.

On the one hand the tests in net are designed not to assume anything external to the CPU — including how addresses are decoded.

On the other, the Ricoh 2A03 (/'NES 6502'): (i) is used (almost) exclusively in the NES; and (ii) includes the APU and some other parts in the chip, so the "external to the CPU" test is fuzzier than it should be.

I think possibly a good compromise would be just to restrict all memory accesses in the NES-specific tests to the first 2kb of memory? Would that satisfy the problem adequately?

I think possibly a good compromise would be just to restrict all memory accesses in the NES-specific tests to the first 2kb of memory? Would that satisfy the problem adequately?

Now that I've finished my cycle-accurate CPU emulator of this chip for the NES I feel more confident weighing in here.

I think it could be an improvement to only use addresses that don't have special mapping behavior, but it invites a lot of complexity. I'm confused about why you're choosing the first 2KB (assuming this is 0x0000 - 0x1fff which is just 0x0000 - 0x07ff mirrored.

However if we do acknowledge the memory mapping, then that invites a lot of additional complexity where we need to support mappers.

I think the real issue is that the documentation could be more explicit (instead of implicit) about not choosing to respect memory mapping or any special cartridge mapping behavior, and I do like that this suite of tests allows me to properly isolate and unit test the CPU. Time and energy permitting, I'd like to find a suite of test roms and create some per-cycle truth data with a similar level of thoroughness found in this repo. (It's a fantastic repo!)

I'm confused about why you're choosing the first 2KB

The first 2kb runs to address 0x07ff; up to 0x1fff would be the first 8kb.

However if we do acknowledge the memory mapping, then that invites a lot of additional complexity where we need to support mappers.

I'm suggesting I just get the generator silently to drop any test that happens to generate an access outside of the range [0x0000, 0x07ff] and let it keep going until there are the desired number of test cases.

... though more explicit documentation might also just be the correct fix.

So I've gone with "more explicit documentation" as the immediate fix, as per #37 but if I can persuade myself that an appropriate test filter — such as the proposed first-2kb-only, but possibly something else — would render the issue moot then I'll return to the topic.