Corrupt-a-Mon

Every Pokemon in Red and Blue is stored squashed, and the Game Boy rebuilds it from a pile of compressed bits every single time one shows up. This page runs that exact rebuild, ported from the game's own code, then lets you sabotage it the five ways real glitches do. Pick a Pokemon, hit Corrupt it, and keep whatever crawls out!

How does a whole Pokemon fit in a few hundred bytes?

Sprites are the quiet miracle of this cartridge. The 151 front sprites in Pokemon Red take up 56,044 bytes all together, where the same pictures stored as plain Game Boy tiles would need 89,968. (Pikachu is 270 bytes, Magnemite is the smallest at 134, and Slowbro is the biggest at 637, which honestly feels right.) The trick is that the game never stores a picture at all. It stores instructions for drawing one, and a routine the pokered disassembly calls UncompressSpriteData follows them to the letter, in this order:

1. The size byte. The very first byte holds the width in its top four bits and the height in its bottom four, counted in 8 by 8 pixel tiles, so 0x55 means 5 tiles by 5. Every real front sprite is 5 by 5 (48 of them), 6 by 6 (48) or 7 by 7 (55), because 7 by 7 tiles is all the room the battle screen gives a Pokemon.
2. Two one-bit layers. A Game Boy pixel is one of four shades, which takes two bits, so each sprite is stored as two black and white layers that get stacked at the end. The bit right after the size byte says which of the game's two sprite buffers receives the first layer, and the buffer decides whether that layer becomes the light bit or the dark bit of every pixel.
3. Runs of nothing. Each layer is written as pairs of bits, top to bottom, one tile column at a time. Most of a sprite is empty background, so long stretches of empty pairs get squeezed into a single run-length number instead of being spelled out.
4. The mode. Between the two layers sit one or two bits for the decode mode. Mode 0 delta decodes both layers, mode 1 delta decodes the first layer and XORs it into the second, and mode 2 delta decodes both and then XORs. (Fun fact: not one of the 151 front sprites uses mode 0. 74 use mode 1 and 77 use mode 2.)
5. Delta decoding. The layers are stored as changes rather than pixels, reading left to right along each row, where a 1 means "different from the pixel before" and a 0 means "same as before". A big solid body turns into mostly zeros that way, and zeros are exactly what the run-length step loves.

Last of all, a routine in home/pics.asm centers the finished picture in a 7 by 7 tile window, flush with the bottom, and hands it to the screen. The tool's battle screen view runs that step too, which matters a LOT once the size byte starts lying.

What does each corruption actually do?

1. Flipped bits. The compressed stream has no checksum and nothing to resync on, so one wrong bit changes how every bit after it gets read. That is why a single flip can leave the top of a sprite perfect and turn everything after it into static. Gen 1 is full of single bits landing where they should not (MissingNo.'s famous item trick is one Pokedex bit landing on your bag), and this is what one of those does to a picture.

2. A wrong size byte. The decoder trusts the size byte completely. Tell it a 5 by 5 Pokemon is 9 by 3 and it lays the exact same bits out on a 9 by 3 grid, so every column starts in the wrong place and the picture comes out sheared into stripes. The game actually keeps two copies of this byte, one at the front of the sprite data (the decoder reads that one) and one in the Pokemon's base stats (the screen routine reads that one to center the picture), and the tool lets you break either or both. Anything bigger than 7 by 7 no longer fits in the game's 392 byte sprite buffers, so the Sprite RAM line tells you how far it spilled, and in the cartridge's save RAM the Hall of Fame record sits just past those buffers, with a 256 byte gap in between.

3. Bitplanes. Swap the two layers and the light gray and the dark gray trade places while black and white stay put (an early version of this site's own decoder made exactly this mistake). Drop a layer and four shades collapse to two. The swap works the honest way, by flipping the one layer-order bit in the stream, and the drop wipes one of the two buffers after decoding.

4. A wrong pointer. Every Pokemon's base stats hold a two byte pointer to where its sprite data starts, and glitch Pokemon read that pointer from bytes that were never meant to be one (MissingNo.'s points into data that is not a sprite at all). Nudge the pointer and the decoder reads a random byte as the size, a random bit as the layer order, and somebody else's instructions as the picture. Push it forward and you run into the next Pokemon's data, pull it back and you start inside the previous one. Glitch Pokemon like ゥ .4 get their whole look this way, with a size byte that describes a sliver instead of a creature.

5. A wrong decode mode. The mode bits get parked in a RAM variable (wSpriteUnpackMode) until both layers are unpacked, and if that value is wrong, perfectly good data gets rebuilt the wrong way. Skip a delta pass that should happen and that layer comes out as bare outlines, just the spots where pixels change (try Charmander in mode 1). Add a delta pass that should not happen and every edge becomes a switch that stays flipped until the next edge, so the layer smears into sideways streaks (try Pikachu in mode 0).

Why does MissingNo. look the way it does?

Now for the famous one. When you meet MissingNo., the game reads its base stats from a slot that holds no real Pokemon, and the size byte it finds there is 0x88, a claim of 8 by 8 tiles for a window that only holds 7 by 7. (The full autopsy is on the MissingNo. page.) The centering math in home/pics.asm works out the starting spot with single byte arithmetic, and on a Game Boy 7 minus 8 does not go negative, it wraps around to 255. So the copy starts partway through the window instead of in the top corner, each column runs one tile taller than the window, and every column spills into the next one. Load any Pokemon, set the size byte to 8 by 8 in both copies, and watch the battle screen view shear!

Is this really the game's decoder?

Yes, line by line. The engine on this page is a port of UncompressSpriteData and its helpers from home/uncompress.asm, plus the centering and interlacing from home/pics.asm, both from the pokered disassembly, running on a model of the cartridge's sprite RAM so that broken input breaks the same way. The 151 compressed front sprites are embedded straight from a Red cartridge, each one cut to exactly the bytes the decoder reads, and an automated test decodes all 151 and matches the disassembly's own master artwork, pixel for pixel, on both screens. That test caught something fun, too: six Pokemon (Rattata, Spearow, Nidoran♀︎, Zubat, Geodude and Omanyte) store their layers in the opposite order from the other 145, so a decoder that ignores the layer-order bit gets their grays backwards!

A few honest notes about where this page has to stand in for the cartridge:

• Past the end of a Pokemon's own data, the page keeps reading the next Pokemon in Pokedex order. In the real cartridge a front sprite is followed by that same Pokemon's back sprite, and the sprites are grouped in the game's internal index order, which this page does not carry.
• Memory outside the three sprite buffers starts out empty here. On a real cartridge it holds whatever was there before.
• A run-length field with more than 15 ones in a row makes the real decoder read its length table past the end and into its own code. This page continues the table's pattern instead. Only badly wrecked data ever gets that far.
• The wreckage cry uses the three bytes right after the size byte, played through the same Gen 1 cry engine as the Cry Synth. The game only has 38 base cries, 0x00 to 0x25, so this page folds the first byte into them (the remainder after dividing by 38) and uses the other two as the pitch and length. The fold is this page's own rule: the cartridge never plays a picture as a cry.

Your homework: find the smallest corruption that makes a Pokemon completely unrecognizable, then send it to a friend with the share link and make them guess who it used to be. Every glitch Pokemon the real games produce has its own page in the Glitchhouse, and if you make something truly cursed, tell me about it on the contact page. Toodles!