Save data structure (Generation IV)

This article is incomplete. Please feel free to edit this article to add missing information and complete it.

---

The save data structure in the Nintendo DS is stored as a .SAV file, which is broken up into two pairs of blocks. Each pair has one small block, and one big block. The offsets for Platinum are different from Diamond and Pearl.

In Diamond and Pearl, the first small block starts at 0x00000 and ends at 0x0C0FF, the first big block starts at 0x0C100 and ends at 0x1E2DF. In Platinum, the first small block starts at 0x00000 and ends at 0x0CF2B, the first big block starts at 0x0CF2C and ends at 0x1F10F. The second pair of blocks are at the same address plus 0x40000 for all the three games.

One block pair is always a backup of the other block pair.

Small block

The small block has the following data:

Offset	Contents
0x68 - 0x77	Trainer Name
0x78 - 0x79	Trainer ID
0x7A - 0x7B	Secret ID
0x7C - 0x7F	Money
0x80	Gender
0x81	Origin
0x82	Badges
0x83	Avatar
0x9C	Number of Pokémon in Party
0xA0 - 0x627	Party Pokémon blocks
0x00630 - 0x008C3	Items placeholder
0x008C4 - 0x0098B	Key Items placeholder
0x0098C - 0x00B4B	TMs & HMs placeholder
0x00B4C - 0x00BEB	Medicines placeholder
0x00BDC - 0x00CEB	Berries placeholder
0x00CEC - 0x00D27	Poké Balls placeholder
0x00D28 - 0x00D5B	Battle Items placeholder
0x00D5C - 0x00D8B	Mail placeholder
0x0CF18 - 0x0CF2B	Footer

Item placeholders

In these placeholders, each item takes 4 bytes with the following structure:

Offset	Contents
0x00 - 0x01	Item ID
0x02 - 0x03	Item amount

Each item has a unique ID to get identified. See the list of items by index number in Generation IV for these IDs.

Footer

The last 0x14 bytes of each block (small and big) are used as a footer. It has the following structure:

Offset	Contents
0x00 - 0x03	Used to connect a small block with a big block
0x04 - 0x07	Number of the save
0x08 - 0x0B	Size of the block
0x0C - 0x0F	K
0x10 - 0x11	T
0x12 - 0x13	Checksum of the block

Checksum

The game uses a CRC-16-CCITT algorithm for the checksums. These checksums are calculated from a whole block without taking the footer.

Example

SMALL BLOCK 1
D1 01 00 00 | 42 04 00 00 | 00 C1 00 00 | 23 06 06 20 | 00 00 | 7E 7A

BIG BLOCK 1
D0 01 00 00 | F1 02 00 00 | E0 21 01 00 | 23 06 06 20 | 01 00 | 0D 39

SMALL BLOCK 2
D0 01 00 00 | 41 04 00 00 | 00 C1 00 00 | 23 06 06 20 | 00 00 | 0C 7F

BIG BLOCK 2
D1 01 00 00 | F2 02 00 00 | E0 21 01 00 | 23 06 06 20 | 01 00 | F6 8A

Since the value of 0x0C0F0 - 0x0C0F3 is higher in small block 1 (42 04 00 00 > 41 04 00 00), that is the current small block. Then, by matching the value of 0x0C0EC - 0x0C0EF (which is D1 01 00 00) to the big block. This means that the current big block is actually big block 2 (assuming the big block's checksum is correct).

Data structure in the Pokémon games General Character encoding Generation I Pokémon species • Pokémon • Poké Mart • Character encoding • Save Generation II Pokémon species • Pokémon • Trainer • Character encoding (Korean) • Save Generation III Pokémon species (Evolution • Pokédex • Type chart) Pokémon (substructures) • Move • Contest • Contest move • Item Trainer Tower • Battle Frontier • Character encoding (GameCube) • Save Generation IV Pokémon species (Evolution • Learnsets) Pokémon • Save • Character encoding (Wii) Generation V–present Character encoding Generation VIII Save TCG GB and GB2 Character encoding

This data structure article is part of Project Games, a Bulbapedia project that aims to write comprehensive articles on the Pokémon games.