Research MissingNo. explained (for real)

You probably won't know me, but if you do, you'd probably know me as the guy who discovered that Body Slam can't paralyze Normal-types in RBY along with a few other RBY in-battle glitches by tracking down the source code of Pokemon Red and Blue. Now, this is something I've been wanting to put together for a long time. Before you ask, this is not the first time I'm going to talk about MissingNo. here on Smogon, but the reality is that I don't like very much how that article turned out. Most of the stuff is too technical, and it barely gets into the most trivial points that are what everybody wants to read about. So hopefully this article will be a little more interesting. I want this to be the kind of article you can link to anyone who asks you something like "can someone explain wtf that missingno thing is?" As informative as possible and at the same time easy to read and understand.

There are plenty of MissingNo. guides out there, and they will tell you much of the same. That's the stuff everybody already knows, but I haven't seen anyone go much beyond that. They'll tell you a lot about the "how" but little about the "why". In this article I'm going to try to focus on the stuff that you can hardly see anywhere.

So let's start with a very trivial question. Is MissingNo. a placeholder, or is it a leftover? You'll see some people telling you the former, and other people telling you the latter. They sound like contradictory terms, but the reality is that it's hard to tell what is the most accurate one to describe MissingNo.. At some point of development, MissingNo. were placeholders, but then, when the games were released, they became lefotver data of those placeholders. So in a way, it's a mix of both. But can we go any further? Did those 39 placeholders actually hold data that got removed and was never shown to us? Did they contain information that could relate to a certain Pokemon that wasn't released until the next generation? Or were they just that, placeholders; with the number of 190 Pokemon being merely an initial goal that the developers couldn't make? Or what's more, was 190 just an arbitrarily chosen number of placeholders early on development, so that they could keep adding more Pokemon whenever they wished? Unfortunately that's something you cannot know unless you were one of the programmers who developed the game.

39? 190? Where do those numbers even come from? You'd likely already know the story, but if you don't, you will at least know that the first generation consisted of a total of 151 Pokemon. Unlike in the future generations, the Pokemon were internally indexed in a different order than the well-known Pokedex order; an order that seems to have relation with the order that the Pokemon were designed. So what does this have to do with anything? In that internal list there are not 151 Pokemon, but 190!

That's not entirely true either though. Out of those 190, there are only 151 that you can actually call Pokemon, and you know which those are. So rather than calling all of them Pokemon, let's just call them slots. Now let's get straight into the point. Why do those 39 slots even exist if they are useless? What's more, why do they exist if they only bring problems and glitches?

And this is what most MissingNo. guides usually fail to explain. Most of them seem to agree that the point of MissingNo.'s existence is to act as an error handler, in the sense that the game throws MissingNo. when it is asked about an unexistent Pokemon. That's sort of true, but not entirely. I mean, what kind of error handler causes the program to glitch up?

The funny thing is that actually, MissingNo. is good for the game's integrity. It doesn't crash the game, or corrupt the game's data too much, but we'll talk about this later. I think we've just gotten to the point where explaining what the things known as Glitch Pokemon are becomes necessary. The reality is that the way the game is programmed, it's possible to reference up to 256 Pokemon anytime, even though there aren't as many. If you asked some random person about who lives in the eight floor of a seven-floor building they'll respond that there are only seven floors. But if you ask the game about the 234th Pokemon, it won't complain and will indeed give you the data it interprets as the Pokemon number 234, whatever that data is.

Now let's keep one thing clear. The fact that the game can reference 256 different Pokemon is not a bug, it's just a given of the processor's architecture. The bug is to actually let the game reference them. Normally that shouldn't happen because... it makes no sense to happen; for example, if you send Nidoking into a battle the game will be asked to retrieve certain data about the Pokemon #007 (Nidoking's index number). If a wild Pikachu appears, the game will read data from where Pokemon's #084 (Pikachu's index number) data is stored. If instead of Pikachu the wild Pokemon is the number #031 (MissingNo.), it will look for data matching the 31st entry. But yeah, that shouldn't happen, right?

