Noob questions: is the ROM header actually required?

[RetroGames]

I came across the source for a Genesis pong game by TmEE that doesn't use the standard ROM header described in Sega's docs. In fact, TmEE's code just writes a bunch of text over everything that's supposed to exist from $0..$1FF, with the exception of the code start address at $4, and the TMSS string "SEGA" at $100. I made a "hello world" test ROM that duplicates this behavior, and it works fine on emulators. That made me wonder: what parts of the header are required by real hardware? If any of the header items are optional, which ones can the hardware actually make use of, and which ones are completely unnecessary?

[BigEvilCorporation]

This is educated guesswork based on some light experiments so feel free to school me - I think the only required part is the code start address in the CPU vectors table, and the stack address if you intend to use some RAM (TmEE's demo does not, and he doesn't branch to subroutines, so he can get away with it) - the rest of the table can be empty so long as the interrupt addresses are never fired (clear the interrupt level, and don't cause any exceptions to be raised by dividing by zero or whatever).

The title strings are read by emulators, perhaps some poorly written implementations could crash the emulator (attempting to read a string at a known address up to a null terminator or something), and it's possible some debuggers or development kits might try to make use of the header (SNASM2 MEGARUN.EXE tool and my cartridge flash software dump info to stdout), but I doubt anything in a real machine would try to reference any of the data in a meaningful way.

Sonic carts (and probably many others) use one of the longword spaces to store the ROM checksum, but this is programmer implemented.

[Natsumi]

only the pointer to start of code, and SEGA at $100 are required. Everything else depends on your needs. For example if you need V-int and H-int you will need their specific pointers, or if you want to be emulator friendly you probably would have the SRAM and ROM pointers as well, but by no means are required.

[RetroGames]

I doubt anything in a real machine would try to reference any of the data in a meaningful way.

only the pointer to start of code, and SEGA at $100 are required.

I thought maybe at least the country codes at $1F0 ("J" for Japan, "U" for USA, etc.) might be needed by the hardware for region locking games, but it looks like that's not the case?

The title strings are read by emulators, perhaps some poorly written implementations could crash the emulator (attempting to read a string at a known address up to a null terminator or something), and it's possible some debuggers or development kits might try to make use of the header (SNASM2 MEGARUN.EXE tool and my cartridge flash software dump info to stdout)

Sounds reasonable. Only other thing I can think of is perhaps Sega wanted the header to be present for QA or manufacturing purposes, or something like that. Maybe it would have been easier in some cases for relevant employees to check a ROM's header than to figure out details about the ROM some other way? Whatever the deal is, it's odd that Sega asks you to specify redundant stuff, like where RAM starts and ends. Maybe they were thinking of forward compatibility issues?

Sonic carts (and probably many others) use one of the longword spaces to store the ROM checksum, but this is programmer implemented.

I'm guessing that's supposed to be used as part of a (very) simple anti-piracy scheme, right?

I always appreciate the responses, guys. Thanks!

[Natsumi]

I thought maybe at least the country codes at $1F0 ("J" for Japan, "U" for USA, etc.) might be needed by the hardware for region locking games, but it looks like that's not the case?

Region locking is always software implementation. Such as the Sonic 3 and Sonic & Knuckles carts (I believe), check the header for country code and compare against version register. Error message is shown if correct settings aren't present.

Sounds reasonable. Only other thing I can think of is perhaps Sega wanted the header to be present for QA or manufacturing purposes, or something like that. Maybe it would have been easier in some cases for relevant employees to check a ROM's header than to figure out details about the ROM some other way? Whatever the deal is, it's odd that Sega asks you to specify redundant stuff, like where RAM starts and ends. Maybe they were thinking of forward compatibility issues?

Likely forward compatibility as well as having a standard which provides easy-to-access information about the cart. Sonic & Knuckles uses the serial number for generating blue spheres for example. This would not be possible if there was no such standard. It is likely also better for cart manufacturers, because Sonic 2 had 3 revisions, each of them have slightly different serial number.

I'm guessing that's supposed to be used as part of a (very) simple anti-piracy scheme, right?

Unlikely, because as long as the piratists can correctly rip a ROM, it will never fail the checksum check, and the checksum algorithm is very easy to understand, as it is only few lines of code (in Sonic games anyway). It is more likely done to prevent ROMs which aren't loaded correctly from running, but as far as I know this in reality did not help as much as hoped (you could still load a ROM, without red screen, and it'd be a glitchy mess). This would theoretically ensure no ROM is incorrectly loaded, but in practice I don't think it ever was that successful.

[RetroGames]

Region locking is always software implementation.

That's interesting. So unless a Gen/MD game is designed to be region locked, there's nothing stopping you from running it on any version of the console, be it PAL, NTSC, Japanese, European, whatever? (I haven't looked into region issues much yet. I kind of assumed putting PAL games in NTSC systems or vice versa would fry the cartridges or something. )

Sonic & Knuckles uses the serial number for generating blue spheres for example. This would not be possible if there was no such standard.

Went and looked this up. That's pretty cool.

It is more likely done to prevent ROMs which aren't loaded correctly from running, but as far as I know this in reality did not help as much as hoped (you could still load a ROM, without red screen, and it'd be a glitchy mess). This would theoretically ensure no ROM is incorrectly loaded, but in practice I don't think it ever was that successful.

"Loaded correctly" in what sense? From ROM to RAM? Also, what is the "red screen"? If it's to do with the VDP, I may have encountered it (well, sort of, as it was in an emulator I was using to test a "hello world" ROM I made).

