40 lines
1.8 KiB
Plaintext
40 lines
1.8 KiB
Plaintext
The desmume save file format is merely a raw save file with a FOOTER.
|
|
|
|
This was chosen in order to maximize compatibility with other emulators,
|
|
which tend load the savefile as-is and let the game read out of whatever range
|
|
it is expecting. To assist with this, before writing the save file, desmume
|
|
will pad the raw save file out to the next highest known length. Note that this
|
|
may sometimes be incorrect if the savefile hasnt been written through to the end
|
|
during initialization. This could cause other emulators to fail to recognize the
|
|
save file.
|
|
|
|
Additionally, the footer makes it easier to analyze save files, because the
|
|
game's data will be at the correct addresses starting at offset 0x0000.
|
|
|
|
The footer format can be identified by locating the 16Byte ascii string
|
|
"|-DESMUME SAVE-|"
|
|
at the end of the file. This corresponds with the following save structure:
|
|
|
|
struct Footer {
|
|
u32 actually_written_size;
|
|
u32 padded_size;
|
|
u32 save_type; //(not currently used)
|
|
u32 address_size; //address bus size
|
|
u32 save_size; //size parameter of the save type (not currently used)
|
|
u32 version_number; //should be 0
|
|
char cookie[16];
|
|
};
|
|
|
|
note that padded_size should be where you see the end of the raw save data
|
|
and the beginning of desmume-specific information, including some junk before
|
|
the actual footer.
|
|
|
|
actually_written_size is the highest address (plus one) written to by the game.
|
|
|
|
The new desmume savefile system tries to make as few decisions as possible,
|
|
which is the reason for the behavior of actually_written_size and the disuse
|
|
of save_type and save_size. If few decisions are made, then few mistakes can
|
|
be made. That is the idea, anyway. We'll make decisions later if we need to.
|
|
save_type and save_size are reserved in case we do.
|
|
|