Save data structure (Generation III)
|
This article is incomplete. Please feel free to edit this article to add missing information and complete it. |
|
This article does not yet meet the quality standards of Bulbapedia. Please feel free to edit this article to make it conform to Bulbapedia norms and conventions. |
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. The structure consists of 128 KB of data, though not every byte is used. Emulators may append additional data for the purposes of maintaining real-time clock operations.
The integrity of most of the file is validated by checksums.
Data types
Unless otherwise noted, integer values occupy the specified number of bytes, and are little-endian and either unsigned or two's complement.
Text data
Text data for Generation III is stored in a proprietary character set. The text characters available for use by players in the game have the following byte values:
-0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -A -B -C -D -E -F 0-
1-
2-
3-
4-
5-
6-
7-
8-
9-Unused, except for 0x00 (space) A- 0 1 2 3 4 5 6 7 8 9 ! ? . - B- … “ ” ‘ ’ ♂ ♀ , / A B C D E C- F G H I J K L M N O P Q R S T U D- V W X Y Z a b c d e f g h i j k E- l m n o p q r s t u v w x y z F- Unused, except for 0xFF (terminator)
In the Japanese version, significantly more of the table is used, owing to the need to store both Japanese kana and English characters:
-0 -1 -2 -3 -4 -5 -6 -7 -8 -9 -A -B -C -D -E -F 0- あ い う え お か き く け こ さ し す せ そ 1- た ち つ て と な に ぬ ね の は ひ ふ へ ほ ま 2- み む め も や ゆ よ ら り る れ ろ わ を ん ぁ 3- ぃ ぅ ぇ ぉ ゃ ゅ ょ が ぎ ぐ げ ご ざ じ ず ぜ 4- ぞ だ ぢ づ で ど ば び ぶ べ ぼ ぱ ぴ ぷ ぺ ぽ 5- ア イ ウ エ オ カ キ ク ケ コ サ シ ス セ ソ 6- タ チ ツ テ ト ナ ニ ヌ ネ ノ ハ ヒ フ ヘ ホ マ 7- ミ ム メ モ ヤ ユ ヨ ラ リ ル レ ロ ワ ヲ ン ァ 8- ィ ゥ ェ ォ ャ ュ ョ ガ ギ グ ゲ ゴ ザ ジ ズ ゼ 9- ゾ ダ ヂ ヅ デ ド バ ビ ブ ベ ボ パ ピ プ ペ ポ A- 0 1 2 3 4 5 6 7 8 9 ! ? . - B- … “ ” ‘ ’ ♂ ♀ , / A B C D E C- F G H I J K L M N O P Q R S T U D- V W X Y Z a b c d e f g h i j k E- l m n o p q r s t u v w x y z F- Unused, except for 0xFF (terminator)
String fields can take up all of the bytes in which they are allotted. If a string is shorter than the maximum length for its field, it can be terminated with 0xFF.
In the name field for Eggs, the game places the bytes 0x60 0x6F 0x8B corresponding to タマゴ (tamago), the Japanese word for egg). This remains in the English version even though the characters have been replaced.
File structure
The Generation III save file is broken up into two game save blocks, each of which is broken up into 4 KB sections. Each 4 KB section is independently validated by checksum.
One block of game save data represents the most recent game save, and the other block represents the previous game save.
- If any checksum for the most recent game save fails, the game will use the previous game save instead.
- If any checksum for the previous game save fails, the player will be forced to start a new game.
| Offset | Size | Contents |
|---|---|---|
| 0x000000 | 57344 | Game save A |
| 0x00E000 | 57344 | Game save B |
| 0x01C000 | 16384 | Unknown |
Game save A, Game save B
14 sections representing a game save.
Exactly which game save is the most recent and which one is the previous depends on the relative values of the save index field.
The game will alternate which region of the save file it writes to each time the game is saved. 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.
Section format
All sections contain the same general format: they contain however many bytes of data, followed by a header.
| Offset | Size | Contents |
|---|---|---|
| 0x0000 | 4080 | Data |
| 0x0FF4 | 2 | Section ID |
| 0x0FF6 | 2 | Checksum |
| 0x0FFC | 4 | Save index |
Data
The checksum-able data within the section. The actual number of bytes checked is determined by Section ID.
Section ID
Specifies the save data being represented, as well as how many bytes to validate for the checksum. This is a 16-bit unsigned field and must have one of the following values:
| ID | Size | Contents |
|---|---|---|
| 0 | 3884 | Trainer info |
| 1 | 3968 | Team / items |
| 2 | 3968 | Unknown |
| 3 | 3968 | Unknown |
| 4 | 3848 | Rival info |
| 5 | 3968 | PC buffer A |
| 6 | 3968 | PC buffer B |
| 7 | 3968 | PC buffer C |
| 8 | 3968 | PC buffer D |
| 9 | 3968 | PC buffer E |
| 10 | 3968 | PC buffer F |
| 11 | 3968 | PC buffer G |
| 12 | 3968 | PC buffer H |
| 13 | 2000 | PC buffer I |
All 14 sections must be present exactly once in each game save block.
Checksum
Used to validate the integrity of saved data.
A 16-bit checksum generated by adding up bytes from the section. The algorithm is as follows:
- Initialize a 32-bit checksum variable to zero.
- Read 4 bytes at a time as 32-bit word (little-endian) and add it to the variable. The number of bytes to process in this manner is determined by Section ID.
- Take the upper 16 bits of the result, and add them to the lower 16 bits of the result.
- This new 16-bit value is the checksum.
Save index
Every time the game is saved, its Save Index value goes up by one. This is true even when starting a new game: it continues to count up from the previous save.
All 14 sections within a game save must have the same Save Index value. The most recent game save will have a greater Save Index value than the previous save.
Section 0 - trainer info
This section contains information regarding the player character.
Fields documented below simply list known values; there may be additional significant data in this section:
| RS | E | FRLG | ||||
| Offset | Size | Offset | Size | Offset | Size | Contents |
|---|---|---|---|---|---|---|
| 0x0000 | 8 | 0x0000 | 8 | 0x0000 | 8 | Player name |
| 0x0008 | 1 | 0x0008 | 1 | 0x0008 | 1 | Player gender |
| 0x000A | 4 | 0x000A | 4 | 0x000A | 4 | Trainer ID |
| 0x000E | 5 | 0x000E | 5 | 0x000E | 5 | Time played |
| 0x00AC | 4 | N/A | 0x00AC | 4 | Game Code | |
| N/A | 0x00AC | 4 | 0x0AF8 | 4 | Security key | |
Player name
The name of the player. Represented as a string that can be from 1 to 7 characters in length.
Player gender
Specifies the gender of the player character:
- For boy characters, this is set to
0x00 - For girl characters, this is set to
0x01
Note that changing this value will, for an unknown reason, not be reflected immediately on the character sprite when first loading the game. To update the sprite, the player must load into a new map first, such as entering or exiting a building.
Trainer ID
The player's internal Trainer ID.
- The lower 16 bits represent the visible, public ID.
- The upper 16 bits represent the hidden, Secret ID.
Time played
Specifies how much time has elapsed during gameplay.
This value is actually 4 values representing, in this order: the hours, minutes, seconds and "frames" that have elapsed. A frame is 1/60th of a second.
The hours field is 16-bit. The other three fields are 8-bit.
Game Code
Identifies which game this save data applies to.
- For Ruby and Sapphire, this value will be
0x00000000. - For FireRed and LeafGreen, this value will be
0x00000001. - For Emerald, this is the location of the Security Key field, so any value other than 0 or 1 can be used to identify Emerald.
Security key
Used to encrypt sensitive data, such as money or item quantities. Applied to data via a simple exclusive or operation.
Important Note: The ultimate origin of this value is not well understood. It may be derived from other data, or it may just be a random number. The offsets listed in the table above are not known to be 100% guaranteed, but a copy of the value appears at offset 0x01F4 in Emerald and 0x0F20 in Fire Red/Leaf Green.
Ruby and Sapphire either do not utilize this masking operation, or the mask is always zero. Editor's Note: This could use some further investigation. If the mask does exist, it would be located at the same spots as in Emerald. In all of my testing, Ruby/Sapphire data has not been protected by a security key.
Section 1 - team / items
This section contains information regarding the player's team of Pokémon as well as their item inventory.
Fields documented below simply list known values; there may be additional significant data in this section:
| RS | E | FRLG | ||||
| Offset | Size | Offset | Size | Offset | Size | Contents |
|---|---|---|---|---|---|---|
| 0x0234 | 4 | 0x0234 | 4 | 0x0034 | 4 | Team size |
| 0x0238 | 600 | 0x0238 | 600 | 0x0038 | 600 | Team Pokémon list |
| 0x0490 | 4 | 0x0490 | 4 | 0x0290 | 4 | Money |
| 0x0498 | 200 | 0x0498 | 200 | 0x0298 | 120 | PC items |
| 0x0560 | 120 | 0x0560 | 120 | 0x0310 | 168 | Item pocket |
| 0x05B0 | 80 | 0x05D8 | 120 | 0x0310 | 120 | Key item pocket |
| 0x0600 | 64 | 0x0650 | 64 | 0x0430 | 52 | Ball item pocket |
| 0x0640 | 256 | 0x0690 | 256 | 0x0464 | 232 | TM Case |
| 0x0740 | 184 | 0x0490 | 184 | 0x054C | 172 | Ball item pocket |
Team size
The number of Pokémon currently on the team.
Team Pokémon list
Data representing information for up to 6 Pokémon, as an array. For the format, please refer to: Pokémon data structure in Generation III.
All 100 bytes of the Pokémon record are used.
Data representing Pokémon beyond the team size are dummied out with byte value 0x00.
Money
The amount of money held by the player. Must be XORed with the security key to yield the true value.
Item pockets
Lists of item entries representing the player's item inventory for the various Bag pockets.
The number of item entries available per pocket in each game can be calculated by taking the number of bytes from the table above, and dividing by 4, which is the size of the item entry structure. The inventory limits are as follows:
| PC | Key Item | Ball | TM/HM | Berry | ||
|---|---|---|---|---|---|---|
| RS | 50 | 20 | 20 | 16 | 64 | 46 |
| E | 50 | 30 | 30 | 16 | 64 | 46 |
| FRLG | 30 | 42 | 30 | 13 | 58 | 43 |
Item entry
Item entries are defined using the following structure:
| Offset | Size | Contents |
|---|---|---|
| 0x00 | 2 | Item index |
| 0x02 | 2 | Item quantity |
Item index
The item's index.
Item quantity
The number of this item available in the Bag. Must be XORed with the lower 16 bits of the security key to yield the true value.
The security key does NOT apply to items stored in the PC.
Section 4 - rival info
This section contains information regarding the rival character.
Fields documented below simply list known values; there may be additional significant data in this section:
| RSE | FRLG | |||
| Offset | Size | Offset | Size | Contents |
|---|---|---|---|---|
| N/A | 0x0BCC | 8 | Rival name | |
Rival name
The name of the rival. Represented as a string that can be from 1 to 7 characters in length.
Sections 5-13 - PC buffer
These sections contain information regarding the contents of the Pokémon Storage System.
Although the PC buffer occupies 9 sections within the game save, it still functions like a single section in and of itself: it's like one big section that was split apart across multiple sections.
The bytes within the PC buffer's component sections are contiguous within it. That is to say, the 3968 bytes occupied by section 5 represent bytes 0 to 3967 in the PC buffer, the 3968 bytes in section 6 represent bytes 3968 to 7935 in the PC buffer, and so-on.
Altogether, the PC buffer contains 3968 bytes from each of 8 sections and 2000 bytes from 1 section, for a total of 33744 bytes.
Fields documented below simply list known values; there may be additional significant data in this section:
| RSEFRLG | ||
| Offset | Size | Contents |
|---|---|---|
| 0x0000 | 4 | Current PC Box |
| 0x0004 | 33600 | PC Boxes Pokémon list |
Current PC Box
The most recently viewed PC box, minus 1. That is to say, 0 represents Box 1 and 13 represents Box 14.
PC Boxes Pokémon list
A list of 420 Pokémon records. For the format, please refer to: Pokémon data structure in Generation III.
Only 80 bytes of the Pokémon record are used, meaning everything after the substructures is not included. Instead, those values are regenerated upon withdrawing a Pokémon from the PC. This is the basis of the Box trick.
Records are ordered as left-to right, top-to-bottom, per box. That is to say, the first 6 records represent the top row of Box 1 (boxes are 5 rows by 6 columns), and the first 30 records represent Box 1.
Empty cells within boxes simply dummy records containing nothing but byte value 0x00.
| |||||||||||||||||||||||||||||||||
|
This data structure article is part of Project Games, a Bulbapedia project that aims to write comprehensive articles on the Pokémon games. |
