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: PokéWTrainer freeze  (Read 5111 times)

0 Members and 1 Guest are viewing this topic.

Wack0

  • Coder, reverser, beta collector [BetaArchive staff]
  • Distinguished Member
  • *
  • Offline Offline
  • Gender: Male
  • cBRH - Doing nothing since 2k7
    • View Profile
PokéWTrainer freeze
« on: March 28, 2014, 02:35:14 pm »
So, I decided to break out bgb and investigate why certain glitch pokemon freeze the game on encounter.

And first on my list was pokewtrainer..

Turns out the cause for the freeze is.. buffer overflow.

I don't know the entire specifics, but as part of sprite loading the game calls AlignSpriteDataCentered (at $16C2).

It copies data between two sprite buffers.

Now, the sprite buffers are located at the start of SRAM; there are three of them, each 392 bytes in size (7*7 tiles, where a tile is 8 bytes long). (And for those who don't know, SRAM is located at the start of RAM.)

Of course, the sprite data is abnormal. The sprite width of PokéWTrainer's front sprite just happens to be 00.

And this byte is equal to the number of loops taken. So the function loops 256 times and ends up trying to copy $179E0 bytes (or over 94KB) from $A188 to $A0F0. This obviously means both these pointers wrap around, and we end up overwriting nearly the entirety of RAM (and attempting to overwrite ROM, something that will never succeed except maybe in some lame flashcarts). Go figure.

We freeze thanks to the vblank interrupt handler. Therefore I doubt this will ever be exploitable to run arbitrary code (although I'm not TheZZAZZGlitch so...).

And yes, I know what you're thinking. Here, take a screenshot. This is what could happen to your save file.

« Last Edit: March 28, 2014, 02:38:11 pm by Wack0 »
C H E C K E D . B U I L D S . A R E . A W E S O M E N E S S

BetaArchiveSoftHistory Forumsirc.rol.im #galaxy,#softhistory

Also known as The Distractor.

Shane, please stop telling children that there's a Mew outside under the delivery trucks. - Management

Pokémon: arbitrary code execution 1996-2016

pokechu22

  • Member+
  • *
  • Offline Offline
  • Gender: Male
    • View Profile
Re: PokéWTrainer freeze
« Reply #1 on: March 28, 2014, 04:03:04 pm »
First question: Where does the pattern "0039" come from?  I see it a lot when the game crashes.

Second question:  If the sprite width comes from an address, could the address be a variable?  It would explain how "♀ ." corrupts the sound when it appears sometimes, but other times doesn't.  Although I don't know why "♀ ." doesn't corrupt the save data then...  Hm. 

Also, a correction:
Quote
(7*7 tiles, where a tile is 8 bytes long).
Tiles are 16 bytes long.  Two bytes per row of pixels.  As an example, this:
Code: [Select]
01010101
00001111
Would produce this:
Code: [Select]
░ ░▒█▒█
Though you probably already know that. 

Also, I never knew that sprite data was compressed.  Is that a common thing on Gameboy games?
When I underline text, that usualy means I am using the [‍acroynm] tag to provide aditional information.  Hover over it to view.
My youtube channel

Wack0

  • Coder, reverser, beta collector [BetaArchive staff]
  • Distinguished Member
  • *
  • Offline Offline
  • Gender: Male
  • cBRH - Doing nothing since 2k7
    • View Profile
Re: PokéWTrainer freeze
« Reply #2 on: March 28, 2014, 04:22:27 pm »
First question: Where does the pattern "0039" come from?  I see it a lot when the game crashes.

No idea.

Quote
Second question:  If the sprite width comes from an address, could the address be a variable?  It would explain how "♀ ." corrupts the sound when it appears sometimes, but other times doesn't.  Although I don't know why "♀ ." doesn't corrupt the save data then...  Hm. 

Possibly. Depends on what is being pointed to.

Quote
Also, a correction:
Quote
(7*7 tiles, where a tile is 8 bytes long).
Tiles are 16 bytes long.  Two bytes per row of pixels.  As an example, this:
Code: [Select]
01010101
00001111
Would produce this:
Code: [Select]
░ ░▒█▒█
Though you probably already know that. 

Also, I never knew that sprite data was compressed.  Is that a common thing on Gameboy games?

The "tile is 8 bytes long" thing is going by IIMarckus' disasm.

Regarding sprite data being compressed, I didn't know this either until I saw the relevant parts of the disasm. I assume some games would have compressed sprites to keep the rom size down.
« Last Edit: March 28, 2014, 05:29:23 pm by Wack0 »
C H E C K E D . B U I L D S . A R E . A W E S O M E N E S S

BetaArchiveSoftHistory Forumsirc.rol.im #galaxy,#softhistory

Also known as The Distractor.

Shane, please stop telling children that there's a Mew outside under the delivery trucks. - Management

Pokémon: arbitrary code execution 1996-2016

pokechu22

  • Member+
  • *
  • Offline Offline
  • Gender: Male
    • View Profile
Re: PokéWTrainer freeze
« Reply #3 on: March 28, 2014, 05:17:06 pm »
Also, a correction:
Quote
(7*7 tiles, where a tile is 8 bytes long).
Tiles are 16 bytes long.  Two bytes per row of pixels.  As an example, this:
Code: [Select]
01010101
00001111
Would produce this:
Code: [Select]
░ ░▒█▒█
Though you probably already know that. 

Also, I never knew that sprite data was compressed.  Is that a common thing on Gameboy games?

The "tile is 8 bytes long" thing is going by IIMarkus' disasm.

Regarding sprite data being compressed, I didn't know this either until I saw the relevant parts of the disasm. I assume some games would have compressed sprites to keep the rom size down.

Hm.  I never knew there was a disassembly.  Found a link to it though; it is here

I have used a tool to create Gameboy sprites, and it said they could be exported to a "GB-COMPRESS"ed format, but I had no idea on the details.  These sprites are definitely compressed though.  Interesting.
When I underline text, that usualy means I am using the [‍acroynm] tag to provide aditional information.  Hover over it to view.
My youtube channel

TheZZAZZGlitch

  • Distinguished Member
  • *
  • Offline Offline
  • Gender: Male
  • Unknown opcode fc at 801a
    • View Profile
Re: PokéWTrainer freeze
« Reply #4 on: March 29, 2014, 08:23:02 am »
Quote
Where does the pattern "0039" come from?  I see it a lot when the game crashes.

When the game starts executing code from where it shouldn't, it will most commonly encounter an 'rst 38' instruction, and it's essentially the same as 'call $0038'. It will push the return address ($0039) onto the stack, and jump to address $0038.
At $0038, we have again:
0038: FF    rst 38
So this is an infinite loop. It will keep writing $0039 to stack forever. Eventually, when the stack space runs out, it will start writing to other memory areas. Hence the vertical bars (corrupting VRAM) and erased save files (corrupting SRAM).

Quote
If the sprite width comes from an address, could the address be a variable?  It would explain how "♀ ." corrupts the sound when it appears sometimes, but other times doesn't.  Although I don't know why "♀ ." doesn't corrupt the save data then...

a) Sprite width cannot come from a variable address - it is always read from the base stats table. The sprite data itself may vary though.

b) Normally, viewing invalid Pokemon sprites or corrupting the whole address space in some other way won't corrupt the save file completely. It will corrupt the first 0x2000 bytes, but it won't affect the save. It's because SRAM has switchable banks, just like ROM. The save file is in bank 1, but the save corruption happens in bank 0.
But if the memory corruption somehow causes the bank to switch (for example, by writing $01 to $0000), the save will get erased.

qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF qÁF

Wack0

  • Coder, reverser, beta collector [BetaArchive staff]
  • Distinguished Member
  • *
  • Offline Offline
  • Gender: Male
  • cBRH - Doing nothing since 2k7
    • View Profile
Re: PokéWTrainer freeze
« Reply #5 on: March 29, 2014, 08:36:20 am »
Normally, viewing invalid Pokemon sprites or corrupting the whole address space in some other way won't corrupt the save file completely. It will corrupt the first 0x2000 bytes, but it won't affect the save. It's because SRAM has switchable banks, just like ROM. The save file is in bank 1, but the save corruption happens in bank 0.
But if the memory corruption somehow causes the bank to switch (for example, by writing $01 to $0000), the save will get erased.

OK. I figured SRAM had switchable banks, but I couldn't find any information about that at all.
C H E C K E D . B U I L D S . A R E . A W E S O M E N E S S

BetaArchiveSoftHistory Forumsirc.rol.im #galaxy,#softhistory

Also known as The Distractor.

Shane, please stop telling children that there's a Mew outside under the delivery trucks. - Management

Pokémon: arbitrary code execution 1996-2016

Nerator

  • GCLF Member
  • Offline Offline
  • CHARIZRAD 'M ROXORX or is it.
    • View Profile
