Take the upper 16 bits of the result, and add them to the lower 16 bits of the result.Įvery time the game is saved, its Save Index value goes up by one.The number of bytes to process in this manner is determined by Section ID. Read 4 bytes at a time as 32-bit word (little-endian) and add it to the variable.Initialize a 32-bit checksum variable to zero.Used to validate the integrity of saved data.Ī 16-bit checksum generated by adding up bytes from the section. This is a 16-bit unsigned field and must have one of the following values: IDĪll 14 sections must be present exactly once in each game save block. Specifies the save data being represented, as well as how many bytes to validate for the checksum. The actual number of bytes checked is determined by Section ID. The checksum-able data within the section. Section formatĪll sections contain the same general format: 3968 bytes of data, followed by a footer. For example, When entering the Hall of Fame for the first time, the entire contents of its sections are set to 0x00. The first time each of these features are used on a new game, the data is wiped. Hall of Fame, Mystery Gift/e-Reader, Recorded Battle For example, if the most recent save was Game Save A, then the next time the game is saved, it will be written to Game Save B. The game will alternate which region of the save file it writes to each time the game is saved. Pokemon Fire Red Save Game EditorĮxactly which game save is the most recent and which one is the previous depends on the relative values of the save index field. If any checksum for the previous game save fails, the player will be forced to start a new game.ġ4 sections representing a game save.If any checksum for the most recent game save fails, the game will use the previous game save instead.
One block of game save data represents the most recent game save, and the other block represents the previous game save. Each 4 KB section is independently validated by checksum. The Generation III save file is broken up into two game save blocks, each of which is broken up into 4 KB sections. Strings in fixed-length fields are terminated with 0xFF with any remainder padded with 0x00. Text data is stored in a proprietary encoding. Unless otherwise noted, integer values occupy the specified number of bytes, and are little-endian and either unsigned or two's complement. The integrity of most of the file is validated by checksums. Emulators may append additional data for the purposes of maintaining real-time clock operations. The structure consists of 128 KB of data, though not every byte is used.
The save data structure for Generation III is stored in the cartridge's battery-backed RAM chip (SRAM), or as a '.sav' file from most emulators.
Please feel free to edit this article to make it conform to Bulbapedia norms and conventions. This article does not yet meet the quality standards of Bulbapedia. Please feel free to edit this article to add missing information and complete it. From Bulbapedia, the community-driven Pokémon encyclopedia.