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!
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
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.
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.
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)
Quote from: KingMike on 24/Aug/2016 03:03:00 AM
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.
FWIW WinHex has several options for byte swapping, so it might be able to do what you need.
I just load the DAT files from DAT-o-MATIC into a swiss army knife for ROMs named ucon64 (http://ucon64.sourceforge.net/) 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 (http://snarfblam.com/files/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.