What do the last 8 bytes in a ROM mean?

[PacManPlus]

Hi:

 

I am trying to figure out what the last 8 bytes in a ROM image specify and I am having some trouble. Can someone help me?

 

For example, Ms.Pac-Man has the following bytes:

 

$FF

$C7

$4D

$F3

$20

$CA

$1C

$F4

 

I believe the $FF and the $C7 mean something as $C7FF I would imagine, because I know that $CA20 is the entry point to the program (the 5th and 6th bytes reversed).

 

I just cannot figure out what the $4D, $F3 and the $1C, $F4 mean.

 

Thanks in advance for your time.

 

Bob

Edited October 12, 2006 by PacManPlus

[SeaGtGruff]

Hi:

 

I am trying to figure out what the last 8 bytes in a ROM image specify and I am having some trouble. Can someone help me?

 

For example, Ms.Pac-Man has the following bytes:

 

$FF

$C7

$4D

$F3

$20

$CA

$1C

$F4

 

I believe the $FF and the $C7 mean something as $C7FF I would imagine, because I know that $CA20 is the entry point to the program (the 5th and 6th bytes reversed).

 

I just cannot figure out what the $4D, $F3 and the $1C, $F4 mean.

 

Thanks in advance for your time.

 

Bob

The last 6 bytes of a ROM are vectors, with the least-significant byte followed by the most-significant byte, although some Atari 2600 ROMs use two of them for bankswitching hotspots.

 

$FFFA and $FFFB are the non-maskable interrupt (NMI) vector. The Atari 2600 doesn't have NMIs, so these two bytes are used as bankswitching hotspots for Atari's 32K bankswitched cartridges. But the Atari 7800 *does* have NMIs, so I presume that these two bytes are used for the NMI vector in an Atari 7800 ROM cartridge.

 

$FFFC and $FFFD are the reset or boot vector. When a game is powered up, the Atari jumps to the address pointed to by this vector. In the example you gave, that would be address $CA20.

 

$FFFE and $FFFF are the BRK or IRQ interrupt vector.

 

MR

[kenfused]

Hi:

 

I am trying to figure out what the last 8 bytes in a ROM image specify and I am having some trouble. Can someone help me?

 

For example, Ms.Pac-Man has the following bytes:

 

$FF

$C7

$4D

$F3

$20

$CA

$1C

$F4

 

I believe the $FF and the $C7 mean something as $C7FF I would imagine, because I know that $CA20 is the entry point to the program (the 5th and 6th bytes reversed).

 

I just cannot figure out what the $4D, $F3 and the $1C, $F4 mean.

 

Thanks in advance for your time.

 

Bob

 

.byte $FF ;Region verification ???

.byte $F7 ;only validate 4K (one less than the page to start verification on?)

.word NMI ;NMI addr

.word START ;start addr (I think this has to point to within signed code)

.word IRQ ;IRQ Address

[EricBall]

DC.W ROMTOP + $07FF

NMI DC.W DLLNMI

RESET DC.W START

IRQ DC.W IRQRTI

 

Where ROMTOP is the first page (through $FF7F) the NTSC digital signature ($FF80 - $FFF7) covers. On PAL cartridges I believe these bytes are still used to detect 2600 cartridges.

 

The NMI vector is used by the MARIA DLI interrupt.

 

On powerup the 7800 starts with the BIOS ROM active. Once the BIOS determines the cartridge is a 7800 cartridge (or a 2600 cart & locks the 7800 into 2600 mode), then it does an indirect JMP to the RESET vector.

 

The NTSC BIOS also checks to make sure the three vectors point to addresses inside the area covered by the digital signature.

[Bruce Tomlin]

Hi:

 

I am trying to figure out what the last 8 bytes in a ROM image specify and I am having some trouble. Can someone help me?

 

For example, Ms.Pac-Man has the following bytes:

 

$FF

$C7

$4D

$F3

$20

$CA

$1C

$F4

 

I believe the $FF and the $C7 mean something as $C7FF I would imagine, because I know that $CA20 is the entry point to the program (the 5th and 6th bytes reversed).

 

I just cannot figure out what the $4D, $F3 and the $1C, $F4 mean.

 

Thanks in advance for your time.

 

