3.102c

added: support for upcoming new biosset detection
misc: workaround for MAME .117u1 biosset issue


(looks like ztnet cache got a little problem at the moment, so auto update might fail for some time...)


Roman Scherzer

> 3.102c
>
> added: support for upcoming new biosset detection
> misc: workaround for MAME .117u1 biosset issue
>

Hi Roman,

are you sure that your update really fixes the problem. I had not read your warning unfortunately before I started to scan my files. I trusted CMP to fix all issues as usual, damage was done. 576 files contain all their bios roms now. I rescanned with 3.102c, but it does not recognize the bios roms to be unneeded and does not remove them. Maybe the release was not meant to do that and I have to wait for the next update.

Yes I'm sure it fixes the problem.

1) Be sure you've downloaded the correct package (crc32 of cmpro.exe is 0x64c2dc25).
2) Clear the cache in the profiler and try again.
3) Be sure you did a full install (or auto update) since new files were added (simply overwrite all). Only replacing the exe won't work.


Roman Scherzer

> Yes I'm sure it fixes the problem.
>
> 1) Be sure you've downloaded the correct package (crc32 of cmpro.exe is
> 0x64c2dc25).
> 2) Clear the cache in the profiler and try again.
> 3) Be sure you did a full install (or auto update) since new files were added
> (simply overwrite all). Only replacing the exe won't work.

1) and 3) I am sure that's not the problem since I use auto update.

2) Already quite sure that's the culprit, forgot to clear the cache before I did a fresh full scan. I'll do that when I am home and let you know. Thanks for the quick response, Roman.

The cache should get auto-cleared with the current version. Most likely auto-update grabbed a previously uploaded version (which I removed after 2 minutes). Check the checksum of the exe.


Roman Scherzer

> The cache should get auto-cleared with the current version. Most likely
> auto-update grabbed a previously uploaded version (which I removed after 2
> minutes). Check the checksum of the exe.
>
Checksum is identical. Redownloaded the zip file from your homepage and installed it on top of my previous installation and wiped the cache manually just to be sure. Scanned with the same result: no unneeded files reported. Checked with an old MAME 0.105 profile, which was still there: it reported plenty of non-separated bios roms.

It came to my mind that there might be a difference if you are using the mame.exe to create the rom data vs. using a pre-made dat file. Since I have not compiled my own MAME from the source for a while, I have been using the dats from mamechannel.it until a binary (either MAME32 or plain vanilla MAME) has been available. The latest one might still have been created in the old fashion. Do you do any check on the data provided by dat files in the same way as the output from the exe is checked or is there any difference, e.g. would CMP just rely on the data to be OK?

In case you need to check this, the dat file still contains all the information you would need to check things like cloneof, romof, biosset in order to make the same analysis as you do with the mame.exe output, doesn't it?

Pre-made dats will not parse properly in ClrMAMEPro. My guess is you are keying off of something in the XML itself.

I just submitted a fix to MAMEDev to add a isbiosroot=(yes|no), to update the runnable=(yes|no), and to correct the romof to actually point to the BIOS set that the game belongs to.

Not sure if it will get approved or rejected.

Bryan

> > The cache should get auto-cleared with the current version. Most likely
> > auto-update grabbed a previously uploaded version (which I removed after 2
> > minutes). Check the checksum of the exe.
> >
> Checksum is identical. Redownloaded the zip file from your homepage and
> installed it on top of my previous installation and wiped the cache manually
> just to be sure. Scanned with the same result: no unneeded files reported.
> Checked with an old MAME 0.105 profile, which was still there: it reported
> plenty of non-separated bios roms.
>
> It came to my mind that there might be a difference if you are using the
> mame.exe to create the rom data vs. using a pre-made dat file. Since I have not
> compiled my own MAME from the source for a while, I have been using the dats
> from mamechannel.it until a binary (either MAME32 or plain vanilla MAME) has
> been available. The latest one might still have been created in the old fashion.
> Do you do any check on the data provided by dat files in the same way as the
> output from the exe is checked or is there any difference, e.g. would CMP just
> rely on the data to be OK?
>
> In case you need to check this, the dat file still contains all the information
> you would need to check things like cloneof, romof, biosset in order to make the
> same analysis as you do with the mame.exe output, doesn't it?
>

The fix is for xml formatted dats only (since -listinfo format is not supported by mame since ages). No matter if premade or direct MAME import.

So I assume you didn't use an xml-style mame datfile.


Roman Scherzer

> The fix is for xml formatted dats only (since -listinfo format is not supported
> by mame since ages). No matter if premade or direct MAME import.
>
> So I assume you didn't use an xml-style mame datfile.
>

The pre-made dat file look structurewise basically the same as the dat files you maintain on your homepage for MAME flyers and samples.

Checked and everything works fine with the 117u1 binary. But you know that already. So the actual problem was using the dat file. Any plans to include a check for bios roms in external dat files in a future release, or not worth the trouble since the problem is expected to go away shortly anyway?

you mix up 2 things here. The MAME xml format changed, so I added a fix for that. The -listinfo format isn't supported by MAME since ages and biosset sets are defined in a different way. So it's not cmpro's job to handle your wrong datfile. I wonder why people use an external (not xml) datfile for MAME anyway....


Roman Scherzer

There are 2 supported formats: -listxml and -listinfo.
-listxml have been changed, so I fixed it.
-listinfo hasn't changed. A wrongly converted datfile is not my problem.


Roman Scherzer

I saw a few MAME dats floating around for 117u1 that were wrong because of the bug. I had to alter the program my friend uses to build his dat sets just to handle the different XML type.

Bryan

> There are 2 supported formats: -listxml and -listinfo.
> -listxml have been changed, so I fixed it.
> -listinfo hasn't changed. A wrongly converted datfile is not my problem.
>
>
> Roman Scherzer
>

As I said...noone needs to use external datfiles for cmpro + MAME ;)


Roman Scherzer

> A wrongly converted datfile is not my problem.
>

That wasn't implied. I blame only myself for being lazy and not compiling my own MAME for creating the proper input for CMP.

I even could have just waited for a binary and your update (had I known about the problem early enough) instead of using a pre-made dat file (from a source which had always been reliable n the past). In that case, I would not even have noticed any changes.

But one learns from his mistakes.