Main Menu
Main Page
Forums
New pages
Recent changes
Random page
Help

Glitches
Arbitrary code execution
Pokémon cloning
Pomeg glitch and Glitzer Popping
Tweaking and voiding
Glitches by generation
Other glitch categories

References/Resources
Databases
Disassembly projects
The Big HEX List
Interactive tools
Reference documents
Terminology

Affiliates
Legendary Star Blob 2 (Hakuda) (日本語/Japanese)
Pokémon Speedruns wiki (English)
PRAMA Initiative (Français/French)
MissingNo. Glitch City (Italiano/Italian)
Become an affiliate!

Technical
Site source code

Search Wiki

 

Search Forums

 

Author Topic: The exact reason why unstable missingno crashes.  (Read 6694 times)

0 Members and 1 Guest are viewing this topic.

TheSixthItem

  • Game breaker
  • GCLF Member
  • *
  • Offline Offline
  • Gender: Male
  • ZZAZZDZZGZZUZZKZZ#ZZXZZUZZ7ZZ#ZZ
    • View Profile
Re: The exact reason why unstable missingno crashes.
« Reply #15 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
I do things

Evie the Bird Mother 🌸 ☽

  • Veteran Contributor
  • *
  • Offline Offline
  • Gender: Female
  • ああ、紅茶がおいしい。 ~ ^^
    • View Profile
Re: The exact reason why unstable missingno crashes.
« Reply #16 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.
« Last Edit: March 10, 2020, 08:44:57 am by Evie (retired from head adminship) »
(I was former joint head admin but stepped down)
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Here have some free flowers on every post. ^^
✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿✿
Love, faith, hope are free. If all is lost friends save us.
Thanks fans for lovely Torchic artwork. ♡ First image thanks Nyapon.