SDSC ROM tag for Genesis

For SMS/GG program development, an extra header ("tag") was added to the ROM file for identification. It provides some simple features like the date and version of the program, who wrote it, the program name, and any additional notes. Emulators like MEKA and ROM tools such as SMS Checker support the tag.

The original SMS/GG specification is at:

http://www.smspower.org/dev/sdsc/SDSCROMTag101.txt

As someone who's written a lot of SMS/GG software, it's been helpful to keep track of the programs, and as a form of documentation.

So, over at S8-DEV I proposed an alternate implementation of the SDSC ROM tag for Sega Genesis/MegaDrive programs. Kaneda suggested it be discussed here.

My suggested changes for the Genesis are as follows:

- Locate tag at $200. This is past the important parts of the vector table and header, but is low enough in memory that you don't have to inflate the ROM size any more than needed.

- New format is:

Code:
org $200

dc.b "SDSC"; Tag ID

dc.w $0100; Version (BCD, v1.0)

dc.w $3101,$2005; Date (BCD, DD/MM/YYYY, 31-1-2005, year is big-endian format)

dc.l sdsc_author; Who wrote the program

dc.l sdsc_title; Program title

dc.l sdsc_notes; Any other notes from the author

Empty strings would just have a NUL character (0) instead of changing the pointer to an arbitrary value. Strings can appear anywhere within the 68000 address space so there is no real limit to size.

I'd rather not modify or expand the original Genesis header, and would like to keep the SDSC tag as simple as possible which is why the proposed Genesis version doesn't do anything more that the SMS/GG version did.

Of course it's up to emulators and tools to support the tag - I wrote a simple commandline program to display the tag and optionally update the date field. Perhaps Kega and Gens can support it.

The other nice thing is that it would fix the problem of ROM renamers getting the title right for PD software - just append the program title, author name, and optionally the version number from the tag and you'll always get a correct filename. Something like:

"Racing Game by John Doe (V1.0).bin"

Any thoughts or suggestions? If people like this idea I'll draft an official specification for review.

PS: Note that this is for homemade software, not something you'd stick into an existing commercial ROM!
 
Ummmm, as u might know (joking), the genesis roms already have a rom header...

Compared to the nes/gg/gba (who doeesnt have) games, sega had a good idea.

Why not reusing the old header?

Because we can specify "Homebrew" value for the game "Style" tag (E:Education, G:Game...).

Well, what do u think about?
 
I definately like this idea. I do have one suggestion though.

Locate the SDSC header in the MEMO field($1C8, 40 bytes long) of the standard header. Since, to my knowledge, the MEMO field is just for miscellaneous junk the developer wants to put there, this really wouldn't be an abuse of that field. This would have three advantages.

First, an SDSC header can be applied to an existing PD ROM without recompiling so long as it had a proper Sega header in the first place. There are quite a few PD ROMs for the Genesis for which the original source is no longer available and many of these use $200 for useful data or code.

Second, if you move it to the MEMO field it can also be used for homebrew Sega CD/Mega CD titles. The Sega CD BIOS compares everything from $200 to the end of the security code against the copy in ROM so adding an SDSC header would prevent the game from booting. In such a case the pointers for the author, title and notes would be relative to the beginning of the track and not an absolute address on the 68K

Third, less space is used. Granted the header isn't that big, but it gives those that are coding little 4K demos fewer excuses to leave the SDSC header out.
 
Woot ! Charles is there :D

Genesis isn't my domain so I won't comment on your post, but I'm glad to see you around ;)
 
Originally posted by fonzievoltonov@Thu, 2005-02-10 @ 04:46 PM

Ummmm, as u might know (joking), the genesis roms already have a rom header...

Compared to the nes/gg/gba (who doeesnt have) games, sega had a good idea.

Why not reusing the old header?

Because we can specify "Homebrew" value for the game "Style" tag (E:Education, G:Game...).


The current header has some deficiencies. It has a copyright date (not exactly the same as a build date, but perhaps close enough), but it doesn't contain the day of the month (just the month and the year). It has no space allocated for the name of the author. The MEMO field could be used as a notes field, but it has a limited length (40 bytes). The version field is only two ascii characters, 4 BCD digits are more appropriate.
 
So... I have another suggestion...

