Glitch City Laboratories Archives

Glitch City Laboratories closed on 1 September 2020 (announcement). This is an archived copy of a thread from Glitch City Laboratories Forums.

You can join Glitch City Research Institute to ask questions or discuss current developments.

You may also download the archive of this forum in .tar.gz, .sql.gz, or .sqlite.gz formats.

Generation II Glitch Discussion

Generation II glitch Pokédex entries analysis (and RAM Pokédex entries) - Page 1

Generation II glitch Pokédex entries analysis (and RAM Pokédex entries)

Posted by: Torchickens
Date: 2020-04-29 21:20:30
In Pokémon Crystal EN (v1.0) the pointer table is at 11:4378 (offset 0x44378). Note that the banks are not all the same, for example Bulbasaur has its entry at bank 0x60, and Celebi has it at bank 0x74. The banks are from 11:4351 (offset 0x44351) and are $60 ("Pokedex Entries 001-064"), $6E ("Pokedex Entries 065-128"), $73 ("Pokedex Entries 129-192") and $74 ("Pokedex Entries 193-251"). Following that is $CD, which is beyond the end of the ROM so I'm unsure how that works, but apparently there is a design flaw in the code anyway. I wonder if that means for a glitch Pokémon like ????? (FC), since the marker byte is 0x81 it would be Magikarp's bank or $73? However, this can probably be found out later in writing from testing.

Now, Celebi is at 74:58CC, which reads "TIMETRAVEL" as expected (and possibly the rest of the data follows). CC 58 is at 0x4456C and now the cheetahmen

No. 252: 013E
No. 253: 17CD
No. 254: 5639
No. 255: 2E3E
No. 000 (256): 7621

The banks here only matter for the 4000-7FFF region; as 0000-3FFF is unbanked/bank 0, so No. 254 and No. 000 (and theoretically banked RAM but unfortunately there are no RAM/'naturally' customisable dex entries, at least in this version of Crystal (and GSC in general)).

Catching the glitch Pokémon in battle (without its unused flag set; which is set after catching it at least once or modifying your Pokédex seen/own data directly) is a good way to see the Pokédex entry (all of which have been documented in the past). You can't normally see the dex entry by opening the Pokédex even with 251-255 and 0 registered, though. Other ways in theory include just locking the relevant dex entry memory addresses, and I think I've done this before; so with arbitrary code execution that would likely be possible too; or maybe using ACE to bring up the entry directly.

With a debugger, you can set a breakpoint to when de=your dex entry pointer. Although No. 252's Dex entry usually freezes the game, you can actually adjust the de pointer, and then check if what may be page 2 from the original pointer (after A button) is results in a freeze. In this case, it didn't and for some reason I got a different ????? sprite that may not have been documented before (if it's consistent). However, the buttons locked up afterwards.


253 (Egg) is documented before, but it can still vary for some reasons (possibly as it uses control characters as one reason; giving a name based on previous Trainer encountered data). You can encounter for instance, Elite Four Will, change D22D to 01 (wild battle) and catch the Egg, to see "Elite Four Will" printed in the Pokédex entry. This makes me wonder if you can cause a buffer overflow in the Pokédex with unterminated Trainer name data (though it might already occur with some of the freezing entries).


254 seems to be from 74:5639  (which is where " 's magma " comes from). So my theory was wrong (the marker byte is 0x91 and this would be 73 if true, so I'm still unsure what the disassembly meant).


255 : From 2E3E as expected. I noticed Entei was in the name this time, previously on the image it was Mewtwo. Entei was my currently battling Pokémon.


000 : 74:7621. This region is full of all 00 bytes and the game freezes. Changing de to D000 in RAM with the previous method, it loads (but as you're changing it, the category and text will be changed to where you set it to). The sprite is plain white (and it has the footprint with 256 in it) as expected.

Later I may document all the pointers for every Gold/Silver/Crystal in each language, but I'm going to do a quick search to see if any are in RAM (allow 'naturally' for fully custom Pokédex entries). Setting a breakpoint to 11:434F will give you the pointer as the value of register pair de. A surrounding area of this code, which doesn't use any changing RAM addresses; looks like 5f 19 46 d1 e1 , so maybe we can use that to find the equivalent routines. (As it turns out, this is helping for Crystals but not Gold/Silver which probably have different code for this. For Gold/Silver you can instead set a breakpoint to 11:4334.

Lucky for us, No. 252 has it's Pokédex entry in EN Gold from D5E5, which is your fourth key item ^^. So with enough bad inventory shenanigans/ACE, you can write a custom Pokédex entry. However, for some reason you may still get 99999(…)s on the first page; the effects only apply on the second page.

Copy this into D5E5 80 96 84 92 8e 8c 84 50 B6 04 26 11 50 8e 8c 86 7f 87 80 97 57

In other words, you need to have Item 5: Machine Part x150  Item 6: Star Piece x146 (…) and so on; only just filling the key items pocket. You can probably use Coin Case glitch to fill your TM/HM pocket with x255, then adjust the quantities and copy them over to D5E5 to get all the items straight away. Then use Coin Case glitch to encounter No. 252, either directly or as a roaming Pokémon and catch it.


The others for EN Gold:
No. 000's Dex entry is sourced from 0000
No. 253 (Egg)'s Dex entry is sourced from AFC5 (unsure of bank, SRAM may be closed)
No. 254 - A7EA (unsure of bank, SRAM may be closed)
No. 255 - 11C1

Re: Generation II glitch Pokédex entries analysis (and RAM Pokédex entries)

Posted by: CasualPokePlayer
Date: 2020-05-18 19:10:15

$74 ("Pokedex Entries 193-251") Following that is $CD, which is beyond the end of the ROM so I'm unsure how that works, but apparently there is a design flaw in the code anyway.

Looking at the code, it seems like $74 is actually for 193-256. The $CD could never be read due to this instruction:

(it's actually just an "and $03" which can never result in $04, which would be needed for the $CD to be used)

Also, even if $CD could be reached, it would just result in standard invalid bank switch behavior, the upper bit being ignored so it bank switches to $4D.