41
clrmame Discussion / Re: cmpro 4.06 released
« on: 04 July 2012, 18:48 »I will check it...
Thanks, Roman. Hopefully this wouldn't be too difficult to implement and I'm sure it would be very helpful.
- 25 January 2025, 04:04
- 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.
Thanks, Roman. Hopefully this wouldn't be too difficult to implement and I'm sure it would be very helpful.
42
clrmame Discussion / Re: cmpro 4.06 released
« on: 18 June 2012, 02:11 »
Congrats on another release, Roman.
Out of curiosity, is there any way you could work in Arbee's suggestion regarding the CHD check?
Thanks.
Out of curiosity, is there any way you could work in Arbee's suggestion regarding the CHD check?
Thanks.
43
clrmame Discussion / Re: Software lists
« on: 03 June 2012, 17:29 »
Thanks, Roman. Responses:
1) I see.. so I guess these extra SysDef paths are there in case someone wanted to keep e.g. Devices in a separate location from other BIOS files? I think that by default the device files are kept with the BIOS files if I'm not mistaken.
2) Gotcha. Still not sure exactly why it's done that way but from what you're saying I guess that's a MAME/MESS internal thing.
3) I see. To use my example, I noticed that the 3do_m2 list has its software commented out for now because MESS doesn't yet use it, but it's still included for documentation purposes. In that case I guess that would be missed in scanning under the "single profile" mode - though in "multiple profile" mode, chances are the user would just import ALL software lists and catch that one - so the latter option is more inclusive and therefore arguably better. By the way, how does ClrMAME get the actual list names for its "-listsoftware name_of_the_list" operation? Does it derive the names from the xml files or from some other MESS-internal command?
4) I see now - that makes sense. When "auto-assign" was run it came up with about a 5% success rate for software paths with existing sets in them; i.e. about 95% of the time it thought software was in the bios path for some reason. I guess the only recourse would be to do as you suggest and manually assign them. I'm sure most of the "hell" would only have to be experienced once, though it would also have to be done each time new software lists are introduced (or existing names change, as they have in the recent past).
Anyway, in light of the above I'm going to keep using the "multi-profile" batch mode as I've done in the past.
Thanks!
1) I see.. so I guess these extra SysDef paths are there in case someone wanted to keep e.g. Devices in a separate location from other BIOS files? I think that by default the device files are kept with the BIOS files if I'm not mistaken.
2) Gotcha. Still not sure exactly why it's done that way but from what you're saying I guess that's a MAME/MESS internal thing.
3) I see. To use my example, I noticed that the 3do_m2 list has its software commented out for now because MESS doesn't yet use it, but it's still included for documentation purposes. In that case I guess that would be missed in scanning under the "single profile" mode - though in "multiple profile" mode, chances are the user would just import ALL software lists and catch that one - so the latter option is more inclusive and therefore arguably better. By the way, how does ClrMAME get the actual list names for its "-listsoftware name_of_the_list" operation? Does it derive the names from the xml files or from some other MESS-internal command?
4) I see now - that makes sense. When "auto-assign" was run it came up with about a 5% success rate for software paths with existing sets in them; i.e. about 95% of the time it thought software was in the bios path for some reason. I guess the only recourse would be to do as you suggest and manually assign them. I'm sure most of the "hell" would only have to be experienced once, though it would also have to be done each time new software lists are introduced (or existing names change, as they have in the recent past).
Anyway, in light of the above I'm going to keep using the "multi-profile" batch mode as I've done in the past.
Thanks!
44
clrmame Discussion / Software lists
« on: 03 June 2012, 16:27 »
Hi Roman, I wanted to ask a few questions about running ClrMAME against MESS under the "single profile":
1) Under SysDef paths, what are "[STANDARD]" and "[DEVICE]" and how do they relate to scanning?
2) Why are only three bios sets recognized - 3do, cd32, and cd-i? I would imagine either all bios sets would be listed there or none would; there doesn't appear to be anything special about these particular sets unless I'm missing something, so it's a bit confusing this way.
3) Why are some software lists missing, such as 3do_m2? How does the SysDef feature obtain the software lists for display there?
4) Can you add a way to easily assign a single SysDef path to multiple lists (outside of external file manipulation). I noticed the user a few posts down had some issues with this; I was just curious if you could add a feature to address it within ClrMAME itself.
Thanks!
1) Under SysDef paths, what are "[STANDARD]" and "[DEVICE]" and how do they relate to scanning?
2) Why are only three bios sets recognized - 3do, cd32, and cd-i? I would imagine either all bios sets would be listed there or none would; there doesn't appear to be anything special about these particular sets unless I'm missing something, so it's a bit confusing this way.
3) Why are some software lists missing, such as 3do_m2? How does the SysDef feature obtain the software lists for display there?
4) Can you add a way to easily assign a single SysDef path to multiple lists (outside of external file manipulation). I noticed the user a few posts down had some issues with this; I was just curious if you could add a feature to address it within ClrMAME itself.
Thanks!
45
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 27 October 2011, 01:39 »
Thanks for the explanation. Just to keep you up to speed: I ran a test against the C2D system to check for differences but got similar results. :/
I hate to return to this, but what about the hash algorithms? If the CMP option is to "Decompress CHD and check SHA1/MD5", whereas chdman simply says "SHA1 verified successfully" after it's done, then at least at the surface it looks like CMP is doing a bit more; i.e. also performing a calc of MD5. This would at least explain things, however my logic is probably flawed.
Also, perhaps there's something going on during the download. Both tools have to download the chd from the network share, but maybe chdman streams it differently? I tend to doubt the 802.11n network is the bottleneck with CMP but maybe it is?
Also, I suppose if you have time to create a build with GCC, that would at least eliminate item #4 from your list. Just a thought.
I hate to return to this, but what about the hash algorithms? If the CMP option is to "Decompress CHD and check SHA1/MD5", whereas chdman simply says "SHA1 verified successfully" after it's done, then at least at the surface it looks like CMP is doing a bit more; i.e. also performing a calc of MD5. This would at least explain things, however my logic is probably flawed.
Also, perhaps there's something going on during the download. Both tools have to download the chd from the network share, but maybe chdman streams it differently? I tend to doubt the 802.11n network is the bottleneck with CMP but maybe it is?
Also, I suppose if you have time to create a build with GCC, that would at least eliminate item #4 from your list. Just a thought.
46
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 25 October 2011, 03:15 »
Thanks, Roman. So I plunked your single-threaded cmpro64.exe in the install directory and ran it.. but the results are about the same: area51.chd took over 10 mins to scan. For shiggles I tried the 32-bit CMP you included but got basically the same results as expected. Likewise, I tried the same scan with CMP 3.138a - similar results.
I ran chdman again and it just blazes through the verify (relatively speaking of course). Not sure what else would help explain the difference between cmpro and chdman though. Realizing they both share the same code, are you sure chdman -verify actually decompresses and checks against both hash types as CMP does? Maybe it's only checking one of them (after all, it reports "SHA1 verification successful" when it's done). And maybe there's something about the way it decompresses? Also, I used the chdman from MESS .143 to compare, in case it matters.
I ran chdman again and it just blazes through the verify (relatively speaking of course). Not sure what else would help explain the difference between cmpro and chdman though. Realizing they both share the same code, are you sure chdman -verify actually decompresses and checks against both hash types as CMP does? Maybe it's only checking one of them (after all, it reports "SHA1 verification successful" when it's done). And maybe there's something about the way it decompresses? Also, I used the chdman from MESS .143 to compare, in case it matters.
47
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 24 October 2011, 12:10 »
Yeah, I was a little surprised myself about that. It does seem a tad snappier than the C2D, though not as much as was hoping.
48
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 23 October 2011, 21:04 »
Sure, Roman - I'd like to test out a single-threaded build when it's convenient for you to make one. I'm curious to know if that's the issue.
In case it helps, I'm running CMP 4.01 on Win7 x64 with a Sandy Bridge mobile proc (i7-2620M). I also have an older C2D system I could try it on (as I understand it, threading models are completely different with the C2D architecture).
By the way, did CMP always have multi-threaded hash calculation? If not, I could also try downloading/testing an old build that doesn't. Also, are there any other features in CMP that are multi-threaded?
Thanks again, Roman.
In case it helps, I'm running CMP 4.01 on Win7 x64 with a Sandy Bridge mobile proc (i7-2620M). I also have an older C2D system I could try it on (as I understand it, threading models are completely different with the C2D architecture).
By the way, did CMP always have multi-threaded hash calculation? If not, I could also try downloading/testing an old build that doesn't. Also, are there any other features in CMP that are multi-threaded?
Thanks again, Roman.
49
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 23 October 2011, 15:11 »
Ok, benchmarks:
CHD deep scan area51.chd (CMP 4.01): 10mins 55secs
chdman -verify area51.chd: 2mins 54secs
So yes, considerable difference there, assuming those two operations are equivalent in function (both decompressing and checking CHD against hashes). Again, based on what you said earlier I'm now thinking CMP 3.x builds could exhibit the same behavior, though I haven't tested with any of those lately (though I could if you think it would help).
Either way this is odd CMP behavior considering it uses the same code as chdman as you mentioned.
CHD deep scan area51.chd (CMP 4.01): 10mins 55secs
chdman -verify area51.chd: 2mins 54secs
So yes, considerable difference there, assuming those two operations are equivalent in function (both decompressing and checking CHD against hashes). Again, based on what you said earlier I'm now thinking CMP 3.x builds could exhibit the same behavior, though I haven't tested with any of those lately (though I could if you think it would help).
Either way this is odd CMP behavior considering it uses the same code as chdman as you mentioned.
50
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 22 October 2011, 15:16 »
Thanks for the info, Roman - even if it wasn't the greatest news at least I understand a little more what's actually happening. By the way, it sounds like you are referring to general incompatibilities with CMP and SAMBA, not just CHD deep scanning, right? I didn't notice any issues with SAMBA other than this performance issue, and scanning was pretty quick without the "deep" option flagged, though now that I think about it, I haven't rebuilt anything with that setup either.
Anyway, it seems there are only a few options to attempt resolving the performance problem:
1) Attach the ext4 drive to a Win7 system and use something like this to read it.
2) Use CMP with Wine on a Linux system with the ext4 drive attached (any issues that you know of there?)
3) Wait for CMP to become a little more Linux fs friendly (and not I'm not about to bug you about that, but wait I just did, ooh see what I did there?)
Thoughts?
Anyway, it seems there are only a few options to attempt resolving the performance problem:
1) Attach the ext4 drive to a Win7 system and use something like this to read it.
2) Use CMP with Wine on a Linux system with the ext4 drive attached (any issues that you know of there?)
3) Wait for CMP to become a little more Linux fs friendly (and not I'm not about to bug you about that, but wait I just did, ooh see what I did there?)
Thoughts?
51
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 21 October 2011, 22:58 »
Wow, not sure what's wrong here then. Are you aware of any performance differences between deep scanning to a remote WinXP/NTFS drive vs. Linux/ext4 over SAMBA? It's the only other thing I can think of, since I think I was using the former when I noticed faster results.
52
clrmame Discussion / Re: CHD deep-scanning with recent CLR builds
« on: 21 October 2011, 12:11 »
Thanks, Roman. Would be great to know what you find.
53
clrmame Discussion / CHD deep-scanning with recent CLR builds
« on: 14 October 2011, 22:46 »
Recently I've observed that with the 4.x versions of CLR, deep-scanning CHDs (i.e. with "Decompress CHD and check MD5/SHA-1" option flagged) takes longer than I recall with the 3.x versions - perhaps even twice as long. Is this a known issue with recent builds or could this be on my end? I don't have any other "Hash and CHD" tab options flagged but maybe there's something else to tune for better performance? Thanks.