What nobody ever told you about MissingNo.

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 Pokémon 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 how that article turned out very much. 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?" I hope that it's 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 information. 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.

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 will tell 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. was a bunch of placeholders, but when the games were released, it became leftover 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 Pokémon that wasn't released until the next generation? Or were they simply placeholders, with the number of 190 Pokémon being merely an initial goal that the developers couldn't attain? Or was 190 just an arbitrarily chosen number of placeholders early on development so that they could keep adding more Pokémon 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 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 Pokémon. Unlike in the future generations, the Pokémon were internally indexed in a different order than the well-known Pokédex order, which seems to be related to the order that the Pokémon were designed. So, what does this have to do with anything? In that internal list there are not 151 Pokémon, but 190!

That's not entirely true either, though. Out of those 190, there are only 151 that you can actually call Pokémon, and you know which ones those are. So, rather than calling all of them Pokémon, 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? Also, why do they exist if they only bring problems and glitches?

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 a nonexistent Pokémon. That's sort of true, but not entirely. I mean, what kind of error handler causes the program to glitch?

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 Glitch Pokémon are becomes necessary. The reality is that the way the game is programmed, it's possible to reference up to 256 Pokémon at any time, even though there aren't that 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 Pokémon, it won't complain and will indeed give you the data it interprets as the 234th Pokémon, whatever that data is.

Now let's keep one thing clear. The fact that the game can reference 256 different Pokémon is not a bug; it's just a given feature 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 Pokémon #007 (Nidoking's index number). If a wild Pikachu appears, the game will read data from where Pokémon #084's (Pikachu's index number) data is stored. If, instead of Pikachu, the wild Pokémon 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 Pokémon 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 off. We've just seen that there are 151 Pokémon and 39 MissingNo., with the remaining 66 slots being something called Glitch Pokémon. So, what's the difference between MissingNo. and a Glitch Pokémon?

