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

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

1

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 16 April 2023, 15:09 »

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?

Easy answer: You're tring to scan a 253 collection with a MAME binary based on 239 (the window title of your screenshot shows it). Back then the hashes were different.

I've just noticed it after I made a split set. man, I feel dumb now. Must have grabbed an old mame version of my drive to create the profile. *hitting head against the wall*
Sorry about the rant, and wasting your time.

2

clrmame Discussion / Re: rebuilder 0.05 released

« on: 15 April 2023, 14:51 »

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

3

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 15 April 2023, 13:14 »

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

4

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 15 April 2023, 10:38 »

@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?

5

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 12:53 »

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

6

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 12:44 »

It's fun to hear the diskspace argumentation in 2023....if you decided to collect MAME (and maybe software lists) you shouldn't care about the few extra size of such "clones of clones" at all....each upcoming laserdisk chd will be more than all the files together...
...

I come from a time where a MAME collection would fit on a CD-rom... 
I had a spare 1TB drive, devoted to MAME (started years back), up till now. The past weekend I decided to fire it up again, and update my (then) split sets, but came to the conclusion the drive wasn't going to cut it anymore. so I decided to try my luck with a merged romset.

The (popular*)source I got it from, seems to use romvault as a means to manage the roms. So this is why I got intrigued into the reason why it does not match a CMP scan. Your replies have been verry educational and helpful, for which my gratitude.

For me it actually doesn't matter if I have a set as a single zip, or 20 zipfiles, but storage has become a 'problem', as in "i'll need to get myself a bigger disk for MAME now".

7

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 12:20 »

would it list an additional 136081-3030.15d rom with f143f0e16850ad98366db208e956f7402d1ca848 in pitfight4 as unneeded then? Or would it simply mark it green?
...

re-reading this, I get your point, and is something i'll test. Just like mame, it is possible that RV doesn't care where the file/rom is. and it will mark it green eighter way. but it is still a rom manager, so there should be some 'standard' it adheres to, and not put it randomly in a subfolder/zip that is most convenient, or it would never be consistent.

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.

8

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 12:08 »

would it list an additional 136081-3030.15d rom with f143f0e16850ad98366db208e956f7402d1ca848 in pitfight4 as unneeded then? Or would it simply mark it green?



Well, it's of course your decision, however if you're coming from MAME's -listxml output, you see that e.g. "136081-3030.15d" from pitfighter 3 and 4 do not have any "merge" attribute set...and if you follow the idea of having the archive structure like

- the archive is named after the parent set
- the subfolders in the archive are named after the clones and each holds the files for that clone but limits it to the ones which differ from its parent

Sounds a bit more structured if you ask me.....(compared to..."ah yeah...and it also needs a file from another subfolder since the clone shares a file with another clone, too)

But again...it's all about interpretation and personal taste.....however it's now 26 years that I hear of a full merged storing method like that (romvault's)...may be an idea as additional view for the rebuilder tool (https://www.emulab.it/forum/index.php?topic=8816.0) which currently supports split, full (always with subfolders) and "standalone" which is also "new" compared to cmpro....

This way it does save (some marginal) space, doesn't it? as in my pit fighter example, rev3 becomes a parent for rev4, and rev4 only includes roms that are not in rev3. in CMP's case, the roms from rev3 are duplicated from rev3 to rev4 and only the actual (head) parent, pitfight is taken into account, right?
I'm not saying this is the 'correct' way. Just thinking out loud, and trying to figure out the difference between CMP en RV, and why they differ.

What about split then? will CMP also include the rev3 roms into the rev4 zip?

Becuase the way I see it now (I could be completely wrong), merged is just the same as split, but clones are just included as subfolder in the parent/main zip, which could save some space because of zipfile header/encapsulation overhead?

9

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 11:49 »

Just for reference, this is how RomVault interprets the same set:

10

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 11:27 »

Thanks. So as you say, and what I suspected, it is subject to interpretation (there is no standard unfortunately, and MAME does indeed not care, as long as the file is there somewhere), and it seems CMP and RV differ in that aspect. so a RV merged romset, is not compatible with CMP's algorithm, apparently (and vice/versa).

I've always been a split set advocate, but thought I would change that for this current set. I guess it bit me in the *ss 

I'll just stick to RomVault then. it is, in my humble personal opinion a bit more intuitive and user-friendly.

Thanks for the help though. It did clear up a lot.

11

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 10:53 »

CMP does (now) show the subfolder in front of the rom in the SetInformation, and pitfall seems okay now.

But now i'm left with a large list of "missing but fixable"

Seems like pit fighter rev4 want the include roms that are from pit fighter rev3 (and are present).
I don't believe this should be by design for a merged romset, as the proceeding revision already has the correct files.

settings and profile are correct (I believe):


Ater all this,
I tried starting over from a freshly unzipped CMP, reloading mame.exe,.... nothing seems to do the trick.

12

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 09:39 »

followed your suggestions, but still same result.

13

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 09:27 »

Looks like you're using full merged sets where all client files are *always* stored in subfolders.
By default, cmpro only does this when a merge collision was detected to prevent overwriting of files (when a clone uses an identically named rom file but with a different hash).
If you want to always use subfolders, go to Settings and turn on Full Merge Mode -> Hash Collision Name

Thanks for the detailed explanation.
I believe subfolders are the default for romvault, hence it verifies as 100%.

Prior to trying CMP, I used romvault to go from an older split set, to the latest merged romset, i'm trying to validate with CMP.
My set also verifies with the (torrent)source of the current set.

unfortunately, setting Hash Collision Name in settings and performing a new scan did not fix it for me.

14

clrmame Discussion / Re: mame merged sets not scanning correctly?

« on: 13 April 2023, 09:09 »

For romvault I extraxted the XML manually. For CMP, it is a direct import from mame.exe.
Merge tag options are 'on' as per default settings for Clrmamepro 4.047 (this is a new freshly unzipped, first usage case).

steps to reproduce:

• extract and run Clrmamepro 4.047
• create profile from mame.exe and load
• add rompath in settings
• set scanner option to prefer merged sets
• click new scan

as per request, screenshot of the scan, and proof the rom actually exist, despite CMP claiming the rom is not there (and/or wrong filename):

15

clrmame Discussion / mame merged sets not scanning correctly?

« on: 13 April 2023, 08:42 »

Hi,

I'm trying to verify a MAME 0.253 merged romset, But Clrmamepro 4.047 is reporting a whole lot of missing sets and wrong filenames. DAT/xml was created from mame.exe. default Clrmamepro settings. only change made is Merged sets selected in scanner window.

Romvault reports a 100% valid set with the same mame.exe xml output, so i kow for a fact the set is good.

I found this old post, with similar report, here.

Anyone know if there is any (default)setting that could cause this?