Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

tried it, but how do I verify the output?
https://www.emulab.it/forum/index.php?topic=8905.msg25366#msg25366

The readme.md tells you:



Since there is no scanner yet, can I scan my rebuilt sets with clrmamepro?
Yes, but be aware of the following:

• clrmamepro does not have the standalone merge mode (it only has not-merged + disable separate bios sets, but either way it won't match)
• clrmamepro's profiler options to parse disk/rom merge tags and don't create dummy clones have to be enabled (that's the default by the way) since the new rebuilder only cares about merge attributes for checking relationships.
• for full merged sets, clrmamepro's settings option "Hash Collision Name" mode has to be enabled (this is not enabled by default) and profiler option "naming pattern" should be "%f%1" (default). The new rebuilder always uses subpaths for clones/dependencies and that matches this behaviour. Keep in mind, this is only valid for compressed sets. Decompressed ones don't have subfolders, then don't enable the hash collision name mode.

Thanks for new version. I'm in process of rebuilding whole MAME 253 set without CHDs from fully extracted archives into separated directories.

Extracted files are placed on M.2 disk, destination will be Seagate SV35 3TB disk (not too fast but at the moment I don'r have extra SSD for destination). Let see how long it will take on Core i5 10600KF and 16 GB RAM versus standard clrmamepro

tried it, but how do I verify the output?
https://www.emulab.it/forum/index.php?topic=8905.msg25366#msg25366

then you should switch to new rebuilder's standalone mode...which really produces "unmerged" sets ;-)

I've used Rebuilder 0.05, you recently released on my RV created merged set to output a new merged set according to your algorithm.

I've noticed Rebuilder 0.05 (in Full mode) does also put all clones into subfolders, so that would mean when scanning the output with CMP, Hash Collision should be ticked, right?

I also verified, that indeed RB, does duplicate clone roms, that are not tagged as "merge", which I agree, is *the correct way* by design of the mame xml and default in CMP, unlike RV's algorithm (not sure how RV decides what is a parent, and when a clone should have roms, owned by another clone/revision). The difference is only about 3GB worth of 'redundant' data.

I'm currently running a RV scan, to check that that RB merged set is indeed complete, and if it actually reports redundant (clone) roms as unneeded (which I suspect).
After that I wil try a CMP scan again, and see if anything changed. I would suspect the missing but fixable should be gone now, but still there is the problem that I mentioned above, which is weird....

*edit*
as suspected, RV reports unneeded roms. But, it also reports a missing rom for osa_mastro.


It seems RB put osa_analyst into its own zip, osa_analyst.zip, while it has a romof="osa_maestro" tag. (it is missing a cloneof= tag though...)

Code: [Select]

<machine name="osa_analyst" sourcefile="src/devices/bus/saitek_osa/maestro.cpp" isdevice="yes" runnable="no" romof="osa_maestro">
<description>Analyst</description>
<biosset name="b" description="Analyst B"/>
<biosset name="c" description="Analyst C"/>
<biosset name="d1" description="Analyst D (set 1)" default="yes"/>
<biosset name="d2" description="Analyst D (set 2)"/>
<biosset name="dp" description="Analyst D+"/>
<biosset name="dpp" description="Analyst D++"/>
<rom name="m6l_a15_u2.u2" bios="b" size="32768" crc="91570897" sha1="e6db36ffc87ce3941a3e12222678069cff9e47f6" region="maincpu" offset="0"/>
<rom name="b6c_721_u3.u3" merge="b6c_721_u3.u3" bios="b" size="32768" crc="b1e57023" sha1="6cec5cdc0bf4f8ac88afb0397fcb4738136b0431" region="maincpu" offset="8000"/>
<rom name="m6l_b30d_u2.u2" merge="m6l_b30d_u2.u2" bios="c" size="32768" crc="bb10e15c" sha1="7b0fb987c49da76a03b46c80d2b4eacaa785ee75" region="maincpu" offset="0"/>
<rom name="b6c_721_u3.u3" merge="b6c_721_u3.u3" bios="c" size="32768" crc="b1e57023" sha1="6cec5cdc0bf4f8ac88afb0397fcb4738136b0431" region="maincpu" offset="8000"/>
<rom name="ma3_714a_u2.u2" merge="ma3_714a_u2.u2" bios="d1" size="32768" crc="435e1e30" sha1="0d82df7c40443cb341dacebdf65f33c3e03bce70" region="maincpu" offset="0"/>
<rom name="b6m_b15_u3.u3" merge="b6m_b15_u3.u3" bios="d1" size="32768" crc="6155de90" sha1="bb5cdf061dde2d1dc7925d455891c3ade1d274e3" region="maincpu" offset="8000"/>
<rom name="ma3_714a_u2.u2" merge="ma3_714a_u2.u2" bios="d2" size="32768" crc="435e1e30" sha1="0d82df7c40443cb341dacebdf65f33c3e03bce70" region="maincpu" offset="0"/>
<rom name="b6m_629_u3.u3" merge="b6m_629_u3.u3" bios="d2" size="32768" crc="15e7b1f1" sha1="d2a757114f13c6141d74a15671aa06b675304b4a" region="maincpu" offset="8000"/>
<rom name="m6m_625_u2.u2" merge="m6m_625_u2.u2" bios="dp" size="32768" crc="aa7b5cfd" sha1="e909108fdace633a519fecf0b9876fe6a46b2067" region="maincpu" offset="0"/>
<rom name="b6m_614_u3.u3" merge="b6m_614_u3.u3" bios="dp" size="32768" crc="eff75543" sha1="d7c1b3824bc87d5ffada6f5c8c72a8b292ff3d46" region="maincpu" offset="8000"/>
<rom name="d++_u2.u2" merge="d++_u2.u2" bios="dpp" size="32768" crc="48ef032c" sha1="d336cb2096780b4d3bcceda0d2ed1246e780cd8d" region="maincpu" offset="0"/>
<rom name="b6m_614_u3.u3" merge="b6m_614_u3.u3" bios="dpp" size="32768" crc="eff75543" sha1="d7c1b3824bc87d5ffada6f5c8c72a8b292ff3d46" region="maincpu" offset="8000"/>
<device_ref name="r65c02"/>
<device_ref name="generic_socket"/>
<device_ref name="software_list"/>
<device_ref name="hd44780_a00"/>
<chip type="cpu" tag=":maincpu" name="Rockwell R65C02" clock="8000000"/>
<configuration name="CPU Frequency" tag=":FAKE" mask="7">
<confsetting name="4MHz" value="0"/>
<confsetting name="5.67MHz" value="1"/>
<confsetting name="6MHz" value="2"/>
<confsetting name="7.2MHz" value="3"/>
<confsetting name="8MHz" value="4" default="yes"/>
<confsetting name="10MHz" value="5"/>
</configuration>
<device type="romimage" tag=":extrom" interface="saitek_egr">
<instance name="romimage" briefname="rom"/>
<extension name="bin"/>
</device>
<slot name=":extrom">
</slot>
<softwarelist tag=":cart_list" name="saitek_egr" status="original"/>
</machine>
So as you can see, RV wants to remove all redundant roms as we already established, and might be considered incorrect, as per interpretation. But it also wants to move osa_analyst, to a subfolder/clone to osa_meastro.


*edit2*
As for CMP, (unless I'm doing something complete wrong here) it looks like even Rebuilder 0.05 can't produce a merged mame romset that can satisfy the scanner.. (no offence).




I have used CMP years back... but it has lost credibility for me. And I do not mean that in offence. I respect your work.. but these inconsistencies are driving me nuts...

how is it possible that alpinesa isn't listed as a clone to its parent alpines. in doing so, CMP wrongfully considers alpinesa as the parent and wants to rename alpines.zip to alpinesa.zip. This surely can't be by design?:


While this might not break MAME, it is not consistent with the XML:

Code: [Select]

<machine name="alpinesa" sourcefile="namco/namcos22.cpp" cloneof="alpines" romof="alpines">
<description>Alpine Surfer (World, AF2 Ver.A, set 2)</description>
<year>1996</year>
<manufacturer>Namco</manufacturer>
<rom name="af2ver-a_ll.ic2" size="2097152" crc="d8025e98" sha1="e1c08557e70d632bf1e99356d6c6f76b5f407b8f" region="maincpu" offset="3"/>
<rom name="af2ver-a_lm.ic3" size="2097152" crc="5f805d51" sha1="b7fa9028deeaf1c549e9c2d6099925a0d0ad1598" region="maincpu" offset="2"/>
<rom name="af2ver-a_um.ic4" size="2097152" crc="e7e057e3" sha1="436e4645ba0e8734c0e25c7c22489bf97066944d" region="maincpu" offset="1"/>
<rom name="af2ver-a_uu.ic5" size="2097152" crc="3eee10a2" sha1="6e52c5132581e7fe69a257195af5bc9f3a3efe25" region="maincpu" offset="0"/>
<rom name="c71.bin" merge="c71.bin" size="8192" crc="47c623ab" sha1="e363ac50f5556f83308d4cc191b455e9b62bcfc8" region="master" offset="0"/>
<rom name="c71.bin" merge="c71.bin" size="8192" crc="47c623ab" sha1="e363ac50f5556f83308d4cc191b455e9b62bcfc8" region="slave" offset="0"/>
<rom name="af1data.8k" merge="af1data.8k" size="524288" crc="ef13ebe8" sha1="5d3f697994d4b5b19ee7fea1e2aef8e39449b68e" region="mcu" offset="0"/>
<rom name="af1scg0b.12f" merge="af1scg0b.12f" size="2097152" crc="46a6222a" sha1="5322ef60690625b9b8dbe1cfe0c49dcd9c8b1a4c" region="sprite" offset="0"/>
<rom name="af1cg0.8d" merge="af1cg0.8d" size="2097152" crc="7423f3ff" sha1="6a2fd44823ef46111deb57d328b1b75cc355d413" region="textile" offset="0"/>
<rom name="af1cg1.10d" merge="af1cg1.10d" size="2097152" crc="ea76689a" sha1="73dd3af737a3e9903abe5ed9c9ae7eded51d8350" region="textile" offset="200000"/>
<rom name="af1cg2.12d" merge="af1cg2.12d" size="2097152" crc="2a38943a" sha1="15d737996f49bf6374ef6191bbfbe0298d398378" region="textile" offset="400000"/>
<rom name="af1cg3.13d" merge="af1cg3.13d" size="2097152" crc="7f5a3e0f" sha1="241f9995323b28df23d20a75e1f43ce6e05434cd" region="textile" offset="600000"/>
<rom name="af1cg4.14d" merge="af1cg4.14d" size="2097152" crc="a5ee13e2" sha1="48fd3c912690f21cbbc2a39bed0a82be41a0d011" region="textile" offset="800000"/>
<rom name="af1ccrl.3d" merge="af1ccrl.3d" size="2097152" crc="6c054698" sha1="8537607646b183883c5aa4060fb0af640da4af87" region="textilemap" offset="0"/>
<rom name="af1ccrh.1d" merge="af1ccrh.1d" size="524288" crc="95a02a27" sha1="32ee87b76ae9fcec6d825e3cf4d5cbb97db39544" region="textilemap" offset="200000"/>
<rom name="af1ptrl0.18k" merge="af1ptrl0.18k" size="524288" crc="31ce46d3" sha1="568fb9ee9ac14e613a4fd7668cb38315c10be62b" region="pointrom" offset="0"/>
<rom name="af1ptrl1.16k" merge="af1ptrl1.16k" size="524288" crc="e869bf00" sha1="b3c3026891ae3958d1774c905e97c3b57a414ea7" region="pointrom" offset="80000"/>
<rom name="af1ptrm0.18j" merge="af1ptrm0.18j" size="524288" crc="ef7f4d8a" sha1="02f77c68004b7dccc99b61126e7d07960eb15028" region="pointrom" offset="100000"/>
<rom name="af1ptrm1.16j" merge="af1ptrm1.16j" size="524288" crc="7dd01d52" sha1="adc1087435d31ed6163ad046466955f01517450f" region="pointrom" offset="180000"/>
<rom name="af1ptru0.18f" merge="af1ptru0.18f" size="524288" crc="177f1591" sha1="3969e780e5603eca0a65f65c1ad14d1cef918b39" region="pointrom" offset="200000"/>
<rom name="af1ptru1.16f" merge="af1ptru1.16f" size="524288" crc="7521d18e" sha1="dc03ef369db16f59c138ff4e22260d1c04782d1f" region="pointrom" offset="280000"/>
<rom name="af1wavea.2l" merge="af1wavea.2l" size="4194304" crc="28cca494" sha1="4ff87ab85fd17bf8dbee5b03d99cc5c31dd6349a" region="c352" offset="0"/>
...
After having a look at the changelog, and noticing the following:

Code: [Select]

4.046a (2022-08-16)
  revert: since MAME does not support subfolders on unpacked sets, the disk names handling change from 4.046a needs to be reverted

4.046 (2022-08-14)
  fixed: support for other sample extensions is broken
  fixed: more compatibility for standalone rebuilder tool in handling disk names in full merged mode (hash collision mode)
  fixed: more compatibility for standalone rebuilder tool in handling of devices with romof attributes in full merged mode
  misc: updated 7zip sdk/dll tp 2201I even reverted to 4.046 in the hopes that would fix it, but nothing...

@Pandor: not on PC ATM, but IIRC starting from the same -listxml and using merged sets you'll end up with same results on both CMP and RV.
Only thing you need to change in CMP is the Hash Collision methodology (as Roman already told you) and you'll have same Scan results. 
...

Tried it with those settings, to no success.
I might have done something wrong, but CMP doesn't even seem to honor the mame xml output...
Example for 'Zackman':

While to XML clearly states the folowing:

Code: [Select]

<machine name="zackman" sourcefile="handheld/hh_hmcs40.cpp">
<description>Zackman</description>
<year>1983</year>
<manufacturer>Bandai</manufacturer>
<rom name="hd38820a49" size="4352" crc="b97f5ef6" sha1="7fe20e8107361caf9ea657e504be1f8b10b8b03f" region="maincpu" offset="0"/>
<rom name="zackman.svg" size="910695" crc="8385497b" sha1="eec68a9f677e3ae849414278f6461929d77f3169" region="screen" offset="0"/>
<device_ref name="hd38820"/>
<device_ref name="screen"/>
<device_ref name="pwm_display"/>
<device_ref name="speaker"/>
<device_ref name="speaker_sound_device"/>
<chip type="cpu" tag="maincpu" name="Hitachi HD38820" clock="400000"/>
<chip type="audio" tag="mono" name="Speaker"/>
<chip type="audio" tag="speaker" name="Filtered DAC"/>
<display tag="screen" type="svg" rotate="0" width="487" height="1080" refresh="60.000000" pixclock="31557600" htotal="487" hbend="0" hbstart="487" vtotal="1080" vbend="0" vbstart="1080" />
<sound channels="1"/>
<input players="1">
<control type="joy" buttons="1" ways="8"/>
</input>
<port tag=":IN.0">
</port>
<port tag=":IN.1">
</port>
<port tag=":IN.2">
</port>
<port tag=":IN.3">
</port>
<port tag=":IN.4">
</port>
<driver status="good" emulation="good" savestate="supported"/>
</machine>according to the XML filesize should be 910695 for zackman.svg (which it is), but CMP insists it should be 910689 with different CRC?
What kind of sorcery is this?   

I understand that CMP, unlike RV might want to duplicate roms shared between clones if there is no merge TAG present. but not honoring the filesize and CRC as described in the XML seems weird.. Where is it getting this from?

Fantastic!
Thanks Roman 

Rebuilder 0.05 released

https://mamedev.emulab.it/clrmamepro/binaries/rebuilder_v005.zip
https://mamedev.emulab.it/clrmamepro/binaries/readme.html

0.05 has a major unicode update, so now all your utf8 chars (no matter if in the datfile, in archives, in folders, in log output etc) should be handled correctly.

As a small extra...(I had a little time and wanted to see how easy it is to reuse the core) I've added rebuilderUI ;-)
It's a tiny UI for the rebuilder....the options should be easy to understand since they match the commandline parameters. The log list has a context menu and the window is resizable (things you don't see on the screenshot below).

RebuilderUI (rebuilderUI.exe) saves its settings in settings_ui.xml while the commandline rebuilder (rebuilder.exe) uses settings.xml. Both need the 7z.dll.

Hope you enjoy it...

then you should switch to new rebuilder's standalone mode...which really produces "unmerged" sets ;-)

@Pandor: not on PC ATM, but IIRC starting from the same -listxml and using merged sets you'll end up with same results on both CMP and RV.
Only thing you need to change in CMP is the Hash Collision methodology (as Roman already told you) and you'll have same Scan results. 

Anyway,
may I suggest you mixing the modes for your romset?
I find myself really pleased with roms UNMERGED (including BIOS) and chd sets merged.
Be aware I'm meaning chd sets, not chd.

"As you say, I think it will deem it as unneeded, and move it to rev3 where it is 'needed', if not present, and discard it from rev4. But I have not tested this."

Why should it be needed in rev3 and not vice versa? just because some string says revision 3 versus 4 and an xml ordering of 3 before 4....Sorry...but I don't follow this logic.... :-)

You are absolutely right. Maybe it's just my human logic, that a previous revision (or named so), would be a 'parent' to a latter revision, and that a child could receive from its parent... Don't get me wrong. you make a lot of sense. I'm not trying to undermine, just understand.