Party scrolling memory corruption: Difference between revisions

← Older edit

Party scrolling memory corruption (view source)

Revision as of 13:00, 5 December 2021

499 bytes removed , 2 years ago

no edit summary

VisualWikitext

Anonymous user

glitchcitywiki>Evie (Torchickens)

Revision as of 17:54, 11 November 2021 (view source) glitchcitywiki>Evie (Torchickens) (→‎HRAM manipulation) ← Older edit		Latest revision as of 13:00, 5 December 2021 (view source) glitchcitywiki>Evie (Torchickens) No edit summary
(9 intermediate revisions by the same user not shown)
Line 1: '''Party scrolling memory corruption''' is a glitch in {{RGBY}} documented by TheZZAZZGlitch (and Evie for the ~~HRAM~~cursor ~~modification~~tile ~~method~~corruption). Note it may function differently in the Japanese versions.{{clarify}} If the player does not want to use the [[expanded party]], they can try the method described in [[no expanded party international Select glitching]] (currently allows for Pokémon 235-) even if the player doesn't have over 6 Pokémon, but without swapping the Pokémon. ==Description== Using this glitch, simply leaving the cursor on a Pokémon beyond slot 6 will attempt to animate its menu sprite and corrupt memory addresses; making it a useful application to change a good portion of RAM addresses, and potentially aid in setting up applied glitches (such as changing the moves of a party Pokémon). The Pokémon will animate at a certain rate (perhaps depending on how much HP it has). Every time the Pokémon animates, the memory address representing its tile number will increase by 0x40 with respect to exceeding 0xFF will loop the value back to 0x00; so athree ~~memory~~different ~~corruption~~ ~~+0x40~~corruptions ~~(one~~of ~~corruption)~~the ororiginal ~~+0x80~~are possible (~~two~~+0x40, ~~corruptions)~~+0x80 or ~~-0x40 (three corruptions~~+0xC0) ofmodulo ~~the original is possible~~256 depending on when the player chose to exit the selected Pokémon. If the desired memory address to corrupt is far away, the player can choose to scroll quickly to try not to corrupt memory addresses before it. Line 175 ⟶ 177: #CCDX #CCEX #CCFX ~~#C#CFX~~ #CD0X ~~#C#D0X~~ #CD1X ~~#C#D1X~~ #CD2X ~~#C#D2X~~ #CD3X #CD4X Line 273 ⟶ 275: #D2FX ==Placement of the cursor tile== ~~==HRAM manipulation==~~ {{incomplete}} ~~{{Researchneeded\|1=More technical specifics}}~~ The game writes 0xED to C3B4 (slot 1), C3DC (slot 2), C404 (slot 3), C42C (slot 4), C454 (slot 5) and C47C (slot 6). Slots beyond slot 6 continue in this pattern (address +0x28) each time. Altering the glitch by altering FF81 in HRAM (currently, the only ways known to do this are with [[arbitrary code execution]] and possibly [[connection copier]]) will corrupt the memory in a different way relative to the new upper address in the memory (which was previously C3). If for instance, the OAM DMA buffer starts at C4XX, the first Pokémon may touch C3B4, the second C3DC, the third C404, the fourth C42C, the fifth C454 and the sixth C47C; which allows altering memory addresses later before, hence from this relationship of +0x28 for the next Pokémon, C3B4+(0x28*[n-1])=the address to corrupt where n is the desired Pokémon slot, or (address/0x28)}-(C3B3/0x28) is used to locate the cursor position the player was on (or needs to be on) before the corruption. {{~~clear~~clr}}▼ ~~Details however are relative to the upper address chosen, and this same logic might not work for ones different to C4XX.~~ ▲{{clear}} {{stub}} [[Category:Generation I glitches]]