Tile Chaos describes a glitch effect in Pokémon Red, Blue, and Yellow, where tiles fill the screen and possibly animate.
Tile Chaos can be caused by glitch moves, glitch items, and Poké Balls when the value of D057 (otherwise the equivalent wIsInBattle value) is greater than 02.
Tile Chaos effects started by glitch moves are often caused by a glitch animation.
From glitch items
Tile Chaos in Pokémon Red and Blue can be set up by an unterminated name glitch item by having a Poké Ball at the top of the items list page, pressing A on the unterminated name glitch item where a 0x50 sub-tile (or 0x50 byte) is after the coordinate that affects D057, and backing out with B.
This effect may also be accompanied by The Hooked Metapod in non-Japanese versions (or possible other hooked Pokémon in Japanese versions) from the corrupted of both $D059 (wCurOpponent) and $D05F (hooked Pokémon).
In v1.1 and up releases of Japanese Pokémon Yellow, Tile Chaos can also be caused by (variable name) (hex:7C).
From glitch moves
The glitch moves (variable name) (0xB8) (Red/Blue) and (variable name) (0xB8) (Yellow) in Pokémon Red, Blue, and Yellow have an effect that causes Tile Chaos, if Super Glitch does not occur.
Another example of a Tile Chaos causing glitch move is "わざマシン５３" (TM53) from Pokémon Red and Green.
On glitch moves (at 6:11)
Invalid 0xD057 value Tile Chaos:
RST 38 offered the following explanation regarding Tile Chaos on the forums.
The animation system in Gen I games is based on command streams, a specialized assembly if you would like. Every command is either: a special effect(executes some assembly code according to the search table, very likely to crash on glitch animations, or ACE) a subanimation(renders some frame blocks, this is likely what causes the 'Tile Chaos' effect)
Frame blocks are the stuff that build complex animations, an array of... not tiles, but gameboy sprites actually. So you might ask: Then why does the entire screen gets flooded with garbage, intead of just a few glitchy sprites floating around? Well, remember that buffer overflows don't exist to GameFreak, so the DrawFrameBlock writes past OAM buffer and into the screen data.
Why does it happen when modifying D057 then?
It seems like some code responsible for preparing PokeBall throw animation, doesn't properly initialize address D11E(wPokeBallAnimData in disassembly). This address determines two things: the number of animations(4 if caught, 6 if not) in its high nybble + the number of shakes in its low nybble.
The high nybble ends up being zero. And we all know that having zero as a loop counter right from the start in Gen I is not a good thing... So, the TossBallAnimation function has an animation array that it iterates through and plays in this loop.
Its contents: Poof Effect, Hide Mon Sprite, Shake, Poof on break, Show Mon Sprite (later two if not caught, throw animation depends on ball type)
After it done iterating through this array, counter still has 250 animations! Interpreting unrelated data as animation IDs doesn't end well, causing this effect.