Byte order of Jaguar ROM images and cartridge EPROM

[Richard42]

Hello all,

 

I just wanted to post here and note some useful things that I learned in the last few days, since I had searched quite a bit for this information online and didn't find it. Hopefully it will be useful for someone else in the future who gets sent here by a search engine. I am a software engineer and long time vintage game and computer collector, and I recently started building a Jaguar collection. The availability of documentation and tools for homebrew gave me the idea to write a game for the Jag. I'm at a very busy point in my life so it might not get done for a few years but I thought I would at least get the hardware to make it happen now in case these things get more rare in the future. I got a skunkboard off of ebay and a bunch of parts to make 20 cartridges (I hope to sell the game). My EPROM burner is a GQ-3x from mcumall with the ADP-054 adapter to be able to burn the 27C160 42-pin rom.

 

I have a bunch of ROM images from many years ago when I tried to get Virtual Jaguar working on my Linux PC (I think the old version that I have isn't really playable with any of them). I thought I should get my feet wet (and make sure the eproms I got from China worked) by burning a ROM image. The rom images that I have end with a .jag extension. A lot of the homebrew images are odd sizes (not powers of two), but the commercial game images are 1MB, 2MB, or 4MB. The major problem here is to figure out how to split/pad/etc the rom images into two binary 2MB files suitable for EPROM burning.

 

Through trial and error, I figured out that these .JAG files consist of a series of 32-bit values in little-endian byte order. This is surprising, because I can see by using the Unix 'strings' program that the text messages embedded in the rom images are not byte-swapped. The letters in the messages appear in normal order. So that means it must be common to store strings in a little-endian format in data areas in Jaguar programs. I wrote a program (attached) to split a single 32-bit .JAG ROM image into 2 separate 16-bit binary eprom images suitable for burning. Since the data are stored in little-endian format in the image file, the low 16-bit EPROM binary comes from the first 2 bytes of each 4-byte group, and the high EPROM binary comes from the second 2 bytes of each 4-byte group. My eprom burning software expects the data for a 16-bit EPROM image to be in big-endian order, so I also swap each byte pair before writing out the EPROM binary.

 

The Jaguar cartridge interface is 32-bits wide. In order to figure out which EPROM chip on the cartridge supplies with the high 16-bits and which one supplies the low 16-bits, I looked at the traces on a cartridge PCB and read the documentation on this web page: http://www.mdgames.de/jag_pcbs.htm The low bits D15-D0 are wired up to the top chip (farthest away from the edge connector), while the high bits D31-D16 are wired up to the bottom chip (closest to the edge connector).

 

One thing that I do not yet know is how to generate the images for <4MB ROMs such that they pass the authentication check. Does the extra space on the 16-megabit EPROM need to be padded with 0xFFFF, or 0, or duplicate images of the ROM? Does anyone know?

romsplit.zip

[GT Turbo]

SCPCD or Zerosquare can answer you/

 

[Matthias]

Hello!

 

...

One thing that I do not yet know is how to generate the images for <4MB ROMs such that they pass the authentication check. Does the extra space on the 16-megabit EPROM need to be padded with 0xFFFF, or 0, or duplicate images of the ROM? Does anyone know?

 

The authentication check will read parts of the very first $2000 bytes of the cartridge-ROM and then run the verification against the rest of the ROM based on what those first $2000 bytes contained, these $2000 are usually called 'encryption header' (btw: this header also contains the info about the bus-width of the cartridge).

 

Those 1 MB, 2MB or 4MB ROM-dumps that you spoke about contain the valid encryption header, but game-files that you generate yourself do not, so you need to add the appropriate data to them.

 

There are 2 options:

1) Full standard encryption process including padding and splitting using tools that Atari provided.

 

2) Using the so called 'Universal Encryption Header', by simply attaching this $2000-byte file at the front of your game-file.

 

All tools for option 1) and 2) are either included in the Jaguar-DevKit or were later released by Curt Vendel and can be found either on AtariAge, or on his website.

 

 

Kind regards

Matthias

 

PS: I would like to ask you to change the name of your project- and ZIP-files slightly to differ them from Atari's ROMSPLIT-tool.

[Zerosquare]

One thing that I do not yet know is how to generate the images for <4MB ROMs such that they pass the authentication check. Does the extra space on the 16-megabit EPROM need to be padded with 0xFFFF, or 0, or duplicate images of the ROM? Does anyone know?

If the size is a power of two, just add duplicate images of the ROM at the end.

 

The ROMs whose size is not a power of two are typically homebrew stuff with no header. To make them suitable for burning, you need to :

 

1) add the universal encryption header at the beginning of the file (you can get it here : http://www.jagware.org/jag_uploads/dev/jagcrypt.zip). You can use the Atari tools instead to generate a "real" encryption header, but it's cumbersome and has no real advantage (except that it checks the whole contents at boot, so if there are bad contacts on the cartridge slot, you get a red screen right away instead of weird glitches/crashes).

 

2) pad the result to your memory chip size with $FF bytes (or anything else really, it doesn't matter, but $FF is best since it's the default contents of erased EPROMS/Flash chips so it's faster to write).

 

If you want a simpler solution, Reboot's JiFFI can be used to convert your ROM in a few clicks : http://reboot.atari.org/new-reboot/jiffi.html

Edited April 28, 2013 by Zerosquare

[Richard42]

Thanks for your replies; this answered my question. I'll use an emulator and skunkboard to do the development but it's good to understand the authentication so that I can make a properly signed cart when it's done. I also found last night that the private encryption keys for cart and CD were leaked in about 2004, in the jagenc2.zip archive. Has anyone ever published a disassembly or memory map of the encryption header?

[Zerosquare]

Has anyone ever published a disassembly or memory map of the encryption header?

http://atariage.com/forums/topic/37617-jag-encryption-round-2/page__st__75#entry1737309

[Shamus]

Pretty much all cartridge images out there (.j64) are not "true" cart images in the sense that the actual format of the chips in most released games are in 32-bit little endian format (cf. here and here). So it would seem that the MMUs on the Jaguar present this data to the system in big endian. Of course, it also depends on the width of the ROM as well (for Cybermorph at least, it's 32-bits, and probably lots of others--haven't really looked into it that much TBH).

 

Also, non-carts are usually assembled somewhere in Jaguar RAM and may or may not work if moved into the cartridge space ($800000); though I think that Jiffi takes cares of that kind of thing when making cart images of RAM based stuff.

 

Also be aware that there are lots of files out there that may look like stuff with headers, but in reality are nothing more than headerless binary files.

[Shamus]

Disregard the paragraph about the cart data being in little endian, that guy that I linked above dumped his cart wrong.

[ggn]

Disregard the paragraph about the cart data being in little endian, that guy that I linked above dumped his cart wrong.

 

I'm sure feedback like that must have helped you fixing stuff up