Re: Official 1st Gen (Red/Blue and Yellow) Glitch Discussion
Posted by: ISSOtm
Date: 2018-09-27 10:52:10
Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.
You can join Glitch City Research Institute to ask questions or discuss current developments.
You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.
Again, the corruption flips flags outside of their intended use. Simply enough, the corruption sets the flag that tells the game that it's linked, and that flag being set causes the game to load Red's sprite.
Again, the corruption flips flags outside of their intended use. Simply enough, the corruption sets the flag that tells the game that it's linked, and that flag being set causes the game to load Red's sprite.
How do you manually set that up?
ld hl, $D72E
set 6, [hl]
Just set bit 6 of D72E.
ld hl, $D72E
set 6, [hl]
R/B
Debug Yellow's anti-crash only prevents rst opcodes from crashing, but invalid opcodes will still hang. VBA doesn't emulate them.
The crashes are caused by the sprite decompression process overflowing outside of SRAM bank 0, and when that writes invalid values to C0EF-C0F0, then the game crashes. This has been known for a long time.
As for manipulating the sprite to not crash, I can't tell because I don't know what the front sprite pointer is, but the general issue is that you'd need to manipulate the compressed data, which would require overwriting a very large chunk of memory that's probably used by the game for something else, so you'd be in fact causing a crash by your attempt to prevent them.
I can't understand that wall of text.