Golden Sun ACE

		Written by Dyrati

Golden Sun ACE discovery:

In Tret Tree, when you step on a leaf tile, it modifies an off screen tile.  The modified tile is at some offset to the address of the tile you stepped on, 0x100 bytes away typically.  When you're out of bounds, there's a lot of data there that is used for unrelated things, that also happen to have values that make them look like leaf tiles to the game, so when you step on them, they still modify memory at specific offsets.  A while ago, Teawater discovered that, and documented several details, although at the time, it was really just him doing the research I think.

Very recently, interest was revitalized when FX unexpectedly transformed himself into Jenna by stepping on a leaf tile out of bounds.  He and Plexa started stepping on a bunch of tiles just to see what happens, and a lot of weird things happened, a couple of them became immediately useful for speedrunning.

Several people, including myself, started taking a serious look at it.  My goal was to try to make ACE possible.  After a fair amount of digging and interesting finds, Teawater pointed out that if you overwrite the end of the tile event list, then it's possible to trick the game into branching to an address near the start of WRAM, but only in ARM mode.

I put that theory into practice.  When the game branched to WRAM, it interpreted player inventory as code to execute.  I created an inventory setup that was both possible to obtain naturally, and whose data in memory translated to a series of ARM assembly instructions that activated debug mode (and avoided a crash).  Over the next couple of days I made it speedrun viable, eventually switching to using character names instead of inventory.

Several successful tests on emulator later, the community was able to verify that the technique works on console, on the nintendo DS, and on the GBA

		Technical info by Teawater

Tret's setup is basically like... (When in-bounds and all coords positive.)
+0x0000 = Layer 1
+0x0100 = Layer 2
+0x4400 = Layer 3
Where layers are positioned in each map can vary. But l'd assume +0x0000/+0x0100/+0x8000 is likely the common structure.)

(For all maps in both GS1 and GS2 =(For address positions) Y position increments in 0x200, and X position increments in 0x4. Each tile's data is 32 bit of info.)

For Tret, when stepping on leaf tiles from any layer, it tries to write on layer 2 based on your coordinate.
If you go out-of-bounds, then you subtract a small amount (for -Y, -0x200; for -X, -0x4) ; But I think that's mainly due to the code that adds to negative coords before getting the event IDs on the tilemap? (Before even executing the event at all.)
("?" is mainly because I've definitely seen a function like that, but didn't verify its direct use to that.)

Leaf tiles are used only to overwrite the end of list command/marker.
Which means we can trick the game into reading garbage data (from another room), as event entries...  Step on the associated tile, then boom.... you got ace... or at least code execution where you can start doing something.

It's a bit tricky, since not just any data could work.
https://imgur.com/XSu8rFv
This is removing the end-of-list marker

This is explaining that data has requirements to work.
https://imgur.com/qwsHtFN
The DD one (blue in first image) would change into an ID that is a leaf tile ID.... with enough reloads
So it is a pointer somewhere before the player names, but since everything in between basically equates to null, then you get to the names.
I think a proper video explaining it in-depth would be a good idea. But not sure I feel like making it. xD
That, and if there's a chancce for ace in GS2, it might be better to wait anyway.