Project64 makes invalid CRCs in Banjo-Kazooie saves 
Author Message
User avatar

Joined: 2014-10-29 21:24
Posts: 1814
Location: People's Republic of America
 Project64 makes invalid CRCs in Banjo-Kazooie saves
After I added mupen64plus support to minos, I discovered something horrible: Project64 and mupen64plus get different results when running Banjo-Kazooie's CRC algorithm! This makes save files created with one emulator incompatible with the other.The 3 save files each have their own 32-bit CRCs which differ between emulators. When each file is completely blank, the checksum is: (Left: Project64, Right: mupen64plus)File 1: 24 F4 A3 49, DC 82 0F 84File 2: D5 91 C8 7B, 34 46 03 D2File 3: 7B B1 A0 39, 9E 19 25 67Strangely enough, I noticed that at address $1FC in the EEPROM, a 32-bit CRC is written that, no matter what, always remains the same no matter how the 3 save files change. The only way it will change is if Banjo-Kazooie is loaded in a different emulator. In Project64, the CRC is F2 3B 05 D3, and in mupen64plus, the CRC changes to 32 C9 A1 E6.My hypothesis right now is that one of these emulators has a bug in its implementation of the NEC VR4300 instruction set, and it causes the checksums to be thrown out of whack in whichever emulator has the bug. I want to say that Project64 is the bugged one because there are many Super Mario 64 hacks that work only on it (even the multiplayer mod shows only a black screen but still plays music when played in mupen64plus), but I can't be too sure. I'm also not ruling out the possibility that both of them are bugged in different ways.I will need an EEPROM save of Banjo-Kazooie from an EverDrive 64 (or extracted directly from the game cartridge) in order to determine which emulator is bugged. If anyone is willing to upload one, it would be ideal if at least 1 file is blank (doesn't have to be all of them). If you choose to back yours up and create a new one with 3 blank files, make sure to at least start a game, then immediately turn off the Nintendo 64 as soon as you see the beginning of the intro cutscene with Gruntilda's Tower over a green cloud background. This is required in order to "format" whichever 2 blank files you didn't choose.If you decide to look at the EEPROM yourself, then do note that a file's ID number does not correlate to its location in the EEPROM. Sometimes Banjo-Kazooie will shuffle the 3 files around plus some kind of backup file denoted by an ID of 0x00. The address on the left will contain 0x00, 0x01, 0x02 or 0x03 for Backup, File 1, File 2, and File 3 respectively, and each file's checksum will be found at the address on the right:$001: $074$079: $0EC$0F1: $164$169: $1DC

_________________
bsnes-mcfly: A port of the Qt GUI from v073 to v106.
nSide: A higan fork w/NES boards and peripherals and Sonic & Knuckles Lock-On.
Dragon Quest I & II RPGOne Beran Inn bugfix


2017-09-21 20:29

Joined: 2016-07-25 01:17
Posts: 27
 Re: Project64/mupen64plus different CRCs in Banjo-Kazooie sa
http://www11.zippyshare.com/v/kHTQwczY/file.html

From my EverDrive 64 v2.5.

Started as empty, then started the first save file and reset once the intro cutscene started.

Looks like Mupen64Plus is correct and Project64 is the one that's messed up.


2017-09-21 20:40
User avatar

Joined: 2014-10-29 21:24
Posts: 1814
Location: People's Republic of America
 Re: Project64/mupen64plus different CRCs in Banjo-Kazooie sa
Yes, the CRCs in this upload match mupen64plus's CRCs exactly.

Well, that settles it. Project64 is bugged and produces improper CRCs in Banjo-Kazooie. I had suspected that this was the case. This could also affect any number of other games. I know Super Mario 64's saves work in both emulators, but that's just one example.

Which is unfortunate for me, because I have a 100% save of Banjo-Kazooie made in Project64, and it'll have to go into the trash if I can't figure out how the game generates CRCs (it does not match the public CRC32 standard, I know that much).

_________________
bsnes-mcfly: A port of the Qt GUI from v073 to v106.
nSide: A higan fork w/NES boards and peripherals and Sonic & Knuckles Lock-On.
Dragon Quest I & II RPGOne Beran Inn bugfix


2017-09-21 20:51
User avatar

Joined: 2014-09-27 09:39
Posts: 2949
 Re: Project64/mupen64plus different CRCs in Banjo-Kazooie sa
You could always try to load a PJ64 savestate in M64P.

https://groups.google.com/forum/#!msg/m ... tLaw3rNwAJ

https://github.com/mupen64plus/mupen64p ... /issues/52


2017-09-21 21:06
User avatar

Joined: 2014-10-29 21:24
Posts: 1814
Location: People's Republic of America
 Re: Project64/mupen64plus different CRCs in Banjo-Kazooie sa
Wow, why'd you use the sarcasm tag? That trick worked perfectly!

If I have any other saves made in Project64 that won't work in mupen64plus, I'll have to try this trick in those games, too. Think I'll try to convert my Banjo-Tooie save next... EDIT: Banjo-Tooie didn't need it. Saves created in one emulator will work in the other.

_________________
bsnes-mcfly: A port of the Qt GUI from v073 to v106.
nSide: A higan fork w/NES boards and peripherals and Sonic & Knuckles Lock-On.
Dragon Quest I & II RPGOne Beran Inn bugfix


2017-09-21 21:24
User avatar

Joined: 2014-09-27 09:21
Posts: 1550
Location: 日本
 Re: Project64 makes invalid CRCs in Banjo-Kazooie saves
Yeah, the use of a sarcasm tag in a helpful post seems quite odd. Perhaps you felt you were stating the obvious in a condescending manner? Or not? I dunno...

_________________
CaptainJistuce: He's totally in the wrong, Kakashi's 100% in the right.
Note: The above statement is subject to act of byuu.


2017-09-21 21:37
User avatar

Joined: 2014-09-27 09:44
Posts: 643
 Re: Project64 makes invalid CRCs in Banjo-Kazooie saves
I honestly would've assumed it wouldn't work, that save states made in one emulator wouldn't work in another. I mean...many emulators don't work with save states in different versions.


2017-09-21 21:46
User avatar

Joined: 2014-09-27 09:39
Posts: 2949
 Re: Project64 makes invalid CRCs in Banjo-Kazooie saves
I did it because the idea sounded so stupid, not because I thought it wouldn't work or it was obvious. My bad.


2017-09-21 21:55