Re: My idea of me documenting all Pokédex entires of 0xDC
Posted by: Parzival
Date: 2019-09-12 17:28:08
Breakpoints are only possible with a debugger. Like BGB's.
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this:
; string: species name
; height in feet, inches
; weight in pounds
; text entry
RhydonDexEntry:
db "DRILL@"
db 6,3
dw 2650
TX_FAR _RhydonDexEntry
db "@"
Here "DRILL" means Rhydon is the Drill Pokémon. This string is the first to be printed to the screen, and with good reason: The game need to know where that string ends in order to find all the other data.
Consider a Pokédex entry at $AA00. Contrary to what I initially believed, the SRAM is actually unlocked during the battle. It is locked when the game finished loading the player's back sprite, but is then unlocked when the game loaded the back sprite of my first Pokémon and never locked again. I can't tell if this is intentional.
Well, on my save file for testing, SRA0:AA00 is a bunch of 0xFF anyway. (Probably because I have cleared the save file some time in the past.) Which is an awfully long string of "9". More "9"s than healthy for the game. For example, at some point it overwrites wOptions and then wLetterPrintingDelayFlags, which causes the game to wait 15 frames between characters. And that's terrible.
For some reason, beginning at SRA0:BBB7, my save data is no longer 0xFF. It begins with some bytes I don't understand ("E4 35 70 01 67 3E 8C 00 00 39 C3 BB 94 20 20 D3 01 8C 8C 8C 20 D3 38"), and then (starting at $BBCE) becomes "00 39 00 39 00 39 …". I guess old crashes don't die that easily.
Anyway, the game mercy kills the PlaceString subroutine when it sees 0x00 at $BBBE. But it puts the pointer de at $19F3, which is… here. Starting from $19F4, the bytes "17 96 66 22" are interpreted as the height and weight data (23'150"/880.6 lb; the 150 displayed as " 0" when forced to be printed in two digits). Right after there happens to be a 0x50 terminator. Everything is fine!
Except that wJoyIgnore has also been overwritten to 0xFF, so I softlock. Oh well. At least I can soft reset.
It should be clear by now why this Pokédex entry behaves differently depending on the save file, especially after looking at glitch Pokémon sprites (which are known to trash SRAM Bank 0, also known as HOF data). Anyway… why don't you set a breakpoint at 10:435E and see for yourself?
Well that explains why I get random everything; I have never cleared the file. Also I havent got a clue how to set a breakpoint…