[TmEE co.(TM)]

Checksum is for a simple integrity check. The game does a check on itself and typically shows a red screen when the freshly made checksum doesn't match with stored one.

Region locking is purely game's own thing, hardware only provides couple bits that refrect the region setting of the machine, it is up to the game to do something with it.

[Natsumi]

I have 3 Mega Drives. 2x EU Sega Mega Drive Model 1, and 1x US Sega Genesis model 1. I also have EU Sonic the Hedgehog, US Sonic the Hedgehog, EU Sonic the Hedgehog 2, JP Sonic the Hedgehog 2, and eu Sonic the Hedgehog 3. Now, I can play all the Sonic 1 and 2 carts on any Mega Drive I own (except the JP import because its wider, only one of my EU Mega Drives are modded to account for this). However, I can not play my Sonic 3 on my US Mega Drive, because of region locking. And looking at the code, neither do Sonic 1 or 2 implement any region locking, and Sonic 3 does. So you can play any game on any region, as long as it doesnt region lock by software.

Also checksum often is just a counter, where each word of the ROM is added as 16-bit integer, and it does this from 0x200 to End of ROM. The resulting number is checksum and is compared against predefined checksum that is calculated on post-processing. If they do not match, A blank screen with high contrast colour is show usually, and in Sonic games this colour is $00E, or bright red.

[RetroGames]

Checksum is for a simple integrity check. The game does a check on itself and typically shows a red screen when the freshly made checksum doesn't match with stored one.

Also checksum often is just a counter, where each word of the ROM is added as 16-bit integer, and it does this from 0x200 to End of ROM. The resulting number is checksum and is compared against predefined checksum that is calculated on post-processing. If they do not match, A blank screen with high contrast colour is show usually, and in Sonic games this colour is $00E, or bright red.

OK, now I've got it. (The red screen I saw in my testing was obviously something unrelated, since I didn't do anything with the checksum. Not to mention that it was on an emulator, so it could have been anything.)

I can play all the Sonic 1 and 2 carts on any Mega Drive I own (except the JP import because its wider, only one of my EU Mega Drives are modded to account for this).

Ah, that's good to know. If I'm ever thinking about importing games, I'll keep that in mind.

you can play any game on any region, as long as it doesnt region lock by software.

All right, that's very cool. Checking into this a little more, it seems that besides the different shape/size of some carts that you talked about, the only general problem with running PAL games on NTSC consoles and vice versa is the difference in CPU clock speed and video refresh rate on PAL systems vs. NTSC systems. Apparently that's why some European import games, like Mega Man: The Wily Wars, run "slowly" on USA consoles?

[Natsumi]

most developers are sensible enough to have the games able to run on NTSC and PAL systems as is, even if they have region locking (Sonic 3 and Sonic & Knuckles for example are like this), however some specific games or game companies may have had different policies regarding to this and having separate ROMs for different regions, which may be an issue

[RetroGames]

most developers are sensible enough to have the games able to run on NTSC and PAL systems as is, even if they have region locking (Sonic 3 and Sonic & Knuckles for example are like this), however some specific games or game companies may have had different policies regarding to this and having separate ROMs for different regions, which may be an issue

Well, that's good news. I was worried it would be hard to make a single ROM that works correctly in all systems, but it sounds like it's not so much of a problem. I'll look into this more closely once I have the basics figured out.

Thanks a ton for taking the time to answer my incessant questions! It means a lot to me.

[ComradeOj]

Yes and no. Some parts of the header need to be in their correct spots, and the rest isn't that important.
I made a small demo that shoves a lot of code into the header area to make better use of ROM space. Only the entry point vector, stack start, "SEGA" at $100 (for TMSS), Vblank and Hblank vectors are in tact. The rest of the header is full of code!

Here is a photo of what that looks like in a hex editor. http://i.imgur.com/FyjAzrv.png The highlighted area is all normally the header.
You can download the demo ROM image + source here http://mode5.net/download/Tiny%20Demo.zip It freezes in certain emulators, but works fine on real hardware.

In short, some parts of the header are required, specifically the vector table, stack starting location (at $000 in ROM) and "SEGA" at $100. The game name, region stuff, checksum, and pretty much every other part of the header is optional. Region coding and checksum is only checked in if you program your stuff that way. Otherwise, it doesn't matter a bit.

[Sik]

Repeating what has been said but the required parts are:

* $000004: pointer to where the program starts
* $000100: either "SEGA" or " SEGA" (if you want it to work on TMSS systems)

Nothing else, though some things like interrupts may need some other parts of the headers. The $000000 vector (the stack pointer) is not needed as far as I know: you can just use LEA (...), SP in the program instead to get the same effect. Well, unless there's some obscure 68000 behavior I'm not aware of.

But you need at least those two to get things to work everywhere.

[Natsumi]

Sonic & Knuckles (and possibly Sonic 3, havent checked) have the first longword (stack address) set to 0. Later in the code it is corrected the be the actual stack address in RAM. And a hack I've made has text instead of the stack address. So yes, first longword is also not needed, because you can use LEA or MOVE.W/L to SP.

[Mask of Destiny]

Sonic & Knuckles (and possibly Sonic 3, havent checked) have the first longword (stack address) set to 0.

0 is a valid value for the stack pointer and indeed is probably the most appropriate value if you want the stack to grow down from the top of RAM. The stack pointer is decremented before data is written, so the first word pushed to the stack will end up at $FFFFFFFE.