N64 headers are part of the ROM. There was some idiot on a crusade to remove them and obviously wasn't bright enough to realize this breaks them.
The first 0x40 is the internal header, but you can only rely on the first 0x18 being set. Prototypes don't always set an internal name or ID, as the IDs were provided by Nintendo when accepting them for release. In fact, there's a fairly good chance the protos you see with complete headers were added by the people who clean the dumps so certain HLE emus can run them.
From after the 0x40 header until 0x1000 is the bootstrap, which you'll find is remarkably similar between games. I'll get into that in a minute. Generally the game executable follows, but this isn't mandatory. Otherwise, there's no standard format for N64 data like with NES carts. They can put whatever data they want wherever they want. It's just a big block of free memory.
Depending on how you plan for your emulator to work, you may or may not need to parse the header at all. If you're using a PIFrom, the header will be unpacked without any real effort on your part and the bootstrap will be automatically copied. PIFrom is copied to BFC00000 at boot and the PIF is responsible for forcing the video mode. You're expected to provide a few other values though, which would normally be provided by the CIC chip (and maybe system, not 100% clear on the particulars):
BFC007E4: device state flags
00080000 S3: osRomType (True boots from IPL, not cartridge)
00040000 S7: osVersion
00020000 S5: osResetType
0000FF00 S6: CIC seed value
000000FF mirror of CIC seed value, unread
From there, PIFrom automatically passes control to the bootstrap, and this in turn passes control to the main game executable.
If you aren't using PIFrom you'll have to do what it does manually. Firstly, you'll need to copy the bootstrap to A4000040, which you'll recognize as being SP memory. Set S3 = osRomType, S4 = osVideoMode, S5 = osResetType, S6 = CIC seed value, and S7 = osVersion. You'll also have to do the register initialization the PIF usually does, but that's involved enough to make this post a bit messy. Either way, the bootstrap will boot the game as normal.
You can thank Intel for little-endian ROMs. The native format is big-endian, but one common copier switched them around. You can't rely on any file extension to determine endianess. As an example, .n64, which in the previous post was listed as little endian, was the registered extension for N64 ROMs in the Monegi Multi Viewer. It expected them to be big-endian. The N64 is locked into big-endian as far as I can tell, but technically the endianess would be determined by whether the high bit (0x80) of the first or second byte is set.
Despite several popular emulators using the internal region code to determine the region of the game, the N64 never looks at it. Of course, an individual game may, but the system is blind to all header data beyond the first 0x18.
You shouldn't need it for emulation purposes, but this is a slightly amended table of the header, stolen from somebody at Dextrose ages ago. If I knew who it was I'd give them credit, but alas, I do not. Fairly certain Release is not properly subdivided.
0000h (1 dword): initial PI_BSD_DOM1 REG settings
80000000 indicator for endianess
00F00000 initial PI BSD Domain 1 Release reg
000F0000 initial PI BSD Domain 1Pages reg
0000FF00 initial PI BSD Domain 1Pulse Width reg
000000FF initial PI BSD Domain 1Latency reg
0004h - 0007h (1 dword): ClockRate
FFFFFFF0 ClockRate override
0008h - 000Bh (1 dword): Program Counter (PC)
000Ch - 000Fh (1 dword): Release
0010h - 0013h (1 dword): CRC1
0014h - 0017h (1 dword): CRC2
0018h - 001Fh (2 dwords): Unknown (0x0000000000000000)
0020h - 0033h (20 bytes): Image name
Padded with 0x00 or spaces (0x20)
0034h - 0037h (1 dword): Unknown (0x00000000)
0038h - 003Bh (1 dword): Media format ('N' for carts, 'D' for disk, 'E' for expandable carts)
003Ch - 003Dh (1 word): Cartridge ID
003Eh - 003Fh (1 byte): Country code
003Fh - 0040h (1 byte): Version (i.e.: 00 = 1.0, 15 = 2.5)
0040h - 0FFFh (1008 dwords): Boot code