nesdev.com

Hi !

Sorry for this very noobish question, I just took some time from my almost complete GB emulator, and wanted to try some NES stuff.

I just started reading documentation, played with FCEUX debugger, and tried to understand about this reset vector, that when read, the program counter is assigned to that value.

Now, I'm checking Donkey Kong USA, no memory banks, but cannot find the address that FCEUX shows me anywhere on the entire rom (reading it as hex), searched for it low endian and big endian.

So, how is this reset vector gets assigned (memory 0xFFFC and 0xFFFD) initially ? Does this address come from the gamepak or is hardcoded into the nes cpu ?

Thanks,

The ROM from the cartridge gets mapped into $8000-$FFFF. The reset vector is part of the ROM.

The 6502 is little endian. Donkey Kong's reset vector is $C79E, which you'll find stored in the vector table as $9E then $C7, consecutively.

This reference may help: http://wiki.nesdev.com/w/index.php/CPU_memory_map

Yes I've read most of those pages.

Still can't get it, I searched the rom for "9E C7" with a hex editor and couldn't find it. So where is it supposed to be ?

Also, that DK rom has a size of 0x6000. Am I supposed to map it entirely to 0x8000 - 0xFFFF ? I read that these older games, maps the cartridge from 0x8000 to 0xBFFF, and then it mirrors the rest (0xC000 - 0xFFFF), but since this game has more than 0x4000 of size, what happens with the extra 0x2000 ? is it not used ?

Sorry, I'm really frustrated =(

Well, maybe the next thing to look at is the file format for NES ROMs: http://wiki.nesdev.com/w/index.php/INES

There is a separate memory space for graphics, on the NES. The Donkey Kong cartridge has two ROMs in it, not just one. One is called the PRG-ROM (used by the CPU), and the other is called the CHR-ROM (used by the PPU graphics chip).

The PPU memory layout is described here: http://wiki.nesdev.com/w/index.php/PPU_memory_map

$0000-$1FFF on the PPU is mapped to the CHR-ROM in the cartridge. It represents the graphics tiles used for sprites and backgrounds. Does this explain the extra $2000 worth of data you found?


You'd expect it to appear at $FFFC when mapped into the CPU's memory space. You've already realized that Donkey Kong only has 16k, and not a full 32k, so it gets mirrored at both $8000 and $C000. $FFFC is in that second region, so the offset of the reset vector in the ROM is:

$FFFC - $C000 = $3FFC

Finally, an iNES file has a 16 byte header, so:

$3FFC + $10 = $400C

That's where you should find your reset vector ($9E, $C7).

That's really useful information !!! Thank you so much,

As to why I couldn't find that reset vector while searching, well, let's say I screw up and opened DK in the NES debugger, and opened DK jr in the hex editor .. =D

If your hex editor isn't already in rows that are a multiple of $10 (16), then you should resize it to be. It makes things much easier; 16-byte rows particularly are nice if you're hexing CHR, as it makes for one tile per row.

yes, that was the default in HxD, great editor.

Thanks for the tip !