Weegifying Games

ACE is freakin' tough. You make the console do whatever you want with ACE. Except modifying the ROM, tough luck. BUT everything else WORKS !
Sadly, some games are programmed too well for ACE to be possible...
Unless you do something the engineers that created the Game Boy probably never thought someone did someday. Let's get started.


Click the tabs to see stuff !

What is this ?

The concept is this :

  1. Plug Pokémon Red, Blue or Yellow in your PGB, SGB or GBC.
  2. Using an ACE glitch, execute a certain code.
  3. This code freezes the game. While it is frozen, remove the cartridge, and put another in its place.
  4. 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 !

Credits

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

UseItem_:
	ld a,1
	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
	
	ld hl,ItemUsePtrTable
	dec a
	add a
	ld c,a
	ld b,0
	add hl,bc
	ld a,[hli]
	ld h,[hl]
	ld l,a
	jp [hl]
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...

 
Back to dem top