What about just puting a pointer that links to the SDSC header?

So we put this pointer somewere in the classic genesis header... And the user can put the SDSC header anywere in the rom.

Not a good idea? :) :/
 
Originally posted by Mask of Destiny@Thu, 2005-02-10 @ 11:54 AM

Locate the SDSC header in the MEMO field($1C8, 40 bytes long) of the standard header. Since, to my knowledge, the MEMO field is just for miscellaneous junk the developer wants to put there, this really wouldn't be an abuse of that field. This would have three advantages.


I like this idea. The only possible problem I can see is that SVP programs use $1C0-$1CF to define the program entry point. It's a moot point at the moment, but in time I'd like to continue my research on the SVP and eventually get it emulated, meaning we can write our own 3D programs and wouldn't want the tag to interfere. Perhaps using $1D0 onwards would be better.

First, an SDSC header can be applied to an existing PD ROM without recompiling so long as it had a proper Sega header in the first place. There are quite a few PD ROMs for the Genesis for which the original source is no longer available and many of these use $200 for useful data or code.


I assume the strings would be appended to the end of the ROM? I don't think there is enough room within the memo area to define the tag and the title/author strings. Placing them outside that area would change the checksum, though I realize most PD programs don't have a valid checksum or even a completely valid Sega header to begin with.

Second, if you move it to the MEMO field it can also be used for homebrew Sega CD/Mega CD titles. The Sega CD BIOS compares everything from $200 to the end of the security code against the copy in ROM so adding an SDSC header would prevent the game from booting. In such a case the pointers for the author, title and notes would be relative to the beginning of the track and not an absolute address on the 68K


Full agreement on this one, supporting the Sega CD would be great.

Would the distinction of how to interpret the pointers be up to the emulator or tool being used? E.g. an emulator would know if loading an ISO image that the pointers are track relative and not absolute, while a BIN file would be cartridge and therefore absolute.

The other option is to add a byte to indicate the tag type, something like 0=cartridge, 1=CD. As those are the only forms of media the Genesis accepts, I can't think of it getting any complicated than that.
 
Originally posted by cgfm2+Thu, 2005-02-10 @ 08:42 PM--><div class='quotetop'>QUOTE(cgfm2 @ Thu, 2005-02-10 @ 08:42 PM)</div><div class='quotemain'>I like this idea. The only possible problem I can see is that SVP programs use $1C0-$1CF to define the program entry point. It's a moot point at the moment, but in time I'd like to continue my research on the SVP and eventually get it emulated, meaning we can write our own 3D programs and wouldn't want the tag to interfere. Perhaps using $1D0 onwards would be better.[/b]


I agree. I don't see any really good reason not to move it back.

Originally posted by cgfm2+--><div class='quotetop'>QUOTE(cgfm2)</div><div class='quotemain'>I assume the strings would be appended to the end of the ROM? I don't think there is enough room within the memo area to define the tag and the title/author strings. Placing them outside that area would change the checksum, though I realize most PD programs don't have a valid checksum or even a completely valid Sega header to begin with.[/b]


If it wasn't for the SVP problem, it might have been possible to stuff the strings in there for most of them (especially since most of the author names tend to be aliases and not full names), but I don't see a major problem with sticking it at the end (hopefully in an existing padded area and not by extending the file if it's already padded to a nice even boundary). A utility could check to see if it has a valid checksum and recalculate it if it does.

<!--QuoteBegin-cgfm2
@

Would the distinction of how to interpret the pointers be up to the emulator or tool being used? E.g. an emulator would know if loading an ISO image that the pointers are track relative and not absolute, while a BIN file would be cartridge and therefore absolute.

The other option is to add a byte to indicate the tag type, something like 0=cartridge, 1=CD. As those are the only forms of media the Genesis accepts, I can't think of it getting any complicated than that.

[/quote]

It occurs to me that apart from trying to read the header on the console itself (at which point it would be patently obvious whether it's a cartridge or a CD), it's just easier to treat everything as relative since the cartridge is mapped to 0 anyway so there's effectively no difference between treating it as an absolute value and a relative (unless it's got a mapper on it I suppose).

<!--QuoteBegin-"ICEknight"


You're talking about homebrewn stuff only, right?[/quote]

yes
 
Back
Top