6502 CMOS (rockwell and WDC) have incorrect tests for BBR/BBS?

[jmchacon]

I've been running the tests on my impl (https://github.com/jmchacon/rusty6502) and everything on the base 6502 and NES variant I have in 100% agreement and that also lines up with my understanding of the chips too.

CMOS is a different story. Specifically 0x0f and the corresponding copies for BBR0-7/BBS0-7. For this example let's look at the first entry for 0f.json:

wdc65c02/v1/0f.json

{ "name": "0f f4 b5", "initial": { "pc": 41715, "s": 119, "a": 58, "x": 163, "y": 251, "p": 225, "ram": [ [41715, 15], [41716, 244], [41717, 181], [244, 253], [41643, 230], [41718, 31]]}, "final": { "pc": 41718, "s": 119, "a": 58, "x": 163, "y": 251, "p": 225, "ram": [ [244, 253], [41643, 230], [41715, 15], [41716, 244], [41717, 181], [41718, 31]]}, "cycles": [ [41715, 15, "read"], [41716, 244, "read"], [244, 253, "read"], [244, 253, "write"], [41717, 181, "read"], [41643, 230, "read"]] },

This is

BBR0 0xf4,0xb5 which would jump if bit0 is clear at location 0xF4 which it's not since it's 0xFD. The final state seems to confirm that as the PC is set to the next instruction and didn't jump.

The cycles sequence doesn't make sense here though due to the write on cycle4. No part of this instruction ever writes back to RAM. It's a load instruction, not store or RMW. This appears to be accurate but just slipped a write in after the ZP read. Otherwise it's correct if I remove the write. Additionally a missed branch is 5 cycles, not 6 like this is claiming which is also confusing.

While I agree there are lots of errors in docs out there I'm basing this on

https://web.archive.org/web/20141129202001if_/http://archive.6502.org/datasheets/wdc_w65c02s_feb_2004.pdf

which on page 33 shows the sequence WDC documented for this instruction (9b) which lines up with other testing I've done ( Klaus Dormann's functional tests I can pass all the CMOS related ones which does test BBR/BBS).

So it looks like if I stripped all the extra write cycles from these instructions things work as I expect. Is this just a bug in the generation code?