Glitch City Laboratories Archives

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.

Generation I Glitch Discussion

Theoretical "Crash Recovery" - Page 1

Theoretical "Crash Recovery"

Posted by: RST 38
Date: 2019-06-13 02:49:18
[font=verdana][size=12pt]So, the backstory:[/size]
[size=10pt]I was researching the "4 4's true cry" effect. I found that the corrupted audio bank values are constant, always. This new bank has an FF byte exactly where the DetermineAudioFunction jumps to. So that explains the constant crashing…
But… What about that video? Is there a way to recover after the unavoidable rst 38?

Well, if you think about it, this "crash" is nothing but an infinite loop. It doesn't lock up the processor like stops or invalid instructions, it doesn't terminate the process like modern OSes.
It also doesn't disable interrupts…
However, what it does do is trash the memory by overflowing the stack.

Now, what if a VBlank interrupt is fired right when SP points to one of the variables VBlank handler modifies? Then the return pointer gets corrupted and, ultimately, you escape the rst 38 loop…

TBH, I don't think thats anything new. It's kindof obvious something like this could happen, albeit with a very low chance.
I tried to do something like this in BGB, however I don't know how these internal display registers work. But I've calculated that to make SP point to wIgnoreInputCounter(D139) when a VBlank is triggered you need to be on line 78, cycle 128 when opcode at 0038 is executed for the first time… Yeah…

If someone wants to get into these techy hardware details then read pandocs Pandocs and that one talk about gameboy which I don't remember the name of… Also GbdevWiki is a good resource[/size]

[size=12pt]Anyways, what do you think? Is this what really happened in the "4 4's true cry" video?[/size][/font]

Re: Theoretical "Crash Recovery"

Posted by: Parzival
Date: 2019-06-13 07:01:35
fairly sure if an interrupt fires in the middle of a jump it'll push the 0039 to the stack first then jump so no

also you'd have to return somewhere to break out of the loop or it'd jump right back unless you use the routine's RET but that kind of stack manip is super hard to actually do

Re: Theoretical "Crash Recovery"

Posted by: Parzival
Date: 2019-06-13 12:21:20
(sorry for the doublepost but it's been a bit since the last post)

According to Lior, who handles SameBoy, interrupts are always put on hold until after an opcode fully processes. Therefore, it'd either happen before or after the RST 38 opcode you're looking to manipulate with. However, even if this did work, 90% of WRAM would be trashed, so it'd probably either go straight back into the RST 38 loop or hang up somewhere else.

Re: Theoretical "Crash Recovery"

Posted by: RST 38
Date: 2019-06-14 14:03:14
Yeah, I remembered that in the video you clearly see that the garbage code successfully returns.
Well, stack pointer manipulation instructions are no strangers to garbage code, but the probability of them putting the pointer in just the right place is very low… I just don't know what else could've happened.

On a side note, not all pieces of code in this game return. Say, what if a new return pointer points to somewhere in the middle of the overworld loop. Provided map scripts didn't get corrupted, or we got lucky to have a non-crashing one, we could theoretically be safe(except for all the side effects of an overflowed stack).

And also, I believe the current PC value is always pushed onto the stack when an interrupt is fired. Thats the one I'm trying to modify, not the one rst pushes.

Re: Theoretical "Crash Recovery"

Posted by: Parzival
Date: 2019-06-14 15:34:17

Yeah, I remembered that in the video you clearly see that the garbage code successfully returns.
Well, stack pointer manipulation instructions are no strangers to garbage code, but the probability of them putting the pointer in just the right place is very low… I just don't know what else could've happened.

On a side note, not all pieces of code in this game return. Say, what if a new return pointer points to somewhere in the middle of the overworld loop. Provided map scripts didn't get corrupted, or we got lucky to have a non-crashing one, we could theoretically be safe(except for all the side effects of an overflowed stack).

And also, I believe the current PC value is always pushed onto the stack when an interrupt is fired. Thats the one I'm trying to modify, not the one rst pushes.
Breaking the RST 38 loop specifically during the VBlank interrupt means pretty much all of RAM would be trashed. It wouldn't matter, is what i'm saying, as it'd crash very quickly afterwards.

Re: Theoretical "Crash Recovery"

Posted by: Torchickens
Date: 2019-06-30 13:04:57
C90-38F-195 is a Game Genie code to patch 0038 from FF to C9 in Red/Blue - though stepping out of bounds for instance, will not work even with this code enabled.  Using a ROM patch maybe 0038 could be converted into a routine that brings control back to the game, with the stack, other addresses fixed and no execution of freezing code (perhaps also possible with many Game Genie codes). It sounds like crash recovery in this case is possible; in fact TheZZAZZGlitch's debug Yellow hack has crash prevention measures but I don't know sorry. :( Hope this clears some of your questions anyway. :)

Re: Theoretical "Crash Recovery"

Posted by: Parzival
Date: 2019-06-30 13:06:03

C90-38F-195 is a Game Genie code to patch 0038 from FF to C9 in Red/Blue - though stepping out of bounds for instance, will not work even with this code enabled.  Using a ROM patch maybe 0038 could be converted into a routine that brings control back to the game, with the stack, other addresses fixed and no execution of freezing code (perhaps also possible with many Game Genie codes). It sounds like crash recovery in this case is possible; in fact TheZZAZZGlitch's debug Yellow hack has crash prevention measures but I don't know sorry. :( Hope this clears some of your questions anyway. :)
Theoretically you could just have it jump to the overworld loop…?
I'll test that later.

Re: Theoretical "Crash Recovery"

Posted by: Torchickens
Date: 2019-06-30 13:09:37


C90-38F-195 is a Game Genie code to patch 0038 from FF to C9 in Red/Blue - though stepping out of bounds for instance, will not work even with this code enabled.  Using a ROM patch maybe 0038 could be converted into a routine that brings control back to the game, with the stack, other addresses fixed and no execution of freezing code (perhaps also possible with many Game Genie codes). It sounds like crash recovery in this case is possible; in fact TheZZAZZGlitch's debug Yellow hack has crash prevention measures but I don't know sorry. :( Hope this clears some of your questions anyway. :)
Theoretically you could just have it jump to the overworld loop…?
I'll test that later.


Good luck! :)

Re: Theoretical "Crash Recovery"

Posted by: Parzival
Date: 2019-06-30 13:26:38



C90-38F-195 is a Game Genie code to patch 0038 from FF to C9 in Red/Blue - though stepping out of bounds for instance, will not work even with this code enabled.  Using a ROM patch maybe 0038 could be converted into a routine that brings control back to the game, with the stack, other addresses fixed and no execution of freezing code (perhaps also possible with many Game Genie codes). It sounds like crash recovery in this case is possible; in fact TheZZAZZGlitch's debug Yellow hack has crash prevention measures but I don't know sorry. :( Hope this clears some of your questions anyway. :)
Theoretically you could just have it jump to the overworld loop…?
I'll test that later.


Good luck! :)
Even though the rst 38 vector is no longer an infinite loop, it for some reason keeps writing 0039 to RAM for quite a distance before actually jumping TO the overworld loop like it's supposed to.
BGB, are you having a stroke…?

EDIT: BGB WHAT THE f**k ARE YOU DOING
[img]https://i.imgur.com/F9u45OC.png[/img]

EDIT 2: yup. this is where the inexplicable 0039 stack pushes are coming from.