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

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)

tbd