But it does. There are quite a few bugs in Pokemon Red, Blue, and Yellow that can be exploited. The infamous "Old Man glitch" is one you most likely have heard about. And there are more. Anyway let's go back to where we left it. We've just seen that there are 151 Pokemon, 39 MissingNo., with the remaining 66 slots being something called Glitch Pokemon. So what's the difference between MissingNo. and a Glitch Pokemon?

Simple. As we've said, MissingNo. exists. Glitch Pokemon don't. It's just that MissingNo. doesn't exist as much as the real Pokemon, if that makes any sense. The 39 MissingNo. are indexed just the same way Rhydon and Charmander are. That is, they have a number. One key piece of information that hasn't been mentioned yet is the fact that the 39 MissingNo don't come after the real Pokemon, but scattered between them. For example, you have two MissingNo. sitting at numbers 86 and 87, while the numbers 85 and 88 are Raichu and Dratini, respectively.

If you remember, we said that MissingNo. being an error handler was not entirely true, even though it sort of contributes in that regard (yeah, it could've been worse). Anyway, let's say it simply; it exists because it's much easier if it does. If all MissingNo. are explicitly named MISSINGNO. and were given no level up learnset or evolution on purpose, it's not because the programmers bothered to, but because, in a way, they had to. You have to consider that the way the different Pokemon data is stored and read from memory consists on placing the data of one Pokemon after another. For the names, for example, you will write every Pokemon's name one after the other ordered by the Pokemon's index numbers, and then when you want to read the name of a certain Pokemon, you'll take the number of said Pokemon multiplied by the size of each name (10 bytes) and head to that position in memory. That means, if Pikachu is number 84, you will read the name at position 84, regardless of whether there are 14 MissingNo. before Pikachu or not. If you didn't assign a name to each of those 14 MissingNo., you'd be naming Pikachu after the Pokemon number 70, which is Doduo. Doduo used Thundershock! Right, that doesn't sound well.

This doesn't mean that there is no way around not assigning names (and similarly other data) to MissingNo., but just that's it's much more difficult. A function to read data from the position output by the simple [Pokemon number * size of each entry] algorithm is easy to implement, whereas a function that has to account for every single instance of MissingNo. in order to skip it is more complex. Another option would be to reassign the 151 real Pokemon to the first 151 slots, but there could've been functions that accounted for 190 as the total number of Pokemon. So, ultimately, it's easier and/or safer to just name each of those MissingNo, and write a couple of 0's for each MissingNo. in the table that determines the learnset and evolution as well as into their Pokedex Number identifier. And they named them "MissingNo." simply because they could; I mean, why name them 3T/Pj9N.u or WERTYUIOP when you can just name them MISSINGNO. (or whatever the equivalent name in japanese is)?

So as we've seen, the difference between MissingNo. and Glitch Pokemon is that they were more or less forced to assign some data to the former. Needless to say at this point, if the 190 Pokemon idea was never a thing, we'd have 104 Glitch Pokemon. This is what some MissingNo. guides fail to illustrate, and it's that if we didn't have those 39 MissingNo. we wouldn't magically solve all the problems, but we'd just have 39 more Glitch Pokemon that look different (but equally bad as MissingNo.) to each other.

Then, what's the actual difference between MissingNo. and Glitch Pokemon when it comes to what we see in the Game Boy screen? Because some data was manually assigned to MissingNo., it's fixed for the 39 of them. But when the game has to show a Glitch Pokemon, everything is absolutely random. If you remember the example of the building and the floors, if you ask the game for a Glitch Pokemon (e.g. #234) the game will give you data even if there's no a single bit of data assigned to that Pokemon. So it will give you whatever happens to be in the memory area where the data of that Pokemon should be. If that data were to be the famous "I like shorts! They're comfy and easy to wear!" text, the game could be interpreting the hexadecimal identifier of the character 'l' as the level at which that Glitch Pokemon learns the move that shares the number with the character 'i'. That's never the case, but you get the point.

So MissingNo. is sort of a middle ground between real Pokemon and Glitch Pokemon. Some of its data is fixed, but some other is random; particularly, any data that comes within the Pokedex number rather than the index number. While all MissingNo. were given a Pokedex Number of 0 as aforementioned, only data for Pokedex Numbers 1 to 151 exists, so it's much of the same story. Heck, MissingNo.'s infamous Bird-type comes from some random trainer using a Voltorb, whose index number matches the index number of the Bird-type, so it really is that bad. If you wanted, you could actually track down MissingNo.'s properties by interpreting the memory area it retrieves data from. Still, as bad as it may be, MissingNo. doesn't immediately freeze or crash the game unlike some Glitch Pokemon, so some people think of it as an error handler because of that. Plus its name is legible and just not garbage and random characters, which helps the cause. However, you have to look no further than Pokemon Yellow, where MissingNo. will often crash the game immediately, or simply other localizations of Pokemon Red/Blue. This has mostly to do with the decompression of the (garbage) sprite. Some glitch sprites will go through, but some won't. Generally, it would be because the sprite is too "big" that it overflows the sprite buffer corrupting different areas of memory, which may be fatal. Often, the sprite will be large enough to overflow into the Hall of Fame data but not large enough to corrupt other vital areas of memory, this being the reason why MissingNo. famously causes the Hall of Fame to look absoultely trash (note that "large" and "big" aren't the most accurate words to use here but let's leave it like that for simplicity). And surprise, surprise, the sprite data and size of Glitch Pokemon and MissingNo. is all random (but all MissingNo. share it, obviously). This is reflected in the fact that some Glitch Pokemon will crash the game and others won't, although there can be other factors.

Let's be honest for a moment. There are two reasons everybody wanted a MissingNo. back then. One was that having MissingNo. automatically made you cool and the second is that it allowed you to have infinite Master Balls and Rare Candies. Nobody knew exactly why, but that didn't matter. The explanation is actually very simple though. The game keeps track of the species of Pokemon the player has encountered in an array of flags, so that the Pokedex can be displayed accordingly (i.e. only displays the Pokemon you've seen). But there are only 152 flags, for Pokemon with Pokedex numbers between 1 and 152 (the reason there is space for 152 flags and not 151 is because they are grouped eight by eight, i.e. in bytes). When the game attempts to set MissingNo.'s seen flag, it will overflow into the memory area where the items in your bag are stored. A flag is just a bit, and setting it is nothing but writing 1 into that bit if it was 0. In particular, MissingNo.'s seen flag happens to fall into the memory address that stores the quantity of the item in the sixth position of the bag, affecting the highest bit of said 8-bit memory address. Now it's just about converting the binary number 10000000 (each digit represents a bit, with the first digit being the highest bit) to decimal and noticing how it outputs 128. It doesn't make sense to have 128 stacks of an item because the limit is 99, so it essentially means that the sixth item quantity will get increased by 128. So just put a Masterball there, have a MissingNo. encounter, and gotcha! Childhood dream complete.

While most of the stuff you can find about MissingNo. out there will guide you towards the 190 Pokemon and error handler theories, the most creative (or clueless) stories will suggest things like that MissingNo. is Cubone's mother or Kangaskhan pre-evolution, or other stuff I don't want to remember. These theories are exciting and actually make enough sense to be believed by a lot of Pokemon fans. It's easy to see where all of this comes from though. The first argument to support this theory is that MissingNo. evolves into Kangaskhan. Well, that's false. But there's an also famous Glitch Pokemon usually referred to as 'M ('M being the only legible part of its garbage name) that looks the same as MissingNo. and does actually evolve into Kangaskhan. This 'M thing randomly happens to share the Pokedex number with MissingNo., leading to them having the exact same sprite, same stats, and same side effects. So why don't MissingNo. and 'M share the same evolution data? Because the former's is blank (i.e. null, harcoded as a couple of 0's), while the latter's is random. The data that is random for MissingNo. (i.e. read from unrelated memory areas) will be shared with 'M as a consequence of sharing the Pokedex number, but the data that MissingNo was manually assigned to will be different, obviously. Nothing new to see here.

Second argument is that capturing MissingNo. causes the Pokedex to register Cubone as seen. Wtf, why? Because MissingNo. is actually Cubone. Yeah. No. Same thing that occurs with the encounter flags, applies to the caught flags. When the game attemps to set MissingNo.'s caught flag, it overflows into the seen flags and sets Cubone's flag instead. The explanation? Simple. You just have to notice that whereas Bulbasaur is number #001, its flag is actually at position 0, i.e. displaced 0 positions with respect to the beginning of the flag array. In other words, the game will always attempt to set the flag at position [Pokemon number - 1]. MissingNo.'s Pokedex number of 0 will underflow, essentially making it Pokemon number 256, even though the seen and caught flag arrays are just 152 bits long. So now, what's 256 - 152? 104. And which is Pokemon #104 in the Pokedex? Cubone. Yikes!

At this point you may also wonder where the three "special" MissingNo. come from. In case you didn't know it, 3 of the 39 MissingNo. (the last three, with index numbers of #182, #183 and #184) look differently to the other 36, as they show as the Aerodactyl and Kabutops fossils and Ghost, respectively. This definitely doesn't look like a coincidence and in fact it isn't, but don't worry, because, as always, there is an explanation for it.

The difference is that these three MissingNo. actually follow a real purpose. The fossils are the Pokemon shown in the Pewter Museum of Science and the Ghost is just the same Ghost you stumble upon in Lavender Town, with the exception that when you enter a battle of a specific type (triggered by being in Lavender Tower and not having the Shilp Scope in your bag) the enemy's name is replaced with "GHOST". The key difference compared to the rest of "real" Pokemon is that the game only ever needs a specific part of these three; only the front sprite of Kabutops and Aerodactyl fossils is used, and the same goes for Ghost, since you should never be able to actually fight one. Even if the fossils' sprite is shown outside of battle, the function utilized is the same generic "sprite drawing" function, which simply takes the number of the Pokemon as an argument and prints its front sprite in the screen.

An interesting fact about these three MissingNo. is that they take the data of the previously used Pokemon because they have no data. Or at least that's what you'd hear about them out there, because well, they actually share the same data with the other 36 MissingNo.. It's just that it's never loaded. The function that loads the base data of a Pokemon into memory is the same one that loads the front and back sprite pointers (a pointer is a number that indicates where the thing being pointed can be found at in memory), basically because the sprite pointers are also part of the base data. The fossil and Ghost MissingNo. have their own sprite handlers, since if they didn't, they will show up just like a regular MissingNo. would, and I think you will agree with me that it definitely wouldn't look pretty in the museum. These special handlers are implemented in the base data loading function in a way that executing them means to skip the part where the rest of the data is loaded (including the back sprite), which translates to the data of the previous loaded Pokemon being kept.

You know, it's hard to talk about MissingNo. and not even mention the Old Man glitch. I bet you've already heard about it plenty of times. Let's begin with the stuff we all know; the old man tutorial causes the player's name to be temporarily written into the memory area where the tall grass wild Pokemon data is stored, so that the game can print 'OLD MAN' instead of your name. Then, the typical MissingNo. guide will follow this up saying something like "The right shore of Cinnabar Island has no Pokemon assigned", and label the old man tutorial as the cause of the glitch. That's not true though. The OLD MAN string temporarily overwriting the grass wild Pokemon data is not a glitch but merely an efficient use of memory, as the non-volatile memory in the Gameboy is far from unlimited. There are also other memory addresses that serve double purposes, perhaps one related to the overworld and another one related to in-battle stuff. If each of these double usages entailed a glitch, the game would be absolutely unplayable. The glitch does indeed come from Cinnabar Island's shore (which has to be said that it actually belongs to Route 20), but the cause being that it has no wild Pokemon assigned is not true either; it does have the same wild Pokemon data assinged as the rest of the sea of Route 20 (doesn't have grass wild Pokemon data, but does have water wild Pokemon data). So let's look a bit more into it.

It's actually very simple to be honest; nothing but a simple programming oversight. The player's sprite occupies an area of 16x16 pixels when anywhere on the overworld (no matter if walking or surfing). 8x8 pixels form a tile, so it's the same as saying that the player occupies an area of 2x2 tiles. Similarly, an area of 4x4 tiles forms a block, so for example, a block of Cinnabar's shore would be this one:



In particular this is the half-block (2x2 tiles) we are interested on:



Now divide that half-block into four tiles of the same size and notice how you get two different types of tiles: the right two tiles are plain water, while the left two tiles are part of a ledge.

So you may be wondering, what does this have to do with anything? Before generating a wild Pokemon, the game goes through two different checks; one to determine if Pokemon should appear, and a second check to determine which kind of Pokemon (tall grass or water) should appear. To accomplish this, the game tests one of the tiles the player is standing on, and based on that determines which Pokemon to throw, if any. However, of the four available tiles, the game tests a different one for each of the two checks! Innacuracies are incoming...

Let's start with the first check. For Pokemon to appear at all outside of a cave or a dungeon, the tile tested must match either a tall grass or a plain water (sea/lake) tile. If it doesn't, the appearance rate of wild Pokemon will be 0% when standing on that tile, even if the map has wild Pokemon data assigned. Obviously, if the map has no wild Pokemon data assigned at all, no wild Pokemon will appear regardless, but Route 20 does have water wild Pokemon data with a 5% appearance rate (meaning that every step we take gives a 5% chance for a wild Pokemon to appear). The tile tested by the game in this case is the bottom right tile, which, if you check the image above, you can see it's a plain water tile. So far so good, we've passed the first check.

Now the game has decided that Pokemon can appear, so it just has to find out what kind of Pokemon. For this second check, if the tile tested is a plain water tile, water wild Pokemon will be loaded, while in any other case, (tall) grass wild Pokemon will be loaded. Even if we could somehow jump into the roof of a Pokemon Center, it will load grass Pokemon encounters assuming the first check passed and that the map has actual wild Pokemon data assigned. The problem comes from the fact that the tile tested in this case is not the bottom right one, but the bottom left tile! If you check that one out in the image, you'll realize how it doesn't match a plain water tile, causing the game to load grass encounters when standing on that half-block.

Wait a second, didn't the grass wild Pokemon data get overwritten with garbage during the old man tutorial? Why wouldn't the programmers make it so that whenever we enter a new map, the wild Pokemon data is updated with the corresponding data of the new map? Well, they did it, but with a little nuance: the water and grass wild Pokemon data are updated only when the new map has any data assigned of that type. This means that when we Fly to Cinnabar Island from Viridian City and then head to Route 20, only the water wild data is updated, but the grass wild data is kept untouched. Normally, this would translate to encountering Pidgey's and similar stuff on the sea of Route 20 based on the last Route or map we've been (which is already quite bad), but what if we had just had the old man teach us how to catch Pokemon and overwrite the wild grass data with our name characters in the process?

Boom.
 
Last edited:

McMeghan

Dreamcatcher
is a Tournament Director Alumnusis a Tiering Contributor Alumnusis an Administrator Alumnusis a Battle Simulator Moderator Alumnusis the 5th Smogon Classic Winneris the Smogon Tour Season 14 Championis a Past SPL Champion
Excellent read once again coming from you Crystal_. This one was particulary well explained, I understood everything on the first try, granted I'm familiar with your articles by now!

Is there any other event in the game that overwrite the wild grass data, similarly to the Old Man thingy?
 
hey, thanks for the feedback, McMeghan! <3

You can corrupt the wild Pokemon data memory through arbitrary code execution using item 8F (a glitch item), but if you are using that with the only goal of getting MissingNo. there are probably more efficient ways to do so.
 
This is the most excellent explanation I ever read about Missingno. I applaud you for your efforts. I knew some of this but I didn't know about Missingno being 31 different identical "Pokemon". And your discussion about the sprites was informative. It's all stuff I, nor probably a lot of others, really bothered to care.



And you unknowingly helped explain another glitch in your last paragraph - how we can catch Safari Zone Pokemon there too. Since you can fly from there, you can do the same thing as the old man glitch. Not Missingno but still something that I felt added on to this.

Also, can't you somehow do the same from Seaform too? I heard it was possible.
 
Also, can't you somehow do the same from Seaform too? I heard it was possible.
You can do it from anywhere with the same tileset and that same half-block. Seafoam's shore works for that reason, so would the route below Pallet Town if it wasn't because there's tall grass tiles with their own grass wild data there (so it will always load those grass encounters).
 
What a very detailed read. Growing up Missingno was definitely the rage because everyone wanted the masterballs and rare candies. I've tried on numerous accounts to try to get it but i think by yellow version they fixed that problem. at least it wouldn't work for a japanese yellow version
 
I know this is the reason why certain grass tiles in Viridian Forest and the Safari Zone will never have encounters, because their bottom-right subtile is a flower instead of a grass subtile, and flower subtiles cannot give encounters. But I've heard that the same Viridian Forest/Safari Zone oversight doesn't occur in the original Red/Green. Does Japanese R/G check different subtiles? (I've also heard that R/G simply checks the bottom-left subtile in both cases, which would fix the Viridian Forest oversight (supported by the fact that no grass tiles have a flower in their bottom-left subtile) but also would cause there to be no encounters at all on the Cinnabar edge shore. Is this true?)
 

xfix

is a Battle Simulator Administratoris a Community Leaderis a Programmer
Community Leader
I know this is the reason why certain grass tiles in Viridian Forest and the Safari Zone will never have encounters, because their bottom-right subtile is a flower instead of a grass subtile, and flower subtiles cannot give encounters. But I've heard that the same Viridian Forest/Safari Zone oversight doesn't occur in the original Red/Green. Does Japanese R/G check different subtiles? (I've also heard that R/G simply checks the bottom-left subtile in both cases, which would fix the Viridian Forest oversight (supported by the fact that no grass tiles have a flower in their bottom-left subtile) but also would cause there to be no encounters at all on the Cinnabar edge shore. Is this true?)
(disclaimer: I wrote this post on a phone, so it's less detailed than I would like it to be)

In short, Japanese version uses bottom left tile for determining both if encounter is possible and a type. For some reason, international versions changed the tile determining whether encounter can occur to bottom right without changing tile determining encounter type. This introducrs Cinnabar Coast glitch, and disables encounters on certain tiles in Safari Zone and Viridian Forest.

Here is a screenshot I gave camper from Glitch City Laboratories while demonstrating the issue.



Excellent read once again coming from you Crystal_. This one was particulary well explained, I understood everything on the first try, granted I'm familiar with your articles by now!

Is there any other event in the game that overwrite the wild grass data, similarly to the Old Man thingy?
Trading Pokemon. In fact, this is how the glitch was discovered originally, by performing in-game trade in Cinnabar Lab.
 
Last edited:
In short, Japanese version uses bottom left tile for determining both if encounter is possible and a type. For some reason, international versions changed the tile determining whether encounter can occur to bottom right without changing tile determining encounter type. This introducrs Cinnabar Coast glitch, and disables encounters on certain tiles in Safari Zone and Viridian Forest.
Okay, I think that matches what I have? Is it true then that no wild Pokemon at all appear on the east coast of Cinnabar in Japanese R/G? (Since the bottom left subtile is land there.)
 
Okay, I think that matches what I have? Is it true then that no wild Pokemon at all appear on the east coast of Cinnabar in Japanese R/G? (Since the bottom left subtile is land there.)
If it checks the bottom right tile, then no, because it's a ledge tile.

I knew about the special blocks in viridian forest not loading encounters from some old speedrun video I watched, and maybe, just maybe, the reason the tile checked got changed in international versions was because they wanted to make viridian forest have less encounters based on that special tile. Not all of the viridian forest half blocks have the flower in the same position and it looks like none of them has the flower in the bottom left tile. Maybe they modified one of the checks, but forgot about the other. Just a random guess.
 
Last edited:
They supposedly fixed the old man glitch in Yellow version, yet you can still make Pokemon that normally appear in grass appear along the eastern shore of the Seafoam Islands.

You can use this to encounter wild Chansey, if you need one in Yellow version.
 
This reminds me, if MissingNo. is encountered via the Mew glitch or a Gameshark (in Yellow), then the text "Wild MissingNo. appears!" loops and the game freezes after that.
 
Yellow MissingNo. falls into what I considered a too large sprite in the artcile. Its front sprite pointer points to a 0x00 byte. I don't know exactly how the decompression routines handle this, but this and a width value of 0 seem to be the causes for the game crashing during the decompression of the sprite. During its decompression, Yellow MissingNo.'s sprite will overflow into WRAM corrupting key memory addresses, often causing the game to freeze. I don't know the specifics, but apparently, it has to do with the music rom bank address being corrupted.
 

Users Who Are Viewing This Thread (Users: 1, Guests: 0)

Top