It's simple. As we've said, MissingNo. exists. Glitch Pokémon don't. It's just that MissingNo. doesn't exist as much as the real Pokémon, if that makes any sense. The 39 MissingNo. are indexed just the same way that Rhydon and Charmander are. That is to say, 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 Pokémon, but instead are 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 instead because, in a way, they had to. You have to consider that the way the different Pokémon data is stored and read from memory consists of placing the data of one Pokémon after another. For the names, for example, you will write every Pokémon's name one after the other ordered by the Pokémon's index numbers, and then, when you want to read the name of a certain Pokémon, you'll take the number of said Pokémon multiplied by the size of each name (ten 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 Pokémon number 70, which is Doduo. Doduo used Thundershock! Right, that doesn't sound good.

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 algorithm [Pokémon number * size of each entry] 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 Pokémon to the first 151 slots, but there could've been other functions that accounted for 190 as the total number of Pokémon. So, ultimately, it's easier and safer to just name each of those MissingNo. and write a couple of zeroes for each MissingNo. in the table that determines the learnset and evolution as well as their Pokédex Number identifier. And the developers 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 Pokémon is that the developers were more or less forced to assign some data to the former. Needless to say at this point, if the 190 Pokémon idea was never a thing, we'd have 104 Glitch Pokémon. 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 Pokémon that look different (but still as bad as MissingNo.) from each other.

Then, what's the actual difference between MissingNo. and Glitch Pokémon when it comes to what we see on 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 Pokémon, everything is absolutely random. If you remember the example of the building and the floors, if you ask the game for a Glitch Pokémon (e.g. #234), the game will give you data even if there's no a single bit of data assigned to that Pokémon. So, it will give you whatever happens to be in the memory area where the data of that Pokémon 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 Pokémon 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 Pokémon and Glitch Pokémon. Some of its data is fixed, but some of it is random; particularly, any data that comes within the Pokédex number rather than the index number. While all MissingNo. were given a Pokédex Number of 0 as previously stated, only data for Pokédex Numbers 1 to 151 exists, so it's much of the same story. I mean, MissingNo.'s infamous Bird typing 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 Pokémon, so some people think of it as an error handler because of that. Also, its name is legible and not just random characters, which helps the cause. However, you have to look no further than Pokémon Yellow, where MissingNo. will often crash the game immediately, or simply other localizations of Pokémon Red and 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 so "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, which is the reason why MissingNo. famously causes the Hall of Fame to look like absolute 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, unsurprisingly, the sprite data and size of Glitch Pokémon and MissingNo. is all random (but all MissingNo. share it, obviously). This is reflected in the fact that some Glitch Pokémon 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 why everybody wanted a MissingNo. back then. The first 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 Pokémon the player has encountered in an array of flags so that the Pokédex can be displayed accordingly (i.e. only displays the Pokémon you've seen). But there are only 152 flags, which are for Pokémon with Pokédex numbers between 1 and 152 (the reason why 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 Master Ball 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 Pokémon and error handler theories, the most creative (or clueless) stories will suggest things like that MissingNo. is Cubone's mother or Kangaskhan's 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 Pokémon 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 Pokémon usually referred to as 'M ('M being the only legible part of its garbage name) that looks the same as MissingNo. and can actually evolve into Kangaskhan. This 'M thing randomly happens to share the Pokédex 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? It's 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 Pokédex number, but the data that MissingNo was manually assigned to will be different, obviously. Nothing new to see here.

The second argument is that capturing MissingNo. causes the Pokédex to register Cubone as seen. Why? Because MissingNo. is actually Cubone. Yeah, no. The 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 while 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 [Pokémon number - 1]. MissingNo.'s Pokédex number of 0 will underflow, essentially making it Pokémon 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 Pokémon #104 in the Pokédex? 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 different from the other 36, as they show up as the Aerodactyl and Kabutops fossils and the 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 Pokémon 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 Silph Scope in your bag) the enemy's name is replaced with "GHOST". The key difference compared to the rest of the "real" Pokémon is that the game only ever needs a specific part of these three; only the front sprites of the Kabutops and Aerodactyl fossils are used, and the same goes for Ghost, as you should never be able to actually fight one. Even if the fossils' sprites are shown outside of battle, the function utilized is the same generic "sprite drawing" function, which simply takes the number of the Pokémon 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 Pokémon because they have no data. At least that's what you'd hear about them out there, because, in reality, they 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 Pokémon 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, as if they didn't, they would 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 Pokémon 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 Pokémon 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 Pokémon 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 Pokémon data is not a glitch, but merely an efficient use of memory, as the non-volatile memory in the Game Boy is far from unlimited. There are also other memory addresses that serve double purposes, possibly with 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 (about which has to be said that it actually belongs to Route 20), but the cause being that it has no wild Pokémon assigned is not true either; it does have the same wild Pokémon data assigned as the rest of the sea of Route 20 (it doesn't have grass wild Pokémon data, but it does have water wild Pokémon data). So, let's look a bit more into it.

It's actually very simple, to be honest; it's nothing but a simple programming oversight. The player's sprite occupies an area of 16x16 pixels in the overworld (regardless if you're 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 in:

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 Pokémon, the game goes through two different checks; the first check is to determine if Pokémon should appear, and the second check is to determine which kind of Pokémon (tall grass or water) should appear. To accomplish this, the game tests one of the tiles that the player is standing on and, based on that, determines which Pokémon to throw, if any. However, of the four available tiles, the game tests a different one for each of the two checks! Inaccuracies are incoming...

Let's start with the first check. For Pokémon 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 Pokémon will be 0% when standing on that tile, even if the map has wild Pokémon data assigned. Obviously, if the map has no wild Pokémon data assigned at all, no wild Pokémon will appear regardless, but Route 20 does have water wild Pokémon data with a 5% appearance rate (meaning that every step we take gives a 5% chance for a wild Pokémon to appear). The tile tested by the game in this case is the bottom right tile, which, if you check the image above, is a plain water tile. So far so good; we've passed the first check.

Now the game has decided that Pokémon can appear, so it just has to find out what kind of Pokémon. For this second check, if the tile tested is a plain water tile, water wild Pokémon will be loaded, while in any other case, (tall) grass wild Pokémon will be loaded. Even if we could somehow jump into the roof of a Pokémon Center, it will load grass Pokémon encounters assuming that the first check passed and that the map has actual wild Pokémon data assigned. The problem comes from the fact that the tile tested in this case is not the bottom right one, but instead 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 Pokémon 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 Pokémon 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 Pokémon 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 and similar Pokémon on the sea of Route 20 based on the last location we've been (which is already quite bad), but what if we had just had the old man teach us how to catch Pokémon and overwrite the wild grass data with our name characters in the process?

Boom.

« Previous Article

Home