Re: The exact reason why unstable missingno crashes.
Posted by: TheSixthItem
Date: 2017-04-23 21:29:24
https://youtube.com/watch?v=eLuUWUeUTg4
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.
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.
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.