And as I see you determine the order of the PRG roms just by their order in the XML.
Yeah, I figured it's simplest that way. Another way would be to do something like this:
<prg ... id="0" />
<prg ... id="1" />
<prg ... id="2" />
I'm not sure there's anything to gain with that approach though. Anyone of a different opinion?
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).
Yeah, I was planning on that. I find it to be a bit tricky to come up with something elegant, mostly because of the difference between the NES and the Famicom units and also with the availability of four-player games.
Perhaps something like this could work:
<controller port="0">controller name</controller>
<controller port="1">controller name</controller>
<controller port="2">controller name</controller>
<controller port="3">controller name</controller>
<controller port="exp">controller name</controller>
port 0..1: NES standard ports. Two standard pads connected by default (hardwired on the Famicom).
port 2..3: if specified, will tell that a four-player adapter is connected for which the controllers will go through instead.
exp: Expansion port. All Famicom controllers go through this port.
The design may seem a bit sketchy and the meaning may change depending on how things are specified. Does anyone have any better idea on how to tackle this?
As for the controller names. What should be prefered? Short and descriptive names or their actual names? For comparision:
Light gun <-> Zapper, Hyper Shot (Space Shadow)
Floor mat <-> Family Fun Fitness, Family Trainer, Power Pad
Glove <-> Power Glove (Super Glove Ball)
Robot <-> Family Computer Robot, R.O.B
Trackball <-> Hori Track (Operation Wolf)
It may turn difficult to come up with meaningful names for some of the special Famicom controllers due to little information. I'll list some of them:
- Arkanoid controller
- Mouse (Educational Computer 2000)
- Top Rider bike
- Mahjong controller (Ide Yousuke Meijin no Jissen Mahjong)
- Bop bag (Exciting Boxing)
- Tap tap mat (Pokkun Moguraa)
- Pachinko controller (Pachinko Daisakusen)
- Tablet (Oeka Kids)
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!).
Sure, I could put something together later on.
*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".
Right, of course. I completely forgot about that when I wrote things down. Multiple names seperated by comma works for me.
Also, I would recommend adding "ffe" and "dr.pcjr" to the list of system types.
Some people may argue against allowing ffe (Front Far East copier images), but I'm personally fine with both of them. In Addition, I think "noac" (NES-on-a-ship) should be considered as well. There are actually quite a few games (Chinese mostly) made for it that will not work properly on a standard Famicom/NES console (timing issues etc).
*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" />
Excellent ideas! I was hoping that someone more experienced could help improve this section.
*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.
Yeah, SHA-1 was brought up earlier but if I had to choose I'd personally go with MD5 as I have more experience with it. However, there's nothing preventing all three (crc,sha1,md5) from being allowed as far as the XML format goes. The only issue I can see is that it would add more pressure on software that's going to use it. Perhaps it would be best to restrict it to two hashing functions - CRC-32 (the simple and fast), and MD5 or SHA-1 (the more safe and secure). In this case, I'd cast my vote on CRC-32 and MD5.
*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.)
I think it's probably best to leave the NES files alone. The XML format is very flexible and can serve multiple purposes without breaking compatibility. An emulator could for example search for a matching XML file (or an entry from an XML database) while loading a NES file and just use that instead of the file-header.
If desired, I will try to write up a full draft spec and submit it to the board (and Marty) for approval.
Thanks, that would be great and it would help offloading some work for me.