Gameboy Color freeze (or any other console): Visual effects

[The G-Meister]

So with all this stuff in the glitches section about the game locking up, freezing, crashing or whatever you want to call it... do we actually know what happens when the game/a gameboy color freezes, in terms of the graphics? Are the lines specfic to each gameboy, each game, or do they vary dependant on the situation? I'm thinking about making a game sometime soon based around hacking the game itself, and I'd like some context as to what crashes look like on different platforms, so I've got something (moderately) relevant to base the art style on.

I took a quick look around the site and couldn't find anything, and whenever I type "crash" and "gameboy" into Google half the results are Crash Bandicoot games :/ Any takers?

Also I've got some research on the way (been preparing my Red save for a bit of glitching) so I'm not just sapping off of everyone's knowledge for nothing^-^

If no-one's done stuff like this (which I would assume they have) I'll gladly have a look.

[Yeniaul]

I know this is a necrobump, but relevant info included below.

If you crash with lines, beeping occurs, and the LCD messes up from time to time, it's launching crash data from the LCD. It has a length of 4-8 bytes, and 2 bytes are fired out whenever a beep occurs. Thedata repeats until power is turned off.
If the lines have a color laid out like the in-battle HUD, the battle script was executed. If not, the overworld/menu script was executed.

[Eve the Bird Mother ❤✿]

It usually varies based on the situation. I don't know much about the different situations though, but a common freeze in Pokémon Red/Blue/Yellow are the 'rst 38' freezes, in which the game tries to run an FF opcode. As the FF opcode is rst 38 (reset vector 38, which is like 'jp 0038'), and at 0038 there is another rst 38, it confuses the game and the memory is overwritten with a 00 39 pattern. This can affect the VRAM, and can cause bar freeze patterns like https://glitchcity.info/wiki/File:Bar_freeze.png

TheZZAZZGlitch discussed this somewhere else too.

[ISSOtm]

It usually varies based on the situation. I don't know much about the different situations though, but a common freeze in Pokémon Red/Blue/Yellow are the 'rst 38' freezes, in which the game tries to run an FF opcode. As the FF opcode is rst 38 (reset vector 38, which is like 'jp 0038'), and at 0038 there is another rst 38, it confuses the game and the memory is overwritten with a 00 39 pattern. This can affect the VRAM, and can cause bar freeze patterns like https://glitchcity.info/wiki/File:Bar_freeze.png

TheZZAZZGlitch discussed this somewhere else too.

`rst 38h` is `call $0038`, not `jp $0038`. Huge difference there, because this is what causes the memory corruption, since the returns address ($0039) keeps being pushed onto the stack.
Additionally, any interrupt handlers can trigger during the freeze, at least until their control registers get overwritten (and by coincidence, all of them will be disabled, except maybe the joypad, but I think this one ALSO causes a rst $38, so no good since it'd globally disable interrupts. kek) Therefore, the behavior of that crash is somewhat timing-dependent.

[Eve the Bird Mother ❤✿]

It usually varies based on the situation. I don't know much about the different situations though, but a common freeze in Pokémon Red/Blue/Yellow are the 'rst 38' freezes, in which the game tries to run an FF opcode. As the FF opcode is rst 38 (reset vector 38, which is like 'jp 0038'), and at 0038 there is another rst 38, it confuses the game and the memory is overwritten with a 00 39 pattern. This can affect the VRAM, and can cause bar freeze patterns like https://glitchcity.info/wiki/File:Bar_freeze.png

TheZZAZZGlitch discussed this somewhere else too.

`rst 38h` is `call $0038`, not `jp $0038`. Huge difference there, because this is what causes the memory corruption, since the returns address ($0039) keeps being pushed onto the stack.
Additionally, any interrupt handlers can trigger during the freeze, at least until their control registers get overwritten (and by coincidence, all of them will be disabled, except maybe the joypad, but I think this one ALSO causes a rst $38, so no good since it'd globally disable interrupts. kek) Therefore, the behavior of that crash is somewhat timing-dependent.

Darn, that's what I get for not being as careful I should have been.

OK, thanks!