Glitch City Laboratories Forums

Lab γ: Video Games and Glitches Discussion => Pokémon Glitch Discussion => Generation II Glitch Discussion => Topic started by: forsyz on April 22, 2018, 11:13:38 pm

Title: Why does messing up coin case ace not destroy your save
Post by: forsyz on April 22, 2018, 11:13:38 pm
Just to test on gold vc i made the game run random code with coin case ace and it caused game game to crash but my save was still fined did the same on pokemon red vc with 8f and my save was gone.
Title: Re: Why does messing up coin case ace not destroy your save
Post by: ISSOtm on April 23, 2018, 12:57:24 am
It might have been pure luck.
To avoid getting your save corrupted, before using 8F (or any similar item), view a non-glitch Pokémon's sprite, and DON'T save or use the Pokémon storage between that and using the item.
Oh, and... don't use random payloads, st00pid.
Title: Re: Why does messing up coin case ace not destroy your save
Post by: Epsilon on April 23, 2018, 08:22:35 am
Any payload that alters Red's SRAM will invalidate ye almighty $B523 checksum, and the game will reject your save file, calling it "destroyed". In Red, SRAM is often left unlocked, making these edits easier.

In G/S/C, SRAM is almost always left locked, making these edits harder to do unintentionally. 
Title: Re: Why does messing up coin case ace not destroy your save
Post by: ISSOtm on April 23, 2018, 11:23:27 pm
In Red, SRAM is often left unlocked, making these edits easier.
This is plain wrong. The game closes SRAM every time it finishes using it (sprite decompression, saving data, boxes, etc.)
Title: Re: Why does messing up coin case ace not destroy your save
Post by: luckytyphlosion on April 24, 2018, 07:58:46 pm
In Red, SRAM is often left unlocked, making these edits easier.
This is plain wrong. The game closes SRAM every time it finishes using it (sprite decompression, saving data, boxes, etc.)

This is only the case in Yellow. Red/Blue closes SRAM for save operations, but not for sprite decompression. So you cannot delete your save file from a crash unless the crash writes $0A to $0000-1fff, which opens SRAM. Any other write to $0000-$1fff disables SRAM, making it even harder to corrupt savedata.
Title: Re: Why does messing up coin case ace not destroy your save
Post by: ISSOtm on April 25, 2018, 05:23:43 am
To be fair, any value with A as its lower nibble causes SRAM to open, which means writing a random value to 0000-1FFF has a 1/16 chance to open SRAM. If this happens, and is followed by a 0039 crash, SRAM will be trampled over then locked (since SP goes from CFXX to 0000, then wraps). If bank 0 is loaded, you'll be fine (it will corrupt HoF data, but it's not checksummed). If bank 1, 2 or 3 is loaded, this will most likely make the checksum verification fail when starting up again, thus save corrupted.

Again: saving, viewing a sprite and not saving anymore largely reduces your chances of crashing.

Another note: it is also possible to change the loaded SRAM bank, which wraps (thus 3/4 chance of loading a risky bank) by writing to $4000-5FFF.
That's why I assume chances to corrupt are pretty much random, but you can lower them by properly setting up.

Of note is that Gen II has more SRAM banks, which might not all be checksummed (plus there are some backup banks), potentially reducing the risk of corruption causing "save corrupted" messages, thougsome data would still be corrupted.