Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation I Glitch Discussion

Cause of Special Menu Select glitches (JP) - Page 1

Cause of Special Menu Select glitches (JP)

Posted by: Stackout
Date: 2017-09-01 21:19:45
Couldn't get to sleep, so why not look into the cause of a glitch that hasn't been documented very well?
I used luckytyphlosion's pokered-jp disassembly (a fork of pokered that aims to be a disasm of JP R/G) to help me.

This glitch is caused entirely by the HandleItemListSwapping function. As you can probably see by the helpful comments, the direct cause is the wrong conditional jump was used, and the jump back to the item menu loop happens when carry flag is set, instead of when zero flag is not.

The function can only handle item swapping, and special item lists are just lists of item indices, without quantities.
So, swapping items 1 and 2 cause items 1 and 2 to be swapped with 3 and 4, as items 1 and 2 are interpreted as item+quantity of item 1, and items 3 and 4 as item+quantity of item 2.

Going by the sets of swaps in the wiki article, the last swap swaps items 7 and 8, that is, bytes 14-15 and 16-17. These bytes are located after the FF array terminator. The buffer in WRAM where the item list is located is in fact only 16 bytes long (and the first byte is the list quantity). Directly after this buffer is a pointer to the item list itself, so this pointer is swapped with some undefined data beyond the list terminator but still within the buffer.

I have not yet determined why this causes corruptions to other parts of memory.

Re: Cause of Special Menu Select glitches (JP)

Posted by: Torchickens
Date: 2017-09-02 06:47:23

Couldn't get to sleep, so why not look into the cause of a glitch that hasn't been documented very well?
I used luckytyphlosion's pokered-jp disassembly (a fork of pokered that aims to be a disasm of JP R/G) to help me.

This glitch is caused entirely by the HandleItemListSwapping function. As you can probably see by the helpful comments, the direct cause is the wrong conditional jump was used, and the jump back to the item menu loop happens when carry flag is set, instead of when zero flag is not.

The function can only handle item swapping, and special item lists are just lists of item indices, without quantities.
So, swapping items 1 and 2 cause items 1 and 2 to be swapped with 3 and 4, as items 1 and 2 are interpreted as item+quantity of item 1, and items 3 and 4 as item+quantity of item 2.

Going by the sets of swaps in the wiki article, the last swap swaps items 7 and 8, that is, bytes 14-15 and 16-17. These bytes are located after the FF array terminator. The buffer in WRAM where the item list is located is in fact only 16 bytes long (and the first byte is the list quantity). Directly after this buffer is a pointer to the item list itself, so this pointer is swapped with some undefined data beyond the list terminator but still within the buffer.

I have not yet determined why this causes corruptions to other parts of memory.


Nice research Wack0. Thanks! :)

I recently did some other research about this on another thread (http://forums.glitchcity.info/index.php?topic=7984.msg205778#msg205778) and came to similar conclusions; swapping an entry switches pairs of bytes as if they were item/quantity pairs even though the list is displayed as item-item-item, and it is possible to change the list location pointer (including the number of entries on the list) that way illustrated in the thread.

I didn't look into why a Super-Glitch-esque effect can occur though.

Re: Cause of Special Menu Select glitches (JP)

Posted by: Stackout
Date: 2017-09-02 08:48:20

I didn't look into why a Super-Glitch-esque effect can occur though.


I just tried looking into it, but couldn't figure it out from static analysis alone. I guess some work in the debugger would be required.

I guess it depends on what ends up in wListPointer? The wiki page does say the effects don't happen every time.