Atari 7800 NTSC signature check

[phoenixdownita]

Just a question.

 

Is it possible that the 7800 is satisfied by just checking the signature of the last 16KB (from 0xc000 to 0xffff)?

I asked because there's no way the BIOS can guess what banking the cart implements and yet it needs to do the check before releasing control to the code in the cart at the end of the address space.

 

I had a multi that was for 32K multigames and as some were only 16KB I simply doubled them in the actual ROM without ill effects.

 

http://atariage.com/forums/topic/224038-multicarts-suggestions/?do=findComment&comment=2983661

 

Either that or there is some special code/flag that is supposed to tell the 7800 how to bank in/out the pages while doing the check which seems a very weird to me.

Edited September 23, 2015 by phoenixdownita

[Trebor]

The below may help, from the link download in the post here, this is what has been documented:

 

"The rules for making a cartridge start up in Atari 7800 mode:

=============================================================

The encrypted cartridge hash at $FF80-$FFF7 must be valid. (This will not

be necessary with a European 7800 console, as they do not have the crypto

check.)

The high nibble of $FFF8 must be $F.

The low bit of $FFF8 must be set. This was at some time intended for a

region setting, with the USA apparently being the low bit. So just set

$FFF8 to $FF (which should mean "all regions"), and forget about it.

The high nibble of $FFF9 must be $4-$F, and should not include the bank switch

memory range of a bank-switched cartridge. This should be set to $F for

fastest startup whenever possible.

The low nibble of $FFF9 must be 3 or 7. 3 will disable the k3wl Atari

rainbow startup graphics, but won't make the game start any faster. So use 7.

The reset vector at $FFFC-$FFFD must point into the hashed range.

Technical mumbo-jumbo:

======================

The Atari 7800 encryption is based upon a hash generated from the cartridge

data. This hash is then encrypted (using the private key of P and Q which

were contained in the Atari ST program) and stored in the cartridge at

addresses $FF80-$FFF8. At startup, the Atari 7800 runs its own hash of the

cartridge data, then it decrypts the signature using the public key, N. If

the hash does not match the decrypted signature, the 7800 will start up the

cartridge in Atari 2600 mode.

Because the signature algorithm doesn't always have a valid solution, the

fourth byte in the hash is not checked for a match. Instead, it is changed

until a valid solution is found. This usually takes four or less attempts

at encryption, though I have seen it take as many as twelve.

The page range to be hashed will be a multiple of 4K, up to 48K. This

is specified in the cartridge at address $FFF9. The high nibble of this

byte refers to which page to start the hash. The $FF00 page is handled

specially, by zeroing out the bytes which will receive the signature.

One important thing to note is that the 7800 validates that the reset vector

points within the hashed page range. This was to prevent the making (either

accidentally or intentionally) of a "magic key" game in which the encrypted

range can be copied verbatim and otherwise ignored. In fact, Harry Dodgson's

monitor cartridge can be used this way, as only 4K is hashed, and the reset

vector points to a jump to outside of the hashed range.

Before generating the signature for a cartridge, the high nibble of $FFF9

must be set. Since the hash is slow enough on a 7800 that you can notice

the difference in startup time between a 4K hash and a 48K hash, it is

recommended for newly written games to always set this byte to $F0 and simply

make sure that the reset vector is in the $Fxxx range.

Also, when signing bank-switched games, $FFF9 should never be less than $C0

to ensure that the hash will not be dependent upon the bank switch area."

[CPUWIZ]

Just a question.

 

Is it possible that the 7800 is satisfied by just checking the signature of the last 16KB (from 0xc000 to 0xffff)?

I asked because there's no way the BIOS can guess what banking the cart implements and yet it needs to do the check before releasing control to the code in the cart at the end of the address space.

 

I had a multi that was for 32K multigames and as some were only 16KB I simply doubled them in the actual ROM without ill effects.

 

http://atariage.com/forums/topic/224038-multicarts-suggestions/?do=findComment&comment=2983661

 

Either that or there is some special code/flag that is supposed to tell the 7800 how to bank in/out the pages while doing the check which seems a very weird to me.

 

The last 4K is all you need.

[phoenixdownita]

OK, thanks, I kind of suspected it.

What did actual original games do way back when? 4K, 8K all the way to 48K? [for the ones that are that big with no banking]

Edited September 24, 2015 by phoenixdownita

[CPUWIZ]

OK, thanks, I kind of suspected it.

What did actual original games do way back when? 4K, 8K all the way to 48K? [for the ones that are that big with no banking]

 

I haven't looked at all of them, but the bigger the area, the longer the "booting" takes and nobody likes that.

[phoenixdownita]

 

I haven't looked at all of them, but the bigger the area, the longer the "booting" takes and nobody likes that.

I see.

So basically the last 4K could be made universal and then once the boot is done it's like open season, only the first jump has to be within the 4K, the next one can be anywhere. Right?

I know it would be a waste of 4K on the only officially fixed page but just speculating here.

[CPUWIZ]

No, you don't even need to jump into the last 4K first, the vectors are not part of the signature check AFAIK. I'll check my MCP devcart code later, but I think I am starting outside the last 4K.