Pokémon DP Save File Structure

General Save File Structure

A Pokémon Diamond, Pearl, and Platinum save file is broken down into two pairs of blocks. Each pair consists of one small block and one big block. One big block contains current information regarding the PC storage system, including stored Pokémon, box names, box wallpapers, and the current open box. One small block contains current information on every other aspect of the game's progress, such as the trainer's name, ID number, acquired badges, party Pokémon, items, and much more. The other pair of blocks is a backup of the saved information.

The first small block in the file begins at 0x00000. The first big block begins at 0x0C100. The second small and big blocks are at the same address + 0x40000. It is important to note that the current small and current big blocks are not always stored in order in the save file (i.e. if the second small block is the more current, the first or second big block can possibly be the more current as well).

Block Footers

The last 0x14 bytes of each save block is a footer. The footer is used to determine:

• If it is a big or small block
• If it is a current block or a backup block.
• Which big/small block it links to.

Here is the structure of the block footer:

Offset	Purpose
0x00 - 0x03	Save ID number
0x04 - 0x07	Save index number
0x08 - 0x0B	Size of block
0x0C - 0x0F	Unknown
0x10 - 0x11	Unknown
0x12 - 0x13	Checksum

Loading/Saving A Save File

When the game loads the save file, it first compares the save index number of each small block. If the small block with the highest save index number has a correct checksum, then the game checks to see which big block has a matching ID number. If both big blocks have the same ID number as the small block, then the big block with the highest save index number is chosen. If the big block chosen by the save file has a correct checksum, then the game loads successfully. If the checksum is incorrect in either the small or big block, the game reverts to the other block pair. If either of their checksums are incorrect, then no data is loaded, and a new game must be started.

When the game saves data, the save index number is incremented + 1 from the current save index number, and the backup small block is overwritten with the new data.

If nothing in the big block has changed, then the save ID number in both blocks is retained. However, if changes have been made to the big block, then the backup big block is overwritten with the new data, and a new save ID number is generated, which is then written to the new small block. This is the reason why the game varies on how long it takes to save.

Thus, either small block can be linked with either big block, and the current pair is identified using the footer information.

Offsets

Trainer ID - 0x70

• Random unsigned 16bit integer
• The visible identification number of a trainer
• Determines ownership of Pokémon.

Secret ID - 0x72

• Random unsigned 16bit integer
• The hidden identification number of a trainer
• Determines ownership of Pokémon.
• Determines variation in the game.

Party Pokémon - 0x98

The Pokémon in the trainer's party.

• 6 blocks of 236 byte structures

Main article: Pokemon NDS Structure

Safari Zone Pokémon - 0x72D0

• 32bit unsigned integer result from the ARNG.
• Four Daily Safari Zone Pokémon
• Index_n = ( ARNG >> ( n * 0x5 ) ) & 0x1F
• Safari Zone Pokémon index list
• Notes: Both Safari Zone Pokémon and Swarm Pokémon have the same ARNG value.

Swarm Pokémon - 0x72D4

• 32bit unsigned integer result from the ARNG.
• One Daily Swarm Pokémon
• Index = ARNG % 0x1C
• Swarm Pokémon index list
• Notes: Both Safari Zone Pokémon and Swarm Pokémon have the same ARNG value.