MemPak Problems

The Problem with DexDrive

I have downloaded around 418 DexDrive .N64 files. Somehow, 324 of them (73%) contain the exact same 256-byte ID area, but it's technically invalid and forces games ask to repair when used. Luckily most save data is actually fine after choosing "yes" to repair.

The problem is: this shouldn't be the case, and it fucks up research. The ID area is supposed to be unique for each Controller Pak. It's improbable that all these independent DexDrive users used the exact same Controller Pak. So what this means is, DexDrive wasn't actually giving clean dumps, the original system data for these files are overwritten and are lost.

It's a bit of a blow, but there are still 94 left that somehow made it unscathed - maybe it was before or after a specific DexPlorer update? Who knows.

The Problem with Emulators

Update: As of May 2021, Larper64 now generates a proper random serial number in the header (based on my research attempting to show what the original factory contents looked like). Project64, Mupen64plus and Cen64 still use the original static Mupen64 header, but all received patches for fixing the 0x03 issue mentioned below.

As of May 2020, all the recent emulators piggyback off each other when it comes to Controller Pak code. That list includes: Mupen64, Project64, Mupen64plus, ParaLLEl, Cen64 and Larper64.

This is from original Mupen64 (2002):

void format_mempacks() {
    unsigned char init[] = {
        0x81,0x01,0x02,0x03, 0x04,0x05,0x06,0x07, 0x08,0x09,0x0a,0x0b, 0x0c,0x0d,0x0e,0x0f,
        0x10,0x11,0x12,0x13, 0x14,0x15,0x16,0x17, 0x18,0x19,0x1a,0x1b, 0x1c,0x1d,0x1e,0x1f,
        0xff,0xff,0xff,0xff, 0x05,0x1a,0x5f,0x13, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff, 0xff,0xff,0x01,0xff, 0x66,0x25,0x99,0xcd,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0x05,0x1a,0x5f,0x13, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff, 0xff,0xff,0x01,0xff, 0x66,0x25,0x99,0xcd,
        0xff,0xff,0xff,0xff, 0x05,0x1a,0x5f,0x13, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff, 0xff,0xff,0x01,0xff, 0x66,0x25,0x99,0xcd,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0x05,0x1a,0x5f,0x13, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0xff,0xff,0xff,0xff, 0xff,0xff,0xff,0xff, 0xff,0xff,0x01,0xff, 0x66,0x25,0x99,0xcd,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00, 0x00,0x00,0x00,0x00,
        0x00,0x71,0x00,0x03, 0x00,0x03,0x00,0x03, 0x00,0x03,0x00,0x03, 0x00,0x03,0x00,0x03
    };
    for (int i = 0; i < 4; i++) {
        for (int j = 0; j < 0x8000; j += 2) {
            mempack[i][j] = 0;
            mempack[i][j+1] = 0x03;
        }
    memcpy(mempack[i], init, 272);
    }
}

What this code does is writes hard-coded values to the starting memory of the MPK, for every game. So every game has the exact same serial number, etc. The for loop is also inaccurate - it writes 0 and 0x03 far further than it should, and ends up contaminating the data.

Nemu64 (2000) and Daedalus (2001) actually did a better job, but it was still flawed. They used a game's "repair" function on an empty file, and used that dump in their code for every game. That still meant that the ID was identical for every .MPK file it created, and it looked like it had been 'repaired'.

The Problem with Batteries (and corruption)

Obviously a dead battery means the end of your save files. But it is a complete loss, meaning any insights into the original factory contents are also lost. Also, when you "repair" a damaged Controller Pak, you are overwriting data that may have never been touched since it was first formatted in the factory.

The type of memory used here is battery-backed SRAM. It's not super clear how a dead battery can change the data, but it often does so by 'randomizing' the data (due to thermal noise). There is also evidence that show certain bit patterns such as AA 55 or C9 C9 or 71 8E. Also the level of corruption can vary depending on how long power is lost to the chip.

Ideally, to work out the original contents of MPK data, we don't want corruption. But there is also a slight possibility that the bit patterns such as AA 55 may have actually been written in the factory. But it is still garbage data.

The Problem with Unofficial Mempaks

Unofficial Paks often encounter unexplaind failures. I've personally only had failures on knock-off PS1 and GC memory cards, but it makes sense. But what about the factory contents? Knock off brands probably never had access to official Nintendo documents. They were cheaply made and were direct competitors to Nintendo.

So there is a real likelihood that different manufacturers formatted the initial data differently than others. This would be almost impossible to prove, but it may explain certain patterns found in example MPK dumps.