Re: PokéWTrainer freeze
« Reply #6 on: April 09, 2014, 07:48:56 am »
Hey, Wack0! Just wanted to stop by and report something i noticed. May be it's not new, but i didn't see it, mainly because i'm new to glitching/memory hacking thing.
Anyway, i was inspired by MissingNoXpert LGPY series on YouTube, and i was kinda interested by pokemon "4 4" (hex BF), cause it was only one pokemon in range of 190-199 (which MissingNoXpert showed) to crash game every time. I got BGB emulator and dived in.
I didn't use Mew trick to encounter "4 4" (mainly because i'm too lazy of beating the game :P), so i just modified RAM at address $D058 to BF. After doing some seemingly random stuff with debugger i eventually, through some tries found some code that seemed to repeat many times. After comparing lines with IIMarckus's disasm (i understood, that adresses could vary in Yellow), i realised, that it was very same AlignSpriteDataCentered function/subroutine (don't know, how this things called exactly in asm), in Yellow it starts at address $149F. So i remembered your topic and wondered, if "4 4" crashed game exactly like PokeWTrainer, cause of sprite width. So here's piece of code from disasm:
Code: [Select]
AlignSpriteDataCentered: ; 16c2 (0:16c2)
ld a, [H_SPRITEOFFSET]
ld b, $0
ld c, a
add hl, bc
ld a, [H_SPRITEWIDTH] ; $FF00+$8b
.columnLoop
push af
push hl
ld a, [H_SPRITEHEIGHT] ; $FF00+$8c
ld c, a
So there game loads sprite offset, width and heigth from addresses $FF8D, $FF8B and $FF8C respectively. I think they're loaded there sometime earlier in the runtime from ROM. So i checked these addresses for "4 4" and yep, offset was 18h, but width and height were both 00.
Then i thought, may be i can encounter him normally if i change width and height manually? I checked values for Pidgey (were 05h and 28h) and encountered "4 4" again, but rigth as the game got to code at $149F i changed values at $FF8B and $FF8C and it worked like magic! I'll attach screenshots.
His sprite in your party and back sprite seems normal and don't crash your game, but it's hard to see because of this damn black glitchbox.
Sorry in advance if knew about it before, it was just my first sort of discovery in glitching, so i wanted to share! Also english is not my native language, so sorry for any mistakes.

pokechu22

  • Member+
  • *
  • Offline Offline
  • Gender: Male
    • View Profile
Re: PokéWTrainer freeze
« Reply #7 on: April 09, 2014, 10:09:17 am »
Hey, Wack0! Just wanted to stop by and report something i noticed. May be it's not new, but i didn't see it, mainly because i'm new to glitching/memory hacking thing.
Anyway, i was inspired by MissingNoXpert LGPY series on YouTube, and i was kinda interested by pokemon "4 4" (hex BF), cause it was only one pokemon in range of 190-199 (which MissingNoXpert showed) to crash game every time. I got BGB emulator and dived in.
I didn't use Mew trick to encounter "4 4" (mainly because i'm too lazy of beating the game :P), so i just modified RAM at address $D058 to BF. After doing some seemingly random stuff with debugger i eventually, through some tries found some code that seemed to repeat many times. After comparing lines with IIMarckus's disasm (i understood, that adresses could vary in Yellow), i realised, that it was very same AlignSpriteDataCentered function/subroutine (don't know, how this things called exactly in asm), in Yellow it starts at address $149F. So i remembered your topic and wondered, if "4 4" crashed game exactly like PokeWTrainer, cause of sprite width. So here's piece of code from disasm:
Code: [Select]
AlignSpriteDataCentered: ; 16c2 (0:16c2)
ld a, [H_SPRITEOFFSET]
ld b, $0
ld c, a
add hl, bc
ld a, [H_SPRITEWIDTH] ; $FF00+$8b
.columnLoop
push af
push hl
ld a, [H_SPRITEHEIGHT] ; $FF00+$8c
ld c, a
So there game loads sprite offset, width and heigth from addresses $FF8D, $FF8B and $FF8C respectively. I think they're loaded there sometime earlier in the runtime from ROM. So i checked these addresses for "4 4" and yep, offset was 18h, but width and height were both 00.
Then i thought, may be i can encounter him normally if i change width and height manually? I checked values for Pidgey (were 05h and 28h) and encountered "4 4" again, but rigth as the game got to code at $149F i changed values at $FF8B and $FF8C and it worked like magic! I'll attach screenshots.
His sprite in your party and back sprite seems normal and don't crash your game, but it's hard to see because of this damn black glitchbox.
Sorry in advance if knew about it before, it was just my first sort of discovery in glitching, so i wanted to share! Also english is not my native language, so sorry for any mistakes.

