EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: yescabernetnointernet on 01 September 2022, 20:24
-
OK... First of all, let's define a legend:
Hey Roman, I'd like to understand more about the settings for merged sets.
(https://i.ibb.co/PTcDhYy/Profiler-Options-Misc-Profiler-Options-Parsing-Options-Hash-Collision.jpg) (https://ibb.co/PTcDhYy)
PROFILER > OPTIONS > MISC PROFILER OPTIONS
- Parsing Options
- Parse ROM 'merge' Tags
Why someone would not to parse the merge attribute (as declared inside M. A. M. E.'s XML) of a clone's rom name?
I mean, if I want my sets to be merged I need to tell clrmamepro to parse the merge attribute, right?
- Parse DISK 'merge' Tags
As above... I want my sets to be merged, so both roms and CHDs should be merged accordingly to what's declared inside M. A. M. E.'s XML.
- Hash Collision(is this enabled only when Hash Collision Name is selected in Full Merge Mode?)
- Single File
This will put only roms with same sha1sum inside its clone's subdirectory, right?
- Single Clone
This will put ALL roms of each clone with same sha1sum inside the relative clone's subdirectory, right?
- All Clones in Relationship
?
(https://i.ibb.co/nC6cTDG/Settings-Full-Merge-Mode.jpg) (https://ibb.co/nC6cTDG)
SETTINGS
- Full Merge Mode
- Normal Mode
?
- Hash Collision Name
"You use the hash collision naming convention fo all clone files, no matter if a hash collision happened or not."
? ... Please could you elaborate on this in simple terms :)
Looking at this excerpt as a reference, could you help me by reporting a concrete example?
<machine name="hotd4a" sourcefile="sega/lindbergh.cpp" cloneof="hotd4" romof="hotd4">
<description>The House of the Dead 4 (Export) (Rev A)</description>
<year>2005</year>
<manufacturer>Sega</manufacturer>
<biosset name="bios0" description="6.0.0010 alternate version"/>
<biosset name="bios1" description="6.0.0009"/>
<biosset name="bios2" description="6.0.0010"/>
<rom name="6.0.0010a.bin" merge="6.0.0010a.bin" bios="bios0" size="1048576" crc="10dd9b76" sha1="1fdf1f921bc395846a7c3180fbdbc4ca287a9670" region="pci:1f.0" offset="0"/>
<rom name="6.0.0009.bin" merge="6.0.0009.bin" bios="bios1" size="1048576" crc="5ffdfbf8" sha1="605bc4967b749b4e6d13fc2ebb845ba956a259a7" region="pci:1f.0" offset="0"/>
<rom name="6.0.0010.bin" merge="6.0.0010.bin" bios="bios2" size="1048576" crc="ea2bf888" sha1="c9c5b6f0d4f4f36620939b15dd2f128a74347e37" region="pci:1f.0" offset="0"/>
<rom name="fpr-24370b.ic6" merge="fpr-24370b.ic6" size="4194304" crc="c3b021a4" sha1="1b6938a50fe0e4ae813864649eb103838c399ac0" region="pci:1e.0:03.0" offset="0"/>
<rom name="vid_bios.u504" merge="vid_bios.u504" size="65536" crc="f78d14d7" sha1="f129787e487984edd23bf344f2e9500c85052275" region="pci:01.0:00.0" offset="0"/>
<rom name="317-0427-com.bin" merge="317-0427-com.bin" size="8192" crc="ef4a120c" sha1="fcc0386fa708af9e010e40e1d259a6bd95e8b9e2" region=":pic" offset="0"/>
<disk name="mda-c0004a_revb_lindyellow_v2.4.20_mvl31a_boot_2.01" merge="mda-c0004a_revb_lindyellow_v2.4.20_mvl31a_boot_2.01" sha1="e13da5f827df852e742b594729ee3f933b387410" region="cf" index="0" writable="no"/>
<disk name="dvp-0003a" sha1="46544e28735f55418dd78bd19446093874438264" region="dvd" index="0" writable="no"/>
[...]
## tuncated output ##
[...]
</machine>
If I understood correctly the merge mode, I should end up with this:
Parent romset
mame/hotd4.zip:
317-0427-com.bin
Parent CHD
mame/hotd4/:
dvp-0003b.chd
Clone CHD
mame/hotd4a/:
dvp-0003a.chd
BIOS romset
mame/lindbios.zip:
6.0.0009.bin
6.0.0010.bin
6.0.0010a.bin
fpr-24370b.ic6
vid_bios.u504
BIOS CHD
mame/lindbios/:
mda-c0004a_revb_lindyellow_v2.4.20_mvl31a_boot_2.01.chd
Thank you Roman!
-
"Why someone would not to parse the merge attribute (as declared inside M. A. M. E.'s XML) of a clone's rom name?"
Let's get back in time....clrmamepro was there before merging was there....and parent/clone relationships did exist before mamedevs introduced merge attributes. And there was a time where merge attributes were completely wrong or each rom had one and so on....back then it was not so reliable as today.
So...coming back from such ancient times, there needed to be a way to see which roms were shared and which were unique within a parent/clone relationship. clrmamepro did that by hash and name compare, i.e. identical hashes with different names were still 2 unique roms. And that's exactly what happens when you disable that option (which is enabled by default by the way). So it's a just a different way of finding out which roms are and which aren't shared.
Same applies for disk merge attributes.
"Hash Collision"
There are parent/clonerelations where roms have identical names but different hashes. So if you fully merge them, one gets overwritten. Unless you put them in subfolders. MAME would load them fine in subfolders when you use 7z/zips. So to prevent data loss when using full merged sets, cmpro can create such a subfolder for you (usually the name of the set but you can change it). "Single File" means, only the file in question gets the subfolder, single clone means, all (clone) files belonging to the clone with the hashcollision get the subfolder, "all clones in relationship" means, all clone files (there can be n clones for 1 parent) get the subfolder. So this option is more a matter of taste/cosmetics, e.g. if you want all or just single files with a subfolder.
"Normal mode" means, that only the set with a hash collision gets subfolders while "Hash Collision Name" means all sets (no matter if they have a collision or not". So with the latter one, you store your fully merged sets where the parent holds its roms on root level of the archive and each clone has a subfolder on its own.
"Your example"
It is correct for split merge mode.
For full merge mode, you wouldn't have mame/hotd4a/dvp-0003a.chd since it's a clone and also for chds, you would put them to the parent...so you'd have mame/hotd4/dvp-0003a.chd and mame/hotd4/dvp-0003b.chd.
Last but not least: This storing mechanism and tricks with subfolders to prevent overwriting of hash collisions isn't defined. MAME itself doesn't care. It follows the romof and deviceRef chain to locate files and doesn't care about names when loading, it loads by hash compare (at least when we talk about archived files).
-
Thanks! ;)