Very weird issue with Blargg CPU instr tests.

Very weird issue with Blargg CPU instr tests.
by on (#150807)
Hello guys,

I've been working on a new 6502 core for my NES emulator. I have basic PPU functionality implemented and input controllers.

I've gone for cycle accurate emulation.

The thing is that my CPU passes all of NesTest suite (Screenshot attached), yet I fail ALL of Blargg's CPU instructions tests except for the "01.basics.nes" single rom. Also the CPU passes some misc tests like "dummy reads" one (also Blargg's)...

I have no idea why (after 3 effective hours of logging / ranting / staring at my code). I'm looking for some advice from you guys, so I can start debugging in the right direction.

Thank you in advance!
Re: Very weird issue with Blargg CPU instr tests.
by on (#151733)
Ok, In the non-passing-blargg-tests version, I had implemented two big function pointer arrays of length 0x10000 (one for reads, one for writes), where each position represented a memory address in the 16 bit range. These arrays were initialized at run-time with pointers to the right memory handler functions (i.e. PPU, Ram, Cart, etc..). As for the fetch-decode-execute loop, I had a switch statement where the cases were tied to the addressing modes (the modes were listed in an enum). The addressing functions took a pointer to the instruction function as parameter, so it calculated the address first and then called that instruction.

I had to rewrite my CPU's fetch-decode-execute loop and memory handlers... So now it uses a huge switch statement that use a case label for each opcode (ugly but works fine), and has memory handler functions that use plain if-else statements for routing the accesses through the different addresses instead of huge function pointer arrays.

I still have no clue why blargg's tests didn't pass on the former implementation, even when passing nestest with no problem at all.

It'd be great to read some comments / thoughts about this from anyone interested.
Thanks in advance.