Expanded party: Difference between revisions
m
Consistent use of uppercase hex
m (Fixed formatting in table in Memory Corruption Pattern section) |
m (Consistent use of uppercase hex) |
||
Line 588:
The memory corruption caused by healing with an expanded party is sparse, but can affect a large diversity of memory locations, depending on how soon the 0xFF terminator byte is found.
For each non-0xFF byte found in the party Pokémon species list, the party healing routine traverses the party Pokémon records beginning at 0xD16B (for {{RB}}), 0xD16A (for {{Y}}), 0xD12B (for {{RG}}). Each record is 44 (
{| class="wikitable"
|+
Line 605:
|Overwritten with the value 0
|-
|'''
|PP for moves
(<code>wPartyMon#PP</code>)
|Lower 6 bits are overwritten with max PP value determined from move ID read from offsets '''0x08''', '''0x09''', '''
'''NOTE:''' If one of the move IDs read is 0, nothing is overwritten for the current offset and the later offsets are skipped, since the game assumes the move list to be terminated.
|}
To calculate the addresses manipulated when healing a certain party slot, multiply the zero-based index of the slot by the size of the Pokémon record (
Since the healing routine uses 16-bit pointers to traverse the memory and only looks for a 0xFF terminator byte to stop execution, it can potentially corrupt memory past the end of the expanded party region (that is, beyond the 256th party Pokémon record) and reach I/O registers and [[HRAM]]. This has been confirmed with an oversized expanded party obtained via memory hacking and using a debugger. <!-- I tested it myself. The game crashed at some point though, just barely touched the beginning of HRAM, but it did get there. Might have been the VBlank interrupt triggering and getting messed up, I was using breakpoints on every loop iteration of the HealParty routine. ~~~~Kagamiin~ -->
| |||