Glitch City Laboratories Forums

Lab γ: Video Games and Glitches Discussion => Pokémon Glitch Discussion => Generation I Glitch Discussion => Topic started by: James-the-Charizard on September 11, 2019, 08:20:54 pm

Title: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 11, 2019, 08:20:54 pm
So I’ve 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. ;)
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Evie the Mother Hen ☽ ❤ on September 11, 2019, 09:26:28 pm
So I’ve 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
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 11, 2019, 09:28:29 pm
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... :-\
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 12, 2019, 07:39:19 am
>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.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 08:33:50 am
RIP the game in that case. Here is what I’ve 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.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 12, 2019, 08:50:23 am
RIP the game in that case. Here is what I’ve 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.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 09:07:54 am
Well I’m not sure, the Pokédex data is from VRAM AA00.
I’m using an android emulator (forgot the name) which means results could differ...
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 12, 2019, 09:52:37 am
Well I’m not sure, the Pokédex data is from VRAM AA00.
I’m using an android emulator (forgot the name) which means results could differ...
AA00 is SRAM...
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 09:55:19 am
O-Ok sorry... :'(
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Evie the Mother Hen ☽ ❤ on September 12, 2019, 10:55:08 am
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.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 11:12:26 am
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.

I’m 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 it’s unlocked, as the species description (normal example would be New Species for Mew) isn’t just mostly 9's, it varies from a few letters to complete garbage.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 12, 2019, 11:40:27 am
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.

I’m 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 it’s unlocked, as the species description (normal example would be New Species for Mew) isn’t just mostly 9's, it varies from a few letters to complete garbage.
Sounds like VRAM, however. Might be pulling from multiple places...
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 11:57:34 am
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.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: bbbbbbbbba on September 12, 2019, 03:11:52 pm
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this (https://github.com/pret/pokered/blob/c9da8510c88524c3c50e33f41ea1881594898d36/data/pokedex_entries.asm#L193):
Code: [Select]
; 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 (https://github.com/pret/pokered/blob/6ba3765c5932996f5da6417ae703794ff10bb1cb/home/text.asm#L126). 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?
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 03:47:38 pm
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this (https://github.com/pret/pokered/blob/c9da8510c88524c3c50e33f41ea1881594898d36/data/pokedex_entries.asm#L193):
Code: [Select]
; 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 (https://github.com/pret/pokered/blob/6ba3765c5932996f5da6417ae703794ff10bb1cb/home/text.asm#L126). 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 haven’t got a clue how to set a breakpoint...
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 12, 2019, 04:28:08 pm
A Pokédex entry is a relatively complicated object. A valid Pokédex entry looks like this (https://github.com/pret/pokered/blob/c9da8510c88524c3c50e33f41ea1881594898d36/data/pokedex_entries.asm#L193):
Code: [Select]
; 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 (https://github.com/pret/pokered/blob/6ba3765c5932996f5da6417ae703794ff10bb1cb/home/text.asm#L126). 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 haven’t got a clue how to set a breakpoint...
Breakpoints are only possible with a debugger. Like BGB's.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 12, 2019, 04:41:40 pm
I see.
Anyways I’ll do more of these later, I gotta go eat dinner and then I’m gonna play video games-
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 16, 2019, 08:14:57 am
More results again:
8'33"/1099.5 lb: Blanked nearly the entire bottom half of the screen, took a while before ending.
1'71"/4437.0 lb: Mess of sounds, eventually crashed. (RST 38h crash)
34'18"/6373.6 lb: More text garbage, exited fine.
1'7"/204.0 lb: Quick, nothing too special.
9'71"/4446.1 lb: Long chaotic mess, but exited fine.
52'71"/4591.3 lb: A few sounds and a slowed down wild encounter theme, that’s it.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 16, 2019, 09:30:56 am
When you get strange noises, make sure to check your various posessions (items and PC items, party and PC mons, pokedex, trainer card, options) as it's probably also executing garbage code.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 16, 2019, 10:38:28 am
I only was able to check two of them since I’m in class now, but I checked bag items and party Pokémon:
Party Items
X Accuracy x150
Master Ball x197
Rare Candy x49
Super Repel x128
TM13 x125
Ether x131
Super Potion x97
Revive x128
TM10 x1
Nugget x1
TM07 x1
Silph Scope
TM21 x1
Elixir x1
Awakening x1

Party Pokémon
Flareon (Level 40)
Glitch Pokémon 0xF2 (Level 40)
Glitch Pokémon 0x00 (Level 1)
Glitch Pokémon 0xEE (Level 41)
Glitch Pokémon 0xD8 (Level 15)
Glitch Pokémon 0xEF (Level 1)
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 16, 2019, 02:21:28 pm
I only was able to check two of them since I’m in class now, but I checked bag items and party Pokémon:
Party Items
X Accuracy x150
Master Ball x197
Rare Candy x49
Super Repel x128
TM13 x125
Ether x131
Super Potion x97
Revive x128
TM10 x1
Nugget x1
TM07 x1
Silph Scope
TM21 x1
Elixir x1
Awakening x1

Party Pokémon
Flareon (Level 40)
Glitch Pokémon 0xF2 (Level 40)
Glitch Pokémon 0x00 (Level 1)
Glitch Pokémon 0xEE (Level 41)
Glitch Pokémon 0xD8 (Level 15)
Glitch Pokémon 0xEF (Level 1)
no, like, every time, as they can execute garbage """""code""""" that does things in the midst of the noises.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 16, 2019, 02:41:08 pm
I only noted for the record. Basically... Literally anything can cause chaos in that Pokédex I think.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 16, 2019, 04:24:09 pm
I only noted for the record. Basically... Literally anything can cause chaos in that Pokédex I think.
This is one of several common effects with glitch text.

https://youtu.be/E-CQS5B2sjY
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 16, 2019, 04:39:42 pm
I only noted for the record. Basically... Literally anything can cause chaos in that Pokédex I think.
This is one of several common effects with glitch text.

https://youtu.be/E-CQS5B2sjY

Yeah and that certainly is a video that helps explain it.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 16, 2019, 06:12:41 pm
I only noted for the record. Basically... Literally anything can cause chaos in that Pokédex I think.
This is one of several common effects with glitch text.

https://youtu.be/E-CQS5B2sjY

Yeah and that certainly is a video that helps explain it.
sarcasm or no?
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: James-the-Charizard on September 16, 2019, 06:22:09 pm
I only noted for the record. Basically... Literally anything can cause chaos in that Pokédex I think.
This is one of several common effects with glitch text.

https://youtu.be/E-CQS5B2sjY

Yeah and that certainly is a video that helps explain it.
sarcasm or no?
No, I was serious. That video really helps.
Title: Re: My idea of me documenting all Pokédex entires of 0xDC
Post by: Parzival on September 16, 2019, 06:32:53 pm
oh good