Home | Forums | What's new | Resources | |
SDSC ROM tag for Genesis |
cgfm2 - Feb 10, 2005 |
cgfm2 | Feb 10, 2005 | ||||
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:
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! |
Runik | Feb 10, 2005 | |||
Woot ! Charles is there Genesis isn't my domain so I won't comment on your post, but I'm glad to see you around |
fonzievoltonov | Feb 10, 2005 | |||
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? |
cgfm2 | Feb 10, 2005 | ||||||||||
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.
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.
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. |
ICEknight | Feb 10, 2005 | |||
You're talking about homebrewn stuff only, right? |
Mask of Destiny | Feb 10, 2005 | |||||||
I agree. I don't see any really good reason not to move it back.
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. |