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