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

Front Sprite Crashers Revealed! Pokemon Red/Blue - Page 1

Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-07-25 21:32:14
First off, some story.
So, the other day, I was observing Hex C1 () and try to figure out why it crashes the game and then something happened which it happened to be caught on video!
https://www.youtube.com/watch?v=ieuJ1O36gtQ
I was thinking if that's really the cause of the crash which was a solution, or was it a coincidence? The next day afterwards, I tried that possible solution again, and surely enough, it worked without crashing!
So, the solution was this that I remembered from the 4 4 true cry follow-up video. Thanks TheZZAZZGlitch!
"Freezing the sound bank values: C0EF and C0F0"
So the true main cause of the crashing is the sprites corrupting the sound bank to invalid values around 99% of a time for Pokemon with Pokedex #205 and #211, while it's 100% or constant for Pokemon with Pokedex #224 ($ED and $EF), #245 ($E2, $E5, and $E8) and #255 ($F5).

Sound bank crashes seem more vulnerable in Red/Blue than Yellow. Yellow Missingno. crashes for a different reason more than just a sound bank corruption. But I can't say that for sure.

Finally, here are the revealed front sprites and $F5's backsprite! This was done on BGB.
https://www.youtube.com/watch?v=jjwYjcw9w_U


The #224, #245, and #255 family glitch pokemon behaves like 4 4 in Yellow, however it will crash the time it appears with lines or does the cry from that particular glitch Pokemon it is sent out and just freezes. There seem to be 6 of these in Red/Blue, while it's 4 in Yellow. 3 if you don't count the purple glitch screen one. ($E9)

The #205 and #211 sprites however, differ so much that it's depended on timing if save states are done. When it's encountered in a wild, it appears as a trainer instead. This was proven in the video as well with $C1. It's pretty much impossible to get an accurate picture from it. Although, the differ doesn't occur in VBA, but that's to be expected on a non-accarute emulator. Possibly due how it does the corruption, when those sprites finally appear, most of the time it likes to cause the low-pitched channel of Hitmonchan's cry over its usual one, but sometimes it will play the usual cry afterwards anyway.

Finally, $F5's backsprite is constant, but it always messes up the current music which likely touched the sound bank values as well. The short glitch music before it finally comes out is always the same with sometimes a different start though.

And there you have it. I don't know how useful this information will be, but I'm glad I figured it out and solved my objective. However, I don't think there's a way with glitches to freeze addresses like that in-game. I don't think 8F can perform an action that makes the values stay fixed, but I could be wrong.

Thank you.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: ISSOtm
Date: 2018-07-26 16:40:42
Hey!

Sound banks seem as (un)reliable in R/B as in Yellow. If they seem less vulnerable, the reason is unrelated.

Np, 8F cannot freeze the addresses. However, if OAM DMA is called before the audio code, it would be possible to use DMA hijacking to fix the sound banks.
And it appears that it IS the case!
Here's some code to fix the banks. It uses SMC to store the value of the last valid sound bank, and if the sound bank is invalid, then it restores it.
Note that this code MUST be placed at $DF00, otherwise it will NOT work properly.

  ld a, [$C0EF] ; wAudioROMBank
  call .checkBank
  jr z, .bankOK
  ld a, 0 ; @DF08
  ld [$C0EF], a
  ; Writing again is fine, it's a no-op and save instructions
.bankOK
  ld [$DF09], a ; Modify ld instruction to save value

  ld a, [$C0F0] ; wAudioSavedROMBank
  call .checkBank
  jr z, .savedBankOK
  ld a, 0 ; @DF18
  ld [$C0F0], a
.savedBankOK
  ld [$DF19], a

; Set up vars for transfer
ld c, $46
ld a, $C1
ret

.checkBank ; $DF25
  cp 2 ; BANK(Audio1_UpdateMusic)
  ret z
  cp 8 ; BANK(Audio2_UpdateMusic)
  ret z
  cp $1F ; BANK(Audio3_UpdateMusic)
  ret

I may have gotten some addresses wrong, but I think I did OK. Here's the bytecode:

