Print

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

[flaviosr]

Hi to All,
I am referring to NeoKobe ROMs, that have a structure like [DIR ROMname]\[ROMcompressed files].
I cannot remember in which ClrMAME version but in the past everything was ok and ClrMAME was able to check all the files in the right directories.
Now it does not work anymore! ClrMAME now wants all the files in the root directory... with filenames like [DIR ROMname]-[ROMcompressed files].
Please notice the "-" instead than the "\".
Can anybody help? There is the possibility for ClrMAME to work the "right way"?
Thank you

[Roman]

storing method did not change:
rompath/setname/rom1..romN for decompressed sets
rompath/setname.zip (rar/7z) for conpressed ones

If sets have subfolders they are specified in the datfile's romnamed.

Nothing has changed for years for this, so I assume your rompath setup is somehow wrong.

when it comes to merges sets you also can check settings' hash collidion naming options.

[flaviosr]

I supposed so but I do not understand what's happening (and I had old good checks while now I have wrong ones).
From the report I read:
[BIOS] PC-6001 (60) (NEC)-[BIOS] PC-6001 (60) [ROM] [folder: [BIOS] PC-6001 (60) (NEC)-[BIOS] PC-6001 (60) [ROM] - size: 20kb]
missing set: [BIOS] PC-6001 (60) (NEC)-[BIOS] PC-6001 (60) [ROM]
"The internal ROMs are not important for my problem..."

While in the datfile I read:
<game name="[BIOS] PC-6001 (60) (NEC)\[BIOS] PC-6001 (60) [ROM]">
   <description></description>
   <rom name="BASICROM.60" size="16384" crc="54c03109" md5="2a13a60acf99a659144655b6c9e39b92" sha1="c622fefda3cdc2b87a270138f24c05828b5c41d2"/>
   <rom name="CGROM60.60" size="4096" crc="b0142d32" md5="9153f89e83f94f5d1cfe0a4e75d03372" sha1="9570495b10af5b1785802681be94b0ea216a1e26"/>
</game>

I am missing something?

Thank you

[Roman]

the backslash in the setname is wrong. Most likely cmpro replaces this bad character with - .
subfolders can only be used in the romname not the setname.

[flaviosr]

Thanks to your hint I should have understood...
I am trying to use a SuperDAT and not a standard DAT. And I have read around the Net that ClrMAME is not compatible with SuperDAT, right?

[Roman]

what is superdat?

and again, nothing regarding subfolder usage or storing method has been changed. rompath/setname/rom1..N where rom1..N can be stored within an archive or a folder and can have subfolders.

double think about the definition of a set in this context. a set is a collection of roms not a collection of games. pacman is a set in eg Mame and it contains some roms, the ic dumps from the pacman arcade board.

[flaviosr]

Well... I have to be true and I am not 100% sure about what a SuperDAT is... I am discovering the changes between a DAT and a SuperDAT in these days.
My idea is that a SuperDAT is similar to a collection of DAT... i.e., if you want to check multiple ROMset in multiple directories you can create "this" SuperDAT including the subdirectories with the "language" you have seen above.
I have discovered that "this" SuperDAT is compatible with ROMVault and everything is ok now... but I am 99% sure that last Xmas they worked also with ClrMAME. I had simply a 100% check result with the same files in the same directory... nothing changes. When I made a new check I lost the 100% compliance and I discovered this difference...

Anyway thanx for the help.

[Roman]

combining dats can be done but not by using folders on setname level.
for quick scanning multiple dats cmpro's batcher is the prefered method. when Im back from holiday I can go into details

[Roman]

cmpro replaces illegal characters in setnames ( like ><*? / \ etc) with - ....and it does this since years....so if you think it was working last year, your datfile was structured differently.
So again, setnames cannot hold \ / for specifying subfolders. You can move the name to each romname though:

rom name="[BIOS] PC-6001 (60) [ROM]\BASICROM.60" ...

[flaviosr]

I really do not understand why I had the sets checked and confirmed... anyway now I have solved the problem with ROMVault, but I have to say that ClrMame is much better... perhaps I will parse the "SuperDAT" to change to a "standard DAT"...