What is this ?
The concept is this :
- Plug Pokémon Red, Blue or Yellow in your PGB, SGB or GBC.
- Using an ACE glitch, execute a certain code.
- This code freezes the game. While it is frozen, remove the cartridge, and put another in its place.
- The new game starts up !
Pretty mind-blowing, right ?
What do you mean, "You just have reset your console !"
Didn't you understand ? I did not do that !
I made the CPU execute custom code while another cartridge than Pokémon was inserted !
In that case, the custom code just started the game. But what if that code edited the save file in a specific way ? Or jumped to the code that displayed the credits ?
You guessed it. We could already do anything with Pokémon. Now we can do anything with any game
Interested ? Then here goes the method !
Now we can really break games beyond imagination.
Going further with this
Okay, I've presented a method to do this on Game Boy.
The method is specific to the GB.
But. The general concept ; removing a cartridge while the CPU is NOT accessing it to essentially have ACE on the new cart.
That's not console-specific.
The concept is even more general, imagine performing it with an USB key ?
Or at least with a different console.
...Okay, people knowing how to access Super Mario Bros. glitch worlds on the Famicom using Tennis will recognize something similar here.
This has been tested on SNES, and it looks like it... doesn't work ? D'oh !
Still, I heard nobody tried using these neat "piggybacking" adapters (those used to bypass region restrictions). I believe using those will fix the problem, but I didn't try !
8F's inner workings
I really recommend that you have some knowledge of the Game Boy's circuitry and CPU assembly.
How does 8F make this magic possible ? Why and how the setups ?
So many questions. And they all have answers !
8F is an item with identifier 5D. That's all ! That's all its magic : being an invalid item. Now, let's take a look at the routine called by the game when using an item.
ROM offset : D5C7
GB offset : ROM03:55C7
ld [CD6A],a ; initialise output to success value
ld a,[CF91] ; contains the ID of the item being used
cp a,HM_01 ; HM_01 equals 196
jp nc,ItemUseTMHM ; TMs and HMs have a special script
ItemUsePtrTable has ROM offset D5E1, and GB offset ROM03:55E1. Let's follow what happens with CF91 containing 5D : what happens when using 8F.
The game doesn't jump to ItemUseTMHM, so :
ld hl,ItemUsePtrTable ; HL = $55E1
dec a ; A = $5C
add a ; A = $B8
ld c,a ; C = $B8
ld b,0 ; BC = $00B8
add hl,bc ; HL = $5699
At this point, we need to know what is at ROM03:5699. And this is where we were over-lucky. Because at ROM03:5698
is a ld a,[$D163] instruction in the middle of the ItemUseBall routine. Which means that ROM03:5699-569A contains the address $D163.
ld a,[hli] ; A = $63
ld h,[hl] ; HL = $D199
ld l,a ; HL = $D163
jp [hl] ; PC = $D163
The game actually read the operand of the "ld a,[addr]" instruction as an address, and by sheer luck
they use the same formats. Alleluia ! ACE.
And so CPU execution continues at $D163, where everything begins...