My hashes don't match No-Intro. Is that normal?

[Lowe0]

I'm using a Retrode running v0.19, HW ver 2.2, plugged directly into a USB 3.0 port, the N64 plugin from DragonBox, clean cartridges, and the voltage is set to 3.3V.  I'm running Win10, and am using PowerShell's Get-FileHash cmdlet as my verifier.

However, none of my hashes match No-Intro.  A few examples (these are my hashes, not No-Intro's):

Doom 64: B67748B64A2CC7EFD2F3AD4504561E0E
F-Zero X: 753437D0D8ADA1D12F3F9CF0F0A5171F
SW Racer: 1EE8800A4003E7F9688C5A35F929D01B
Zelda MM: 2A0A8ACB61538235BC1094D297FB6556
GoldenEye: 70C525880240C1E838B8B1BE35666C3B

(And many more; I tried to pick common cartridges that didn't have multiple variants.)

These load in RetroArch Mupen okay, so I'm not sure if I should be worried that parts of the file are corrupt.  Is it normal to get dumps that don't match?

Thanks!

[Pickle]

try google'ing the md5 hashes, for instance the doom64 hash brings up hits in emulator source code:

https://github.com/ricrpi/mupen64plus-rpi/blob/master/test/mupen64plus.ini

So you can be pretty certain that was a good dump

[Aleron Ives]

Have you tried dumping games from systems other than the N64? If you get a Genesis or SNES dump that matches the No-Intro database, then everything is probably working fine, and the N64 plugin is doing something slightly different than whatever dumper No-Intro used to compile its database. If you can dump carts from multiple systems and none of them match the No-Intro database, then you might have a problem, because my Retrode Genesis dumps match No-Intro's.

[Matthias_H]

Also keep in mind the distinct possibility of N64 ROMs being overdumped (file size > actual size of ROM). This will of course alter the hash although it is not a problem in practice.

[KingMike]

There is also the issue of byte-order with N64 ROMs.
From what I understand, people have been arguing for a long time over what the correct byte order is in N64 ROMs.

(like if you open an N64 ROM in a hex editor, there should be at least a game title in ASCII. IIRC, No-Intro uses the byte-order that creates a jumbled title (like instead of SUPER MARIO 64, USEP RAMIR O46, or whatever)

[Lowe0]

There is also the issue of byte-order with N64 ROMs.
From what I understand, people have been arguing for a long time over what the correct byte order is in N64 ROMs.

(like if you open an N64 ROM in a hex editor, there should be at least a game title in ASCII. IIRC, No-Intro uses the byte-order that creates a jumbled title (like instead of SUPER MARIO 64, USEP RAMIR O46, or whatever)

Yep, this was it.  Thanks!

I'll get (or write) a tool to swap endianness (dd conv=swab won't work, as it swaps byte pairs; it looks like N64 conversion involves pivoting quads) and try again.

[Aleron Ives]

FWIW WinHex has several options for byte swapping, so it might be able to do what you need.

[ssokolow]

I just load the DAT files from DAT-o-MATIC into a swiss army knife for ROMs named ucon64 and run ucon64 -rdat *.n64 to rename them. Anything left un-renamed didn't match. (Or without the -rdat to get details)

Before I discovered ucon64, I used a little tool named Snarfblam ROM Hasher (which runs perfectly well in Wine on non-Windows systems) which gives MD5, SHA-1, and CRC32 for the file, the ROM, and the ROM after byte-swapping it.

Emulators don't care, so I've never needed to byte-swap my ROMs, but ucon64 can byte- or word-swap N64 ROMs too.