Chaotic glitches

From Glitch City Wiki
Jump to navigation Jump to search

A chaotic glitch describes the effects of a glitch very sensitive to initial conditions (comparable to the chaos theory in science), or where many factors (such as the contents of many often not typically related memory addresses), or hardware specific details are involved.

Certain glitches will have more sensitive outcomes than others, for example, the possible encounters from the old man glitch encounters will depend on the letters of the player's name, compared with the internal name of the - (CoolTrainer♀-type) glitch move; which has a higher degree of 'randomness' and influenced by the layout and frequency of 0x50 terminated strings in the memory map.

The glitch may also work differently in an inaccurate emulator where specific hardware details are involved (such as internal hardware timing, invalid opcodes (including invalid stop codes), VRAM inaccessibility, Echo RAM, invalid banks).

Another glitch may involve something physical, such as the effects of pulling out the Game Pak while the power is on, a Game Pak with a fault such as a broken memory bank controller, or noise over the serial I/O port.

List

This section is incomplete, please feel free to add any missing information about the subject. It is missing: {{{1}}}.
  • - (CoolTrainer♀-type)'s internal name (as accessed by the buffer and displayed by PP restoring items) has a degree of 'randomness' and is influenced by the layout and frequency of 0x50 terminated strings in the memory map. The reason for this is because the game searches for name strings beginning with 0x50, but for glitch moves this search can extend past the end of the ROM bank (4000-7FFF).
    • This also applies to Super Glitch moves from 0xA7 onward (note 0xA6 always has over 20 characters in its name; causing the buffer overflow effect - later glitch move names are expected to land in areas of RAM with seemingly random names), however on older versions of VisualBoyAdvance, glitch move 0xA7's name will typically always be "qq" due to incorrect emulation of VRAM inaccessibility and the E0 E0 50 bytes at 0x83C5. VRAM, SRAM and WRAM are the start of non-ROM regions that can be searched (in that order).[1]
  • In Pokémon and Green, item 0x00 has a seemingly random name as well, but research is currently incomplete.
  • Arbitrary code execution will typically run a region of RAM as code; for this reason, changing one byte will change an entire opcode or operand; the effects can be very different, and can be affected by lots of seemingly unrelated factors other than them being variables in the RAM (anything from for instance Pokémon, to items, to play time, to states or movements on the overworld can be included as a requirement for the code). Additionally, the structure of the memory map is not necessarily organised for the player (for example, while inventory structures for the item and quantities (D31E-D346 (-1 in Yellow) go on in a continuous order, some data pertaining to various parts of the game is located further on (D347+), and Pokédex flags further back (D2F7-D31C (-1 in Yellow). The program counter can also attempt to run Echo RAM, HRAM (hardware RAM such as the zero page and I/O registers), SRAM, VRAM. For unintended ROM code execution, the game will also have no way of distinguishing data from code.
    • The combination of a glitch that corrupts SRAM and the use of B1F is known for its hard to predict effects.
    • Pokémon Yellow C109 ID 0x0F arbitrary code execution runs DA41 but this is first influenced by wPlayTimeMaxed, followed by wPlayTimeMinutes, wPlayTimeSeconds; meaning a specific play-time is required.
  • Glitch item Q;MP- (0x72) in Pokémon Yellow (may also not always freeze the game).
  • The effects of nudging, tilting, or pulling out the Game Pak while the power is on are known for their 'randomness', but most of the time freeze the game.
  • Glitches which do not execute code from Echo RAM but access it (example: dokokashira door glitch).
  • Glitches relying on specific hardware or CPU timing (example: Viridian Forest 0xF8FF glitch).
  • SRAM corruption from glitch Pokémon sprites involves the sprite decompression subroutines and results in data this is difficult to predict.
    • The effects of encountering non-fossil/ghost MissingNo. in Pokémon Yellow, also known to have been inaccurately emulated by VisualBoyAdvance (see also: stable unstable MissingNo.; a technique exploiting clearing the SRAM with Up+Select+B first, before encountering a MissingNo. or performing any glitch which corrupts the SRAM).
  • Glitches relying on a frame/'sub-frame' not accounted for by the emulator.
  • Bad clone glitch and the 'Celebi glitches' such as Celebi Egg glitch (party method) if the alteration of the cloning glitch is used (known to be easier in Pokémon Stadium 2).
  • The OAM corruption glitch (if not properly emulated).

See also

References

This article or section is a stub. You can help Glitch City Wiki by expanding it.