Glitch City Laboratories Forums

Lab γ: Video Games and Glitches Discussion => Pokémon Glitch Discussion => Generation I Glitch Discussion => Topic started by: Evie the Bird Mother 🌸 ☽ on November 16, 2014, 03:34:06 pm

Title: The exact reason why unstable missingno crashes.
Post by: Evie the Bird Mother 🌸 ☽ on November 16, 2014, 03:34:06 pm
This is just a question I'd like to raise, out of interest and maybe for something practical. Is there some way without cheats or tools to control whether a regular Missingno. (not fossil or ghost) you get from Trainer-Fly will freeze the game?

I've noticed a difference in effects if I invert the sprites by viewing the sprite of a glitch Pokémon before encountering Yellow Missingno. I also tried Missingno. sprites from 'different banks (http://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9mon_base_stats_data_structure_in_Generation_I#Sprites)', but I forgot Missingno.'s sprite pointer, it could be in bank 0 which would make the bank irrelevant or if it's actually the sprite dimensions that matter.

I know that getting regular Missingno. doesn't have much use. The fossil and ghost Missingno. can also duplicate your items. But it may be significantly easier to get an applicable lower Special than 181-183.

Additionally, regular Yellow Missingno.'s extremely high experience cap makes it an ideal donor for merging two Pokémon together. You can get a "perma" level 255 Missingno./X-x hybrid this way, and the base stats would be those of X-x's.

I do have a solution to my problem. You can do the item underflow glitch by encountering a fossil or ghost Missingno. first and getting a stack of 255 Potions, get the items for Lol glitch (https://www.youtube.com/watch?v=7klMjrBPLkU) and then do a Lol glitch here (nets you a hex:43 Missingno.)

(http://i3.minus.com/i4w0kOnR4Pk0.png)

But for what I want to do, I thought encountering fossil and ghost Missingno. and getting the lol glitch items would take significantly longer than successfully getting/seeing regular Missingno. (incidentally ExtraTricky's double Trainer-Fly method (http://forums.glitchcity.info/index.php/topic,6638.msg196396.html#msg196396) apparently gives you a 1/8 chance of encountering a special Missingno. if you do a double Trainer-Fly with the level 80 Starmie from the Cubone for Machoke trade).

Edit: Remaining HP glitch may also be able to give you regular Missingno. or a Pokémon with the CoolTrainer move as move 1 for Yellow's only CoolTrainers (Missingno. and Horsea). It's a shame that box 1 has to never have been filled for that.
Title: Re: The exact reason why unstable missingno crashes.
Post by: Bert on November 16, 2014, 04:06:57 pm
Yellow MissingNo is one volatile dude.

In my experience, I've had the most luck with the Channelers in Pokémon Tower. I think several (at least 3) of the Fishermen on Route 12 will spawn MissingNo and have a very low chance of freezing/crashing the game.
Title: Re: The exact reason why unstable missingno crashes.
Post by: Evie the Bird Mother 🌸 ☽ on November 16, 2014, 04:17:36 pm
Yellow MissingNo is one volatile dude.

In my experience, I've had the most luck with the Channelers in Pokémon Tower. I think several (at least 3) of the Fishermen on Route 12 will spawn MissingNo and have a very low chance of freezing/crashing the game.

Thanks for the tip. I tried a Channeler but unfortunately still got freezes. I'll try the Fishermen next.

If you want to look up the Trainer yields, I recommend this huge image (http://puu.sh/257S), but it's not fully accurate for Yellow due to roster changes between Red/Blue and Yellow.

Edit: I'm not getting much different results. It could be something specific in the memory that's affecting it, but I'm not very good at using a debugger. Bert, can I use your save if you've got one where it works, please?
Title: Re: The exact reason why unstable missingno crashes.
Post by: Bert on November 16, 2014, 04:27:53 pm
...Everything I said suddenly becomes hypocritical since I can't even test this myself. My Yellow Version is still a glitchy mess and Trainers still send out level 0 Pokémon with boatloads of HP. That's assuming I can even fly to one of those locations instead of getting thrown into battle against a Trainer after choosing 'Fly.'

It's all based on my memory anyway.

That's a great image! Kudos to the creator.
Title: Re: The exact reason why unstable missingno crashes.
Post by: Evie the Bird Mother 🌸 ☽ on November 16, 2014, 04:30:16 pm
Oh, OK. Thanks anyway. Incidentally on my BGB save I get "Missingno. is trying to learn", while on my VBA save I just get a freeze. I've yet to test if it's due to me using different emulators or if there's something about my save that's causing the differences.

Edit: Huh, that gives me an idea. Maybe I should open my Pokémon menu in that Celadon Mansion anti-Super Glitch spot, then immediately cheat a Missingno. by altering D058 (011F58D0). I know this is likely completely unrelated though.
Edit 2: Nope, didn't work lol. I should try using BGB debugger, even though I'm not too experienced with it.
Edit 3: It's not ''completely'' unpredictable, because from the same state I've got the game trying to run the same invalid opcode in the ROM (3F:6BE9) even after waiting a little/doing things before closing the menu. I was doing what I did above though in the anti Super Glitch spot.
Edit 4: The game apparently did a 'call 6BD4' at 0:2314 to get to that invalid opcode.

Edit 5: So I was tracing through things, and the game was doing this to this sprites (drawing blackness and moving sprites down). The game repeated the code at RO2F:7482 a lot, where there is a jr nz, 7482 at 2F:7486.

(http://i2.minus.com/ijTYpwzqxTQ2J.png)
(http://i5.minus.com/ifElySFAfTuAA.png)
Title: Re: The exact reason why unstable missingno crashes.
Post by: luckytyphlosion on February 28, 2015, 05:37:38 pm
Today, I decided to look into unstable missingno once again, and this time, I found something interesting and very useful.

Unstable Missingno's sprite is too large, so it overflows into WRAM, and corrupts the audio addresses. Through some breakpoints (and a bit of luck), I was able to track down the cause of the crash.

The crash is due to wC0EF being overwritten, where wC0EF is a value that determines the music rom bank. The new ROM bank swapped to will most likely cause a crash, unless you get really lucky because for some reason, wC0EF can be "random". The randomness appears to be set every time you perform the tfly, but I don't know what exactly causes the randomness.

To see which ROM Bank is swapped to, simply put a(n) jump/execute breakpoint to 22EC.
Title: Re: The exact reason why unstable missingno crashes.
Post by: SatoMew on February 28, 2015, 05:48:15 pm
I don't know if you've watched it but Crystal_ has a video series on MissingNo.

https://www.youtube.com/playlist?list=PLLvtRtlPBbbir2XWF9T5UhGnOsYhJbD2Y
Title: Re: The exact reason why unstable missingno crashes.
Post by: luckytyphlosion on February 28, 2015, 05:59:01 pm
Oh, that video series documents about Red/Blue Missingno, which is different than Yellow Missingno. Yellow Missingno is infamous for crashing the game once it slides across the screen. The audio usually becomes corrupted too.
Title: Re: The exact reason why unstable missingno crashes.
Post by: SatoMew on February 28, 2015, 06:01:55 pm
Oh, that video series documents about Red/Blue Missingno, which is different than Yellow Missingno. Yellow Missingno is infamous for crashing the game once it slides across the screen. The audio usually becomes corrupted too.

Oops! I misunderstood the variant of MissingNo. you were referring to. My bad.
Title: Re: The exact reason why unstable missingno crashes.
Post by: Evie the Bird Mother 🌸 ☽ on March 01, 2015, 07:14:27 am
Merged because there was an existing thread related to this.

That is pretty enlightening, simply C0EF (and C0F0)!

Without any deeper knowledge, I will just speculate as food for thought:

Maybe there is a way to have Yellow Missngno. never freeze the game, if the value it becomes is not too random (and if you can change it to 02, 08, 1F, 20; valid sound banks or any 'safe for running from/catching Yellow Missingno.' glitch value).

Maybe if you can anticipate that the value is going to change to a glitch bank, then certain glitch banks will end up executing code in writable memory?
Title: Re: The exact reason why unstable missingno crashes.
Post by: camper on March 01, 2015, 11:39:50 am
Yellow Missingno. has a 10x13 sprite that's just enough to corrupt a small part of WRAM but not ALL of it like those #205 Pokemon in Red/Blue with 5x256 sprites. Its front sprite pointer is 0x0006 though, which is supposed to be constant, so it's the decompressing process that's varying...
Title: Re: The exact reason why unstable missingno crashes.
Post by: luckytyphlosion on May 18, 2015, 02:49:38 pm
After looking at Unstable/Yellow Missingno again, I've finally found out why it exactly crashes the game. Here's a summary of the first discovery, which I already covered in the previous post.


So if Unstable Missingno's Sprite overflows into WRAM, but the sprite data is clearly taken from ROM, then why do the effects seem random when encountering it?

The "randomness" of Unstable Missingno is (unsurprisingly) caused by the content of unused SRAM, more specifically $BF66 and $BF67. When the game decompresses Missingno's sprite, it clears the sprite buffers, but not the unused SRAM. This means that the bytes copied to the Music Banks will always be different. I'm not familiar with the decompression function, so I'm not exactly sure if other sram portions affect whether Unstable Missingno would crash or not.

In order to make Missingno stable, one would need to repeatedly encounter it until the SRAM bytes become re-written in a way that would write a stable music bank.
Title: Re: The exact reason why unstable missingno crashes.
Post by: camper on May 20, 2015, 01:30:21 am
After looking at Unstable/Yellow Missingno again, I've finally found out why it exactly crashes the game. Here's a summary of the first discovery, which I already covered in the previous post.

  • Unstable Missingno's Sprite has quite enormous dimensions (8x10 iirc?), which overflows into music and sprite related data. wc0ef and wc0f0 mark the bank in which the current music is stored in, so when its sprite is decompressed, those addresses are overflowed, which causes the game to run through garbage data and ultimately crash the game.

So if Unstable Missingno's Sprite overflows into WRAM, but the sprite data is clearly taken from ROM, then why do the effects seem random when encountering it?

The "randomness" of Unstable Missingno is (unsurprisingly) caused by the content of unused SRAM, more specifically $BF66 and $BF67. When the game decompresses Missingno's sprite, it clears the sprite buffers, but not the unused SRAM. This means that the bytes copied to the Music Banks will always be different. I'm not familiar with the decompression function, so I'm not exactly sure if other sram portions affect whether Unstable Missingno would crash or not.

In order to make Missingno stable, one would need to repeatedly encounter it until the SRAM bytes become re-written in a way that would write a stable music bank.

Unstable Missingno. has a dimension of 11x13.

So does it mean once you encounter Missingno. once in a save and it doesn't crash, it's safe to encounter it again?
Title: Re: The exact reason why unstable missingno crashes.
Post by: Crystal_ on May 22, 2015, 09:31:32 am
The problem with Yellow MissingNo is not its 10x13 sprite size at 0x39fcc (base stats data), but the first byte of its sprite data which is also supposed to be the sprite size. This size value is used during the decompression while the one in the base stats data is used during the "post-decompression" to determine how to arrange and where to place the decompressed chunks of the sprite on the screen. This is all I know though.

Yellow MissingNo.'s frontsprite pointer points to 0x0006 which is 0x00. This means both height and width of 0. These width (high nybble) and height (low nybble) values are multiplied by 8 and saved to W_SPRITEWIDTH and W_SPRITEHEIGHT. I don't really know what happens from here but if you change 0x0006 to anything between 0x01 to 0xFF (i.e. anything not 0 width AND 0 height) everything will be fine other than the well-known HoF corruption which is still very far from reaching WRAM.
Title: Re: The exact reason why unstable missingno crashes.
Post by: danny on March 17, 2017, 07:16:56 pm
Unstable Missingno. has a dimension of 11x13.

Wrong, 10x13. (Wow, bumping an entire thread just to add that little note.)
Title: Re: The exact reason why unstable missingno crashes.
Post by: TheSixthItem on April 23, 2017, 08:29:24 pm
Yellow missingno takes it's behavior from an unused chunk of data in SRAM bank 0 which can be quite random. thezzazzglitch made a video on stable yellow missingno using a method of arbitrary code execution
https://youtube.com/watch?v=eLuUWUeUTg4
Title: Re: The exact reason why unstable missingno crashes.
Post by: Evie the Bird Mother 🌸 ☽ on March 10, 2020, 08:42:32 am
The problem with Yellow MissingNo is not its 10x13 sprite size at 0x39fcc (base stats data), but the first byte of its sprite data which is also supposed to be the sprite size. This size value is used during the decompression while the one in the base stats data is used during the "post-decompression" to determine how to arrange and where to place the decompressed chunks of the sprite on the screen. This is all I know though.

Yellow MissingNo.'s frontsprite pointer points to 0x0006 which is 0x00. This means both height and width of 0. These width (high nybble) and height (low nybble) values are multiplied by 8 and saved to W_SPRITEWIDTH and W_SPRITEHEIGHT. I don't really know what happens from here but if you change 0x0006 to anything between 0x01 to 0xFF (i.e. anything not 0 width AND 0 height) everything will be fine other than the well-known HoF corruption which is still very far from reaching WRAM.

Hmm anyone know more?

Quote from: Wiki
Its base experience yield byte is 0x0B. Its sprite dimensions in the base data structure is 10x13, but actual sprite dimensions are 0x0. Its front sprite source pointer is 0x0006 and its back sprite source pointer is 0x0D0C with actual sprite dimensions of 6x6.