Previous Thread
Next Thread
Print Thread
Page 2 of 9 1 2 3 4 5 6 7 8 9
Joined: Jan 2006
Posts: 18
B
Member
Offline
Member
B
Joined: Jan 2006
Posts: 18
You have my support Marty, if we can get something finalized, I'll be happy to add conversion support for it. JDG, I like your ideas, it's as if you've been reading my mind smile

A netlist would be better, but, it would be such a nightmare to write all of those up. The major advantage to using a netlist (IMO) is that it would simplify the emulator in the respect that it would only need to emulate the various components and leave the connection details to the container format. I can't even count in my head how many boards use a 74/161 but connected in different ways. Anyways, I just can't see the amount of work required being done.

Regarding the "confirmed" and "virtual" board names, that's pretty much how I've been trying to handle the names in the db, with the UNIF version being the virtual name. I could use some help coming up with some standardized names though :| For example, Jaleco's PCBs are usually named using the games catalog ID, but many of them use the same board but still have the unique name. So I try to use something for the UNIF name that can be shared between them, but the results are not always pretty. For example I just did one last night, JF-19, which currently is assigned JALECO-74*08/32/161/174/174, bleh :|

I don't really like the idea of appending the XML to the end of an iNES file though. I'd rather see it in a zip along with one file per ROM. Having stuff in a zip keeps it open to being able to put other things in as well such as those ADPCM speech synth ROMs, should they ever get dumped or just the recordings of them like we have now.

Joined: Jan 2006
Posts: 138
M
Marty Offline OP
Senior Member
OP Offline
Senior Member
M
Joined: Jan 2006
Posts: 138
Originally Posted By Sotho Tal Ker
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?

Originally Posted By Mike S.
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:

Code:
<peripherals>
  <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>
</peripherals>

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)

Quote:
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.

Originally Posted By JDG
*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.

Quote:
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).

Quote:
*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.

Quote:
*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.

Quote:
*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.

Quote:
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. smile

Joined: Mar 2001
Posts: 16,841
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,841
Likes: 45
My understanding is that there's a workable crack/spoof for MD5 out there. This is why MAME went with SHA1 after initially flirting with MD5.

That said, it's pretty unlikely you could come up with a file that spoofs *both* CRC32 and MD5.

Last edited by R. Belmont; 06/29/07 02:46 AM.
Joined: Feb 2004
Posts: 2,291
Likes: 19
Very Senior Member
Offline
Very Senior Member
Joined: Feb 2004
Posts: 2,291
Likes: 19
The "crack" for MD5 isn't really a crack. The algorithm, given a file and its MD5, will tell you which bits you can change in the file without affecting the MD5. There is not known algorithm that will let you create or alter an arbitrary file to match a given MD5.

The SHA1 "crack" isn't really a crack, either. It's just a weakness in the algorithm that allows you to reduce the space that you do a brute force attack in by a factor of 131072.

Joined: May 2007
Posts: 10
F
Member
Offline
Member
F
Joined: May 2007
Posts: 10
Quote:
I don't really like the idea of appending the XML to the end of an iNES file though. I'd rather see it in a zip along with one file per ROM. Having stuff in a zip keeps it open to being able to put other things in as well such as those ADPCM speech synth ROMs, should they ever get dumped or just the recordings of them like we have now.


I want to agree with this. The old iNES format should have no influence on this new strategy. The rom data should be left alone so that it doesn't take elaborate tools and detection schemes to document and verify roms. Most dumpers that I know have moved completely in favor of DAT files. They're easily modifiable and viewable for dumpers and users alike, but they can't ignore subjective, appended data like headers. And as this new format will prove, they really shouldn't have to.

Joined: May 2007
Posts: 95
M
Member
Offline
Member
M
Joined: May 2007
Posts: 95
A MAME-like approach to storing the ROMs would be nice, sans the stupid MAME things (eight-char filename limits, all game-specific info is documented in the emulator instead of the game set, etc). Multiple ROMs don't belong concatenated together, even if they're on the same cartridge.

This post might be redundant, but I'm getting a feeling that you're planning on keeping iNES files.


Joined: Mar 2001
Posts: 16,841
Likes: 45
R
Very Senior Member
Offline
Very Senior Member
R
Joined: Mar 2001
Posts: 16,841
Likes: 45
Filenames in individual ROMs in MAME are not limited to 8.3, only the outer zip names are.

Joined: Mar 2002
Posts: 1,217
Likes: 2
H
hap Offline
Very Senior Member
Offline
Very Senior Member
H
Joined: Mar 2002
Posts: 1,217
Likes: 2
IMO the zip container containing raw ROM images and an XML board description is the best solution suggested so far. Forget iNES ever existed, it doesn't have any value for future preservation.

(Of course iNES files will keep existing, the purpose of this project is not to kick the iNES format off the throne. Instead of for gaming (iNES), this is for accurate documentation/preservation, right?)

Joined: Jan 2006
Posts: 3,690
Very Senior Member
Offline
Very Senior Member
Joined: Jan 2006
Posts: 3,690
right!

I have a question anyway: how to obtain these raw data? is copynes reliable? if yes, bootgod database is a wonderful reference for this. if not, who would start to dump once more the carts?

EDIT: and notice that I really support this zip with prg+chr+xml idea, I also started to split back a few images following bootgod data... so that we have data available when the xml files are ready (and there will be probably a TOSEC datfiles for these, sooner or later, as I did also for the samples...)

Last edited by etabeta78; 06/30/07 06:26 PM.
Joined: Oct 2005
Posts: 351
R
Senior Member
Offline
Senior Member
R
Joined: Oct 2005
Posts: 351
Originally Posted By Marty
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?


CRC vandals have gone as far as hacking hidden intros into roms and reverse the CRC back to the proper dump. So I think it's worth worrying.

As R.Belmont stated, the crc32+sha1 combo is secure enough, adding more will just slow down the checks.

*edit

On a not related note, will the roms be splitted or still joined?
That's unclear. I favor splitted sets, it looks much better...

Last edited by MESSfan; 06/30/07 07:32 PM.
Page 2 of 9 1 2 3 4 5 6 7 8 9

Moderated by  Marty, R. Belmont 

Link Copied to Clipboard
Who's Online Now
0 members (), 19 guests, and 2 robots.
Key: Admin, Global Mod, Mod
ShoutChat
Comment Guidelines: Do post respectful and insightful comments. Don't flame, hate, spam.
Forum Statistics
Forums9
Topics8,993
Posts118,153
Members5,005
Most Online890
Jan 17th, 2020
Forum Host
These forums are hosted by www.retrogamesformac.com
Forum hosted by www.retrogamesformac.com