FA EF C0
CD 25 DF
28 05
3E 00
EA EF C0
EA 09 DF

FA F0 C0
CD 25 DF
28 05
3E 00
EA F0 C0
EA 09 DF

0E 46
3E C1
C9

FE 02
C8
FE 08
C8
FE 1F
C9



Glad to see someone use BGB, FINALLY!

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-07-27 13:32:21
So, what am I suppose to do with the code exactly?  :-\ I'm a bit confused on how I should put in the memory debugger.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: ISSOtm
Date: 2018-07-28 05:33:14
You must use either BGB's debugger or an in-game memory editor to put either the code or the bytecode at $DF00, then set up DMA hijacking to point to $DF00 (call $DF00 then ld [c], a)

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: Guy
Date: 2018-07-28 14:24:48
This seems like a really great find! I didn't think we'd still be finding GlitchDex-related data in Gen I this far down the line.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: Torchickens
Date: 2018-07-29 15:47:09
Great find GlitchedPokemonStudent!


You must use either BGB's debugger or an in-game memory editor to put either the code or the bytecode at $DF00, then set up DMA hijacking to point to $DF00 (call $DF00 then ld [c], a)



So, what am I suppose to do with the code exactly?  :-\ I'm a bit confused on how I should put in the memory debugger.


To clarify what OAM DMA hijacking involves, it means you alter a routine in the zero page region of the memory (specifically at FF80+) that runs anywhere in the game every frame(?) but more changes are needed if you want to fix things like the player's overworld sprites (see here). 8F can be used to set up OAM DMA hijacking; the easiest way is by using 8F to write C3 (YY XX) where YY XX in ISSOtm would be(?) 00 DF at FF80. This causes the game to constantly run the code at the pointer after the C3.

Using OAM DMA hijacking to constantly write to memory addresses functions similarly to what a GameShark does. With GameShark codes it's arguably easier to set up than OAM DMA hijacking, but it's a neat exploit to try if you want to do this without a GameShark or don't have one.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: ISSOtm
Date: 2018-07-30 21:40:53
Using `C3` is wrong, because this is a jp instruction which does not return to the DMA routine and therefore fails to perform OAM DMA. Use the byte `CD` to instead encode a `call` instruction, which you then follow with `ld [c], a`.

Be very careful when writing to this region, because modifying one byte at a time will crash the game, most certainly. Write a `ret` (C9) at the beginning of the routine to neutralize it (note that this will break sprites temporarily), and write the CD byte last of the 4 "patch" bytes.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-08-02 12:29:28
Sound banks seem as (un)reliable in R/B as in Yellow. If they seem less vulnerable, the reason is unrelated.


I'm sorry, I should've been more clearer. What I meant was that it's instantaneous in Red/Blue, while in Yellow, it crashes at some point when a sound effect will play with an invalid sound bank value. But It only takes a rare miracle to encounter #205 or #211 family glitch Pokemon without crashing. But since it varies so much, heavily than . to an extent, that there isn't really official sprite for it. But those revealed sprites that crash the game, I don't know if that will be allowed to be put into the wiki since the mystery for what it looks like has solved.



FA EF C0
CD 25 DF
28 05
3E 00
EA EF C0
EA 09 DF

FA F0 C0
CD 25 DF
28 05
3E 00
EA F0 C0
EA 09 DF

0E 46
3E C1
C9

FE 02
C8
FE 08
C8
FE 1F
C9



I tried this the other day into the BGB memory editor and it did nothing. That's what values I put in $DF00 if the spaces were right. My save file is unfortunately only at the point of Cerulean City after I beaten Misty, so I can't currently obtain 8F yet and I want to maintain Mew at Level 1 and instant level it to 100, but I can't seem to find an Abra to do the "Long Range Trainer" glitch the route below it, even with fast forward on. Then I fight that Youngster trainer that is after Nugget Bridge to get the Special Stat for Mew. I don't want to borrow other people's save files. That's what I was thinking back then, but they will reply "Do it on your own save file" or something like that.

