Main Menu
Main Page
Forums
New pages
Recent changes
Random page
Help

Glitches
Arbitrary code execution
Pokémon cloning
Pomeg glitch and Glitzer Popping
Tweaking and voiding
Glitches by generation
Glitch categories

References/Resources
Databases
Disassembly projects
The Big HEX List
Pokémon cheat codes
Pokémon glitch terminology
Useful tools
More

Affiliates
Legendary Star Blob 2 (Hakuda) (日本語/Japanese)
Pokémon Speedruns wiki (English)
PRAMA Initiative (Français/French)
MissingNo. Glitch City (Italiano/Italian)
Become an affiliate!

Technical
Site source code

Search Wiki

 

Search Forums

 

Author Topic: Theoretical "Crash Recovery"  (Read 86 times)

0 Members and 1 Guest are viewing this topic.

RST 38

  • Make RSTs useful
  • GCLF Member
  • Offline Offline
  • Gender: Male
  • Glitch researcher, a fan of this community
    • View Profile
Theoretical "Crash Recovery"
« on: June 13, 2019, 01:49:18 am »
So, the backstory:
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


Anyways, what do you think? Is this what really happened in the "4 4's true cry" video?
Lazy until inspired™

Parzival

  • Buyer beware: House comes with 3 free skeletons in a closet of your choice.
  • GCLF Member
  • *
  • Offline Offline
  • Gender: Male
  • This box intentionally left blank. ...wait...
    • View Profile
    • (null)
Re: Theoretical "Crash Recovery"
« Reply #1 on: June 13, 2019, 06:01:35 am »
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

Ask me about betrayal.
Ask me about depression.
Ask me about death.
Ask me about destruction.
Ask me about hardship.
I've been through s**t.
If you need to talk to someone, my PM inbox is always open.

Parzival

  • Buyer beware: House comes with 3 free skeletons in a closet of your choice.
  • GCLF Member
  • *
  • Offline Offline
  • Gender: Male
  • This box intentionally left blank. ...wait...
    • View Profile
    • (null)
Re: Theoretical "Crash Recovery"
« Reply #2 on: June 13, 2019, 11:21:20 am »
(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.
Ask me about betrayal.
Ask me about depression.
Ask me about death.
Ask me about destruction.
Ask me about hardship.
I've been through s**t.
If you need to talk to someone, my PM inbox is always open.

RST 38

  • Make RSTs useful
  • GCLF Member
  • Offline Offline
  • Gender: Male
  • Glitch researcher, a fan of this community
    • View Profile
Re: Theoretical "Crash Recovery"
« Reply #3 on: June 14, 2019, 01:03:14 pm »
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.
Lazy until inspired™

Parzival

  • Buyer beware: House comes with 3 free skeletons in a closet of your choice.
  • GCLF Member
  • *
  • Offline Offline
  • Gender: Male
  • This box intentionally left blank. ...wait...
    • View Profile
    • (null)
Re: Theoretical "Crash Recovery"
« Reply #4 on: June 14, 2019, 02:34:17 pm »
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.
Ask me about betrayal.
Ask me about depression.
Ask me about death.
Ask me about destruction.
Ask me about hardship.
I've been through s**t.
If you need to talk to someone, my PM inbox is always open.