Back to: Nintendo - Nintendo 64

Cruis'n World bad or unverified dump?
 
Category: ROM data
Reference: 2149
Closed (rejected) by: Hiccup.
nitro322 » 2013-08-25 19:23:34

I'm dumping some new N64 games I recently picked up using my Retrode, and have an odd issue with Cruis'n World. Here's the output from ucon64:

Cruis'nWorld.NCWE.n64

Mr. Backup Z64

00000000 80 37 12 40 00 00 00 0f 80 4a d4 00 00 00 14 49 .7.@.....J.....I
00000010 df e6 11 53 d7 61 18 e6 00 00 00 00 00 00 00 00 ...S.a..........
00000020 43 52 55 49 53 27 4e 20 57 4f 52 4c 44 20 20 20 CRUIS'N WORLD
00000030 20 20 20 20 00 00 00 00 00 00 00 4e 43 57 45 00 .......NCWE.

Nintendo 64
CRUIS'N WORLD
Nintendo
U.S.A.
12582912 Bytes (96.0000 Mb)

Padded: Maybe, 270317 Bytes (2.0624 Mb)
Interleaved/Swapped: No
Backup unit/emulator header: No
Checksum: Bad, 0x78b341a5 (calculated) != 0xdfe61153 (internal)
2nd Checksum: Bad, 0x6f10f272 (calculated) != 0xd76118e6 (internal)
NOTE: The checksum routine supports only 6102 and 6105 boot codes
Search checksum (CRC32): 0x41877d7d
Data checksum (CRC32): 0xa123769f
DAT info:
Nintendo 64
Cruis'n World (USA)
Filename: Cruis'n World (USA).n64
12582912 Bytes (96.0000 Mb)
n64-20130505.dat (20130505-044735, ?, Nintendo - Nintendo 64)

As you can see, it recognizes the game as matching an entry in the DAT file, but it also says that the Checksum is bad, so I'm not really sure how that works. I did notice that datomatic considers this particular ROM to be unverified, though, so maybe that's ucon64's weird way of pointing that out?

I dumped this game several times, both before and after cleaning the contacts, and get the same result everytime, so I think it should be a good dump. Would be happy to provide any additional information/pictures/etc. regarding the game/ROM; just let me know what you'd like and how to submit it. I couldn't find any obvious submission instructions for this on the site.

Thanks.
Hiccup » 2016-01-29 02:26:28

Please do post photos. Just upload them somewhere and link.
Hiccup » 2019-05-02 10:29:06

If it matches a dat entry, it must have done that by finding a matching checksum, as N64 didn't have serials in the database then, and I doubt the retrode checks that. The bad checksums mentioned are internal checksums. Either the code for checking these is faulty or these checksums don't actually have to be valid to pass Nintendo's lotcheck.