Print

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

[Roman]

if anyone still use the old tool....

https://mamedev.emulab.it/clrmamepro/binaries/cmpro64_20241207.zip
(64bit exe only)

it only fixes a problem with not detecting unneeded files in a sample parent set..... The bug was in there since decades I think

Definetly time to use the new tools ;-)

[john iv]

Thanks; keeping it around for delta chd detection/creation.

[john iv]

Hmm, have some different results w/ the same .exe:
1. 'classic' cmpro is flagging these hitachis as not being in their parent.
2. new clrmameui does not complain of the initial problem; but it does complain *after* I let cmpro 'fix' its issues in step 1. (screenshot)

[Roman]

I will look into it.........tomorrow...

[Roman]

Ah....devices with romof relations but not cloneof....

hd44780
hd44780u romof hd44780
sed1278   romof hd44780
....

clrmamepro hacked in a parent/clone relationship based on the "romof" statement. But actually hd44780 is not the parent of sed1278 /etc.


the new tools know about linked dependencies (following the romof chain) but for "split or full merge" mode, the cloneof attribute is used.

That's why old cmpro complains about the files (since it wants them in the fake parent), while the new scanner keeps them separated...

[Roman]

I think the reason for having a parent/clone relationship hacked in cmpro was that there were some device romof which actually shared identical files....can't really rememeber.
If I find a little time I will double check it. For now, I'd go with the new solution....no "cloneof" -> no parent/clone relationship. "romof" however plays a role for dependencies (e.g. in standalone mode). BIOSes are included that way for example. Open for comments ;-)

[john iv]

Thanks Roman, I like the way the new tools handle it.  Just mentioned the different behaviour in the classic version in the event there might be people that use it to 'double check' the new tools' results.