Where is the reset vector in a .nes file?

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

Post Reply
rdb9879
Posts: 1
Joined: Sun Jun 03, 2018 1:13 pm

Where is the reset vector in a .nes file?

Post by rdb9879 »

Greetings.

I am trying to learn how the 6502 CPU operates, and playing with NES code is a fun way to do it. I have NESICIDE setup to let me write C-code and use the built in debugging emulator. That is working fine with the "hello world" example program.

If I understood correctly, the 6502 CPU gets its program counter initialization value from a reset vector, hard coded at addresses $fffc and $fffd. However, the *.nes file that I have built only has $A00F bytes.

I'm assuming the *.nes file is not a raw hex file. Maybe either compressed or only containing the allocated sections? What seems even stranger is that the final hundred bytes or so are all constant $ff's.

Where is the reset vector defined?
User avatar
gauauu
Posts: 729
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Where is the reset vector in a .nes file?

Post by gauauu »

Take a look at the documentation about the INES file format. It should answer your question; if you have trouble understanding it, you can ask for clarification here.

Short version is: there's first a header that explains what to expect in the rest of the rom file. Then there's a chunk of CPU-addressable ROM data (what the documentation refers to as PRG-ROM), and potentially a chunk of PPU-addressable ROM data (CHR-ROM). The sizes (and whether the CHR-ROM data exists) would be dependent on what the header specifies. The vectors would be at the end of the CPU-addressable data.
User avatar
rainwarrior
Posts: 8062
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Where is the reset vector in a .nes file?

Post by rainwarrior »

There's 3 parts in the file: 16 byte header, uncompressed PRG (CPU) ROM, uncompressed PPU (GPU) ROM.

There's a lot of ways that the PRG ROM might be mapped into CPU address space. See mapper on the wiki.

For example, a simple 32k NROM (mapper 0) game will load that 32k ROM at $8000.

So if you're looking for a particular address, like $FFFA...

Offset in file (if 32k NROM): 16 + $FFFA - $8000

In FCEUX if you open the Hex editor, you can find the place you want to look at in the NES Memory view, right click and choose "go here in ROM", and this will take you to the corresponding address in ROM. This can be useful if you don't know enough about the mapper yet, it will automatically figure it out.
User avatar
dougeff
Posts: 2876
Joined: Fri May 08, 2015 7:17 pm
Location: DIGDUG
Contact:

Re: Where is the reset vector in a .nes file?

Post by dougeff »

To add a little...the exact location of the reset vector within a .nes ROM can vary, depending on the mapper.

One thing you can do...in FCEUX, is open the debugger. Hit "step into" to stop execution. Now reset the game. Now scroll all the way to the bottom of the debugging disassembly, and right click on the gray area to the left of the last address. It should open the hex editor at the exact location of the reset vector, in view=ROM mode. If you look at the top of the window, it will print the address of the selected ROM address.

Edit...the reset vector should be the 2nd to last address at the bottom of the disassembly in the debugging window.
nesdoug.com -- blog/tutorial on programming for the NES
User avatar
Sumez
Posts: 919
Joined: Thu Sep 15, 2016 6:29 am
Location: Denmark (PAL)

Re: Where is the reset vector in a .nes file?

Post by Sumez »

Just to provide a shorter explanation. $FFFF is a CPU address, and not a direct address in your .nes file. The CPU address space covers everything it has access to, including hardware registers and RAM.

What you are looking for is the part of the PRG ROM that gets mapped to $FFFF, as according to this CPU memory map: https://wiki.nesdev.com/w/index.php/CPU_memory_map

The .nes file basically _IS_ "raw hex" if you want to use that term. It's not compressed, it's just a header, the PRG ROM and the CHR ROM if present, all in order.
Post Reply