I do have a few questions though. When did this OAM DMA hijacking idea get discovered? Was it not used during glitch Pokemon research merits especially in Red/Blue? I feel that some correction has to be involved regarding towards the previously unrevealed information of those glitch Pokemon. Not that I'm forcing here, but I can't find a good way to take a picture of these sprites and how acceptable will it be. Another question that still boggles me. Why is that the glitch Pokemon $F3 in Red/Blue which is a hybrid of Raichu, has the only Pokedex entry that actually crashes the game which is after the "Pokemon was caught" jingle? This is one of the instances that the cause of the crash was not an invalid sound bank. BGB "illegal/unknown opcode" errors almost always occur. But it's vague on where the error is, so what could possibly be the cause of that? Finally, is there something I'm doing wrong with the code you mentioned? I did exactly how it's arranged in the code table, but it didn't work. That's why I gotten so puzzled.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: ISSOtm
Date: 2018-08-02 17:05:28



FA EF C0
CD 25 DF
28 05
3E 00
EA EF C0
EA 09 DF

FA F0 C0
CD 25 DF
28 05
3E 00
EA F0 C0
EA 09 DF

0E 46
3E C1
C9

FE 02
C8
FE 08
C8
FE 1F
C9



I tried this the other day into the BGB memory editor and it did nothing. That's what values I put in $DF00 if the spaces were right.

Did you also set up DMA hijacking?


DMA hijacking is a fairly recent concept, although it's less recent than the recent GlitchDex effort.
As for sprite dumping, it may be possible to dump VRAM or SRAM to get what would be displayed as the sprite if a crash didn't occur after.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: Torchickens
Date: 2018-08-04 12:21:50

I tried this the other day into the BGB memory editor and it did nothing. That's what values I put in $DF00 if the spaces were right. My save file is unfortunately only at the point of Cerulean City after I beaten Misty, so I can't currently obtain 8F yet and I want to maintain Mew at Level 1 and instant level it to 100, but I can't seem to find an Abra to do the "Long Range Trainer" glitch the route below it, even with fast forward on. Then I fight that Youngster trainer that is after Nugget Bridge to get the Special Stat for Mew. I don't want to borrow other people's save files. That's what I was thinking back then, but they will reply "Do it on your own save file" or something like that.


I'm unsure what the data at DF00 is for, but you might need to run it (and not just place the values) as it might not be automatic without the OAM DMA hijacking. This involves modifying FF80 first (in which placing C3 00 DF there might work even though it breaks the overworld sprites).


I do have a few questions though. When did this OAM DMA hijacking idea get discovered? Was it not used during glitch Pokemon research merits especially in Red/Blue? I feel that some correction has to be involved regarding towards the previously unrevealed information of those glitch Pokemon. Not that I'm forcing here, but I can't find a good way to take a picture of these sprites and how acceptable will it be.


OAM DMA hijacking seems to actually have been relatively recently used, although it's still a few years old now. Luckytyphlosion used it in 2015 for a 'RNG plays Pokémon' exploit.


Another question that still boggles me. Why is that the glitch Pokemon $F3 in Red/Blue which is a hybrid of Raichu, has the only Pokedex entry that actually crashes the game which is after the "Pokemon was caught" jingle? This is one of the instances that the cause of the crash was not an invalid sound bank. BGB "illegal/unknown opcode" errors almost always occur. But it's vague on where the error is, so what could possibly be the cause of that?

Good question. I don't have any suggestions that aren't vague either and this is just a guess but it could be a problem with the text. Pokédex entries can execute code if the text begins with the 08 byte. Does this glitch Pokémon have a bad cry?


Finally, is there something I'm doing wrong with the code you mentioned? I did exactly how it's arranged in the code table, but it didn't work. That's why I gotten so puzzled.



I think you need to change data at FF80 (to jp DF00 [C3 00 DF] or call DF00 [CD 00 DF] possibly not sure which) and not just at that location.

Hope this answers your questions!

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: ISSOtm
Date: 2018-08-04 14:22:55

I'm unsure what the data at DF00 is for, but you might need to run it (and not just place the values) as it might not be automatic without the OAM DMA hijacking. This involves modifying FF80 first (in which placing C3 00 DF there might work even though it breaks the overworld sprites).

