2981
clrmame Discussion / Re: MESS and software lists
« on: 05 May 2010, 19:10 »
hehe...no...it will show that for each rom...but actually I can switch that off for softwarelists...
- 19 April 2024, 22:55
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
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.
2982
clrmame Discussion / Re: MESS and software lists
« on: 05 May 2010, 18:59 »
ok...but cmpro will show a warning for the rom without name then.....
2983
clrmame Discussion / Re: MESS and software lists
« on: 05 May 2010, 18:08 »
ok...hashfile works in profiler, -listsoftware output works also... however I found something weird looking in ibmpcjr_cart:
<rom name="basic.bin" size="32768" crc="8fc2a724" sha1="216915e954d393e42a30d1eb8666371439dcbd38" offset="0"/>
<rom size="32768" offset="8000" loadflag="reload" />
the second rom tag doesn't hold any name......any comment on this? Should this mean to load the same rom again at a different offset?
<rom name="basic.bin" size="32768" crc="8fc2a724" sha1="216915e954d393e42a30d1eb8666371439dcbd38" offset="0"/>
<rom size="32768" offset="8000" loadflag="reload" />
the second rom tag doesn't hold any name......any comment on this? Should this mean to load the same rom again at a different offset?
2984
clrmame Discussion / Re: MESS and software lists
« on: 05 May 2010, 10:39 »
you got a software list handy with cloneof statements? The url http://git.redump.net/cgit.cgi/mess/plain/hash seems to be down at the moment
2985
clrmame Discussion / Re: MESS and software lists
« on: 04 May 2010, 19:20 »
hmm...well...currently I only see a chance to support them as a xml file, i.e. you need to create the xml for the softwarelist yourself and then you can load it in the profiler similar to other dats...
<softwarelists>
<softwarelist name= ..../>
</....>
hmm....I guess I will also only support one softwarelist in softwarelists.....
<softwarelists>
<softwarelist name= ..../>
</....>
hmm....I guess I will also only support one softwarelist in softwarelists.....
2986
clrmame Discussion / Re: What's the best way to accomplish this?
« on: 01 May 2010, 18:27 »
the rename wizard is mainly to find renames between two datfiles. what you do with its output is your choice. I use it to do renames in mainly artwork related dats. For your case the described method of scanning and fixing all sets (instead of limiting) and hiding completely missing sets afterwards is in my opinion the way to go. with that method you got the full functionality and dont have to care about filters and stuff. .....or you create dats on your own...which means some manual work. currently I dont see a chance to add a rename check on the avail. sets button procedure.
2987
clrmame Discussion / Re: What's the best way to accomplish this?
« on: 30 April 2010, 14:37 »
Well, first of all if you only want to keep some US clones, you need to switch to unmerged sets.
Reason: If you don't keep parent files you skip the full-merged method where all files are merged into the parent set and -in case of split merging- you won't have the needed parent files available.
Renaming operations from one MAME version to another is one of the reasons why limiting the set list for auditing is a bad idea. If the set was renamed (and the new name isn't enabled), the scanner won't pick it up for renaming (hmm...actually I need to test this...but I'm afraid the renaming works only on the enabled sets). And hitting 'available sets' will only quickly check for the filename....and won't enable it since a new name is required.
What you can do is: Use the setinformation's window "select sets" option which allows selection with wildcards....e.g. %d=*(US)* to enable all sets which got "(US)" in the description string which is usually an indicator for US sets.....however, this is not limited to the sets you got.
The better idea is to not limit your sets....and hide completely missing ones afterwards.
See also: http://www.emulab.it/forum/index.php?topic=22.msg439#msg439 on limiting sets...
Reason: If you don't keep parent files you skip the full-merged method where all files are merged into the parent set and -in case of split merging- you won't have the needed parent files available.
Renaming operations from one MAME version to another is one of the reasons why limiting the set list for auditing is a bad idea. If the set was renamed (and the new name isn't enabled), the scanner won't pick it up for renaming (hmm...actually I need to test this...but I'm afraid the renaming works only on the enabled sets). And hitting 'available sets' will only quickly check for the filename....and won't enable it since a new name is required.
What you can do is: Use the setinformation's window "select sets" option which allows selection with wildcards....e.g. %d=*(US)* to enable all sets which got "(US)" in the description string which is usually an indicator for US sets.....however, this is not limited to the sets you got.
The better idea is to not limit your sets....and hide completely missing ones afterwards.
See also: http://www.emulab.it/forum/index.php?topic=22.msg439#msg439 on limiting sets...
2988
clrmame Discussion / Re: MESS and software lists
« on: 29 April 2010, 18:05 »
ok..got it working now
2989
clrmame Discussion / Re: MESS and software lists
« on: 29 April 2010, 17:37 »
no go....
D:\temp\mess>mess ibmpcjr -listsoftware
<?xml version="1.0"?>
<!ELEMENT softwarelists (softwarelist*)
<!ELEMENT softwarelist (software+)>
<!ATTLIST softwarelist name CDATA #REQUIRED>
<!ATTLIST softwarelist description CDATA #IMPLIED>
<!ELEMENT software (description, year?, publisher, part*)>
<!ATTLIST software name CDATA #REQUIRED>
<!ATTLIST software cloneof CDATA #IMPLIED>
<!ATTLIST software supported (yes|partial|no) "yes">
<!ELEMENT description (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT publisher (#PCDATA)>
<!ELEMENT part (dataarea*)>
<!ATTLIST part name CDATA #REQUIRED>
<!ATTLIST part interface CDATA #REQUIRED>
<!ATTLIST part feature CDATA #IMPLIED>
<!ELEMENT dataarea (rom*)>
<!ATTLIST dataarea name CDATA #REQUIRED>
<!ATTLIST dataarea size CDATA #REQUIRED>
<!ATTLIST dataarea databits (8|16|32|64)
"8">
<!ATTLIST dataarea endian (big|little) "
little">
<!ELEMENT rom EMPTY>
<!ATTLIST rom name CDATA #IMPLIE
D>
<!ATTLIST rom size CDATA #REQUIR
ED>
<!ATTLIST rom crc CDATA #IMPLIED
>
<!ATTLIST rom md5 CDATA #IMPLIED
>
<!ATTLIST rom sha1 CDATA #IMPLIE
D>
<!ATTLIST rom offset CDATA #IMPL
IED>
<!ATTLIST rom status (baddump|no
dump|good) "good">
<!ATTLIST rom loadflag (load16_b
yte|load16_word|load16_word_swap|load32_byte|load32_word|load32_word_swap|load32
_dword|load64_word|load64_word_swap|reload) #IMPLIED>
<softwarelists>
<softwarelist name="ibmpcjr_cart">
</softwarelist>
</softwarelists>
D:\temp\mess>mess ibmpcjr -listsoftware
<?xml version="1.0"?>
<!ELEMENT softwarelists (softwarelist*)
<!ELEMENT softwarelist (software+)>
<!ATTLIST softwarelist name CDATA #REQUIRED>
<!ATTLIST softwarelist description CDATA #IMPLIED>
<!ELEMENT software (description, year?, publisher, part*)>
<!ATTLIST software name CDATA #REQUIRED>
<!ATTLIST software cloneof CDATA #IMPLIED>
<!ATTLIST software supported (yes|partial|no) "yes">
<!ELEMENT description (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT publisher (#PCDATA)>
<!ELEMENT part (dataarea*)>
<!ATTLIST part name CDATA #REQUIRED>
<!ATTLIST part interface CDATA #REQUIRED>
<!ATTLIST part feature CDATA #IMPLIED>
<!ELEMENT dataarea (rom*)>
<!ATTLIST dataarea name CDATA #REQUIRED>
<!ATTLIST dataarea size CDATA #REQUIRED>
<!ATTLIST dataarea databits (8|16|32|64)
"8">
<!ATTLIST dataarea endian (big|little) "
little">
<!ELEMENT rom EMPTY>
<!ATTLIST rom name CDATA #IMPLIE
D>
<!ATTLIST rom size CDATA #REQUIR
ED>
<!ATTLIST rom crc CDATA #IMPLIED
>
<!ATTLIST rom md5 CDATA #IMPLIED
>
<!ATTLIST rom sha1 CDATA #IMPLIE
D>
<!ATTLIST rom offset CDATA #IMPL
IED>
<!ATTLIST rom status (baddump|no
dump|good) "good">
<!ATTLIST rom loadflag (load16_b
yte|load16_word|load16_word_swap|load32_byte|load32_word|load32_word_swap|load32
_dword|load64_word|load64_word_swap|reload) #IMPLIED>
<softwarelists>
<softwarelist name="ibmpcjr_cart">
</softwarelist>
</softwarelists>
2990
clrmame Discussion / Re: MESS and software lists
« on: 29 April 2010, 11:44 »
hmm...still no luck with it...all I get is (besides of the !ELEMENT stuff)
<softwarelists>
<softwarelist name="ibmpcjr_cart">
</softwarelist>
</softwarelists>
<softwarelists>
<softwarelist name="ibmpcjr_cart">
</softwarelist>
</softwarelists>
2991
clrmame Discussion / Re: MESS and software lists
« on: 29 April 2010, 09:48 »
hmm...ok...got a latest SVN build but using the commands only print out an empty list....I guess the real software list data is kept externally and will be included there if available....do you have some test data to play with?
2992
clrmame Discussion / Re: MESS and software lists
« on: 28 April 2010, 09:26 »
You got a mess binary handy to play with? One which supports the additional commands?
....and of course you can always use XSLT to transform the software list into something readable
ah...got one...hmm...I will have a look at it...but don't count on it...
....and of course you can always use XSLT to transform the software list into something readable
ah...got one...hmm...I will have a look at it...but don't count on it...
2993
clrmame Discussion / Re: What should noobs do for MAME?
« on: 24 April 2010, 07:21 »
All copyright holders of the games listed in MAME are invited to make them freely available. If they don't (some did), the copyright law is pretty clear on the legal terms of having (or better not having) them on your hd.
2994
clrmame Discussion / Re: Question about creating folders in the profile view
« on: 23 April 2010, 10:41 »
...you're welcome.....however, don't count on it in the near future.
Currently I'm pretty busy with real (family) live and usually pick some little requests from that list to get included...depending on the time effort needed.
So it may or may not come .... sooner or later ....
Currently I'm pretty busy with real (family) live and usually pick some little requests from that list to get included...depending on the time effort needed.
So it may or may not come .... sooner or later ....
2995
clrmame Discussion / Re: What should noobs do for MAME?
« on: 23 April 2010, 10:36 »
- MAME is not about playing, it's about documenting
- Since MAME's does continous work on correctness, sets will be changed, that's the part where rom managing tools come in....or you can do all the changes on your own
- mamedev.org is the official page mame.net redirects to this
- the latest version of MAME is .137 (and if you want to compile your own current builds, go for .137u3) and this version should be used
- MAME is friendly. If you're refering to rom pages with your web archives, then you're refering to illegal sites. Period.
- Since MAME's does continous work on correctness, sets will be changed, that's the part where rom managing tools come in....or you can do all the changes on your own
- mamedev.org is the official page mame.net redirects to this
- the latest version of MAME is .137 (and if you want to compile your own current builds, go for .137u3) and this version should be used
- MAME is friendly. If you're refering to rom pages with your web archives, then you're refering to illegal sites. Period.
2996
clrmame Discussion / Re: Question about creating folders in the profile view
« on: 23 April 2010, 07:26 »
I put it on my to do list.
2997
clrmame Discussion / Re: Help!
« on: 22 April 2010, 14:05 »
Hmm..ok...looks like fix-missing doesn't do what it should with the chd...(another point for my checklist).
How do you keep the chds? Do you allow chds on rompath root level (scanner->advanced) or not?
Assuming you don't allow them on rompath-root (which is the more common way),
then create subfolders in your rompath
ddrbocd
drmn2mpu
gtfrk3ma
and move the chds to their belongings folder
895jaa02.chd -> ddrbocd
912jab02.chd -> drmn2mpu
949jab02.chd -> gtfrk3ma
How do you keep the chds? Do you allow chds on rompath root level (scanner->advanced) or not?
Assuming you don't allow them on rompath-root (which is the more common way),
then create subfolders in your rompath
ddrbocd
drmn2mpu
gtfrk3ma
and move the chds to their belongings folder
895jaa02.chd -> ddrbocd
912jab02.chd -> drmn2mpu
949jab02.chd -> gtfrk3ma
2998
clrmame Discussion / Re: Help!
« on: 22 April 2010, 13:00 »
Actually you can simply use the fix-missing option to let cmpro create the chd for you at the right place.
Your manual copy and placement in a rompath root will lead to the funny situation that
a) cmpro sees the copied ones there and (if you don't keep chds at rompath-root-level) sees that they are wrongly placed there.
b) now it looks for a best fitting position and here it takes the position where you cloned the files from.....running in circles here....it's not so clever to see that they already exists there and should search for a better position....(reminds me to put this on the todo list). It simply used the first best fitting place...where it should use the 2nd
So either use the fix-missing option or move the chds manually to the correct subfolder and rescan.
Your manual copy and placement in a rompath root will lead to the funny situation that
a) cmpro sees the copied ones there and (if you don't keep chds at rompath-root-level) sees that they are wrongly placed there.
b) now it looks for a best fitting position and here it takes the position where you cloned the files from.....running in circles here....it's not so clever to see that they already exists there and should search for a better position....(reminds me to put this on the todo list). It simply used the first best fitting place...where it should use the 2nd
So either use the fix-missing option or move the chds manually to the correct subfolder and rescan.
2999
clrmame Discussion / Re: Help!
« on: 22 April 2010, 08:26 »
ok great....too early...no coffee....I've replied to the oldest thread not the newest...
So again, Konami weirdness and "clones of clones".
If I remember correctly there are some konami clones which share chds within the clones only.
For example:
Parent set: CHD_A
Clone set 1: CHD_A and CHD_B
Clone set 2: CHD_B
now in this example CHD_B is identical within the clones so you got something like a clone-of-clone. And such a thing isn't supported because split-merging means that you got all sets, where the parent holds the parent files and each clone only holds the files belonging to the clone.
Long talk.....you need to clone the chds in this case, yes, two instances of one and the same file....or switch to fully merged sets (which I would not prefer...)
In times of Terabyte HDs a little bit of CHD overhead ain't an issue....
So again, Konami weirdness and "clones of clones".
If I remember correctly there are some konami clones which share chds within the clones only.
For example:
Parent set: CHD_A
Clone set 1: CHD_A and CHD_B
Clone set 2: CHD_B
now in this example CHD_B is identical within the clones so you got something like a clone-of-clone. And such a thing isn't supported because split-merging means that you got all sets, where the parent holds the parent files and each clone only holds the files belonging to the clone.
Long talk.....you need to clone the chds in this case, yes, two instances of one and the same file....or switch to fully merged sets (which I would not prefer...)
In times of Terabyte HDs a little bit of CHD overhead ain't an issue....
3000
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.