3001
clrmame Discussion / Re: Help!
« on: 22 April 2010, 08:20 »
here we go..
Set = a collection of roms and/or samples and/or chds. You can have sets which for example only consist of a chd.
A little bit CHD storing technique history..
When MAME introduced chds a long time ago, they need to be stored in the official way how MAME loads files:
rompath\setname\file 1...file n
MAME looks into a rompath, seeks a folder named after the set or a zipfile named after the set and then loads roms/samples/chds from that position. Yes, back at that time it was also possible to put a chd into the roms zipfile which is of course nonsense because chds are zlib compressed containers on their own.
So you store e.g. the area51.chd in d:\mame\roms\area51\area51.chd. Looks easy..but don't get fooled, \area51\ is the setname here while area51.chd is the chd filename. They don't necessarily are identical. Usually the filename follows the hd/cd/whatever image's orginal hardware name.
Later on in that history, due to a bug in the implementation, it was possible to have chds on rompath rootlevel (d:\mame\roms\area51.chd). Well, as you can see, you won't be able to see to which set the chd belongs to. As long as a chd is named after the set...ok fine...but have a look at e.g. Naomi or Konami chds...
That bug was fixed and for a long time the official storing method was used again.
With MAME .130 or something, the chd format was updated and because people had to convert a lot of chds manually, some developer reenabled the usage of chds-on-rompath-root level again. So currently, both methods can be used and it's up to you which one you prefer...(most people prefer the official one with setsubfolders).
Enough history talk....
If you want to have chds on root level, you need to tell cmpro this...Scanner->Advance->allow chds on rompath root.
If you want to have your chds in setsubfolders (then disable the upper option), cmpro can help you to do the move part and the subfolder creation. Simply put the chds in a rompath root and scan/fix with sets+roms+chds+unneeded+name check (or simply got all enabled...). Cmpro will then move the wrong placed chds to their correct place.
Now to your log...
"wrong merged ROM set:"
Well, you decided to have fully merged sets.
This means that you keep only a parent set and all belonging clones are merged into this. This includes CHDs. This means for you got one zipfile for the roms and one setsubfolder for all chds of that set (parent and clone). Of course only if you use the setsubfolder chd mode. Other clone zips and clone setsubfolders can be removed.
"wrong placed chd"
Exactly what is written above, cmpro tells you to move the chd to the correct (parent) folder
"missing chd"
well...you don't have it...get it
The fisherman's bait etc naming weirdness....Or in other words...Konami....yes..it might look weird...and it is a combination of the konami chds definition in the database and your used storing method. Konami uses different names for identical clone chds..which look a bit weird (and depending on the profiler option to parse or not parse disk merge tags it plays a role if you need them multiple times or not...so keep that option enabled).
So, first decide how to keep chds, then enable or disable the beloning allow-chd-on-rompath-root level option depending on your selection.
Then scan again and let cmpro fix the files for you.
Set = a collection of roms and/or samples and/or chds. You can have sets which for example only consist of a chd.
A little bit CHD storing technique history..
When MAME introduced chds a long time ago, they need to be stored in the official way how MAME loads files:
rompath\setname\file 1...file n
MAME looks into a rompath, seeks a folder named after the set or a zipfile named after the set and then loads roms/samples/chds from that position. Yes, back at that time it was also possible to put a chd into the roms zipfile which is of course nonsense because chds are zlib compressed containers on their own.
So you store e.g. the area51.chd in d:\mame\roms\area51\area51.chd. Looks easy..but don't get fooled, \area51\ is the setname here while area51.chd is the chd filename. They don't necessarily are identical. Usually the filename follows the hd/cd/whatever image's orginal hardware name.
Later on in that history, due to a bug in the implementation, it was possible to have chds on rompath rootlevel (d:\mame\roms\area51.chd). Well, as you can see, you won't be able to see to which set the chd belongs to. As long as a chd is named after the set...ok fine...but have a look at e.g. Naomi or Konami chds...
That bug was fixed and for a long time the official storing method was used again.
With MAME .130 or something, the chd format was updated and because people had to convert a lot of chds manually, some developer reenabled the usage of chds-on-rompath-root level again. So currently, both methods can be used and it's up to you which one you prefer...(most people prefer the official one with setsubfolders).
Enough history talk....
If you want to have chds on root level, you need to tell cmpro this...Scanner->Advance->allow chds on rompath root.
If you want to have your chds in setsubfolders (then disable the upper option), cmpro can help you to do the move part and the subfolder creation. Simply put the chds in a rompath root and scan/fix with sets+roms+chds+unneeded+name check (or simply got all enabled...). Cmpro will then move the wrong placed chds to their correct place.
Now to your log...
"wrong merged ROM set:"
Well, you decided to have fully merged sets.
This means that you keep only a parent set and all belonging clones are merged into this. This includes CHDs. This means for you got one zipfile for the roms and one setsubfolder for all chds of that set (parent and clone). Of course only if you use the setsubfolder chd mode. Other clone zips and clone setsubfolders can be removed.
"wrong placed chd"
Exactly what is written above, cmpro tells you to move the chd to the correct (parent) folder
"missing chd"
well...you don't have it...get it
The fisherman's bait etc naming weirdness....Or in other words...Konami....yes..it might look weird...and it is a combination of the konami chds definition in the database and your used storing method. Konami uses different names for identical clone chds..which look a bit weird (and depending on the profiler option to parse or not parse disk merge tags it plays a role if you need them multiple times or not...so keep that option enabled).
So, first decide how to keep chds, then enable or disable the beloning allow-chd-on-rompath-root level option depending on your selection.
Then scan again and let cmpro fix the files for you.
?