April 24, 2017, 06:56:36 pm
0 Members and 1 Guest are viewing this topic.
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.
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.
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.
Page created in 0.078 seconds with 17 queries.