Naturally, cartridges are not perfect (I don't think any sort of hardware is, for that matter), and they are susceptible to corrupt data, whether it is due to dust, a dying battery, or turning off the game in the middle of a save. Of course, people expect this to happen at times, and therefore there are ways to detect corrupt data, and in some cases, recover lost data in some games.
In both DKL2 and DKL3, each save file consists of blocks of 0x50 bytes (80 in decimal). (This does not include DKL3's Time Attack data, which is stored separately and functions differently; because of this, Time Attack will not be covered in this post.) The first two bytes contain a 16-bit checksum, which is basically a sum of all the other 0x4E bytes (78 in decimal) in the block. This sum can contain values from 0 to 65535. The idea behind this is that if the checksum is inconsistent with the rest of the data, the games will know that something went wrong, that is, the data was somehow altered.
In an attempt to recover corrupt save data, both DKL2 and DKL3 also have two backup copies of all save files, with a total of three blocks per file (9 blocks altogether among the three save files). The developers intended that the backup copies be used when the original copy is corrupt.
Indeed, when the games start up (during the white screen before the logo appears), the games load the original (i.e. non-backup) copies of each save file, and check to see if the checksums are valid or not. If the checksums are valid, then the save files are fine. However, if there is an invalid checksum in any file, then the games look at the backup copies until they find one with a valid checksum.
If all three copies of a save file have invalid checksums, the games determine that the save file is corrupt beyond repair, and will erase the file completely. This makes sense, because if there is not a functional copy (main or backup) of a save file, then it is basically useless.
However, things get interesting when the games find a backup copy with a valid checksum. Naturally, you'd think that the games would load the backup copy and use it. Indeed, the games ATTEMPT to copy the working backup copy into the main copy of the save file. However, due to a bug, this is not what ends up happening. This is due to an error in the way the games handle the Game Boy's stack (for those who are confused, a stack is a chunk of data in memory that grows and shrinks as data needs to be saved for later use). The games have a subroutine to copy 0x50 bytes from one location in RAM to another (or at least it attempts to do this), and when this subroutine is called, the return address is pushed (added) into the stack, so that the games know what location in ROM they should run once the subroutine is done executing. This subroutine is flawed, however, and as soon as it is executed, it pops (i.e., copies and removes) whatever value was last pushed onto the stack, which, due to the flawed code, will always be the return address, which is not what was intended.
What this basically means is that both DKL2 and DKL3 essentially read the valid data in the backup copy, and write it to this return address instead of writing to the original copy of the save data. Or at least, it would write to the return address, but since this area is read-only memory, nothing ends up happening. (I guess the read-only aspect is actually a good thing, otherwise this code would be corrupted, and who knows what would happen.) This situation could have been prevented if the pop instruction that takes place within this memory-copying subroutine was instead executed before the subroutine (as opposed to within it), so that the data popped would be the RAM address of the original (non-backup) copy of the save file.
Also, after this all happens, DKL2 and DKL3 attempt to copy the original copies of all save files, and write them to all their respective backup copies (whether the files are functional or corrupt), just in case the original copies of save files are functional, but backup ones aren't. However, this also uses the same buggy subroutine to attempt copy the data, so this ends up not happening either.
When saving in Kong Kollege or Wrinkly Refuge, however, both games do correctly load the buffer that happens to be in RAM, and copy it three times to the current save file (once for each of the three copies).
It is odd that Rareware took the time to implement a checksum mechanism, and included functionality for backup copies, but didn't bother to test to see if this all worked properly. There almost might as well be no backup copies at all, since the recovery mechanism doesn't even work correctly. It is also odd that the bug first appeared in DKL2, and wasn't even fixed at all in DKL3. You'd think someone at Rareware would have noticed this along the way...
A side effect to this is that if the byte that stores the world where you last saved is corrupted, you would start on an invalid area when entering the world map. This would cause you to start in a random area, with a illegible level name on the bottom of the screen. When you move around, the game doesn't know where to properly take you, so you might walk in weird paths (sometimes lasting for minutes!) until you can move again. Sometimes, the game will freeze, from what I've been told.
I managed to find a couple of videos of some of this happening in DKL3:
Also, in DKL3, I've heard of cases of people entering glitchy levels from this bug, where the unused Rocket Run music can be heard. I haven't witnessed this for myself, though.
By the way, the first DKL doesn't have this problem -- its mechanism of saving files is different. It uses different methods of checking to see if the save files are valid, and it doesn't even attempt to use backup copies, so if a save file is corrupt, it will always be erased. You can see more details on this here. At least it's not glitchy!
Finally, I will soon release ROM patches that fix this bug for both DKL2 and DKL3. I will post them somewhere in the ROM hacking forum. Stay tuned!
Wow, this post was really long
