Glitch City Laboratories Forums

Lab γ: Video Games and Glitches Discussion => Pokémon Glitch Discussion => Generation I Glitch Discussion => Topic started by: GlitchedPokemonStudent on July 25, 2018, 08:32:14 pm

Title: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on July 25, 2018, 08:32:14 pm
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 (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 (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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on July 26, 2018, 03:40:42 pm
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.
Code: [Select]
  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:
Code: [Select]
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!
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on July 27, 2018, 12:32:21 pm
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on July 28, 2018, 04:33:14 am
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)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Sherkel on July 28, 2018, 01:24:48 pm
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on July 29, 2018, 02:47:09 pm
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 (http://gameboy.mongenel.com/dmg/asmmemmap.html) 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 (https://glitchcity.info/wiki/OAM_DMA_hijacking)). 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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on July 30, 2018, 08:40:53 pm
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 02, 2018, 11:29:28 am
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.

Code: [Select]
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on August 02, 2018, 04:05:28 pm
Code: [Select]
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 04, 2018, 11:21:50 am
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 (https://forums.glitchcity.info/index.php?topic=7155.0) 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!
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on August 04, 2018, 01:22:55 pm
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
Code: [Select]
ld a, HIGH(wShadowOAM) ; wShadowOAM is the game's OAM buffer, in RBY's case: $C100
ldh [rDMA], a
into
Code: [Select]
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)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 12, 2018, 12:35:25 pm
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 15, 2018, 03:18:57 pm
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.

(https://i.imgur.com/WY62PfT.png)

Will you mind putting that in the description?
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 15, 2018, 05:38:31 pm
Thanks for this GlitchedPokemonStudent! :)

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

Quote
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.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 15, 2018, 06:50:23 pm
Quote
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 (https://youtu.be/g9MwW2I15mo?t=383)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 15, 2018, 07:03:42 pm
Quote
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.

Ah, OK. Makes sense.

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.

Interesting. Sounds like my experience of French version's of 4 4. If a trainer sends out French 4 4 you can force the Safari Zone encounter system as well.


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 (https://youtu.be/g9MwW2I15mo?t=383)

Some back sprites are sourced from RAM with the first byte specifying the dimensions, so I think it's possible a certain RAM address needs to have a nybble of 0 for this to work (e.g. 00). I don't know the source location of Red/Green's #234 family backsprite but can look it up for you one moment.

Edit: The #234 backsprite pointer is at $0043 (a ROM location), according to here (https://docs.google.com/document/d/1UXh27xFgGqrrxKJx-afoqZ22ROe_X1Ex-oU9KTWxkGM/edit), so that's likely not the issue. (Unless there's a difference here between the v1.0 and v1.1 ROMs)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 20, 2018, 01:58:08 pm
For Red/Green Missingno's (Regular form) back sprite. Instead of the crashing v1.0 and v1.1 one that glitches out the music and takes 12-13 seconds to show up, I got this which only took 2 seconds to show up and no sound bank freeze necessary.

It's named "Blood" in the translation which I find it a bit creepy, so I nicknamed it to MisNo.
(https://i.imgur.com/fHUj5em.png)

Also, it turns out that Missingno. is 4 4 in Red/Green as well, while still containing its own palette and that devilish red glitch screen.
(https://i.imgur.com/94yZd4M.png)

(https://i.imgur.com/RSSu5Sh.png)

(https://i.imgur.com/BUKmfOX.png)
(https://i.imgur.com/j7fsoTR.png)
(https://i.imgur.com/UIlyliI.png)

I seem to draw two things in mind from Pokemon Red/Blue and earlier. (Before Yellow)

In Red/Green to Red/Blue, the game instantly freezes when it finds out an invalid sound bank, while in all versions of Yellow, it crashes when a sound effect plays out in an invalid sound bank. I noticed it's the same for glitch/invalid trainers as well, but from the AI instead. In Red/Green to Red/Blue, it crashes after "wants to fight" only if the encounter trigger isn't coming from a trainer. However, in Yellow, it doesn't seem to be the case until the game allows it to use a move, but it can't, resulting a freeze. But the question is, why right after "wants to fight" sentence finally finishes? Since I know for certain that it's not caused by an invalid sound bank at all and I don't know what addresses cause that crash there, but what I do know, is that the AI's in the Daycare or Boxed Pokemon Data, and that's why it crashes when it tries to use a move instead of randomly trying to use Guard Spec. or Full Heal on the glitch Trainer's Pokemon if it does have status like Poison or Paralysis.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 21, 2018, 09:17:01 am
Soon I'm going to check these too on real hardware and add them to the wiki (also made a comment on your video).
Edit: Also if you ever feel like adding these yourself, feel free and it would be greatly appreciated. :) You might need to follow this session error workaround (https://forums.glitchcity.info/index.php?topic=8240.0).
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: coloradohugge on August 21, 2018, 10:06:52 am
Wait? I'm lost. Why are we using the translation now? :O
It acts way differently than the actual Red/Green.
And many glitch pokémon behaves differently.

I went through all the glitch pokémons and documented them all in the translation version last year just for fun, and they differ a lot from the Official Releases.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 21, 2018, 11:23:41 am
Wait? I'm lost. Why are we using the translation now? :O
It acts way differently than the actual Red/Green.
And many glitch pokémon behaves differently.

I went through all the glitch pokémons and documented them all in the translation version last year just for fun, and they differ a lot from the Official Releases.

Ah OK. Yeah, not too surprising given the differences between other languages as well. I mean the sprites from the official versions will be added (not English Red/Green); so for instance the front sprite crashers on Red/Blue/Yellow, official Japanese Red/Green v1.0 and v1.1.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: coloradohugge on August 21, 2018, 12:22:19 pm
I mean the sprites from the official versions will be added (not English Red/Green); so for instance the front sprite crashers on Red/Blue/Yellow, official Japanese Red/Green v1.0 and v1.1.

Ah I see. cool, that's what i hoped for. ;D
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 21, 2018, 01:10:02 pm
I guess I have to find the ROM download for Red/Green somewhere else if that's the case. Not to mention the translation was done poorly. I think the text was the only thing that was changed, however it did crash the same way for $DD and $F5 compared to that Pokemon Green Glitch Trainers video, but for some reason, it seems less often for #250 front sprite and completely different result for #234 backsprite. I don't know, the person who made that video probably used VBA because I did hear some error sound a few times, so I guess it might have to do something with how volatile the sprites are in some emulators since in VBA I just tried for testing the sound bank freeze and the English Red/Blue #205 and #211 seem mostly constant, but corruption is the same, could that be due to VRAM inaccessibility? No wonder why it's suddenly more difficult to find an official sprite for those glitch Pokemon since it does vary depending on the timing, even with save states.

A bit off-topic, but:
Speaking of VBA, there is another thing I noticed in difference. The wave channel sounds quieter in VBA than in BGB, actual GBC, and 3DS Virtual Console. Listen carefully in TheZZAZZGlitch's Pokemon glitches and emulator accuracy video and you'll notice it, especially during the Cerulean City and Pokemon Center music. I can identify what emulator they are using just by that alone. It was more noticeable to me since I gotten so used to hearing the VBA volume thanks to currently long absence MissingnoXpert. At that time, I had no knowledge of emulator accuracy until I saw that video, and the first two videos I uploaded were recorded from VBA.

My next goal was to check on Japanese Yellow Glitch Pokemon and try to make a video of it since that GlitchoGaming did not, however, no matter how hard I tried to look for it, I can't seem to find it and people will say "no" of sending people their backup download of it due to rules. Which means unfortunately, I am left out and be unable to mess around and show off those glitch Pokemon myself unless one of you are kind enough to temporarily do it for me. I don't know how much different Japanese Blue's glitch Pokemon are though according to what I have seen, I might have to research on that again in case my memory was wrong.

Edit - I can't seem to find the Japanese Blue download either.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 21, 2018, 01:29:28 pm
I guess I have to find the ROM download for Red/Green somewhere else if that's the case. Not to mention the translation was done poorly. I think the text was the only thing that was changed, however it did crash the same way for $DD and $F5 compared to that Pokemon Green Glitch Trainers video, but for some reason, it seems less often for #250 front sprite and completely different result for #234 backsprite. I don't know, the person who made that video probably used VBA because I did hear some error sound a few times, so I guess it might have to do something with how volatile the sprites are in some emulators since in VBA I just tried for testing the sound bank freeze and the English Red/Blue #205 and #211 seem mostly constant, but corruption is the same, could that be due to VRAM inaccessibility? No wonder why it's suddenly more difficult to find an official sprite for those glitch Pokemon since it does vary depending on the timing, even with save states.

A bit off-topic, but:
Speaking of VBA, there is another thing I noticed in difference. The wave channel sounds quieter in VBA than in BGB, actual GBC, and 3DS Virtual Console. Listen carefully in TheZZAZZGlitch's Pokemon glitches and emulator accuracy video and you'll notice it, especially during the Cerulean City and Pokemon Center music. I can identify what emulator they are using just by that alone. It was more noticeable to me since I gotten so used to hearing the VBA volume thanks to currently long absence MissingnoXpert. At that time, I had no knowledge of emulator accuracy until I saw that video, and the first two videos I uploaded were recorded from VBA.

My next goal was to check on Japanese Yellow Glitch Pokemon and try to make a video of it since that GlitchoGaming did not, however, no matter how hard I tried to look for it, I can't seem to find it and people will say "no" of sending people their backup download of it due to rules. Which means unfortunately, I am left out and be unable to mess around and show off those glitch Pokemon myself unless one of you are kind enough to temporarily do it for me. I don't know how much different Japanese Blue's glitch Pokemon are though according to what I have seen, I might have to research on that again in case my memory was wrong.

The ROMs are more commonly referred to as Pocket Monsters Aka, Pocket Monsters Midori, Pocket Monsters Ao and Pocket Monsters Pikachu I think. Any luck with those names?

Pocket Monsters Ao (Japanese Blue) has different sprites to Red/Green/Pikachu.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 21, 2018, 02:12:19 pm
The ROMs are more commonly referred to as Pocket Monsters Aka, Pocket Monsters Midori, Pocket Monsters Ao and Pocket Monsters Pikachu I think. Any luck with those names?

Yes, edgeemu being first on the search list, second for Pocket Monsters Pikachu. Thanks. I did think of searching "Japanese Pokemon Yellow"and "Pocket Monsters Yellow" But I never thought they would be named in Japanese form. Thank you. Although, Pocket Monsters Midori one said "Rev A" which means it could be v1.1 and not v1.0 because Missingno's back sprite crashes on v1.0, but v1.1 doesn't, so I tried different websites, but they were so uncooperative and I got no luck on that one.

BTW, is the "Official 1st Gen (Red/Blue and Yellow) Glitch Discussion" thread really that inactive? It says last post was September of last year.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 21, 2018, 02:41:46 pm
The ROMs are more commonly referred to as Pocket Monsters Aka, Pocket Monsters Midori, Pocket Monsters Ao and Pocket Monsters Pikachu I think. Any luck with those names?

Yes, edgeemu being first on the search list, second for Pocket Monsters Pikachu. Thanks. I did think of searching "Japanese Pokemon Yellow"and "Pocket Monsters Yellow" But I never thought they would be named in Japanese form. Thank you. Although, Pocket Monsters Midori one said "Rev A" which means it could be v1.1 and not v1.0 because Missingno's back sprite crashes on v1.0, but v1.1 doesn't, so I tried different websites, but they were so uncooperative and I got no luck on that one.

BTW, is the "Official 1st Gen (Red/Blue and Yellow) Glitch Discussion" thread really that inactive? It says last post was September of last year.

You're welcome. Yes, Rev A is the v1.1 release and the ones without a revision label may be v1.0, you can check with an MD5 hash checking tool and the comparing them to the ones associated with the dumps listed here:

https://datomatic.no-intro.org/?page=show_record&s=46&n=1025 (Red 1.0)
https://datomatic.no-intro.org/?page=show_record&s=46&n=1026 (Red 1.1 (Rev A))

https://datomatic.no-intro.org/?page=show_record&s=46&n=1028 (Green 1.0)
https://datomatic.no-intro.org/?page=show_record&s=46&n=1029 (Green 1.1 (Rev A))

https://datomatic.no-intro.org/?page=show_record&s=46&n=1021 (Yellow 1.0)
https://datomatic.no-intro.org/?page=show_record&s=46&n=1022 (Yellow v1.1 (Rev A))
https://datomatic.no-intro.org/?page=show_record&s=46&n=1023 (Yellow v1.2 (Rev B))
https://datomatic.no-intro.org/?page=show_record&s=46&n=1024 (Yellow v1.3 (Rev C) but also called "Rev 3")
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 23, 2018, 05:46:48 pm
You're welcome. Yes, Rev A is the v1.1 release and the ones without a revision label may be v1.0, you can check with an MD5 hash checking tool and the comparing them to the ones associated with the dumps listed here:

So, how do I make this process work exactly?  :-\
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 24, 2018, 04:17:28 am
You're welcome. Yes, Rev A is the v1.1 release and the ones without a revision label may be v1.0, you can check with an MD5 hash checking tool and the comparing them to the ones associated with the dumps listed here:

So, how do I make this process work exactly?  :-\

Usually it's quite easy and is just a matter of downloading an MD5 checker (there are fortunately open source/free ones), and opening the ROM (or any file you want to check) to automatically calculate the MD5 value. From there, check the value to the one in the "MD5" field under Dump source(s) in the links I posted above.

Here is a free one for Windows:

http://www.winmd5.com/

Hope this helps :)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Sherkel on August 24, 2018, 01:02:26 pm
It's named "Blood" in the translation which I find it a bit creepy, so I nicknamed it to MisNo.
https://www.sljfaq.org/afaq/kanji-pronunciation.html (https://www.sljfaq.org/afaq/kanji-pronunciation.html)
けつばん is supposed to stand for 欠番 (missing number), but the on'yomi of 血 (blood) is けつ, and there's a five-character limit.

Don't mind me, I just find this sort of thing humorous. Keep up the good work!
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 24, 2018, 06:34:15 pm
You're welcome. Yes, Rev A is the v1.1 release and the ones without a revision label may be v1.0, you can check with an MD5 hash checking tool and the comparing them to the ones associated with the dumps listed here:

So, how do I make this process work exactly?  :-\

Usually it's quite easy and is just a matter of downloading an MD5 checker (there are fortunately open source/free ones), and opening the ROM (or any file you want to check) to automatically calculate the MD5 value. From there, check the value to the one in the "MD5" field under Dump source(s) in the links I posted above.

Here is a free one for Windows:

http://www.winmd5.com/

Hope this helps :)

Oh, you mean to check the ROM with the MD5 checker and compare it to the MD5 checksum value from the dumps.

I guess I would be using Red v1.0 instead.

Anyways, I made a video regarding v1.0 and v1.1 Missingno.
https://www.youtube.com/watch?v=s_Ls5YX6c6Y&feature=youtu.be (https://www.youtube.com/watch?v=s_Ls5YX6c6Y&feature=youtu.be)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 25, 2018, 01:06:20 pm
Oh, you mean to check the ROM with the MD5 checker and compare it to the MD5 checksum value from the dumps.

I guess I would be using Red v1.0 instead.

Yes.

Anyways, I made a video regarding v1.0 and v1.1 Missingno.
https://www.youtube.com/watch?v=s_Ls5YX6c6Y&feature=youtu.be (https://www.youtube.com/watch?v=s_Ls5YX6c6Y&feature=youtu.be)

Nice video! May you attach screenshots of the battles please? Then the sprites can be added to our wiki.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 25, 2018, 04:50:01 pm
Nice video! May you attach screenshots of the battles please? Then the sprites can be added to our wiki.

I took the front sprite ones, however, it seems like it only uses solid square on its first encounter, and then next encounters, it will do the 4 4 noise pixels with minor variations here and there each reset. Unfortunately, I don't know how to get around the devilish red glitch screen it has.

The (First Time) one will not show up if other glitch Pokemon shown up before Missingno.

v1.0 (First Time)
(https://i.imgur.com/ay3WBoR.png)
v1.0 (After reset or non-first encounters with minor variations)
(https://i.imgur.com/LLNWEwb.png)
v1.1 (First Time)
(https://i.imgur.com/Nht9h1G.png)
v1.1 (After reset or non-first encounters with minor variations)
(https://i.imgur.com/7eBMttN.png)

And finally, Missingno.'s back sprite in v1.0.
(https://i.imgur.com/dyLWdYt.png)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 25, 2018, 11:51:56 pm
Thanks! :)

Have added the MissingNo. back sprite to the MissingNo. and GlitchDexJP/RG:000 articles and the MissingNo. v1.1 front sprite to the MissingNo. article.

About the v1.1 sprite, つりあげた is the 'the hooked Pokémon' string and it looks like those are the genuine sprites.

But with the v1.0 sprites it says "しょうぶを しかけてきた!" which means a glitch Trainer wants to fight. Despite that the sprites are quite similar so perhaps it is the glitch Pokémon's sprite and not the Trainer's (like if you force a wild Pokémon to be a Trainer). May you test them with 010134D0 (wild Pokémon and not trainer) enabled please and post the results?
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 26, 2018, 10:00:51 am
But with the v1.0 sprites it says "しょうぶを しかけてきた!" which means a glitch Trainer wants to fight. Despite that the sprites are quite similar so perhaps it is the glitch Pokémon's sprite and not the Trainer's (like if you force a wild Pokémon to be a Trainer). May you test them with 010134D0 (wild Pokémon and not trainer) enabled please and post the results?

I'm sure it's due to the sprite tampering with the battle mode.

I did test that with 4 4 this summer, but I'm not sure how to make them work with Glitch Pokemon $C8 and onwards since trainers appear instead, since the Pewter Museum method for battles and stats didn't seem to work in terms of all glitch Pokemon, while for battles, it only works for the Mew Glitch obtainable Pokemon. But with that code on+the wild Pokemon battle mode lock, it's not enough otherwise. I think it should be possible since I did see this in the past. https://youtu.be/CnuuRz4hcIM?t=31 (https://youtu.be/CnuuRz4hcIM?t=31)

Edit - Just to note, it's CF90 in English Yellow.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on August 26, 2018, 11:23:31 am
But with the v1.0 sprites it says "しょうぶを しかけてきた!" which means a glitch Trainer wants to fight. Despite that the sprites are quite similar so perhaps it is the glitch Pokémon's sprite and not the Trainer's (like if you force a wild Pokémon to be a Trainer). May you test them with 010134D0 (wild Pokémon and not trainer) enabled please and post the results?

I'm sure it's due to the sprite tampering with the battle mode.

I did test that with 4 4 this summer, but I'm not sure how to make them work with Glitch Pokemon $C8 and onwards since trainers appear instead, since the Pewter Museum method for battles and stats didn't seem to work in terms of all glitch Pokemon, while for battles, it only works for the Mew Glitch obtainable Pokemon. But with that code on+the wild Pokemon battle mode lock, it's not enough otherwise. I think it should be possible since I did see this in the past. https://youtu.be/CnuuRz4hcIM?t=31 (https://youtu.be/CnuuRz4hcIM?t=31)

Edit - Just to note, it's CF90 in English Yellow.

Yes. Actually I think what I'll do is add the sprite anyway but note that the situation involved activating a Trainer battle, because it is caused by the glitch Pokémon at least.

What I do to try and get the 'actual' sprites for the 0xC8+ ones is encounter the Trainers in Viridian Gym, then enable the species modifier code only while the Trainer is about to send out a Pokémon.

You can work out the Pewter Museum exhibit code if you use cheat searcher to search for 182 (0xB6) while viewing Kabutops Fossil and 183 (0xB7) while viewing Aerodactyl Fossil. This should give you about three codes or so but one of them is the exhibit modifier. I'll go and find it for you for Red/Green in case you don't have it as well, one moment.

Edit: Found it. :) Modify CF78 or use 01xx78CF. 0x1F froze my game without loading a sprite even with 0102EFC0 and 0102F0C0 on though :(.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 26, 2018, 12:38:21 pm
Alright, I didn't figure how to forcefully encounter non-Mew Glitch Pokemon in the wild, but I found a way to view invalid glitch Pokemon in stats.
https://www.youtube.com/watch?v=nrwNxIQwpME (https://www.youtube.com/watch?v=nrwNxIQwpME)

All you have to is set CF90 to a value that is a glitch Pokemon hybrid like $EF and then view the glitch Pokemon's stats. Doing so on a regular Pokemon will have their own glitched sprite it seems, especially for Pidgey and Sandshrew which already has a known glitch hybrid Pokemon.

Now I need to figure how it controls the Trainer range and its sprites. 4 4's effect was possible to see during the wild because it's not in the Trainer range for 200-255. And I want to know what will happen if $ED is encountered in the wild, because it may have some difference. I wonder if it will act similarly to Japanese Yellow's Missingno. I could try the same for #207 glitch pokemon family and the #202 family as well if it's even possible to do it in the first place, since no person has ever done it before.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on August 26, 2018, 01:47:10 pm
Edit: Found it. :) Modify CF78 or use 01xx78CF. 0x1F froze my game without loading a sprite even with 0102EFC0 and 0102F0C0 on though :(.

Maybe you got unlucky. Because I got it on both v1.0 and v1.1, although the latter did show for a split-second before displaying the blank box again.
v1.0
(https://i.imgur.com/EQ8Yyz2.png)
v1.1 Just before it returned displaying the blank box.
(https://i.imgur.com/7bQitne.png)
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: GlitchedPokemonStudent on September 08, 2018, 03:45:16 pm
It seems 4 4-like sprites and #205 family Pokemon doesn't change no matter what sprite bank I put in (CF90), Even if I edit values on where the sprite pointers are. but it works fine for that crazy $EC and $F4 glitch Pokemon for Yellow. Is it because of the base sprite dimensions instead of actual dimensions having a 0 which treats it as 256? Putting a 0 in these glitch Pokemon just results longer load time. Female Symbol does the volatile effect when VRAM 8150 is 0, but if you change it, it removes that effect, same with Yellow Missingno. BGB can allow you to edit ROM values, but it's temporarily since it doesn't save it when you close the emulator. For 4 4, it only partially changes the look, but not the effect. Same goes for $ED in Yellow, same with the #205&#211 family glitch Pokemon. Something finicky is going on with those glitch Pokemons sprite dimensions, if it's not a zero value in their sprite pointer that's causing it, then it's probably something somewhere else entirely.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Evie the Bird Mother ❤✿ on September 09, 2018, 04:54:52 am
It seems 4 4-like sprites and #205 family Pokemon doesn't change no matter what sprite bank I put in (CF90), Even if I edit values on where the sprite pointers are. but it works fine for that crazy $EC and $F4 glitch Pokemon for Yellow. Is it because of the base sprite dimensions instead of actual dimensions having a 0 which treats it as 256? Putting a 0 in these glitch Pokemon just results longer load time. Female Symbol does the volatile effect when VRAM 8150 is 0, but if you change it, it removes that effect, same with Yellow Missingno. BGB can allow you to edit ROM values, but it's temporarily since it doesn't save it when you close the emulator. For 4 4, it only partially changes the look, but not the effect. Same goes for $ED in Yellow, same with the #205&#211 family glitch Pokemon. Something finicky is going on with those glitch Pokemons sprite dimensions, if it's not a zero value in their sprite pointer that's causing it, then it's probably something somewhere else entirely.

I can't remember the specifics about base dimensions and actual dimensions other than the base dimensions are found in the base stats data structure (https://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9mon_base_stats_data_structure_in_Generation_I) and the actual dimensions are found by following the pointer and getting the beginning value, but yeah maybe the base structure having a 0 nybble in it may be causing the issue re: it not changing even if you edit the 'actual' dimensions. $EC and $F4 don't have a 0 nybble in the base structure dimensions but do in the 'actual' dimensions.

Another thing that's relevant is that R/B Family 205 gets its front sprite from VRAM (8E8F), while 4 4 gets it from an unbanked region (0510). For Family 205 even though some of the RAM can be banked, I'm unsure if the indices>sprite bank relationships apply here. For 4 4/Family 250, any sprite pointers between 0000-3FFF are unbanked, so the relationship doesn't apply in this case either.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: joshuarpl on December 29, 2018, 04:27:29 pm
So, is there any reason why pokemon like 4 4 corrupt the sound banks? Maybe it is the oversized sprites, maybe it is something else?
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Parzival on December 29, 2018, 07:28:09 pm
So, is there any reason why pokemon like 4 4 corrupt the sound banks? Maybe it is the oversized sprites, maybe it is something else?
It doesn't corrupt the sound banks, it switches to sound banks that don't exist.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on December 30, 2018, 10:13:07 am
It corrupts the sound bank selection, and that's because of the oversized sprite's decompression.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Sherkel on December 30, 2018, 05:40:21 pm
Basically, all sprites in RBY are stored in a compressed format so they could fit all 151 (plus back sprites) in, but glitch ones obviously don't care about being the right size, so the parts of their sprites that don't appear end up in other places, such as the Hall of Fame data with MissingNo. and 'M.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on December 30, 2018, 06:53:49 pm
To put it more clearly, part of the decompressed data spills past the intended decompression buffer, and into first the Hall of Fame, then misc RAM, including eventually the selected sound bank
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Parzival on January 01, 2019, 06:08:06 pm
To put it more clearly, part of the decompressed data spills past the intended decompression buffer, and into first the Hall of Fame, then misc RAM, including eventually the selected sound bank
at that point isn't like half of WRAM trashed?
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Sherkel on January 02, 2019, 02:58:41 pm
Hence, Super Glitch.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on January 02, 2019, 07:20:55 pm
No, Super Glitch is something else. The end result is also corruption (in most cases), though.
And how much RAM gets overwritten depends on the sprite itself. It might also overwrite twice (if it goes into Echo RAM range), now that I think about it.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Sherkel on January 02, 2019, 08:10:07 pm
It's just the term I've always used for that amount of instantaneous changes in RAM. Part of me's stuck in the era before ZZAZZ's research revolutionized everything.

Why would it overwrite twice, in cases where it does?
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on January 03, 2019, 05:57:35 am
As I said, if it manages to reach Echo RAM. Reminder that Echo RAM is a mirror of WRAM, so the bytes would get a second corruption round if that happened.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: Parzival on January 03, 2019, 07:17:54 pm
As I said, if it manages to reach Echo RAM. Reminder that Echo RAM is a mirror of WRAM, so the bytes would get a second corruption round if that happened.
NOT ALL of the current WRAM banks though, as Echo RAM is smaller than the WRAM area.
Title: Re: Front Sprite Crashers Revealed! Pokemon Red/Blue
Post by: ISSOtm on January 03, 2019, 07:35:09 pm
It won't corrupt other WRAM banks, sure, but that's not what you're talking about when you say that Echo RAM is smaller than WRAM.
Indeed, $DE00-DFFF can't be corrupted twice. I guess that if stack space gets corrupted, the game will crash, anyways. Instantly. So my point seems to be moot :D