As I've finished the addressing modes and instruction execution, the CPU core, I want to test it before I go on to PPU and APU, so when I get errors there, at least I know they're not dragged from a faulty CPU emulation.
I've searched for test ROMs in the forum and in the main site, but all I found rely on the PPU for test results outputting.
I'd need a test ROM that tests for CPU instruction and addressing modes and outputs the results to a certain memory page so I can check them with a debugger. Of course the test ROM should have some sort of txt references to interpret those results.
I could make some test ROMs myself, but I might end up making the same mistakes that I made in the emu, or worst, making new ones.
I guess I will make some test ROMs anyway, but if someone can point me to one that's already out there, it would be of much help.
Thanks!
Can you use the debugger to trap writes to address $2007?
Well, if it's gonna be a manual test, I can as well just use the debugger to look at memory and registers before and after the instruction.
My
nes_instr_test should work. While it uses the PPU if available, it doesn't hang if it's not or if it doesn't work. It outputs all text to memory as well, so you can examine it even without a PPU. See the readme for full information.
Zepper wrote:
Petruza wrote:
As I've finished the addressing modes and instruction execution, the CPU core, I want to test it before I go on to PPU and APU
- I think annoying. Is that a big risk? I can't understand. Even if you get that test suite ok, it doesn't mean in anyways your CPU code is bug free.
So?
One idea is implement just enough of the PPU to get games to try to boot, so that you can tell you're on the right track toward a working CPU. You'll need it in order to test your CPU's NMI handler anyway.
- Make a dummy PPU that does nothing but vertical blanking. It need not render any graphics; only $2000.D7, $2002.D7, and /NMI need to be implemented.
- Find a known good emulator that can log every executed instruction.
- In both this emulator and your emulator, run Donkey Kong, Balloon Fight, or Mario Bros. (not Super Mario Bros.) until they first turn on rendering (that is, until they write a nonzero value to $2001).
- Compare the instruction logs between the two emulators, and try to account for any differences.
Thanks tepples! looks like a great guide for my next steps.
Any hints of such an emulator? I've used FCEUX so far for debugging.
FCEUX isn't perfect, but its debug menu does have
a trace logger, and its CPU should be accurate enough for you to gain confidence in your own.
Used bit.ly because phpBB's BBCode parser appears not to support braces in [url] elements.
...is a cryptic reply. What about that?
A quoted post may be followed by one of these, all of which mean agreement:
- This.
- That.
- Exactly.
- Right on.
- Quoted for emphasis / QFE.
- Quoted for truth / QFT.
I think he's answering to my question `so?`
But if that's the case, I still don't see the connection.
I was objecting to the cryptic nature of your replies, as confirmed by Petruza thinking you were answering his question. Often a person makes a comment, someone else asks what he's talking about, and the person points to something and says "that" as a shorthand for "that is what I was talking about". This new slang tepples linked to of "this/that" also having a dramatic meaning of "I agree with this/that" is cryptic to me, and difficult to even look up for its meaning unless one knows it happens to be in the Urban Dictionary (because one simply expects to find the definition of the word "this", not an explanation of an idiom using it). Tepples is the first who has ever pointed me to a description of it.
I'm still not making much sense of your first reply either, about it being annoying. What's annoying? What's the big risk you think Petruza is trying to avoid? Were you saying that you can't be sure the CPU really works without having a PPU? I agree regarding I/O mapping, because a CPU test can't be sure all the specific I/O addresses are wired to the proper chips. I disagree about testing the CPU itself; a CPU test can be much more thorough than a game, and give a clear pointer to which instruction(s) are at fault.
Basically, I get frustrated when people make cryptic replies. I guess it's like in school where they wanted you to write complete sentence answers, so it's really clear what the reply is. Maybe it's just me. Sorry.
Ok let's not make a big deal out of this.
If I assume a CPU test will only pass a CPU that handles correctly every 6502 instruction, sets the flags correctly, the results are right, the memory is read and written with the correct values and in the correct addresses, and the cycle count is accurate, then when developing the APU & PPU, I can concentrate on specific problems there, instead of wasting hours of debugging the PPU only to find out that STA $2000 was actually writing to $0020 instead.
There are two kinds of tests: quick
smoke tests to catch obvious errors and detailed tests to catch corner cases and timing errors. You can probably write your own smoke tests like this:
Code:
lda #8
sta $300
lda #9
sta $301
lda #10
sta $302
ldx #0
lda #8
cmp $300,x
bne fail
inx
lda #9
cmp $300,x
bne fail
inx
lda #10
cmp $300,x
bne fail
lda #1
jmp nextTest
fail:
lda #0
nextTest:
sta $7F0
But the CPU has no architectural way to measure its own timing, extra reads, or repeated writes to the same address. So some detailed tests will need a PPU or APU implementation because, for example, they might use PPU side effects to measure on what addresses the CPU executed side effects.
Yesterday I finished a usable version of a disassembler inside my emu and caught such a stupid error as the branch instructions making the jump AND advancing the pc the lenght of the instruction ( 2 bytes )
I guess I can make a simple ROM that performs some examples of every instruction and go step by step checking my disassembler to catch any other obvious errors like the previous one.