search

cxd4 / zs-flash

N64 flash RAM editor for "Legend of Zelda: Majora's Mask".
Creative Commons Zero v1.0 Universal
11 stars 3 forks source link

Owl-statue-based save data gets invalidated (checksum mismatch?). #3

Closed cxd4 closed 8 years ago

cxd4 commented 8 years ago

I could have sworn this utility supported overwriting the save files made from owl statues (at least in my old 2012 prototype of this program it did), but something must have changed about the testing I am doing now. I will have to debug why the checksums now fail and compare to what ROM is doing.

cxd4 commented 8 years ago

Created an image highlighting all the differences between a regular Song of Time save and an as-close-as-possible owl statue save:

Owl- vs. non-owl-saved data

One other difference not captured in the above screenshot: The check-sum at file[0x138E]15..0 (or 0x138E + 0x8000 for the owl statue variant) is changed from 0x637C (Song of Time) to 0x632F (owl statues).

cxd4 commented 8 years ago

Looks like it's the checksum getting corrupted by my own utility.

It appears the checksum is being saved at the spot correctly for non-owl saves only, even though I used my save editor to do nothing other than read and re-export the whole file with no data changes (except perhaps byte order, which shouldn't affect checksums). I will have to add some code to compare and debug what could be going wrong with adding up the correct sum of the bytes or if the algorithm is different from what I thought it should be.

On a side note, the undocumented byte file[0x000023]7..0 is getting written to for owl saves, set to 0x01 instead of 0x00. My analysis of the Zelda debug ROM seems to say nothing about this byte being used. Maybe this is the very indicator of whether a save file is specially written by saving at an owl statue, since the original debugging code in ROM may be more pertinent to the original Japanese releases in which owl statues did not have this purpose anyway.

cxd4 commented 8 years ago

Further investigation shows that an untouched (by my save editor) owl-saved flash save file had a checksum of file[0x100A]15..0 = 0x62E9, while doing a "null open" with my save editor to do nothing but verify each of the checksums for some reason changes it to file[0x100A]15..0 = 0x62C5.

So actually my save editor is storing 0x24 short of what should have been the correct response.

Looking back to my screenshot in the post before, 0x24 is 0x20 + 0x04 which represents the two bytes after the checksum's location in the flash RAM, which is interesting. So I guess it looks like bytes even beyond the address of the checksum need to be factored into the calculation as well.

cxd4 commented 8 years ago

https://github.com/cxd4/zs-flash/commit/566b7b1f9418f30cae1e80db103d88ab1e358ab0

The issue was that if file[0x000023]7..0 is set to TRUE, it's an owl save needing a larger sum range.