I've explained several times what the correct way of doing DMA hijacking is already; don't you read my posts?!? Sorry to be aggressive, but it's frustrating to repeat myself on a trivial thing.
To have OAM DMA hijacking, you need to replace the initial

ld a, HIGH(wShadowOAM) ; wShadowOAM is the game's OAM buffer, in RBY's case: $C100
ldh [rDMA], a

into

call DMAHook ; $DF00 here
ld [$ff00+c], a

and have the hook routine return with a = HIGH(wShadowOAM) (here $C1) and c = LOW(rDMA) ($46)

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-08-12 13:35:25
Alright, I inserted the values into $DF00 and the DMA hijacking into $FF80. Both $C3 and $CD both seem correct. The results, I expected better, especially that it almost worked for #205 and #211 family Pokemon when sent out from a trainer battle, it showed the corruption with 9s once and a few others, but the sprite didn't show up. For #205 family encountered in the wild, nothing happened. It worked perfectly for #224, #245, and #255, except the sprite have solid black tiles for all those three, even the $F5 one. I don't know if I got accurate results, but I think I am on the right track. I will have to test it for $F5's back sprite later.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-08-15 16:18:57
Something I want to show off ChickasaurusGL (A.K.A. Evie Torchic the Glitch Scientist) one crucial thing they didn't point out in the "MissingNo." from all official Generation I versions" video.

So, I decided to try and find out the front sprite crashers in Japanese Red/Green. Missingno. being first on my list. I don't know if this ROM I got that has that translation that reminds me of the Pokemon Google and Bing Translation videos made the result different, but it did freeze like usual without locking the sound banks values just for confirmation.

But then this happened when I did lock the values. It does the "Glitch Pokemon Zoroark-ed/Illusion-ed Glitch Trainer" effect that I like to call it. Just like 4 4, Japanese Yellow Missingno, and the #205 Family in English Red/Blue. I wanted to point this out because it wasn't listed in the pictures. However, I'm not sure if the ROM I used was v1.0 or v1.1, if there is a difference.

[img]https://i.imgur.com/WY62PfT.png[/img]

Will you mind putting that in the description?

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: Torchickens
Date: 2018-08-15 18:38:31
Thanks for this GlitchedPokemonStudent! :)

Sure, I've just added this to the description. Let me know if anything in it needs changing.


Edit 2: An addendum from GlitchedPokemonStudent! A non-freezing battle from MissingNo. in Red/Green can appear if you lock the sound bank values (C0EF and C0F0) to valid values. Like Japanese Yellow MissingNo., it may trigger a Trainer battle. However, GlitchedPokemonStudent says he only tried it on an unofficial translation of the game, so effects may be different on the official Japanese versions.

Re: Front Sprite Crashers Revealed! Pokemon Red/Blue

Posted by: GlitchedPokemonStudent
Date: 2018-08-15 19:50:23

However, GlitchedPokemonStudent says he only tried it on an unofficial translation of the game, so effects may be different on the official Japanese versions.

Actually, I stumbled upon it by accident just after I started the game. Where I downloaded it, it made no mention to such a thing, so I just assumed it was a regular one. The moment I saw the save file screen, I just went "WTF?", but I decided to go along with it.

Anyway, about this glitch Pokemon. https://glitchcity.info/wiki/GlitchDexJP/RG:221
This front sprite is pretty much the earliest 4 4. What's interesting though that it turns into a screwed-up Safari Zone battle with that same dark red screen effect, ever like "bait" or "rock" occurs every time I try to advance until it runs away, crashing the game as a result.

And a few things I experienced with #250 and #234 family in Red/Green.

It seems that the front sprite of #250 family doesn't always corrupt the sound bank value since sometimes it wouldn't do anything to the music. As for #234 family, the back sprite doesn't seem to act volatile. No matter how hard I try, it stays constant when I used Transform with Ditto because when I tried to catch it, the game lock-ups after the choice of giving the nickname. I wonder why it is in this video here that I think they did it by accident since what I got was completely different. https://youtu.be/g9MwW2I15mo?t=383