Nintendo header: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(everynes detail)
(More caveats)
Line 1: Line 1:
About 33% of licensed Nintendo NES games have an header present at their last bank, at addresses $FFE0-$FFF9, right before the interrupt vectors. The [[Famicom Box]] reads this header to determine the title of the inserted game.
About 33% of licensed Nintendo NES games have an header present at their last bank, at addresses $FFE0-$FFF9, right before the interrupt vectors. The [[FamicomBox]] reads this header to determine the title of the inserted game.


The info in them is frequently incomplete and/or inaccurate. When info on a particular filed is not present, a byte $00 or $FF is used for padding.
The info in them is frequently incomplete and/or inaccurate. When info on a particular filed is not present, a byte $00 or $FF is used for padding.
Line 20: Line 20:
== Calculating the checksum ==
== Calculating the checksum ==


[https://problemkaputt.de/everynes.htm#famicomboxromheaderatffe0h Everynes] claims that the Famicom Box system software applies these rules:
[https://problemkaputt.de/everynes.htm#famicomboxromheaderatffe0h Everynes] claims that the FamicomBox system software applies these rules:
;NROM and CNROM: Sum of $E000-$FFFF, $C000-$FFFF, or $8000-$FFFF. The system software detects the size.
;NROM and CNROM: Sum of $E000-$FFFF, $C000-$FFFF, or $8000-$FFFF. The system software detects the size.
;UNROM: Sum of $8000-$BFFF in banks 0-7. Unsure how this interacts with $FFF0-$FFF1 exclusion in the case of UOROM, BxROM, or AxROM.
;UNROM/AOROM: Sum of $8000-$BFFF in banks 0-7.
;GNROM: Each 32 KiB bank has its own header with a checksum of that bank.
;GNROM: Each bank has a header with its own checksum of $8000-$FFFF. All checksums must pass.
;MMC: Sum of $C000-$FFFF, as if NROM-128. No bank switching is attempted.
;MMC: Sum of $C000-$FFFF, as if NROM-128. No bank switching is attempted.


Caveats for particular mappers
A checksum passes if the sum of bytes, minus the bytes at $FFF0 and $FFF1, matches the big-endian value at $FFF0.


Caveats for particular mappers, to be verified:
;UNROM: The checksum routine avoids bus conflicts by searching ROM for the first byte in $8000-$FFFF whose low bits match the low bits of the bank number, reading that byte, and writing it back. This causes problems with UOROM, as this a write with low nibble as a write intended to set bank 0 may instead set bank 8.
:For a 64 KiB UNROM, such as [[240p Test Suite]], the checksum routine reads each of the four banks twice. Thus it double-counts most bytes and (net) single-counts the bytes at $FFF0-$FFF1 because they also appear at $BFF0-$BFF1. A ROM will usually need an extra byte somewhere (such as at $FFDF) whose value is chosen to cancel the lower byte of the checksum of the rest of the ROM.
;AxROM and BxROM: 128 KiB ROM has four banks and thus has a similar double-counting caveat to 64 KiB UNROM. The checksum is in the last bank (bank 3 or bank 7) and, as usual, both bytes are subtracted before comparison despite not having been included in the original sum.
;MMC1: Sum of $C000-$FFFF at power on, as if NROM-128. No bank switching is attempted. Any 16 KiB bank that can be switched into $C000-$FFFF needs its own header with a checksum of that bank.
;MMC1: Sum of $C000-$FFFF at power on, as if NROM-128. No bank switching is attempted. Any 16 KiB bank that can be switched into $C000-$FFFF needs its own header with a checksum of that bank.
;MMC3, most VRCs, FME-7: Sum of $C000-$FFFF at power on, as if NROM-128. These mappers have a fixed bank at $E000-$FFFF and an unpredictable switchable bank at $C000-$DFFF. In order to get the checksum to match regardless of state, the sum of bytes in all 8 KiB banks other than the last must be identical. We seek evidence of games on these mappers having been released for Famicom Box at all.
;MMC3, most VRCs, FME-7: Sum of $C000-$FFFF at power on, as if NROM-128. These mappers have a fixed bank at $E000-$FFFF and an unpredictable switchable bank at $C000-$DFFF. In order to get the checksum to match regardless of state, the sum of bytes in all 8 KiB banks other than the last must be identical. Given the overall lack of mapper IRQ support in the FamicomBox, we seek evidence of games on these mappers having been released for FamicomBox at all.

Revision as of 00:25, 16 August 2021

About 33% of licensed Nintendo NES games have an header present at their last bank, at addresses $FFE0-$FFF9, right before the interrupt vectors. The FamicomBox reads this header to determine the title of the inserted game.

The info in them is frequently incomplete and/or inaccurate. When info on a particular filed is not present, a byte $00 or $FF is used for padding.

  • $FFE0-$FFEF : Name of the game, in ASCII. (sometimes the name is abbreviated or replaced by Nintendo's code). ASCII codes 20h-5Ah allowed. Should be right-justified.
  • $FFF0-$FFF1 : PRG checksum (either the last 16k bank, or the whole PRG-ROM). Sum of all bytes in the relevant area, excluding the two checksum bytes. Big-endian.
  • $FFF2-$FFF3 : CHR checksum. 0x00 if RAM. Big-endian.
  • $FFF4 : Data sizes. Values: 0 = 8 KiB or 64 KiB based on board type, 1 = 16 KiB, 2 = 32 KiB, 3 = 128 KiB, 4 = 256 KiB, 5 = 512 KiB
    • D7-D4: PRG size
    • D3: 0 = CHR ROM, 1 = CHR RAM
    • D2-D0: CHR size
  • $FFF5 : Board Type.
    • D7: 0 = Horizontal nametable arrangement, 1 = Vertical arrangement (inverse of iNES mirroring bit)
    • D6-D0: 0 = NROM, 1 = CNROM, 2 = UNROM/AOROM, 3 = GNROM, 4 = MMC (any). Determines which area to checksum.
  • $FFF6 : Title encoding : 0 = No title entered, 1 = ASCII, 2 = Another encoding
  • $FFF7 : Valid Title Length - 1. 0 if no title entered.
  • $FFF8 : Maker's code, the same used for the FDS, GB, GBC and SNES headers : 1 = Nintendo, 2-254 = everyone else. 255 must be reserved.
  • $FFF9 : Header Validation Byte. 8-bit checksum of $FFF2-$FFF9 should = 0

Calculating the checksum

Everynes claims that the FamicomBox system software applies these rules:

NROM and CNROM
Sum of $E000-$FFFF, $C000-$FFFF, or $8000-$FFFF. The system software detects the size.
UNROM/AOROM
Sum of $8000-$BFFF in banks 0-7.
GNROM
Each bank has a header with its own checksum of $8000-$FFFF. All checksums must pass.
MMC
Sum of $C000-$FFFF, as if NROM-128. No bank switching is attempted.

A checksum passes if the sum of bytes, minus the bytes at $FFF0 and $FFF1, matches the big-endian value at $FFF0.

Caveats for particular mappers, to be verified:

UNROM
The checksum routine avoids bus conflicts by searching ROM for the first byte in $8000-$FFFF whose low bits match the low bits of the bank number, reading that byte, and writing it back. This causes problems with UOROM, as this a write with low nibble as a write intended to set bank 0 may instead set bank 8.
For a 64 KiB UNROM, such as 240p Test Suite, the checksum routine reads each of the four banks twice. Thus it double-counts most bytes and (net) single-counts the bytes at $FFF0-$FFF1 because they also appear at $BFF0-$BFF1. A ROM will usually need an extra byte somewhere (such as at $FFDF) whose value is chosen to cancel the lower byte of the checksum of the rest of the ROM.
AxROM and BxROM
128 KiB ROM has four banks and thus has a similar double-counting caveat to 64 KiB UNROM. The checksum is in the last bank (bank 3 or bank 7) and, as usual, both bytes are subtracted before comparison despite not having been included in the original sum.
MMC1
Sum of $C000-$FFFF at power on, as if NROM-128. No bank switching is attempted. Any 16 KiB bank that can be switched into $C000-$FFFF needs its own header with a checksum of that bank.
MMC3, most VRCs, FME-7
Sum of $C000-$FFFF at power on, as if NROM-128. These mappers have a fixed bank at $E000-$FFFF and an unpredictable switchable bank at $C000-$DFFF. In order to get the checksum to match regardless of state, the sum of bytes in all 8 KiB banks other than the last must be identical. Given the overall lack of mapper IRQ support in the FamicomBox, we seek evidence of games on these mappers having been released for FamicomBox at all.