MD5 codes of good roms (idea for n64 emulators)

[Hacktarux]

I am currently writing the ini file format of mupen64 and searching what info should i put into it. I think that it should be usefull if the emulator can detect good and bad dumps. And maybe, other emulator authors can be interested by implementing it in their emu (actually it is more usefull in other emu than mine ).

Here, you'll find the md5 codes of almost all the good roms (thanks smiff for the help )

 

[Hacktarux]

And source code of the little utility that have generated this file.

 

[Slougi]

Sounds nice, just one question:
All those codes were for the z64 format, what if the rom is in another one? Wouldn't that change the MD5 code completely?

 

[Hacktarux]

My utility swap roms to z64 format before calculating the MD5 code.

 

[Slougi]

What i meant is that if the end user has say, a rom in V64 format, will it still recognize it?

 

[Hacktarux]

If an emu authors want to implement it, he will have to do the same : byteswap to z64 format and calculate the md5. (Or modify the md5 source code so that it swap each word before using it) It is not hard to do but it depends on how the loading process is actually done. This process is done internally, there's no need to change the actual format of the file in the hard drive.

For example the smiff's conker's bad fur day rom in z64 format has the same code as mine in v64 format. (it is one of the roms i have verified).

I don't think it will be long to calculate it, but i think the end user have to be able to disable it.

 

[Slougi]

Ah sorry, I didn't get your point correctly! /slaps self
So basically the rom would always get byteswapped to z64 and after that compared to the MD5 code? How would that work for rom browsers?

 

[Hacktarux]

I depends on how it is implemented on the emu :
- it can be check when the rom is actually loaded (the emu warn the user and ask if he wants to continue)
- it can be done when the user change the directory
- it can be done by an option included in the menu that check a file or a directory.

Or ... any other suggestion ?

 

[flow``]

hacktarux..


i've got the current n64 rom set (-2 unreleased)

if you want to give me a binary (since i have no idea how to compile.. i'm a non-coder ) i'd be happy to generate a list for you.

 

[Hacktarux]

The binary is included in the source code (you need the .exe and the z.dll file). The utility browse automatically all the subdirectory and zip files.

 

[Doomulation]

So basiclly, what you're saying is that, the CRC should always be "right" byteswapped?

 

[Hacktarux]

No, what i meant is that my utility give the same CRC with all the known rom format (of course it has to be good roms to have the same CRC !)

 

[flow``]

that wont work.

many bad dumps have the same crc's as their good dumps.

if you dont believe me, get all of the 1080 bad dumps for example and load up pj64 - it gives the same entry for most of the bad dumps since they all share the same crc..

 

[Hacktarux]

No !!!

I don't use the CRC stored in the rom. I calculate the MD5 fingerprint of the whole rom. If you change only one bit in the rom, the result is compleatly different. I'm sure that this is how goodrom identify the roms but the algorithm is not publically available and it is not implementable in the emulators.

If you don't believe me, try my program on different bad dumps !

edit: my answer to Doomulation was ambiguous because i used the word CRC where i had to use MD5

 

[flow``]

once i get a bigger hdd and am able to unzip them all (~27 gigs) i'll give it a try and send you the list

 

[Hacktarux]

My program perfectly handle roms in zip file !
It will just take more time...

 

[flow``]

hrm.. and its crashing when i double click the executable in my rom directory :/

the only files i took out of the zip were the exe, z.dll, and i put in my zlib.dll (1.1.4) just to make sure

 

[Slougi]

run it via command prompt, u need to specify the rom directory, that's why it seems to crash. really it just gives the error msg and closes, so windows in it's stupidity closes the dos window as well.

 

[Hacktarux]

yes, it's just a little command line tool, once it will be run in a few rom collection, it will be useless, so i have not taken time to make a gui.
It will produce a log file (n64roms_md5.txt) in the directory where you launched it.

 

[Cyberman]

yes, it's just a little command line tool, once it will be run in a few rom collection, it will be useless, so i have not taken time to make a gui.
It will produce a log file (n64roms_md5.txt) in the directory where you launched it.

I wonder if a 64 bit CRC would be a good public substitute for the MD5 codes? I am leery of using algorythms that are patented for things that are GPL or integrated into something that's free.

The big problem with CRC's is picking the right start word and the polynomial for generating the CRC. although 64 bits will take 8 tables of 256 elements to create and might be slow it should have adequate Uniqueness for rom sizes up to 4gig.. 32 CRCS are only guarenteed unique to 64K that's why you can have bad roms with the same CRC's as good roms because the ROM images are large enough the probability of finding a match is significantly increased.

I'm not sure why the hell Nonmindo used 32 bit CRC's for such large roms (sigh).

Cyb