View source for Glitch City RAM manipulation (buffer overflow techniques)

Combining the data of a [[Glitch City]] sourced from RAM with a buffer overflow technique that depends on the contents of the screen (or a related screen buffer) allows the player to have more control over the desired corruption; because the RAM is not fixed and is writable during gameplay.

For example, a form of Glitch City RAM manipulation is used during [[oobLG]]. In Yellow, this is with the help of [[ItemDex/Y:091|6F]] (a screen-saving glitch item), a Glitch City ([[Expanded bag item documentation (Generation I)|with manipulation of the top-left block pointer D35E/D36F to a RAM pointer]]) and an [[Unterminated name Pokémon (Generation I)|unterminated name Pokémon]]. For one method in Yellow, bag item 14's quantity becomes the Pokémon encounter. In the [[blockoobLG]] it is the quantity of item 23 that defines a block on the screen; based on the sub-tiles of the block, and the contents of y=0C, x=0A defines the Pokémon in the screen buffer.

Though Glitch City RAM manipulation has its benefits, there may still be some limitations. 

*For corruptions where a [[0x50 sub-tile]] (interpreted as the 0x50 end control character) is needed to end a corruption, it means there cannot be corruptions where 0x50 is in the middle. (many such as the above oobLG, as well as simpler buffer overflow techniques such as [[Move 0x00 corruption (Generation I)|CoolTrainer♀]] or [[LOL glitch]] (based on [[unterminated name glitch item]] abuse)).
*When using the contents of the screen to print text. For example, the [[Rival LOL glitch]] requires the 0x53 sub-tile which prints the Rival's name (from RAM D34A-D351 (-1 in Yellow)) on the screen to be saved later with a screen saving glitch item. However, control characters in the Rival's name (such as control characters more than one tile long, line break characters, text from another RAM address) will interfere with the required sub-tile.
**Similarly, this applies for any unterminated name glitch items which print tiles depending on the contents of the screen (tile-writing glitch items).
*For corruptions from VRAM, [[VRAM inaccessibility]] may apply resulting in reads of 0xFF but this may be beneficial for corruptions such as [[ZZAZZ glitch]] Trainer encounters<!--(e.g. [[Unterminated fly destinations]])-->.
*For corruptions from SRAM, the pointer in SRAM may be locked or restricted to the current bank. (e.g. [[Dex dump glitch]])

==Types of screen tile corruptions (Glitch Cities)==
Sometimes these can be combined (for example, the first two can be combined with a screen saving glitch item)

*Manipulation of D35E/D36F (top-left block pointer) to print a limited number of desired sub-tiles for CD6D>CF4B buffer-based abuse.
**In [[Super Glitch (Generation I)|Super Glitch]], this is also both CD6D>CF4B buffer-based abuse CD6D>D0E1 buffer-based abuse, taking the lengths of moves from the fight menu into account.
*Exploiting the routine to print text (e.g. in glitch item names with control characters, and unterminated name glitch items)
*Creating [[Super Glitch City|Super Glitch Cities]] (more complex Glitch Cities with glitch tilesets, including tileset data from RAM) for any desired sub-tile, however the control character limitations may apply.
*Using another glitch for direct manipulation of the VRAM (see [[direct VRAM manipulation]]), then applying it to a compatible buffer overflow technique (e.g. [[Text pointer manipulation mart buffer overflow glitch|LWA]]). This subject can also overlap with [[arbitrary RAM modification]]). The control character limitations may not apply.<!--I think there are non-LWA non-ACE and non-ARM methods, but need to research this more-->
[[Category:Generation I glitches]]
[[Category:Terminology]]