EMULAB Forum
clrmamepro [English] => clrmame Discussion => Topic started by: Roman on 04 December 2012, 19:19
-
4.09
fixed: rename profiles (which are based on a xml dat) corrupts xml structure
fixed: fix missing doesn't look into parent set in rompaths in full merge mode it might oversee missing but fixable roms
misc: changed size of compressor settings window
-
I post this at the MAMEWorld just now. =)
-
Thought I had this solved, but it returned when I did a complete scan using v4.09a (64-bit). I'm using merged sets, and when it scans to the p911 CHDs, I get stuck in an endless loop:
Missing CHD: a00kac02.chd
solution: copy a00uac02 to a00kac02....(same SHA1)
...Scan....warning goes away.
New Scan....
warning: a00kac02 is named wrong...cannot rename since a00uac02 already exists
solution: remove a00kac02...
errors/warnings gone...until....I perform a complete scan again, then I go thru the above all over.
I've tried changing "Advanced / Allow CHDs in ROMPath Root" ... no change. I've tried moving them to their own folder (cmpro then moves them to the parent folder, and problem persists).
Is there a setting I'm missing or is this just something to expect when merging roms?
Many thanks!
cmpro: 64-bit v4.09a
mame64: v0.147u4
-
I can have a look at it later tonight...but generally:
- check if you got profiler->options->Parse Disk Merge tags enabled
- keep "Allow CHDs in ROMPath Root" disabled if you store chds in subfolders (which is the common way)
- clone chds need to be stored in their parent set's folder
-
For a full merged p911 set your rompath should contain:
p911.zip with the files: a00uad_nvram.u39, a00eaa_nvram.u39, a00jaa_nvram.u39 and a00kac_nvram.u39
kviper.zip with 941a01.u25, 941b01.u25 and ds2430.u3
and a subfolder named p911 with the chds:
a00eaa02.chd, a00jac02.chd, a00kac02.chd, a00uac02.chd and a00uad02.chd
-
> - check if you got profiler->options->Parse Disk Merge tags enabled
I don't have this option enabled - should it be?
-
yes it should be enabled. Otherwise you need several identical chds twice...which is a waste of diskspace...on the other hand, even with this option disabled, you shouldn't run in that fixing loop...I did not test it yet with this option disabled....I will tonight.
-
- check if you got profiler->options->Parse Disk Merge tags enabled
What about profiler->options->Parse ROMs Merge tag?
should it be enabled or disabled?
I'm keeping split rom sets, btw.
-
ehe...I knew that somebody will ask this...
well...yes, you can enable it too if you like....a new scan will then list a lot of unneeded files for you. The reason why it's not enabled by default is that the rom merge information was too often too wrong in MAME's past. (However cmpro tried to fix this automatically).
The whole story is about differently named files within a parent clone relationship which are physically identical. Usually there is a reason for the diffent name (to match the real IC name on the boards), so for cmpro it means: different names = different roms...your somehow turn this off when enabling rom merge tag parsing. If you currently have a differently named but identical rom in a clone, it will be removed if you got a copy of it already in the parent (with a different name).
In times of multi-terabyte hds and maniacs who collect a full mame set, noone should really care about the saved disk space when enabling it...but anyway...it's your personal taste...
actually when I do some brainstorming about a rewrite of cmpro I think of removing all special rules.....it will end in something like:
- only xml datfiles (MAME dtd)
- other (xml) formats need to do a xslt transformation
- trust in the given xml, i.e. always use merge tags, don't care possible issues during fullmerging based on different roms with identical names (the scanner/rebuilder should handle that) etc..etc...
- no more support for old style rules (like old bad_dump handling via ~crc32)
etc etc...should make life much more easy...at least for the developer ;)
...but hey...not a single line is written yet....
-
did a test with and without the profiler options.....no issues here. Follow the storing method for the files which I've posted and everything should work right (cache clear / new scan).
-
Thank you for the long explanation Roman, very much appreciated.
So basically the general rule should be:
Split set -> ROM merge parsing UNCHECKED
Merge set -> ROM merge parsing CHECKED
Correct?
-
well....sort of...as I said...it's your personal taste...while the defaults are my personal taste....but yes, the full/split merge difference make sense for the merge tags option, too.