-
Notifications
You must be signed in to change notification settings - Fork 8
MemPak structure
This is a very general overview of MPK files. I'll write a more in-depth technical doc later.
The file system isn't rigidly designed or documented. Many aspects are unclear, undefined, unused or inconsequential. So the real mysteries lie on how to handle the lesser understood aspects, rather than basic operations.
- A Controller Pak contains exactly 32 KiB (32,768 bytes) of data, using a "256 Kbit" battery-backed SRAM chip.
- The data is divided into 256-byte sectors known as pages, giving a total of 128 pages, numbered 0-127
- The first 5 pages are reserved system data, storing the file system information
- The remaining 123 pages are intended for the user's save data
- There are 16 slots for individual save files, known as notes. Each note can have 1 or more pages allocated
- Mempak, Controller Pak, pages, notes - yes all weird terminology
This page contains the "ID area". The ID block is 32 bytes and has 3 additional slots for identical backups of this data to restore from. It contains two checksums that are used to validate whether the data is corrupt or not. It also checks whether bit 0 of the DeviceID is set (0x0001 is the ID of "Controller Pak" and never changes). There is also a byte that controls the unsupported 128 KiB (1 Mbit) size variant that was planned but never realized.
Another major purpose of the ID area is the "serial number". Docuemntation states that every Controller Pak has a different serial number, and that games check this to detect when a Pak is removed and a different one is inserted to a controller. However emulators do not emulate this at all, they simply all use the same entire ID - I'm not even sure if this functionality can be tested on hardware.
Page 0 also contains a 32-byte "label area" (first 32 bytes). SDK states that this area is undefined and should not be used. However, 0x81 is written to the first byte during a repair operation, and there also may be some example SDK code that writes 0 to 31 in this area (but I've yet to find it/prove it). It serves absolutely no known purpose and is not relied upon in any way.
So in summary, only a few sanity checks are done here to determine the ID data is not corrupt.
Page 1 is known as the "Inode Table". However, it has no resemblance to the common understanding of 'inode' in Linux, so I just call it simply IndexTable. Page 2 is a 1:1 backup of Page 1, used in case of corruption.
The IndexTable is a 256-byte linked list data structure, which establishes the relationship and order of all of the occupied pages that are used for save data. Every 2 pair of 2 bytes, represent one of the 123 free pages. It parses through each node, to determine the length of the data and the order and position of each section in memory. Each number 5 to 127 indicate where the next page of data is, and 3 means "empty" and 1 means "stop".
The starting page index is stored in the NoteTable (aka file directory), which is next.
The last 2 pages of the system data represent the NoteTable. This is where a list of 16 "note" blocks are stored. Each NoteEntry is 32 bytes fixed in size.
Each NoteEntry stores the starting page index, as well as the game code and publisher code. It also stores the text for "note name" and "note extension", which is visible on MPK managers. There is also a status byte which must have bit 1 set, as it indicates that the note slot is occupied.
A data checksum was intended to be used to check the integrity of save data, but it was never actually implemented and is always 0.
User data that can be used by game saves.