not working with VC/Save

[whoo]

Hi,

File format look like you describe but update dosen't work. (size is 128k instead of 256k on Virtual consol) And data seems to be use from backup part and not for the first section part. (Checksum is bad ?)

(I can send you a sample file)

[cxd4]

File size of any flash RAM for the Nintendo 64 should always be 128k.

I do not imagine that 256k would be correct in any case.

And data seems to be use from backup part and not for the first section part.

Can you describe what you mean here? How are you invoking zs.exe, e.g. with what command or batch file? Yes, if it would help you are welcome to send me a sample file.

[whoo]

Hi,

I'm using virtualconsol and SaveManager to get an un-encrypted save file, obviously no warning when i'm using 128k file. (The file is padded with "0xAA" to 256k when I extract it)

ex:

"zc file -I i" give me right information.
"./zs EEP_NZSP -I i 4 0 0x04" without error
Checksum is at 0x100A as expected.

When I upload the save file to VC, game keeps the old paramaters.

I'm supecting that VC use "backup save" from 0x2000 to 0x3FFF. When I manually change values and checksum between 0x2000 and 0x3FFF. (The savegame is corrupt )

• I'm on linux (no Mswindows @home )
• file is available here pastefile 25b0d4166bf2a76bbb7cf207bf73af60

Dominique

[cxd4]

Yes, the "backup save" from 0x2000 to 0x3FFF is what the game reverts to if it considers the blocks between 0x0000 to 0x1FFF to be invalid. I have no idea what VirtualConsole or Save Manager are, but the game itself is designed to do that. (Of course, if both the backup and actual saves are invalid, the file is just reset as empty/unused.)

What version of the game are you playing? Is it NTSC USA? What's VirtualConsole? Does that mean you're running it on an actual Nintendo 64 or some emulator?

The only way the game will determine a save to be corrupt is if the checksum is wrong (or stored at the wrong location) or the "ZELDA3" string from 0x0024:29 isn't set.

[whoo]

Hi, I'm running ZeldaMM on my Wii (with the NARP channel). As you said, the checksum position/value shouln'd be correct.

I'll read you source code to find the way to calculate it, and verify with a fresh savefile.

[cxd4]

I would propose, take the Wii/VC original save file before my zs command executes any changes on that, have some backup of that, then run my zs command on it making one single minimalist change, then see if it works on VC. If not, send me both files, and I can do a binary comparison on them to see what is being done unusually.

[whoo]

Hi,

I found a fix, to get the right checksum based on the 0x2000 first bytes (and not 0x4000) I know that is quit dirty and should'nt write like that.

Obviously with my trick, the checksum is not the same but WII/VC works with it. The generated file is 128k, instead of 256k from the WII/VC, but it works. WII/VC add automagically extra information (padding with 0xAA)

--- a/zs_data.c
+++ b/zs_data.c
@@ -694,6 +694,7 @@ u16 fix_checksum(unsigned int section_ID)

     format = (read16(&section[0x100A]) != read16(&section[0x300A])) ? 1 : 0;
     limit = (FILE_SIZE / 2) << format;
+    limit = (FILE_SIZE / 2) << 0; 

I've just attach a savefile without modification.

• I've got a bottle in place of bombchu < I 'used the bottle duplication glitch )
• EEP_NZSP.zip

[cxd4]

The format assignment was put there to determine whether the ROM version in use is saving the Pictograph Box snapshots into an extra 4k of the same save slot section (making 8k total), or it is just 4k behind another backup 4k copying the same thing.

There may be some reason the VC output is making the check-sums inconsistent. I will take a look.

[cxd4]

Thanks very much for reporting this.

Try again please.

I see what went wrong. The code you pinpointed had been designed to try to detect whether the save data was written by the Japanese release of Zelda Majora's Mask or not, which uses a slightly different file format. It operated off the assumption that your usage of the utility did not fix the checksum in advance before all operations completed, because it was comparing the two potential checksum addresses (for both formats) to tell if it was one format or the other, which was indeterminate.

[whoo]

Thanks ! It perfectly Works with your update.