Language…
17 users online: 1337doom, AbuseFreakHacker,  BeeKaay, ben15420, Doopu, Gorry, Green, LadiesMan217, Mecke1990, OrangeBronzeDaisy, Pink Gold Peach, playagmes169, rafaelfutbal, Rykon-V73, signature_steve, Skewer,  YouFailMe - Guests: 297 - Bots: 429
Users: 64,795 (2,369 active)
Latest user: mathew

DKC2 Castle Crush Glitch explanation?

It's surprising that no one has thought it up yet. DKC2 is most likely storing executable code in SRAM where it always expects it to be in proper condition, but the glitch (as it causes arbitrary code execution from a location which is not code, due to the fact that it jumps to pointer no longer functioning) could possibly corrupt the code in the SRAM.

Because the SRAM code is now corrupt and it's (possibly) run at the game's startup routine (initialization for something?) it causes weird behavior to happen. That is why the damage is sometimes thought to also expand to the ROM image / cartridge.

I'll test this theory at some point. Any volunteers? Try to get this glitch happening on an emulator or the real SNES. Emulator is better since you could debug if the game stores code to SRAM to begin with.

When the glitch happens, remove the .srm file if using emulator or remove and re-insert the battery if using the real SNES. See if the game suddenly starts working again.
Originally posted by CosmoConsole
It's surprising that no one has thought it up yet. DKC2 is most likely storing executable code in SRAM where it always expects it to be in proper condition, but the glitch (as it causes arbitrary code execution from a location which is not code, due to the fact that it jumps to pointer no longer functioning) could possibly corrupt the code in the SRAM.

Because the SRAM code is now corrupt and it's (possibly) run at the game's startup routine (initialization for something?) it causes weird behavior to happen. That is why the damage is sometimes thought to also expand to the ROM image / cartridge.

I'll test this theory at some point. Any volunteers? Try to get this glitch happening on an emulator or the real SNES. Emulator is better since you could debug if the game stores code to SRAM to begin with.

When the glitch happens, remove the .srm file if using emulator or remove and re-insert the battery if using the real SNES. See if the game suddenly starts working again.


I've been investigating this recently (as in a couple of days ago). My preliminary research, unsurprisingly, its not code executing in SRAM that causes the crash. The SRAM corruption, at least in the particular run I am testing, is causes a bad index which just hits a brk.
Perhaps the game calls the save routine?

The SNES seems capable of using Checksums to verify data integrity, at least for some games. I tried editing save data in Lufia II and it just gets deleted.
Let's milk Sunny Milk. Then she'll have enough money to fund Sunny Milk Real Estate.
Everypony's digging with a shovel
Originally posted by Wiimeiser
Perhaps the game calls the save routine?

The SNES seems capable of using Checksums to verify data integrity, at least for some games. I tried editing save data in Lufia II and it just gets deleted.



Its all about what the game does -- The SNES itself has no notion of a checksum.