Print

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

[F0XHOUND]

Hi Roman, I found a rare case that i dont know if is a bug or not.

My dat file has this line

rom ( name "ZZZ_UNK (RULEZ HF) BRAIN_SKULLS_2_A_1 (DEMO) [D64].d64" size 174848 crc c056af06 )

I have a file with the same filename and same filesize but different crc and detects as valid.
Scan it as good or rebuild it. But crc is 3fa950f9.

Theres another valid checksum or is a bug? Thanks and welldone for your work

[Roman]

Actually it's not a bug Look at the checksums, they are inverted.
c056af06 = ~3fa950f9

In earlier versions of MAME bad dumped roms were marked with an inverted checksum. In later and current versions you got the status flag for this.
If status flags are available, inverted crcs are not taken into account by a rebuild/scan. I guess the used datfile does not have any status flags, so inverted checksums are taken into account....and so you run into this 'issue'.

I will think about a more solid way to say if inverted checksums will be checked or not.

Update:
ok, next version got this old method disabled by default but you can reenable it in profiler options.

[F0XHOUND]

Can you explain it? how to inverted?

[Roman]

You don't have to do anything.

Old way to mark "bad dumps" within a datfile was to list the inverted crc32 of the file. So a bitwise swap from 0 to 1 and vice versa.

Current way to mark "bad dumps" within a datfile is to provide the rom status tag with value 'baddump'.

Since your datfile seems to not use any status baddump definitions, cmpro also tested inverted checksum during rebuild/scan and in your rare case you had a match. A false positive if you like.
The next version of cmpro will have this mechanism deactivated by default (you can turn it on again...but I guess in these days it's really not needed anymore).