By conducting a lot of tests, we observed that addressis dependent on the frame where the gameover is confirmed, the inputs pressed 3 frames before confirmation and the number of characters in the party.

After the 51 gameover,contains. At the 52nd gameover, the game writes the event pointer to(first call to event B2) then to(second call to event B2). Before the game executes event FE, the values inhave changed and contains the some scanline location coordinates. The game loads those values as the current event pointer, and executes events starting this location. This is what is causing the glitch.

The event pointer stack is stored startingand the size of the stack is stored inand(backup). The memory after this stack is largely unused, the only addresses that are often written by the game are located at. The game repeatedly stores intothe horizontal scanline location, intothe vertical scanline location and intothe maximum of allvalues. We are not sure if these values are actually used by the game.

During a gameover screen, however, the game calls event B2 twice but only once event FE. This has the consequence of filling the event pointer stack, which can lead to a stack overflow with repeating gameovers. This is generally unnoticed, because entering any inside map (towns or dungeons) will clear the event pointer stack.

In this game, the developers have implemented a script language for scripted events, which contains everything from music, graphical effects, invoking windows, dialogues, character movements, etc. Two events in this game have a behaviour very close to the JSR and RTS assembly instructions. The first one (event B2) saves the pointer to the current event into a stack and starts executing a series of sub events. The second one (event FE) finishes the series of sub events by loading the event pointer from the top of the stack. Every call to event B2 is meant to be eventually followed by a call to event FE.

$CA0F70

$CA134E

To trigger the game ending, one way is to set the event pointer to the address of the ending, which is located at(just after the boss fight). However, the game will freeze if we jump there because it will try to move characters which are not present. Pointing after the post-Kefka dialogues does work, which was done in the present TAS (address).

$0630-$0632

$0630-$0632

$1700

$2000

As expected, no value ofcomes near the values required to launch the ending sequence. Luckily, most of the values inactually point to RAM addresses, betweenand. Here is a summary of what is present in these addresses:

$1600-$184F: Character data (592 bytes, 37 bytes each character) $1850-$185F: Setup of current party (which party/slot/row for each character) $1860-$1862: Gold $1863-$1865: Game time $1866-$1868: Steps $1869-$1968: Items possessed $1969-$1A68: Item quantities $1A69-$1D4C: Espers, Magic, SwdTechs, Blitz, Lores, Rages, Dances $1D4D-$1DC6: Menu configuration $1DC7-$1FFF: Various stuff

B2 4E 13 00

$CA0000 + $00134E = $CA134E

$0630-$0632

1 character: $1700-$1900

2 characters: $1900-$1B00

3 characters: $1B00-$1D00

4 characters: $1D00-$1FFF

Our goal is to write somewhere in RAM an event that will jump to the ending. A few events can do that: B2, B3, B6, B7, BD, BE, C0-CF, following by the destination address (e.g.jumps to). The values insideheavily depend on the number of characters in the party. Here is roughly which address we have access:

The earliest point where we can trigger the glitch is with a party of two characters. With this party, we can jump to the addresses storing the inventory, the Espers and magics. The problem is that we cannot write any of the jumping events above in memory because no item with the corresponding id is available, and we are limited to 99 for item quantities. Of course, we don't have any Esper or magic available.

XX 13 00

$1D4D

Then, for a very small time, we have access to a 1 character party (solo Terra) during Figaro castle. With this party, we can jump to part of the character data, gold, game time, steps and part of the inventory. Character data would have been very encouraging, but the only characters we can control are Terra and Locke, which are at the beginning of the section, outside our range. Like before, we cannot write the event code using the inventory, but we can use either one byte of the Gold or one byte of the step counter easily. The second problem was to write the destination address in RAM next to the event code, which is of the formwith XX being several values possible between 0x20 and 0x70. We couldn't manage to write these values, however we could make an intermediate jump to a much more friendly area in RAM where we can control values: the config menu. It is located startingand luckily, we have access to the Mithril Pike (id 1D), the Buckler (id 5A) and the Mithril Shield (id 5C).

Here is the state of the memory starting $1860:

| Gold | Game Time | Step counter | Inventory | A0 | xx | xx | xx | xx | xx | C1 | xx | xx | 01 | 00 | 5A | 1D | 5C | Mithril | Dirk | Buckler | Mithril | Mithril | Knife | | | Pike | Shield |

We tried to jump directly to the step counter, but we only could jump to the Gold address. That is why we manipulated the first byte of the Gold value to be A0 (by selling stuff), an event which takes 5 bytes as argument, so that we arrive at the beginning of the step counter.

$CA0000+addr

$CA0000 + $5C1D5A = $261D5A

$1D5A

Event C1 has 3 arguments: t1 (2 bytes), t2 (2 bytes) and addr (3 bytes). The meaning of this event is: if the story bit t1 or the story bit t2 is true, then jump to. We manipulated t2 with the MithrilKnife and the Dirk so that the corresponding story bit is true. So the game jumps at, which is the RAM address, in the middle of the colours of the windows.

5B is a no argument event that does (almost) nothing. We couldn't write B2 on the first byte because the way the colours are stored implied that every other value must be below 7E.

is a no argument event that does (almost) nothing. We couldn't write on the first byte because the way the colours are stored implied that every other value must be below 7E. B2 00 53 00 jumps to address $CA0000 + $005300 = $CA5300 . This is the very end of the world destruction sequence that loads the World of Ruin maps. It was necessary to avoid a softlock during the game ending.

jumps to address . This is the very end of the world destruction sequence that loads the World of Ruin maps. It was necessary to avoid a softlock during the game ending. A9 triggers the game opening, because why not.

triggers the game opening, because why not. 5C is another dummy event like 5B

is another dummy event like B2 4E 13 00 jumps to address $CA0000 + $00134E = $CA134E . This triggers the ending sequence.

Now we have full control over the events we can trigger. We previously changed the value of those colours so that the bytes starting $1D5A are: