nesdev.com

I've been working on a new test framework that can run multiple groups of tests and give better feedback. As a first use of it, here's a set of CPU tests that do most instructions, testing several edge cases. If it fails, it prints the opcode and instruction name. It only tests official instructions right now.

blargg_nes_cpu_test5.zip

These tests work like zexall, trying each instruction with all interesting combinations of inputs and checksumming the registers afterwards. After all the different combinations have been fed to a particular instruction, the checksum is compared with the correct one to determine pass/fail.

EDIT: Replaced with version that doesn't stop on failure, so you get a list of all the instructions that failed.

Can you make it continue after an instruction fails?

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!

Woot! Mine passed ok!

_________________
Zepper
RockNES developer

Thank you for your work on these test case ROMs, I found some more bugs!

Any idea if you're going to add illegal opcode support?

_________________

I've been trying to get this to pass since you've posted it. How exactly is this testing the functions? I'm failing several but is failing of one dependent on the others? I'm getting this (at bottom) but as I go over the functions, everything seems right. Example: ASL, a

Is tmp an 8-bit variable, or more? It could be that one of the instructions used to do the tests isn't working correctly. What does kevtris' nestest say?

The variable tmp is an unsigned int; nestest gives all OK as does the older NEStress. Though not all of your other test pass yet if that matters too.

If tmp is an int, then your code calculates the Z flag wrong!

tmp = memory_read(addr);
tmp <<= 1;
zero_flag = !(tmp);

What happens if this reads 0x80 from memory into tmp? After the <<= 1, tmp=0x100 when it should be 0, and the zero flag is erroneously clear!

New version, tests most unofficial instructions now, more thorough instruction coverage, and includes some documentation and full source code. Switched to MMC1, since apparently UxROM doesn't strictly support CHR ROM. Thanks to bunnyboy and thefox for testing help:
blargg_nes_cpu_test5.zip

I like it, I got errors with cpu.nes on AB ATX, 9C SYA, 9E SXA. I was able to fix ATX by ORing A with $FF, according to documents it's ORed with $EE, $EF, $FE, or $FF depending on CPU internal state like the program counter. Maybe on the NES it's always ORed with $FF, at least it makes your test program a bit happier on my emu.

I couldn't fix my SYA and SXA implementations, can someone explain how these work? I'm currently using this method:

http://www.s-direktnet.de/homepages/k_nadj/opcodes.html

$EF in particular looks like the mask for a carry coming out of the lower nibble, as might be seen in hardware handling packed binary-coded decimal, such as the original 6502 CPU manufactured by MOS Technology.


This might be the case for the NES, which for patent reasons uses a cut-down 6502 core lacking decimal mode.

I just tested and 9C and 9E are screwey. I need to take them off the test. Depending on X and Y they sometimes write to $700, among other things. Maybe someone else can figure them out properly.

Opcode $AB is known to work differently depending on the machine. Possible outcomes I've seen reported:

1. OR with $EE always
2. OR with $EE, $EF, $FE, or $FF based on the contents of other registers
3. OR with a seemingly random value (possibly influenced by DMA transfers)
4. Perform no OR operation at all (go straight to the AND step)

I think this opcode is triggering a bus conflict, causing the bits in A to get forced high in some cases (machine-dependent). Unless people test this opcode on multiple NES's to see if it works the same on all of them or not, we should assume the exact behavior to be unpredictable.

Exactly what is causing errors with $9C and $9E? Specifically, do problems show up during page boundary crossing, when there's no page crossing, or both? I suspect that since the store value is affected by the upper byte of the target address (the "fixed" version, with 1 added to it), it's possible that a page crossing would also cause an issue with the upper address lines during the store cycle. I haven't seen any docs that give light to this possibility, but that may be because no one tested it.

_________________
"Last version was better," says Floyd. "More bugs. Bugs make game fun."

You're right. Not that I've verified this on the NES, but blargg_nes_cpu_test5 passes on my emu if I mask the high address byte with $00 if there's a page crossing on SYA or SXA. Simply ignoring the write on page crossing made it pass too. Though, ORing it with $700 on page crossing (making it sometimes write to $700 like blargg said), makes it fail.