nestest -- reset vector points to 0xC004?

Hey guys,

So I am testing my CPU with nestest. If I hardcode the program counter to start at 0xC000 (like the golden log does), I get pretty good results. Not perfect, but way better than I expected for my first try! However, if I try to initialize the program counter from the reset vector, I always get 0xC004. Right now I have a really dumb romloader implementation that has just enough to load nestest basically. I just blindly load starting from byte 0x0010 of the rom, and starting from memory address 0x8000. I always load the current byte into the current memory address, and the current memory address + 0x4000, then iterate both. The loop runs 0x4000 times. Stupid, but should be good enough.

For loading the program counter on reset (which I also call on a "power on"), I set it equal to the value at memory location 0xFFFD left-shifted 8 bits and then i OR that with the value at memory location 0xFFFC.

Is there anything obviously wrong/problematic in the logic I've mentioned? If not, what else should I look at, or what other info can I provide to help me figure out where I've gone wrong?

Thanks in advance!

From nestest.txt:


$C004 is indeed the normal reset address, but there's an automated mode that runs if you run it from $C000. I suppose this is meant for emulators that don't yet have video or input implemented.

I've read the initial post 3 times now. I don't understand what the "problem" is, re: "what other info can I provide to help me figure out where I've gone wrong?" ROM in question has a reset vector of $C004. Your emulator appears to read the reset vector correctly. So... what's the actual issue? :-)

Yeah, I don't either. He says things are better than expected when executing from $C000, but doesn't say what happens when the PC starts as $C004.

I was just pointing out that it should work either way. The normal entry point is $C004, as specified by the Reset vector, but there's a special mode for incomplete emulators if run from $C000. A complete emulator should be able to execute the program from both entry points.

Ok, so because I saw the golden log start from C000, I thought that I was somehow reading the reset vector incorrectly. Also, when I run from the reset vector, it chokes after only a few instructions. Is this expected if I only have CPU and memory implemented?

Probably. No offense intended (honest), but you're stating a lot of "I don't know anything!" kind of things. Might I suggest you get familiar with the ROM in question by, say, looking at it in a debugger and stepping through its behaviour during power-on to learn? Use something like FCEUX or Nintendulator emulators, as both have good debuggers.

The only way a "test ROM" can work is if several (many) CPU instructions and addressing modes are implemented correctly. The ROM in question comes with a readme that provides insights into its behaviour. You might also find this useful: http://wiki.nesdev.com/w/index.php/Emulator_tests

Yes, it is totally normal - one of the first things it does is poll the PPU (via memory-mapped register at $2002) to wait until it finishes initializing, and even in a fully working emulator that's going to loop for about 10,000 instructions before it continues.

You'll also observe this behavior if you load any other ROM, since it's pretty much a standard part of system initialization that every properly formed program needs to do - if the NES had a BIOS (which it doesn't), it'd have been done in there instead.

No offense taken!-I'm definitely brand new at this. I had read the wiki page, but as far as I could tell it just links directly to the Rom and log without a lot of explanation. Thanks for the readme link, that will help a lot. I decided to focus just on implementing the CPU and memory to start, hence my ignorance about the rest of the system.

I have implemented all of the addressing modes and non-illegal opcodes, so I am trying to use nestest to make sure I have that stuff correct before I try my hand at anything else. I think most of my confusion with that resulted from not having the readme. I've mostly just been reading the links under the cpu section of the nes reference part of the wiki, and trying to really just digest that portion of it. I have read the NESDOC pdf to get a high level view of everything, but again I wanted to narrow my focus at the beginning so I don't get overwhelmed.

Thanks for all of the great replies, you guys have a fantastic community here

I'm sure I'll be back with more noob questions as I move forward with my project