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 I Glitch Discussion

My idea of me documenting all Pokédex entires of 0xDC - Page 1

My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-11 21:20:54
So Ive continued testing that Pokémon, and I thought… Maybe I could document the height/weight combos and note which ones work, which ones crash, and which ones cause weird effects. ;)

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Torchickens
Date: 2019-09-11 22:26:28

So Ive continued testing that Pokémon, and I thought… Maybe I could document the height/weight combos and note which ones work, which ones crash, and which ones cause weird effects. ;)


Sounds good! ^^ Thank you! I forgot what happens what it crashes/why it may crash. If you can find patterns that would be great! :D

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-11 22:28:29
Well I can split crash between actual game crashes (as in everything is halted and the screen blanks with bar lines) and lock-ups. (Game keeps running, but all buttons cease to work, forcing a reset anyways.) Sadly I am not sure what causes Pokédex entries to crash… :-\

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Parzival
Date: 2019-09-12 08:39:19
>screen blanks with bar lines
That's called a RST 38h crash, as it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038. Then, at 0038, it jumps to 0038.

You get the point. Every time this happens, it writes 2 bytes to WRAM. Oh wait, we're in VRAM now. …now we're in SRAM. …now we're just writing to ROM. great. Oh look, we've wrapped around! Repeat ad infinitum.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 09:33:50
RIP the game in that case. Here is what Ive got so far:
52'71"/1946.8 lb: Some glitchy sounds, does end relatively quickly.
8'18"/1090.1 lb: Crazy mix of Pokémon cries and moves. Sounds stopped after awhile, assuming a 00 39 pattern crash, where it was stuck on the Pokédex with no sounds or buttons working.. (No hex viewer so can't know for sure)
47'74"/1180.6 lb: Brief chaotic glitch combo of music and sounds, large amounts of garbage text appeared at the bottom of the screen (glitch tiles and letters/numbers) with a 48 error, but it ended after.
1'3"/177.3 lb: Mostly spammed a sound effect like that of Defense Curl from gen 2. Gave up after about 2 minutes when nothing was happening.
34'71"/4437.0 lb: Quick burst of glitchy sounds, gave a 48 error and ended.
80'3"/6099.0 lb: We all know this one. Mess of sounds that repeat twice and eventually locks up.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Parzival
Date: 2019-09-12 09:50:23

RIP the game in that case. Here is what Ive got so far:
52'71"/1946.8 lb: Some glitchy sounds, does end relatively quickly.
8'18"/1090.1 lb: Crazy mix of Pokémon cries and moves. Sounds stopped after awhile, assuming a 00 39 pattern crash, where it was stuck on the Pokédex with no sounds or buttons working.. (No hex viewer so can't know for sure)
47'74"/1180.6 lb: Brief chaotic glitch combo of music and sounds, large amounts of garbage text appeared at the bottom of the screen (glitch tiles and letters/numbers) with a 48 error, but it ended after.
1'3"/177.3 lb: Mostly spammed a sound effect like that of Defense Curl from gen 2. Gave up after about 2 minutes when nothing was happening.
34'71"/4437.0 lb: Quick burst of glitchy sounds, gave a 48 error and ended.
80'3"/6099.0 lb: We all know this one. Mess of sounds that repeat twice and eventually locks up.
You'd know if it was a 0039 crash (aka an RST 38h crash) as VRAM would get trashed. Also, it'd be great if we could figure out where it's pulling the data from.

Also, use BGB. It has a builtin fully-featured debugger.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 10:07:54
Well Im not sure, the Pokédex data is from VRAM AA00.
Im using an android emulator (forgot the name) which means results could differ…

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Parzival
Date: 2019-09-12 10:52:37

Well Im not sure, the Pokédex data is from VRAM AA00.
Im using an android emulator (forgot the name) which means results could differ…
AA00 is SRAM…

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 10:55:19
O-Ok sorry… :'(

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Torchickens
Date: 2019-09-12 11:55:08

O-Ok sorry… :'(


Don't worry about it buddy ^^

Hmm I think SRAM can be locked at points; I wonder is there a point where all the data is read as FF FF FF (…) because it is locked? So 999 category max height/weight etc. Or is the region always unlocked for when the Pokédex entry is brought up.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 12:12:26


O-Ok sorry… :'(


Don't worry about it buddy ^^

Hmm I think SRAM can be locked at points; I wonder is there a point where all the data is read as FF FF FF (…) because it is locked? So 999 category max height/weight etc. Or is the region always unlocked for when the Pokédex entry is brought up.


Im not sure.. There may be some points where it is locked and only (or mostly) reads FF FF FF (999…) when the game spams 9999 at the bottom. But it seems its unlocked, as the species description (normal example would be New Species for Mew) isnt just mostly 9's, it varies from a few letters to complete garbage.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: Parzival
Date: 2019-09-12 12:40:27



O-Ok sorry… :'(


Don't worry about it buddy ^^

Hmm I think SRAM can be locked at points; I wonder is there a point where all the data is read as FF FF FF (…) because it is locked? So 999 category max height/weight etc. Or is the region always unlocked for when the Pokédex entry is brought up.


Im not sure.. There may be some points where it is locked and only (or mostly) reads FF FF FF (999…) when the game spams 9999 at the bottom. But it seems its unlocked, as the species description (normal example would be New Species for Mew) isnt just mostly 9's, it varies from a few letters to complete garbage.
Sounds like VRAM, however. Might be pulling from multiple places…

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 12:57:34
Certainly possible, this may be a complicated situation. In the mean time, I got a few more pokedex variations done:
1'18"/204.0 lb: Eventually locked up with the gym battle theme, with light buzzing sound occasionally.
52'7"/4591.3 lb: Bunch of hyper beams early on, gave a 48 error, but continued, eventually the game halted while stuck on a sound, assuming an unknown opcode.
9'7"/179.9 lb: Short burst of sounds, quick exit with a 48 error.
34'7"/6357.0 lb: Same as above, different sounds.

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: bbbbbbbbba
Date: 2019-09-12 16:11:52
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?

Re: My idea of me documenting all Pokédex entires of 0xDC

Posted by: James-the-Charizard
Date: 2019-09-12 16:47:38

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…