I wonder if any of you more experienced emu developers have any idea what might be causing my sprite bug.
When I run Mario Bro and Donkey Kong 3, some of the sprites are missing.
I'm pretty sure the problem is in the CPU code, but I have no idea where. I replaced my CPU code with a different one and the problem goes away.
My CPU code passes all the Nestest and Nestress tests (except for the invalid op codes, which are not used in these games).
So, any idea what might cause this type of problem? Long shot I know, otherwise I'll have to step through every instruction!!
If you're passing every nestest test (apart from illegal opcodes), then your CPU is fine. However, you're post is to vague to help you with. Could you supply us with a screenshot? Are you cycling through all 8/64 sprites per scanline?
First thing that comes to mind is a timing problem. Perhaps your instructions are too long? This wouldn't be caught by nestest and depending on how you're doing your PPU emulation it might cause some strange graphical problems.
But that's a shot in the dark. How I usually go about solving such problems is I make a tracelog and compare it to another emu's tracelog (FCEUXD can dump tracelogs) or examine it on my own to see if I can spot what's going wrong. If you don't have a tracer built into your emu -- I would highly recommend taking the time to make one -- problems like this come up all the time during all stages of development. The work you put into it now will more than pay for itself with the problems it helps you solve later.
Yep, I'm cycling through all the sprites - but in some games they don't all appear.
I appreciate is a bit vague, I was just hoping someone had had seen a similar problem before (or maybe just a bit of sympathy!!).
So.. in the first level of Mario Bro, Mario is drawn, but only one turtle/koopa ever comes out of the pipe and if if mario turns him and lands on it, the level ends.
In DK3, I get no buzzbees, but DK and Mario are drawn OK.
It's good to know nestest is supposed to be comprehensive, but I'm not convinced because both problems go away when I switch CPU emus and use the same rendering code. BTW the other CPU emu fails most of the nestests!!
Thanks for the reply anyway.
No CPU test can ever be 100% comprehensive. In order to test one opcode, it has to assume several others are working properly. So it's very possible for false positives to occur.
Can you upload the source to your CPU emu? I could give it a once over and see if I can spot anything really wrong.
Since you have code that makes things work, you should focus on the differences between it and your code. As Disch said, log a trace of each and find where they differ. The trace could be as simple as a log of the program counter before each instruction. If those all match, then you'll need to log register values too.
Phew, I found it! It was a problem with INC ABSX ($FE) storing the incremented value at the wrong address.
The fact that Nestest didn't spot the problem might be a bit of a warning to others; don't rule out problems in your processor code prematurely just because it passes Nestest.
Saying that, I found Nestest VERY helpful - it did find a few other problems that I wouldn't otherwise have spotted.
Thanks everyone for the suggestions. Comparing debug logs helped once I fixed differences in timing/interrupts and other oddities.
Indeed. Well, I had an addressing mode problem which none of CPU tests pointed it.