The Glitchhouse · Pokemon Red, Blue and Yellow

Super Glitch: the move with no name

Most glitches ask the game to read a number it should not. This one asks it to read a name that was never written, and the game keeps reading until something stops it.

Decoded from a Pokemon Red ROM · part of The Glitchhouse

Every move in Pokemon Red and Blue has a name, and the game prints it in battle with a simple copy: start at the move's name, copy letters until you reach the end marker, stop. There are 165 real moves, and the 165th, Struggle, is the last one with a name. The move IDs just past it point into empty space. Ask the game to announce one of those, and the copy starts reading where the names run out, taking whatever happens to be in memory as letters, and it does not stop until it stumbles onto an end marker somewhere in the machine. That runaway copy is Super Glitch.

Where the moves run out

The game keeps its move names in one long list, 165 of them, in order. Every real move points at a name in that list. Turn the dial and watch the list end: number 165 is Struggle, the last move with a name, and everything past it is the Super Glitch band, IDs that point at nothing.

Move IDs 1 to 165 are real moves, read straight from the game's name list. 166 through 195, hex $A6 to $C3, are the Super Glitch band: valid move IDs with no name behind them. Ask the game to print one and the name copy runs off the end of the list.

Why a name with no name corrupts

To print a move's name, the game does not jump straight to it. It starts at the top of the name list and walks forward, counting end markers, until it has counted as many as the move's ID. Then it copies from there. For a real move that lands on a real name. For a nameless one, the count runs off the end of the list and keeps going into raw memory. Pick a move and watch the search.

MOVE NAME LIST · 1 to 165
UNMAPPED MEMORY
end markers counted: 0target: 163
The search counts end markers, the "@" byte ($50), from the top of the list. A real move ID lands inside the 165 names. A Super Glitch ID counts right past the last name and stops somewhere in memory, and whatever bytes sit there become the move's name.

Copy until you hit a marker

Once the game has a pointer to the "name", it prints it the only way it knows: copy one byte, then the next, and stop when you reach an end marker. A real name reaches its marker in a few letters and fits the box. A name made of raw memory might not have a marker for a long time, so the copy keeps writing, straight past the box and into whatever the game was keeping there. Roll a nameless move and watch how far the copy runs.

bytes written: 0the box holds 12
The copy stops only when it reads the end marker, the "@" byte ($50). Everything written past the twelfth cell has overflowed the name's space in memory. In a real game that spill lands on live data, which is the corruption Super Glitch is known for. The bytes here are random each roll, exactly the point: the length is never the same twice.

Steering the wreck

Left alone, Super Glitch is chaos. What turned it into a tool is that the runaway copy still stops at an end marker, and the marker can be a tile sitting on the screen. That is not a coincidence: the bytes Super Glitch writes are lifted from a full-screen snapshot the game keeps in memory, so what is on your screen literally becomes the corruption, and a "@" tile you position becomes its stop. Players learned to open a menu, the Pokedex, Pokemon, or Item list, at the moment a "@" tile lands in the right spot, so the redraw writes corruption only up to that tile and no further. Move the marker and choose how far the damage reaches.

Tap a tile to place the "@" stop marker, then open a menu.
The redraw copies tiles in reading order and halts when it reaches the "@" marker ($50). Everything before it is overwritten, everything after is spared, so the marker's position is a dial on how much memory the glitch rewrites. The values themselves are lifted from a screen-copy buffer at $CD6D and written into the moveset buffer at $D0E1 (or $CF4B when the move is used in battle), which is exactly why arranging the screen arranges the damage. This whole controlled-Super-Glitch technique was mapped by TheZzazzGlitch.

The names it does give

So does a nameless move ever show a name? Sometimes, yes, and it exposes a second bug. The routine that fetches a move's name checks whether the ID is high enough to be a TM or HM item first, and because of a mistake in the code that check catches high move IDs too. So the deep end of the Super Glitch band does not read garbage at all: the game hands it a clean machine name. Slide across the whole range and watch a move go from having no name, to being called a TM.

Move IDs 166 to 195 ($A6–$C3) have no name and no end marker nearby, so printing them is the runaway corruption above. But 196 and up cross a threshold the game reserves for TM and HM items, and a real bug in GetName applies that threshold to moves too, so $C4–$C8 print as HM01–HM05 and $C9–$FF print as TM01–TM55. Same nameless move slot, two completely different outcomes. Verified in home/names2.asm.

Meet a specimen

A move is just six bytes: an animation, an effect, a power, a type, an accuracy, and its PP. A real move points at six real bytes in the move table. A Super Glitch move's ID lands past the end of that table, so those six bytes are whatever memory happens to sit there. Line a real one up next to a nameless one.

Every field of a real move is defined in data/moves/moves.asm. For a Super Glitch move, the same six-byte slot is read from past the table, so the power, type, accuracy and effect are memory, not design. Using one runs whatever effect code those bytes happen to name, which is how a single move can freeze a battle or kick off the corruption.

Does it still work

Super Glitch is a bug in the 1996 code, so wherever that code runs, the bug runs with it. The one thing to know: unlike catching a Mew, there is nothing here to keep. This is a memory hazard, not a collectible, and its favorite trick is eating your save.

The nameless moves live in the same ROM everywhere it is sold, so the overflow is present on cartridge, on the 3DS re-release, and in every emulator. What changes is only your safety net: save states and restore points let you poke at it and undo the damage.

From the ROM

The whole page rests on one line of the game's source: the last real move is number 165. Here is the end of the move list from constants/move_constants.asm. Tap a move to read its number, and watch the list stop at Struggle.

Struggle is move $A5, decimal 165, and the game defines NUM_ATTACKS as exactly that. Every ID above it, $A6 and up, has no constant and no name. That is the entire seed of Super Glitch, straight from the source.
; constants/move_constants.asm
    const SUBSTITUTE   ; a4
    const STRUGGLE     ; a5
DEF NUM_ATTACKS EQU const_value - 1   ; = 165

; data/moves/names.asm
    ; in-battle "used <move name>!" text can only fit 12 characters

The family it belongs to

Super Glitch is one member of a family, and they all share a single idea: the game reads memory it was never meant to read, and treats whatever it finds as real. Move names here, species numbers next door, your own name down the hall. Pick a relative.

Every one of these is the same trick pointed at a different table: moves, species, or names. Learn one and the rest click into place, which is exactly why they are gathered in the Glitchhouse.

Go deeper: the Gen 1 battle engine | the Name Glitch tool | browse the Glitchhouse.

This page is being built section by section, each one an interactive piece decoded from the ROM. The byte-by-byte overflow, the controlled corruption, and the rest are on the way. The glitch is decades of documentation by the Pokemon glitch community; what we add is the view from the cartridge.

Go deeper: arbitrary code execution | the Mew glitch | browse the Glitchhouse.