Previous Thread
Next Thread
Print Thread
Page 1 of 9 1 2 3 4 5 6 7 8 9
#30761 06/25/07 10:08 AM
Joined: Jan 2006
Posts: 138
M
Marty Offline OP
Senior Member
OP Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
I've been thinking more about the use of XML for image info the last few days and I've even finished writing a custom XML parser. I'd like to present some ideas for how the data could be structured. While it's a very subjective field, my hope is that many people could give their input and contribute to this thread so that we can work towards making a nice, clean and flexible format. Databases, romsets and other stuff comes later. Once we have the format, we can take it from there. Right now I want more action and less blah blah blah.

The following layout is not neccesarily the result of deep thinking. It's just something I threw together to encourage a technical discussion.

random example:

Code:
<game name="Weird Science" system="nes.ntsc" crc="C8BAA563"> 
  <hardware board="nes-weirdrom" mapper="1">
     <prg type="rom" size="128k" crc="09234FB0"> (*) </prg>
     <prg type="ram" size="8k" />
     <prg type="nvram" size="8k"> (*) </chr>
     <prg type="eeprom" size="512"> (*) </chr>
     <chr type="rom" size="256k" crc="FE037AB1"> (*) </chr>
     <chr type="ram" size="8k" />
     <nmt mirroring="0101" />
     <mmc>mmc1b2</mmc>
  </hardware>
  <peripherals>
    ..discuss
  </peripherals>
  <dipswitches>
    ..discuss
  </dipswitches>
  <something else>
    ..discuss
  </something else>
</game>

(*) - optional reference to file

real world example using Shadowgate US version:

Code:
<game name="Shadowgate" system="nes.ntsc" crc="6A1F628A"> 
  <hardware board="nes-tkrom" mapper="4">
     <prg type="rom" size="128k" crc="591364C9" />
     <prg type="nvram" size="8k" />
     <chr type="rom" size="128k" crc="05414DD9" />
     <nmt mirroring="ctrl" />
     <mmc>mmc3b</mmc>
  </hardware>
</game>

Some attribute descriptions:

<game>

crc: crc-32 of combined roms in prg+chr order
system: nes.ntsc, nes.pal, famicom, vs.unisystem, vs.dualsystem, playchoice-10, <insert clone?>

<hardware>

board: pcb/unif name (if available, make something up otherwise?)
mapper: %0..255 (controversial, discuss!)

<prg/chr/nmt>

size: % (in bytes), %k (in kibibytes)
type: rom, ram, nvram (battery-backed), eeprom

mirroring:
0000 - single-screen from PPU $2000
1111 - single-screen from PPU $2400
0101 - vertical
0011 - horizontal
0123 - four-screen (uses extra 2k RAM)
ctrl - controlled by mmc
<xxxx> - any other combination

<xxxx> instead of the commonly refered 'horizontal/vertical/four-screen' good or bad? Discuss!

Some tags and attributes could be optional and have documented default values if unspecified. Ideas for which and what settings? Discuss!

Joined: Feb 2004
Posts: 2,382
Likes: 98
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,382
Likes: 98
Not generic enough. I still think a netlist is better.

Joined: Mar 2001
Posts: 16,919
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,919
Likes: 57
Are you prepared to create one for all known NES cart boards? Because I don't think that's a real common skill smile

I think what Marty has is definitely a good start, but my technical knowledge of NES mappers isn't sufficient to offer a good critique.

Joined: May 2007
Posts: 21
S
Member
Offline
Member
S
Joined: May 2007
Posts: 21
How will you handle games that have multiple PRG roms?

Joined: Oct 2005
Posts: 351
R
Senior Member
Offline
Senior Member
R
Joined: Oct 2005
Posts: 351
crc32 was hacked years ago
why not add some sha1

Joined: Jan 2006
Posts: 138
M
Marty Offline OP
Senior Member
OP Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Originally Posted By Vas Crabb
Not generic enough. I still think a netlist is better.

Maybe so, but I think what you're suggesting will be too difficult to accomplish and work with. Besides, the board name alone will tell everything there is to know about the cartridge minus some specifics like chip sizes and revisions and other things depending on context. That's speaking from an emulation standpoint however, but I think that's just the right balance. The cart has been identified and if someone wants to learn more about the NES-TKROM board used for Shadowgate he/she can look it up.

Originally Posted By Sotho Tal Ker
How will you handle games that have multiple PRG roms?

That's easy. Using the unlicensed Action 52 cart as an example:

<hardware ... >
<prg type="rom" size="512k" crc="64E40C10" />
<prg type="rom" size="512k" crc="69FDC534" />
<prg type="rom" size="512k" crc="7E43E9E1" />
<chr type="rom" size="512k" crc="596442EC" />
</hardware>

Originally Posted By MESSfan
crc32 was hacked years ago
why not add some sha1

While I don't think it's worth worrying too much about CRC vandals, a more safe hash function could indeed be desired.

<game ... crc="baaaaaad" sha1="91a009e610b5e2b9776ac540dcdcada6f8cfc507">

Any other hash function to be considered, or will the two do for now?

Joined: May 2007
Posts: 21
S
Member
Offline
Member
S
Joined: May 2007
Posts: 21
Maybe MD5 as a third option. Those 3 (CRC32,MD5,SHA1) are currently used by ClrMame aswell.

And as I see you determine the order of the PRG roms just by their order in the XML.

Joined: Mar 2001
Posts: 16,919
Likes: 57
R
Very Senior Member
Online Content
Very Senior Member
R
Joined: Mar 2001
Posts: 16,919
Likes: 57
Hacking simultaneous CRC+SHA1 is all but impossible, there's no need for a third smile

Joined: May 2007
Posts: 95
M
Member
Offline
Member
M
Joined: May 2007
Posts: 95
Under peripherals, you might describe the game's expected input methods. Weather the game wants just one controller, two controllers, a light gun, etc. IMO, it should also cover 1-player games that have hidden features using the 2nd-player controller (eg, The Legend of Zelda and its trick that allows you to save the game without having to die).

Also, IMO, it would be ideal if there was some sort of iNES -> New Format converter. A database would probably have to be provided to fill in details that iNES might not describe, but such a script/program would make it much easier than downloading new ROMs (think of the dial up users!).

Last edited by Mike S.; 06/27/07 07:35 AM.
Joined: Jun 2007
Posts: 1
J
JDG Offline
Member
Offline
Member
J
Joined: Jun 2007
Posts: 1
I like the general idea, Marty. Here are a couple of suggestions.

*You should be able to define multiple systems. For instance, some games were released with no ROM changes whatsoever in Japan, the US, and Europe, so in those cases you could have something like this: system="famicom,nes.ntsc,nes.pal". Also, I would recommend adding "ffe" and "dr.pcjr" to the list of system types.
*Allow more than one board type to be specified. The emulator would simply use the first such valid type. For instance, Teenage Mutant Ninja Turtles (US, Ultra Games) has been found on all the following boards: Nintendo's NES-SLROM-04, NES-SLROM-05, and NES-SLROM-06, and Konami's 351908. All of these boards are functionally identical and the ROM is exactly the same for every one. But it would be nice to be able to accurately document the range of actual hardware that they were played on. (By the way, board information is from BootGod's excellent database site.) Listing board manufacturer would be good, too.
*In line with the above suggestion, allow two classes for board types: "confirmed" and "virtual". Confirmed means that this is the exact board name on the actual hardware PCB. Virtual means that it is a compatible board that was never used, but would work, and that emulators could more easily recognize. For instance, "4 Nin Uchi Mahjong" (Japan, Nintendo) is on a black blob board that is called HVC-FJ. That is the real board name. But, it is 100% compatiable with standard NES/HVC-NROM-128. There are tons of bootleg NROM games that use boards with weird or no names. By using an added "virtual" name in addition to the real one, we can ensure compatibility with emulators, while still preserving the actual board name.
For instance, "Ski or Die" (US, Konami) was published only on a 351908 Konami board. But this is 100% equivalent to SLROM. So, the board descriptions would be set up something like this:
<board class="confirmed" name="351908" manufacturer="Konami" />
<board class="virtual" name="NES-SLROM" />

*Rather than a mirroring tag, allow tags for the actual solder pads on the board. This better describes what is actually going on in the hardware, and allows for flexibility with stuff like the MMC5 ExROM boards that have more solder pads than just H and V. For instance, something like this (the below example is standard vertical mirroring):
<pad h="bridged" v="open" />
*I would recommend standardizing on MD5 as a hash algorithm. It's relatively simple to implement. I'm not worried about deliberate collisions with CRC32, but accidental ones; the latter cannot entirely be ruled out even if the probability is low. MD5, on the other hand, makes an accidental collision nearly impossible.
*How about appending the XML to a standard *.NES image? The prg and chr fields, instead of specifying file names, could give the size and the offset (from start of file). This would offer the best of both worlds: a cleanly documented and implemented format for new emulators, while maintaining backwards compatibility with old ones. You'd only have 16 bytes of overhead. (You would probably also want to add a special tag right before the XML, so the parser could easily find it and not confuse it for ROM data if the header was corrupt.)
If desired, I will try to write up a full draft spec and submit it to the board (and Marty) for approval.

Page 1 of 9 1 2 3 4 5 6 7 8 9

Moderated by  Marty, R. Belmont 

Link Copied to Clipboard
Who's Online Now
2 members (Dorando, peter ferrie), 25 guests, and 9 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics9,100
Posts119,237
Members5,019
Most Online890
Jan 17th, 2020
Our Sponsor
These forums are sponsored by Superior Solitaire, an ad-free card game collection for macOS and iOS. Download it today!

Superior Solitaire
Forum hosted by www.retrogamesformac.com