Roman,

I was alerted to a possible 'discrepancy' to some rom sets (that didn't *seem* to be a problem, but I checked it out anyway). After doing a little research, I found what the 'problem' was. If a rom in a set is marked as 'merge', but has a different name to the parent, CMP ignores the merge.

For example :

"gorkans" cloneof="mrtnt"

rom name="gorkprom.1" merge="82s126.4a" size="256" crc="3eb3a8e4" sha1="19097b5f60d1030f8b82d9f1d3a241f93e5c75d6" region="proms" offset="20"/

"mrtnt"

rom name="82s126.4a" size="256" crc="3eb3a8e4" sha1="19097b5f60d1030f8b82d9f1d3a241f93e5c75d6" region="proms" offset="20"/

Anyway, if you remove that rom from gorkans.zip, Mame will play it with no complaints. ClrMamePro will, however, complain about it, but add the files in if scanned with Fix Missing selected.

Well, you probably already know about this, I was just wondering if there was a setting / selection to ignore the name difference?

Thanks,

SK.

> different name to the parent, CMP ignores the merge.

ClrMamePro doesn't use the "merge" tags at all. It creates its own parent/clone rom relationships. It uses a much more stricter and more valid method than MAME's merge tags (besides they were too wrong too often). It doesn't matter if the hashvalues are identical, if the romnames differ, you need both files. The fact that there are double-roms (same crc, different name) is known since the first days of MAME and usually a good driver author fixes the names ;)
MAME doesn't complain because MAME's loading procedure is a mess ;) It simply looks in all sets of a parent/clone relationship and looks for a matching checksum. It doesn't care about romnames at all.

Roman Scherzer
ClrMamePro

> MAME doesn't complain because MAME's loading procedure is a mess ;) It simply
> looks in all sets of a parent/clone relationship and looks for a matching
> checksum. It doesn't care about romnames at all.

then, shouldn't cmp stop caring about romnames too? ^_^ not complaining about this one, but i always found a bit strange your (and logiqx's) stance about this. in logiqx's case, i always thought "why doesn't he at least make it optional". in your case, i am actually surprised with the amount of options cmp already has that you didn't include this one. but your statement about not using merge tags explains it all...

Pi - Every Precious Dream and Vision Underneath the Stars
Arcade news, emulator archives and gamelists at CAESAR

> > different name to the parent, CMP ignores the merge.
>
> ClrMamePro doesn't use the "merge" tags at all. It creates its own parent/clone
> rom relationships. It uses a much more stricter and more valid method than
> MAME's merge tags (besides they were too wrong too often). It doesn't matter if
> the hashvalues are identical, if the romnames differ, you need both files. The
> fact that there are double-roms (same crc, different name) is known since the
> first days of MAME and usually a good driver author fixes the names ;)
> MAME doesn't complain because MAME's loading procedure is a mess ;) It simply
> looks in all sets of a parent/clone relationship and looks for a matching
> checksum. It doesn't care about romnames at all.
>
> Roman Scherzer
> ClrMamePro
>
Roman,

Thanks for the reply.

If, then, I have a list of all the roms affected, and I make the changes to the Mame source, is that the solution you would expect?

If so, then I can make the 90 changes required to bring Mame back into line.

However, couldn't there be a case that the rom could be named differently in the clone? What if the rom was labelled differently on the board, but contained the same data? I would expect that that's the point of being able to say 'the name of the rom in this set is x, but on the parent board, it's labelled y'.

Ideally, this would be one of those thing that could be thrown up when importing the dat, and given the option to either ignore it (as per now) or change the name to match the parent.

As I say, it's up to you. I know each case that this comes up in, so can try making the changes & submitting them to the dev's.

SK.

> If so, then I can make the 90 changes required to bring Mame back into line.

90? Who was I kidding! ;)

This is the results of scanning the XML output for the differences :

Sets Effected : 100
Roms : 332

> As I say, it's up to you. I know each case that this comes up in, so can try
> making the changes & submitting them to the dev's.

most of them will be rejected, because as you pointed out, in many boards the roms were labeled differently for each version/bootleg. however there are still some which are just typos, i believe final lap is one example. but the majority of the cases is a matter of rom labeling. i think that the rom labels could be equally well documented in the source, but this is how mame documents them right now. if you're not a dumper, i don't think haze will accept changes on the file names ;) (except for obvious typos).

however, if you're proficient with altering rom loading stuff, there's an error in datafiles which bugs me a lot, and it's duplicated roms. except in some cases where the roms were phisically duplicated in the board (some sega model 2 i think), most of the times that mame needs to load a rom twice would be better solved by mirroring, i think. at least, in some cases it would be possible to use a ROM_RELOAD. but that's beyond my experience and knowledge, so i'm probably wrong.

a complete list of "errors" in the datfile could be generated using logiqx's datutil.

Pi - Every Precious Dream and Vision Underneath the Stars
Arcade news, emulator archives and gamelists at CAESAR

> > MAME doesn't complain because MAME's loading procedure is a mess ;) It simply
> > looks in all sets of a parent/clone relationship and looks for a matching
> > checksum. It doesn't care about romnames at all.
>
> then, shouldn't cmp stop caring about romnames too? ^_^ not complaining about
> this one, but i always found a bit strange your (and logiqx's) stance about
> this. in logiqx's case, i always thought "why doesn't he at least make it
> optional". in your case, i am actually surprised with the amount of options cmp
> already has that you didn't include this one. but your statement about not using
> merge tags explains it all...
>
> Pi - Every Precious Dream and Vision Underneath the Stars
> Arcade news, emulator archives and gamelists at CAESAR
>



I like it the strict way ;) Every listed ROM has to appear, if you got 10 roms with the same CRC32 but different name within a set, all 10 should appear. Usually the name is accurately based on the pcb itself.


Roman Scherzer
ClrMamePro