Bob

As everybody else has already said, the last six bytes are the standard 6502 reset/IRQ/NMI vectors, low byte first. I seem to recall that NMI is generated by the Maria, and IRQ is generated from the cartridge slot.

 

$FFF8 and $FFF9 have special meanings. I'm looking at the documentation from my sign7800 program, and here's a quick summary:

 

$FFF8 is used for the region checking. The high 4 bits must always be set ($Fx), and on a US machine (EDIT: apparently this is not true!), the low bit must be set. Presumably there is no region check in the PAL version, but I would have to check. - - - Hmm, I just checked my disassembly where I merged in the NTSC source where possible, and it checks the same bit in PAL.

 

$FFF9 is used for the signature check and for the rainbow ATARI screen. The high 4 bits are the high nibble of the lowest address in the digital signature range. The ROM is hashed from that address to $FF7F, then the hash is run through the crypto routine. This should not include bank-switched memory, so in larger games this will be $Cx, $Dx, $Ex, or $Fx. The higher this number, the faster the startup, so just 4K ($Fx) is optimal. The low nibble must be $x3 or $x7. $x3 will disable the rainbow ATARI, but the game won't start up any faster.

 

And the reset/IRQ/NMI vectors MUST point into the address range that is checked for the digital signature.

 

REGION	EQU	 $FE				 ;MASK FOR COUNTRY
...
	  LDA	 $FFF8			;CHECK FOR REGION VERIFICATI...
	  ORA	 #REGION
	  CMP	 #$FF
	  BNE	 BADCART
	  LDA	 $FFF9			;SEE IF MARIA SIGNATURE EXIS...
	  AND	 #$0B				;$07 OR $03 VALID
	  CMP	 #$03
	  BNE	 BADCART
	  LDA	 $FFF9			;GET BOTTOM OF CART ADDRESS
	  AND	 #$F0
	  STA	 CARTBOTM
	  STA	 CSCMOD0+2-CODEDIF;SET UP FOR START OF CHECKSU...
	  CMP	 #$40				;MAKE SURE IT IS NOT TOO LOW
	  BCC	 BADCART

Edited October 13, 2006 by Bruce Tomlin

[supercat]

This should not include bank-switched memory, so in larger games this will be $Cx, $Dx, $Ex, or $Fx.

 

I wonder whether there would have been any technical problem, back in the day, with a company that had rights to one 7800 game, producing a cart which would initially read out as the game to which they had rights, but then upon seeing the jump to ($FFFC) would bank-switch to a different program (one that hadn't been approved). The logic for that wouldn't seem too hard. Wonder what Atari would have done?

[kenfused]

I wonder whether there would have been any technical problem, back in the day, with a company that had rights to one 7800 game, producing a cart which would initially read out as the game to which they had rights, but then upon seeing the jump to ($FFFC) would bank-switch to a different program (one that hadn't been approved). The logic for that wouldn't seem too hard. Wonder what Atari would have done?

I believe there was at least one cart that was minimally signed (4K), and one of the first things it did was jump out of that area. So that in theory could have been used to create third party/homebrews (at a loss of 4K of space). I think the signing program didnt come along too long after that though.

[Bruce Tomlin]

I wonder whether there would have been any technical problem, back in the day, with a company that had rights to one 7800 game, producing a cart which would initially read out as the game to which they had rights, but then upon seeing the jump to ($FFFC) would bank-switch to a different program (one that hadn't been approved). The logic for that wouldn't seem too hard. Wonder what Atari would have done?

I believe there was at least one cart that was minimally signed (4K), and one of the first things it did was jump out of that area. So that in theory could have been used to create third party/homebrews (at a loss of 4K of space). I think the signing program didnt come along too long after that though.

Harry Dodgson's monitor cart. However, that dates to the end of the 7800's life, and the approval process at Atari could have done a quick check for something obvious like that back when people were still making 7800 games. But it meant that you might have to copy someone else's copyrighted code, and more importantly, you would have to waste 4K of ROM, making your game bigger than it had to be.

 

Fortunately, the signature generator program was found not once, but twice, and the key and algorithm (relatively) were easily extracted.

Edited October 14, 2006 by Bruce Tomlin