First off, your English was easily readable, although there were a few typos.  Also, do you think it would be possible to do this effect with a game genie code?  (there's a tool to make them here).

One final thing: you may be able to get a better sprite by using Super Gameboy mode or regular Gameboy mode.  Also, you might be interested in this effect TheZZAZZGlitch once got.
When I underline text, that usualy means I am using the [‍acroynm] tag to provide aditional information.  Hover over it to view.
My youtube channel

danny

  • Decamark Collector and Pokémaniac
  • Member+
  • *
  • Offline Offline
  • i hate being alive
    • View Profile
Re: PokéWTrainer freeze
« Reply #8 on: February 03, 2016, 08:22:05 am »
(and attempting to overwrite ROM, something that will never succeed except maybe in some lame flashcarts)

I know this topic is old, but I've seen pokemon gold overwrite the rom, on visualboyadvance. It had a bunch of 00s and 60s in the first few bites (most likely $0-100)
ralsei is my son.

discord: dani#5700

ISSOtm

  • The French Lord of Laziness (and a huge The Legend Of Zelda fan)
  • Staff
  • *****
  • Offline Offline
  • Gender: Male
  • Pewter City (B)rocks !
    • View Profile
    • My Little Website
Re: PokéWTrainer freeze
« Reply #9 on: November 14, 2016, 08:57:47 pm »
Quote
Where does the pattern "0039" come from?  I see it a lot when the game crashes.

When the game starts executing code from where it shouldn't, it will most commonly encounter an 'rst 38' instruction, and it's essentially the same as 'call $0038'. It will push the return address ($0039) onto the stack, and jump to address $0038.
At $0038, we have again:
0038: FF    rst 38
So this is an infinite loop. It will keep writing $0039 to stack forever. Eventually, when the stack space runs out, it will start writing to other memory areas. Hence the vertical bars (corrupting VRAM) and erased save files (corrupting SRAM).
Hello, £e Nécrobumper here.

Actually, all rst vectors in RBY have a FF instruction, which means any rst instruction is basically an entry point towards that infinite loop... heh.

Also, save files should not be corrupted, since SRAM only unlocks when a $0A is sent. Unless you're using a crappy emulator... why, hello VBA ! Long time no see !
Furthermore, no function that opens SRAM has the potential to crash (maybe VBlank could ? That'd explain)
"THOU SHALL NOT PASS !!"  RIVAL's effect, Gandalf.

Proudly glitching Pokémon Red and Yellow on a Black & White GB, Pocket GB, GB Color, GBA SP and new 3DS.

My Twitter (beware, I'm French)
My YouTube (same warning)

Here is an online tool to build 8F setups : GBz80 to Items !

They see me layzin', they ha-tin'...
Heavy contributor of the global augmentation of entropy (my room's is too damn high !)

Hālian

  • That worldbuilding/micronations/MTG guy
  • Member+
  • *
  • Offline Offline
  • Gender: Male
  • *happy space elf noises*
    • View Profile
    • Hoennese Realm
Re: PokéWTrainer freeze
« Reply #10 on: November 18, 2016, 11:16:08 am »
I wonder why they did that.
Hoennese Realm



All sprites made by Naitekiakki, except:
Recolored Gardevoir made by me

Evie the Mother Hen ☽ ❤

  • Head Administrator
  • *****
  • Online Online
  • Gender: Female
  • I love My Melody. 🦋 ✿
    • View Profile
Re: PokéWTrainer freeze
« Reply #11 on: November 18, 2016, 02:54:38 pm »
I wonder why they did that.

Wack0 and I were talking about this and he wondered whether rst $38 was a good idea for debugging, because if the memory is filled with 00 39 you know a rst $38 is very likely to be the cause.

✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Here have some free flowers on every post :)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿



(Images © Sanrio, Nintendo, Pokémon, HAL Laboratory)

✿ Hi, I'm Evie. Transgender woman but spiritually doesn't believe 'male'/'female' needs to be defined; lives more stereotypically like a woman/I'm a 'girly' nerd who discovered herself. Call me whichever pronouns you like. :)

Feel free to contact me here about anything regarding the site.

Forgiveness. I feel that the more people pray to our greatest source/God/mathematical equality for world peace, the more and more it manifests into reality (until our next spiritual death).

Thank you Nyapon for this lovely artwork. :3

Yeniaul

  • Guest
Re: PokéWTrainer freeze
« Reply #12 on: November 18, 2016, 03:30:47 pm »
Wait... if my understanding of the GBz80 and ROM structure is correct, theoretically, couldn't you just replace the chain of "rst $38" at the beginning of the ROM to code that jumps back to the RST address + 1? So, in Python2-esque format, something like
Code: [Select]
LastPC = F572 #whatever
PC = F573 #or something, really doesn't matter
if instruction == FF: #whatever, works for example
>>jump(0038) #standard "rst $38" behavior
LastPC = F573 #works for example
PC = 0038 #due to jump
#and, at $0038, lies:
jump(LastPC + 1) #so we jump OVER the FF, not back TO it

So... anyone see this in gbz80 ASM?

ISSOtm

  • The French Lord of Laziness (and a huge The Legend Of Zelda fan)
  • Staff
  • *****
  • Offline Offline
  • Gender: Male
  • Pewter City (B)rocks !
    • View Profile
    • My Little Website
Re: PokéWTrainer freeze
« Reply #13 on: November 18, 2016, 06:32:12 pm »
I wonder why they did that.
The rst $38 instruction is actually one byte long. Guess which byte ? Why, it's a $FF ! So I guess they just put some FF bytes because it made sense (when you put a filler value, you usually put $00 or $FF ; however $00 is more "blank"... so they put $FF as fillers anyways.)

I wonder why they did that.

Wack0 and I were talking about this and he wondered whether rst $38 was a good idea for debugging, because if the memory is filled with 00 39 you know a rst $38 is very likely to be the cause.
To debug, something better would have been a jump to a function that prints stuff like stack info, instead of just... crashing.

Wait... if my understanding of the GBz80 and ROM structure is correct, theoretically, couldn't you just replace the chain of "rst $38" at the beginning of the ROM to code that jumps back to the RST address + 1? So, in Python2-esque format, something like
Code: [Select]
LastPC = F572 #whatever
PC = F573 #or something, really doesn't matter
if instruction == FF: #whatever, works for example
>>jump(0038) #standard "rst $38" behavior
LastPC = F573 #works for example
PC = 0038 #due to jump
#and, at $0038, lies:
jump(LastPC + 1) #so we jump OVER the FF, not back TO it

So... anyone see this in gbz80 ASM?
Or just :
Code: [Select]
ret
which is
Code: [Select]
C9

Actually, rst $38 is equivalent to call $0038, with two exceptions :
1. Only one byte long.
2. Because it is two bytes smaller than call $0038, it is also 8 M1 cycles faster (8 processor cycles, to simplify).

It has one downside, though : you can't do conditionals with rst's.


Yeniaul, actually that'd be a ROM hack. TheZZAZZGlitch's Debug Yellow actually has code for the rst vectors that allows them to be "fixed" (either they can act like NOPs, or double-return, or manipulate the stack).

Also, that it not a chain of rst 38's. It's just that there is this :
ROM0:0038   rst 38          FF
Basically, the instruction at $0038 is a call to 0038. So here is what happens :

1. Read a $FF byte (form the code, or from any other rst vector)
2. Push the low byte of PC+1 on the stack
3. Push the high byte of PC+1 on the stack
4. Set PC (program counter) to $0038
5. Read a $FF byte at $0038
6. Push the low byte of PC+1 (= low($0038 + 1) = low($0039) = $39) on the stack
7. Push the high byte of PC+1 (= high($0038 + 1) = low($0039) = $00) on the stack
8. Set PC (program counter) to $0038
9. Goto step 5

Low bytes are first because we have a little-endian processor here ;)

So, what will happen first  is that the stack, usually located between $DF00 and $DFFF, will first overflow into Box Pokémon data when it reaches DEE1 ; then it will corrupt your play time (although in less than a frame it won't matter anymore :P), then the opposing Pokémon data, right before it also gives you some level 57 ($39) 'Ms... but right after that grass encounters will be removed :(
Then objets such as collectible items will despawn and respawn on their maps, then you'll get 3900 Casino Chips (which is... cool, I guess ?). Immediately after, you'll get your PC crammed with Max Repels x0 :D... but you will have 0 items there >.>
Then the stack will proceed to corrupt tile metadata, map metadata (including setting the script pointer to $3900, lol), player ID, badges and options, rival name (like BG tileXX ERROR but not terminated anymore :P), then it will make your purse contain exactly 3900 pokédollars (even though Red won't experience a single frame of having this money, derp), then the pack will fill with 20 stacks of hex:00 glitch items... and OMG THE ITEM PACK CONTAINS 57 ITEMS NOW !!! ITEM UNDERFLOW CONFIRMED !!!!!!1
Then the Pokédex will freak out just a lil'bit (maybe giving us Pokémon #152 in the process, too lazy to figure dat out), then it will turn your beloved Pokémon into some Mankeys and other Pokémon you already know about (the sixth will make you cry !), then give ya the same name as your rival. Then battle-related memories will be screwed up badly.

Now that people aren't right, the world will begin to screw up heavily.
First, menu data will be severely affected. Then all of the game's working data will be overwritten with that obnoxious 0039 pattern. Then tile buffers will be also screwed up (the game won't even have the time to use them anyways), then sprites and NPC will distort in horrible, painful ways. Then sounds will distort.

Then the stack pointer reaches save RAM. If it was open, then behavior differs between loaded banks. Bank 0 will just have your Hall of Fame corrupted (seriously, who cares). Bank 1 will have your main save data corrupted. Bank 2 and 3 will have boxes corrupted.
So, really, other than bank 0, that'll be... "your save file was destroyed !".

Then comes VRAM. Maybe it will be open ; maybe not. But if it is open, first all the screen will be covered with alternating patterns of $00 and $39 tiles. But you won't be able to see it for any more than a single frame if VRAM locks up at this exact moment. Otherwise tiles will be corrupted all with vertical lines of $0039 (little-endian, huh !).

Then comes ROM.
First, the MBC1 banking mode will be set alternatively to 0 and 1 (wow, that doesn't damage the cartridge ? Phew.), then ROM banks 1 and 9 will be alternated between. Then SRAM will be locked again (due to writing non-$0A values). Ironically, during that time, the rst 38 instruction will be overwritten with a $39 (add hl, sp). Because ROM is write-only, nothing happens. Otherwise pretty whacky stuff would go on from then on :D

But $0000 is an end. But after the end is more ; SP is just a 16-bit register.
SP can underflow.
And thus $FFFF (interrupt enable) gets zeroed, and HRAM is zerg-rushed by hordes of $00s paired up with $39s.
Then all sorts of GB registers are overwritten, which should have nice effects. (info here)
Then the stack pointer eliminates the last resistance : OAM. Echo RAM had already submitted itself in the same time as Echo RAM.

Be aware that while all of this is going on, IFF1 is disabled, meaning that interrupts are inhibited. So, all that is going on when the game seems to have crahsed is that is is permanently writing these $0039's to memory. The CPU doesn't crash or freeze. It's just stuck writing these $0039's because it keeps calling the same address.

Now, all writable memory is conquered. And read-only memory has been reduced to silence, since the 0039s have infinite powers and have the CPU all for themselves.
They are almighty.
They rule the GB.
The whole GB.
In less than a frame.

And then the player resets the console, the end.

What a touching story.



[EDIT] I realized I swapped 00s with 39s. I'm too lazy to rewrite all, so imagine it yourself, I'm going to bed.


___________________________________________




Useless trivia :
- Actually, the z80 has several "interrupt" modes that were removed from the gbz80 ; interestingly, mode 0 was triggered by grounding one of the CPU's pins, which made the CPU execute whichever byte was on its data lines. rst's were likely to be created for just that.
- Mode 1 periodically triggered some rst $38's
- Mode 2 periodically triggered a read from an address table, the reading index being given by the data lines at the time on the interrupt. I guess that's how the gbz80 is locked to be.
"THOU SHALL NOT PASS !!"  RIVAL's effect, Gandalf.

Proudly glitching Pokémon Red and Yellow on a Black & White GB, Pocket GB, GB Color, GBA SP and new 3DS.

My Twitter (beware, I'm French)
My YouTube (same warning)

Here is an online tool to build 8F setups : GBz80 to Items !

They see me layzin', they ha-tin'...
Heavy contributor of the global augmentation of entropy (my room's is too damn high !)

Yeniaul

  • Guest
Re: PokéWTrainer freeze
« Reply #14 on: November 19, 2016, 06:57:28 pm »
Also, that it not a chain of rst 38's. It's just that there is this :
ROM0:0038   rst 38          FF
Code: [Select]
ROM0:0000 FF               rst  38
ROM0:0001 00               nop 
ROM0:0002 00               nop 
ROM0:0003 00               nop 
ROM0:0004 00               nop 
ROM0:0005 00               nop 
ROM0:0006 00               nop 
ROM0:0007 00               nop 
ROM0:0008 FF               rst  38
ROM0:0009 00               nop 
ROM0:000A 00               nop 
ROM0:000B 00               nop 
ROM0:000C 00               nop 
ROM0:000D 00               nop 
ROM0:000E 00               nop 
ROM0:000F 00               nop 
ROM0:0010 FF               rst  38
ROM0:0011 00               nop 
ROM0:0012 00               nop 
ROM0:0013 00               nop 
ROM0:0014 00               nop 
ROM0:0015 00               nop 
ROM0:0016 00               nop 
ROM0:0017 00               nop 
ROM0:0018 FF               rst  38
ROM0:0019 00               nop 
ROM0:001A 00               nop 
ROM0:001B 00               nop 
ROM0:001C 00               nop 
ROM0:001D 00               nop 
ROM0:001E 00               nop 
ROM0:001F 00               nop 
ROM0:0020 FF               rst  38
ROM0:0021 00               nop 
ROM0:0022 00               nop 
ROM0:0023 00               nop 
ROM0:0024 00               nop 
ROM0:0025 00               nop 
ROM0:0026 00               nop 
ROM0:0027 00               nop 
ROM0:0028 FF               rst  38
ROM0:0029 00               nop 
ROM0:002A 00               nop 
ROM0:002B 00               nop 
ROM0:002C 00               nop 
ROM0:002D 00               nop 
ROM0:002E 00               nop 
ROM0:002F 00               nop 
ROM0:0030 FF               rst  38
ROM0:0031 00               nop 
ROM0:0032 00               nop 
ROM0:0033 00               nop 
ROM0:0034 00               nop 
ROM0:0035 00               nop 
ROM0:0036 00               nop 
ROM0:0037 00               nop 
ROM0:0038 FF               rst  38
ROM0:0039 00               nop 
ROM0:003A 00               nop 
ROM0:003B 00               nop 
ROM0:003C 00               nop 
ROM0:003D 00               nop 
ROM0:003E 00               nop 
ROM0:003F 00               nop 
Not that any of the others MATTER, it's just I like to be accurate :P

Also, just a C9 doesn't do jack, as, like you said,
Now, all writable memory is conquered. And read-only memory has been reduced to silence, since the 0039s have infinite powers and have the CPU all for themselves.