Theoretical "Crash Recovery"
Posted by: RST 38
Date: 2019-06-13 02:49:18
[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]