Inside the ROM: The deepest secrets of MissingNo. and Glitch Pokémon

Introduction

Discovered back around 1999 when Pokémon Gold and Silver were yet to be released, MissingNo. has become one of the most infamous glitches not only in the Pokémon world, but in the world of video games in general. Childish rumors about MissingNo. are everywhere and of every kind, going from that it can break your game to that it will attack you in a nightmare. The truth is, very few people really know about what MissingNo. is and why it exists. If you ask someone familiar with Pokémon about MissingNo., he will most likely be able to tell you that it is an "error Pokémon" or something of the sort; to a lesser extent, he will probably tell you a bit about its moves or typing (even if he mistakes MissingNo.'s Bird typing with the Flying type!), but hardly anyone knows the deepest secrets of MissingNo.'s or Glitch Pokémon's identities. With this article, I plan to introduce you to the world of Pokémon Red/Blue glitches by focusing on the inner workings and the structure of the games and, more specifically, on what causes MissingNo. and Glitch Pokémon to exist and be who they actually are. If you are the kind of person that has always found Pokémon glitches fascinating, this article is totally for you!

Before you continue, however, you should be aware of the advanced level of the article. This topic requires the reader to be constantly focused in order to grasp or interpret the different concepts and explanations that will be detailed in the article, from the most generic computer science to more advanced Pokémon structures and data of various Pokémon glitches stored in the Pokémon Red/Blue ROM (Read-Only Memory). This may sound a bit boring, but I promise you that if you concentrate, learning how the game is structured and, more specifically, discovering the deepest secrets of MissingNo. and Glitch Pokémon can be a very fun and interesting topic!

Hexadecimal numeration and game's internal structure

Before we get on-topic, there are some general concepts that, while not being directly related to Pokémon, must be comprehended in order to understand all that comes next.

Hexadecimal System, Bits, and Bytes

Hexadecimal numbers will be used in the article very often, as the data we are going to look at in the ROM is in hexadecimal format. Hexadecimal is another numeration like decimal or binary, but on a different base. More specifically, it is based on sixteen numbers:

A, B, C, D, E, and F represent the decimal equivalents of 10, 11, 12, 13, 14, and 15, respectively. The prefixes 0x and $ are used to indicate that the numerical system we are using is hexadecimal. So for example, 0x7C is the hexadecimal equivalent of 124.

A binary digit represents one bit because the possible values are only 0 and 1, which make a total of 2^1 combinations. Since a hexadecimal digit can take sixteen different values, or 2^4 values, it represents a total of four bits. Two hexadecimal digits combined make for 2^8 possible combinations, ranging from 0x00 to 0xFF, or 0 to 255 in decimal format. Thus, two hex digits combined represent a total of eight bits, which is the same as one byte. Bytes are extremely important in this topic, since the Pokémon games are structured internally by bytes. In Pokémon Red and Blue, each byte represents something and affects the game in some way, be it the level of a Pokémon, a letter of a text string, a part of one map, or anything else you can think of. As such, when looking at MissingNo. and Glitch Pokémon, we will have to analyze their data byte by byte.

Banks, Offsets, and Pointers

ROM Banks are groups of 0x4000 bytes and thus are 0x4000 bytes long. If for example, we are in the bank number 0x1C, it means we are in the bank starting at 0x4000 * 0x1C = 0x70000 and finishing at 0x74000.

Offset is a word used to refer to the position of a certain byte. When a byte is in the offset 0x345FA, it means that it is located in the position 0x345FA and that there are 0x345FA bytes coming before it. The Pokémon Red and Blue games have a size of 1 Megabyte or 1048576 bytes. In hexadecimal format, it translates to 0x100000, which means that the offsets we are going to look at may range between 0x0 and 0xFFFFF.

Pointers are slightly more complicated to understand. Essentially, a pointer "points" to a certain position or offset to tell the game that it should skip to that position to read data from it. For example, there is a pointer pointing to offset where the names of all Pokémon start. Most of the pointers we are going to deal with in the article are two-byte pointers, because they occupy two bytes and thus, four hexadecimal digits. These pointers usually point to an offset in the same bank, while the third byte on three-byte pointers is used to denote the bank the offset is located at.

Let's say our two-byte pointer is:

and that it is in the bank 0x07—that is, the bank starting at offset 0x1C000. Firstly, in the Pokémon games, pointers are little-endian (the least significant byte is stored before the most significant byte), which means we have to rotate the two bytes, resulting in:

Then we have to subtract 0x4000 to point to the correct ROM address. It's not easy to explain why it works that way, so just believe me!

Finally, because our two-byte pointer was located in the bank 0x07, the offset it points to will also be in that same bank. More specifically, it will be 0x1E21 bytes after the first offset of the bank 0x07. In other words, the pointer points to:

If we had not subtracted 0x4000 before, the bank we would be accessing would've been the first one (bank 0x00) because of how the Game Boy RAM is structured.

Index Number and Pokédex Entry

We are getting closer to the body of the article, but first, the difference between Index Numbers and Pokédex Entries in the Pokémon games is another key concept you will need to grasp in order to understand what will come next.

Quickly said, Pokémon are internally ordered and identified by Index Number, but the order in which we see them displayed in the game (in the Pokédex) is by Pokédex Entry. The Index Number order presumably follows the order in which Pokémon were made and inserted in the game. For example, Rhydon is a Pokémon we all know to have a Pokédex Entry of 112 or 0x70, but its internal Index Number is 0x01. In general, the Index Number order is messed up, as most evolutionary families aren't grouped together. As will be detailed in the following sections, excluding the number 000, the Pokédex Entry list contains 151 Pokémon, while the Index Number list contains 190. The reason is that the 39 extra Pokémon are MissingNo., which don't show in the table where Pokémon are ordered by Pokédex Entry and thus don't show up in the Pokédex. But what are 39 MissingNo. doing in the internal list of Pokémon? Read on...

What defines a Pokémon

Our next step will be to get used to how the data that defines a Pokémon is structured. MissingNo. and the glitches we are going to deal with are Pokémon after all, so understanding them will be easier if we look at the data of real Pokémon first. Now, think about everything that makes a Pokémon be who it is, even the most obscure characteristics; there are certainly a lot of things to consider, from the most basic like the name and typing, to the lesser known or relevant like height and weight or the growth rate. Everything is defined in the game in some way, in a few different structures. In this section, our objective will be to discover what each structure contains and how it works. It should be noted that, while the sprites and cries are obviously important parts of all Pokémon, their interpretation requires more advanced knowledge and thus will be left out from the article; in addition, the sprites of MissingNo. and the cries of both MissingNo. and Glitch Pokémon are all "garbage", since a combination of bytes that aren't meant to be images or music cause glitched or random sprites and cries, respectively.

Names

The names are obviously an elemental part of the Pokémon. Understanding how names work is simple, so it's a good starting point.

To find the Pokémon Names data, the pointer we have to look at is located at 0x2FAE and 0x2FAF, and this pointer is 0x1E 0x42. It points to a table containing all Pokémon names. It's a three-byte pointer, however, as the data it points to is at the bank 0x07. The third byte that indicates the bank is located a bit earlier, at offset 0x2FA3. Note that the bank byte doesn't necessarily have to be near the other two bytes, as it's read separately. Anyway, following what we saw about pointers in the previous section, we come to the conclusion that the offset we are looking for is 0x1C21E.

In fact, if we move to that offset, the first byte we see stands for the 'R' of Rhydon. We need to use the following table to translate hexadecimal numbers to the equivalent text character in Red/Blue:

The first thing we notice is that the Pokémon Names data is ordered by Index Number instead of by Pokédex Entry. We see this by the fact that the first Pokémon is Rhydon, followed by Kangaskhan, and so on. We'll see the relevance of this once we get into MissingNo. and Glitch Pokémon later.

Each entry is 10 bytes (or characters) long. Shorter names are filled up with [0x50], which is the terminator character in text strings. If we use a hexadecimal editor and load the aforementioned table, we'll see something like this:

General Pokémon Data

The General Pokémon data structure contains a lot of important and interesting information about the Pokémon, including stats, typing, and moves known at level 1. It starts at offset 0x383DE, but for curiosity, note that Mew's data is located at offset 0x425B instead. The General Pokémon data is structured by Pokédex Entry, meaning that it starts with Bulbasaur and ends with Mewtwo, and that there is data for 150 entries instead of 190. Each entry is 28 or 0x1C bytes long. We will look at what each byte stands for by using Bulbasaur's data as an example. As you would expect, it's located from offset 0x383DE to offset 0x383DE + 0x1C = 0x383F9:

Now let's go byte by byte:

Pokédex Data

The two structures we have just looked at shared one basic thing in common: every entry was of the same length. However, this is not the case with the Pokédex data structure, since, as we will see soon, the length will depend on the number of characters of the text string that determines the species of the Pokémon. In the previous two structures, the game could just move forward X bytes depending on the length of the entries of the structure and the Pokémon it wanted to access, and read data from there. However, this is not an option anymore. In the Pokédex data structure, a table of pointers containing a pointer for each Pokémon is necessary. This table is at offset 0x4047E.

Since this is the first pointer table we are going to deal with, it won't cause any harm to see how it looks:

Selected in green, you can see the whole pointer table. There are a total of 190 pointers, ordered by the Index Number of the Pokémon it points to—for example, the first pointer points to Rhydon's data and the second pointer to Kangaskhan's. As expected then, the table is 0x17C or 380 bytes long, as there are 190 two-byte pointers. Thus, the table ends at offset 0x405F9. It's not hard to notice a pattern in the table; using what we have learned about pointers, we know that the first pointer (0xFA 0x45) points to 0x405FA. Now if we look at the next pointer, we can see that the offset it points to is 0x40609, just a few bytes after the first one. This pattern repeats almost every time, the only exception being the pointers of all 39 MissingNo., which point to the same location, as will be expanded on later in a different section. Not only that, but Rhydon's Pokédex data happens to start right after the last pointer of the table, and, as seen from the pattern on the pointer table, the data of all other Pokémon, ordered by Index Number, follow Rhydon's.

Now that we understand how the pointer table works, we can move on with the data itself. The Pokédex data structure contains the following information:

We'll use Kingler as an example:

The selected bytes correspond to Kingler's Pokédex data. The first seven bytes (until the 0x50) determine the species of the Pokémon. Then, we can see Kingler's height is 4'03''. We can calculate its weight by rotating the two bytes (which are 0x28 and 0x05), converting them to decimal, and finally dividing the obtained number by 10. The result is 132 pounds.

Evolution / Learnset Data

The Evolution / Learnset data is accessed similarly to the way Pokédex data is. Since not every Pokémon evolves and learns the same amount of moves by leveling up, it's to be expected that entries can have different lengths and that, as a consequence, a pointer table is required. The table is located at 0x3B05C and works in a very similar way to the table we have just seen. It's ordered by Index Number and the data of the first Pokémon (Rhydon) starts right after the last pointer of the table, at 0x3B1D8. The only difference is that each MissingNo. points to a different location, but as we will see they all share the same data anyway, so it's a bit redundant.

Now let's move on with the structure of the data itself. Evolution / Learnset data is structured in two different parts, separated by a 0x00 byte. The first one refers to the evolution data, and the second one stands for the level-up moves learned by the Pokémon. To illustrate the format of the structure, Weepinbell's data will be used as an example:

As we've just seen, evolution data ends with the second 0x00. To translate evolution data, we'll have a look at the following structures:

Following the rules above, we come to the conclusion that the first byte (0x02) means that Weepinbell evolves by the use of an item. The second byte determines that Weepinbell evolves via Leaf Stone, whose ID is 0x2F. Lastly, the byte on Pokémon ID means that the Pokémon it evolves into is the one with an Index Number of 0xBE, which is Victreebel. Note that 0x01 in the item and trade evolutions just mean that the level required to evolve is 1, meaning that, in practice, only the item or the trade is required to make the Pokémon evolve. Eevee's evolution data is longer, as it contains data for three item evolutions:

Now let's go back to Weepinbell and take a look at its learnset data. It's not difficult to follow the structure; after the 0x00, the next two bytes mean that Weepenbell learns, at level 0x0D or 13, the move 0x23 or Wrap. From the next two bytes (0x0F and 0x4D), we see that at level 15 it learns Poisonpowder. And so on, until a 0x00 comes, causing Weepinbell's data to end and the next Pokémon's data (Victreebel) to start.

Why do MissingNo. and Glitch Pokémon exist?

Now, we know the concepts and understand the Pokémon structures required to move on and look at MissingNo. and Glitch Pokémon. You may be thinking, "Okay, they are some kind of bugged Pokémon that exist in the Red/Blue Pokémon games, but why do they exist?" The first thing you should know is that MissingNo. differs from the other Glitch or "Garbage" Pokémon in many aspects. The key is to be aware that all 39 MissingNo. are some kind of placeholders, so to speak. Presumably, placeholders for Pokémon that were planned to appear in the Red/Blue Pokémon games, but in the end did not. In fact, Shigeki Morimoto, one of the game's programmers, once said that there were actually 190 Pokémon planned to be included in the games. Furthermore, there are many fact-based theories that support this, as we will see in the following paragraphs.

The most evident proof is that all 39 MissingNo. have an Index Number assigned—just the fact that the game developers actually bothered to do that is pretty suspicious. As we saw, the order of the list of Pokémon by Index Number is all "messed up", and while some evolution families are together, some others are not, and for the most part, the order is not logical (say, starter Pokémon are in the end and legendary Pokémon occupy random places). In the matter at hand, the most interesting thing is that MissingNo.'s Index Number entries are all scattered between the entries of real Pokémon. For example, MissingNo. with an Index Number of 0x32 is located between Golem's and Magmar's entries. There is no better way to illustrate this than by linking to a Bulbapedia page that shows the list of Pokémon by Index Number. (By the way, note that the names in brackets near the MissingNo. entries on the page linked don't have anything to do with the Pokémon which was intended to exist in that position; it's just the Gold/Silver identifier equivalent).

To further support this theory, there are documents that prove that there were many designs or prototypes of Pokémon that were discarded (although these Pokémon could have been discarded long before the 151 Pokémon cut-off), and there are theories about GSC Pokémon that could have been planned to be released in the first generation. It's for example interesting that MissingNo. with Index Numbers of 0x56 and 0x57 are placed between evolution families that are ordered, and the same occurs for MissingNo. 0x5E and 0x5F (you can see what I'm talking about by having a look at the link above). This suggests that these four MissingNos. would have been two different two-evolution families.

To further support this theory, there are documents that prove that there were many designs or prototypes of Pokémon that were discarded (although these Pokémon could have been discarded long before the 151 Pokémon cut-off), and there are theories about GSC Pokémon that could have been planned to be released in the first generation. It's for example interesting that MissingNo. with Index Numbers of 0x56 and 0x57 are placed between evolution families that are ordered, and the same occurs for MissingNo. 0x5E and 0x5F (you can see what I'm talking about by having a look at the link above). This suggests that these four MissingNos. would have been two different two-evolution families.

Another interesting thing is that... well... MissingNo. has a defined name in the games, which is, in fact, MissingNo.. MissingNo. stands for nothing else than Missing Number, and if we scrolled down in the table of names that we saw before, we'll see some random "MISSINGNO." strings the same way we saw "RHYDON####" or "KANGASKHAN". It looks like when the creators decided that these 39 placeholders weren't going to be filled with Pokémon, they decided to call them MissingNo. (since they automatically had an entry in the Pokémon Names structure by the fact that this structure is ordered by Index Number) instead of leaving their names blank. This, or "MISSINGNO." was used as a placeholder name until it was replaced with the name of the Pokémon that was supposed to be added there.

Yet more important, or at least interesting, is something we can see from some MissingNo. cries. While I said we wouldn't get into cries, it's definitely interesting to have a look at the table that assigns a type of cry to each Pokémon. For those interested, this table starts at offset 0x39446. It contains the base cry, pitch, and length of the cry (one byte each) of each Pokémon ordered by Index Number. Most MissingNo. have [0x00][0x00][0x00] as their cry data; since 0x00 is also the base cry of Nidoran-M, most MissingNo. cries resemble Nidoran-M's cry. However, a total of nine MissingNo have different cry data, eight of them differing in base cry as well. The most interesting of all is the cry of MissingNo. 0xB5, which is almost exactly like Crobat's cry in the GSC games; it shares the base cry of Zubat and Golbat (as well as Tauros, Squirtle, and Wartortle), but has a different pitch (0x00), making it very similar to Crobat's cry. It may very likely have been just a beta cry... or might have not! There are other MissingNo. cries that, for example, share the base cry of the Dratini family, while 0x45 MissingNo.'s cry is similar to Zubat's, so the Crobat theory is far from proving anything—interesting stuff nonetheless. For those with even more interest, here is a Pastebin that contains data of each unique MissingNo. cry as well as a link to the audio to hear each cry.

All in all, while there are not signs about which Pokémon were supposed to be included in MissingNo.'s slots, it seems more than reasonable enough to think that 39 more Pokémon were intended to be added to the Red/Blue games at some point, for a total of 190. But in the end, maybe due to time or memory issues, only 151 were released. Whether these Pokémon were ever designed or not is another story.

Now, onto Glitch Pokémon. While, MissingNo. is generally classified as a glitch as well, we are going to use the term "Glitch Pokémon" to refer to the glitches that are not MissingNo.. These Pokémon feature many different characteristics, as MissingNo. was actually programmed into the Red/Blue games to some extent, while these Glitch Pokémon weren't at all. All their data, and with all I mean 100% of it, come from bytes that have other meanings in the game and were never intended to be part of the defining data of any Pokémon. Glitch Pokémon are the result of trying to access Pokémon with "invalid" Index Numbers—that is, those outside of 1 to 190. Glitch Pokémon can be forced to appear by performing the glitch known as the Johto Guard glitch with the help of Pokémon Gold or Silver, or by manipulating the RAM (with Gameshark codes for example) or the ROM. If we don't count the more famous 'M [00], which will be explained later, there are a total of 65 Glitch Pokémon which have Index Numbers between 191 and 255 or 0xBF and 0xFF. They cap at 0xFF because it's the last number that can be represented with a byte; as we saw, one byte is used to define the Index Number of a Pokémon, and thus, also one byte is what is used to determine each individual wild and trainer Pokémon, Pokémon that are given by gift... When a byte that determines the Index Number of a Pokémon is set to a number between 0xBF and 0xFF, the game accesses to one of the Glitch Pokémon. Likewise, the Johto Guard Glitch consists of trading a Pokémon with an Index Number outside of 1-190 from GSC to RBY, causing Glitch Pokémon to appear.

One important table that will be often referred to—and manipulated—later is the table located at 0x41024. This table is used by the game to associate the Index Number of all Pokémon, including all MissingNo., with their Pokédex Entry. Its format is very simple. Each entry is one byte long and its value contains the Pokédex Entry of the corresponding Pokémon, which are ordered by Index Number. For example, the first byte of the table is 0x70, which means that the Pokémon with Index Number of 0x01—that is, Rhydon—gets a Pokédex entry of 0x70 or 112. Likewise, the last byte of the table, the one at 0x410E1, is 0x47, meaning that Victreebel (Index Number of 0xBE) is number 0x47 or 71 in the Pokédex. As expected, since all MissingNo. have an Index Number between 1 and 190, they have an entry in the table. They all have 0x00, meaning that they share an "invalid" Pokédex Entry outside of 1 to 151. As we'll see in the next section, this heavily shapes MissingNo.'s identity (remember that we said that the General Pokémon data is determined by Pokédex Entry?).

Without further ado, here is the table:

But why I'm bringing up this table now? And why am I showing data past the end of the table? Because from the end of the table to the byte selected in blue at offset 0x41122, we can take a lot of information about Glitch Pokémon. Let me explain it: while the table ends and was made to end at offset 0x410E1 with Victreebel's entry, the following bytes are used to determine the Pokédex Entry of Glitch Pokémon. These 65 bytes are data used for other things, but when accessing Pokémon with invalid Index Numbers, the game keeps reading data as if it was the continuation of the table. This causes Glitch Pokémon to have "random" Pokédex Entries; some will be invalid entires (those above 151), but some others will be shared with real Pokémon! For example, Glitch Pokémon 0xC0 (that is, the one with Index Number of 0xC0) has what would be its byte in the table set to 0x3D or 61, the Pokédex Entry of Poliwhirl. Since the General Pokémon data is determined by Pokédex Entry, this leads to many Glitch Pokémon sharing stats, basic moves, types, etc. of real Pokémon; in the case of Glitch Pokémon 0xC0, it will be Poliwhirl.

And finally, in no man's land, we shouldn't forget about the aforementioned 'M [00], also known as 'M Block (note that it's called 'M [00] instead of just 'M to differentiate it from Glitch Pokémon that share the same legible text string in their name). In short, it's a Glitch Pokémon with MissingNo.'s Pokédex Entry of 0x00, so it shares qualities of both. It's a Glitch Pokémon because it has an Index Number outside of 0x01 to 0xBE (190): its Index Number is 0x00. It resembles MissingNo. because, as a result of sharing the Pokédex Entry (0x00), they share the General Pokémon data. Since the General Pokémon data structure contains some of the most relevant characteristics of a Pokémon, 'M [00] could be mistaken with MissingNo. (which shouldn't happen to you anymore considering you are reading this!). However, unlike MissingNo., 'M [00] actually learns moves by leveling up—well, just one, Pound at level 136—and can evolve into Kangaskhan, and, at a higher level, into Clefable. As we saw, Evolution / Learnset data is determined by Index Number, which MissingNo. and 'M [00] don't share, so differences between them in level-up moves and evolutions was a genuine option.

Why are MissingNo. and Glitch Pokémon the way they are?

To this point, we have discovered the reasons that make MissingNo. and Glitch Pokémon exist in Pokémon Red and Blue and even speculated about the extra Pokémon theory that comes from MissingNo.'s existence. Now we are going to look at all the data that give them an identity. In other words, we have seen why they are, now let's see what they are. Where does MissingNo. get, for example, its typing, stats, moves, etc. from? And what about the even more obscure Glitch Pokémon? This is a topic we have already touched in some sparse parts of the previous sections of the article, but now we are going to approach this in a much more detailed manner. We are going to use what we have learned from the four Pokémon data structures in the third section of the article to find out about MissingNo.'s and Glitch Pokémon's identities. It can be claimed that this is the most important part of the whole article, since our goal was to arrive here with all the tools and knowledge required to identify and interpret the content of the data that makes MissingNo. and Glitch Pokémon have the characteristics they have. The glitch properties of these Pokémon cause them to take many of their data—especially true for Glitch Pokémon—from locations that have different purposes in the game; for example, data used to determine the parties of some trainers. This data is structured in a way that it can do what it's supposed to do properly and, as a consequence, doesn't follow the structure required to be reasonable Pokémon data. This leads to a lot of nonsense and glitched qualities on these Pokémon that are always intriguing to reveal!

Names

MissingNo.

You should already have an idea about where MissingNo.'s names come from. In fact, we have already mentioned it. We saw that the table at 0x1C21E that contains the names of all Pokémon is ordered by Index Number, so if we scrolled it down we'll eventually see a total of 39 "MISSINGNO." strings in the positions matching the Index Number of all MissingNo.. Pretty simple, isn't it?

Glitch Pokémon

To find out the names of the Glitch Pokémon, we have to look at the data located right after the end of the table. The Pokémon Names table ends with Victreebel's name, as it is the last Pokémon without an invalid Index Number. However, when accessing Pokémon above 0xBE (Victreebel's Index Number), the game reads past the table as if it hadn't ended. Nothing tells the game where to stop reading or where to read from instead, since there is only one pointer involved in the Pokémon Names structure and it points to the address the table starts at. In short, the game takes just the pointer and the Index Number of the Pokémon and reads data accordingly.

Now, let's try to come up with a simple math formula that can take us to the name's starting character of whichever Pokémon we want, including Glitch Pokémon. We already know that the length of each name is 0x0A characters and that the table starts at offset 0x1C21E with Rhydon's first character, so we don't need anything else! To find out the starting offset of any Pokémon's name, we would need to make the following calculation:

where 0xXX is the desired Pokémon's Index Number. The data used to name Glitch Pokémon is logically completely random, since it takes bytes that have other purposes in the game. Out of all 256 possible values a byte can take, only around 90 can be translated to legible characters, causing Glitch Pokémon to have glitched names that feature random tiles (graphical unit of 8x8 pixels).

Remember 'M[00]? It's a special case, since its Index Number (0x00) doesn't go after the valid Index Numbers, but before. No, this doesn't mean that its name would be located before Rhydon's name, since only data after the pointed address is read. So what then? To access to the name of any Pokémon, 0x01 is subtracted from the Index Number of the Pokémon, as seen from the formula above. When 0x01 is substracted from 0x00, it underflows to 0xFF, causing 'M[00]'s data to be at 0x1C21E + 0x0A * 0xFF or 0x1C21E + 0x0A * (0x100 - 0x01), which translates to offset 0x1CC14. In case you don't believe me:

All the '#' would translate to graphical tiles when displayed in the game. In some Glitch Pokémon, these force the player to press the A button a few times in order to load up the whole name. From the image above, we can come to the conclusion that the Pokémon we all refer to as 'M is not the only glitch Pokémon with the same legible name. Now, if you remember that I said the most famous 'M is generally referred to as 'M[00] in order to distinguish it from other 'M, it makes sense right?

General Pokémon Data

MissingNo.

This is one of the most interesting parts of the article because it contains the data that stands out most about MissingNo., including stats, basic moves, and typing. As we saw, the General Pokémon data structure differs from the other three in the fact that it's structured by Pokédex Entry instead of Index Number. But wait, MissingNo. doesn't have a valid Pokédex Entry! So where does all its data come from?

Well, first, you should know it's all random. That alone makes things very interesting. Similar to what happened with Glitch Pokémon names, MissingNo.'s Pokédex Entry of 0x00 causes an underflow. To find the data of any Pokémon, we have to take

where 0xXX is the Pokédex Entry of the Pokémon; if you remember, 0x1C is the size of each entry in the General Pokémon data structure. Since MissingNo.'s Pokédex Entry is 0x00, when 0x01 is subtracted from 0x00, it underflows to 0xFF. This makes MissingNo.'s data be located at offset 0x39FC2. Its data is:

It's not hard to realize that, due to the length of the General Pokémon data structure, MissingNo's data comes long after the General Pokémon data of real Pokémon. In fact, MissingNo's data starts well into Trainer Pokémon data, so it gets its information according to the party of the trainers that happen to be located from 0x39FC2 to 0x39FDD, which are some trainers that belong to the Biker class. Now, to make things more interesting, let's compare the effects these bytes have on MissingNo. with their real purpose and meaning in the game. The Trainer data structure is very easy to understand so don't worry about that:

Glitch Pokémon

Now that we know where MissingNo.'s data come from, it's straightforward to deduce the General Pokémon data of any Glitch Pokémon we want, provided we know its Pokédex Number. As we saw, the Pokédex Entry of some Pokémon is a number higher than 151 or 0x97, but in many cases, it is not (refer to the data right after the Pokédex Order table shown before). Glitch Pokémon with valid Pokédex Entries would take their General Pokémon data from entries of real Pokémon. This was already discussed before, and we saw that for example Pokémon 0xC0 has a Pokédex Entry equal to Poliwhirl's, making it a Poliwhril hybrid. However, the sprite is generally not shared. While the pointers to front and backsprites are the same, the bank loaded rarely coincides, so most hybrid Glitch Pokémon would still have glitched sprites.

A Pokédex Entry between 0x98 and 0xFF (as well as 0x00, but no Glitch Pokémon other than 'M[00] happens to have a Pokédex Entry of 0x00) means that the General Pokémon data of the Pokémon would be taken from data with other meanings in the game, leading to illogical characteristics, which may feature extreme base stats or glitch moves that could make the game freeze or function inadequately. We can easily find the data of any Glitch Pokémon according to the formula we used to locate MissingNo.. If we do that, we would see that Glitch Pokémon with invalid Pokédex Entires would take data from places where Pokémon cry definitions or Trainer data is stored. Notice that some Glitch Pokémon share their Pokédex Entry while some entries are unused, which is logical considering the laws of probability alone. For example, 0x51 repeats three times, while 0xCD repeats a total of eight times. This causes three Magnemite hybrids to exist and eight different Glitch Pokémon to share a glitched General Pokémon data, respectively.

Pokédex Data

MissingNo.

To find out MissingNo.'s Pokédex data, we'll have to go back to the pointer table we saw when reading about Pokédex data in the third section of the article. This way we will be able see how every MissingNo. has the same pointer and thus it points to the same offset. Therefore, it's pretty obvious that the programmers did this on purpose, and it's also evident that the 39 Pokémon MissingNo. is supposed to cover were discarded before Pokédex data was implemented, as otherwise each MissingNo. would point to a different offset and would be in order instead of after the last Pokémon.

MissingNo.'s pointer is 0xE5 0x4F; the easiest way to notice this is by looking at the pointers of MissingNo. 0x1F and 0x20, which are located at the right of the fifth line of that table and share that pointer, like every other MissingNo. does. This means that the pointed address is 0x40FE5, right after Victreebel's Pokédex data.

So what does that data contain? It's more than clear that MissingNo.'s Pokédex data was programmed manually and on purpose. The string that defines the species of MissingNo. is set to "???":

In the Japanese Red/Blue games, its height and weight were set to generic values of 1.0 meters (0x0A) and 10.0 (0x64) kilogrames. However, the way height and weight are structured in the Japanese versions differs from the way they are structured and read in the English versions. The units of measure are different and, in the Japanese games, height and weight only occupy one byte each instead of two like in the English versions. MissingNo.'s Pokédex data from the Japanese versions was not "translated" in the English versions, and this causes MissingNo. to have crazy height and weight values: 10 feet and 3507.2 pounds. MissingNo. weighs almost eight times as much as Onix!

Evolution / Learnset Data

MissingNo.

Every MissingNo. has its Evolution / Learnset data set to [0x00][0x00] on purpose, meaning MissingNo. doesn't evolve and learns no moves by leveling up. While each MissingNo. has a different pointer in the pointer table to Evolution / Learnset data, all pointers point to the same null data. For example, MissingNo. 0x38's pointer is 0xA2 0x74, so it points to 0x3B4A2:

Notice Mankey's entry after MissingNo.'s data ends. Mankey's Index Number is logically 0x39. The 0x00 at offset 0x3B4A1 is the terminator for Koffing (0x37).

Glitch Pokémon

This part is very interesting. Previously, we saw that pointers to Evolution / Learnset data are located starting at offset 0x3B05C. So how would Glitch Pokémon get their pointers then? By simply accessing to data past the pointer table, according to their Index Number. This means that, for example, Glitch Pokémon 0xBF has its pointer located right after Victreebel's, which is the last Pokémon by Index Number. We saw that the Evolution / Learnset data also begins after Victreebel's pointer, which translates to the fact that Glitch Pokémon are taking their pointers from data of some Pokémon. Needless to say, this would lead to random pointers pointing to data that makes no sense when read as Evolution / Learnset data. Let's have a look at the 66 Glitch Pokémon pointers, from 0xBF to 0x00:

Notice that the pointers with the most significant byte between 0x00 and 0x3F point to the first bank, while those with it between 0x40 and 0x7F point to the bank they are at: bank 0x0E, which starts at 0x38000. There are four pointers that lead to the VRAM as they are between 0x8000 and 0x9FFF. The VRAM is constantly varying depending on the graphics; in fact, there is one Glitch Pokémon (0xEA) having a pointer of 0x24 0x81, that features a different learnset depending on the way it is leveled up (battling or via Rare Candies). Let's leave curiosity aside and focus on more practical examples, though.

Firstly, however, let's try to remember what we saw about the Evolution / Learnset data structure. If you remember, Evolution / Learnset data was separated by 0x00, while learnset data was also declared to end with its own 0x00. What this implies as far as Glitch Pokémon are concerned is honestly pretty scary! Until a byte with 0x00 comes, we are certain that no matter what the current data stands for, it won't come to an end. With Glitch Pokémon's data being taken from random places, a piece of large data without 0x00 could lead to extremely long evolutions or learnset lists. Yet, the funny thing is that this is not the whole story, as not even every 0x00 will mark the end!

To better understand this, we should look back to when we saw the way the learnset and evolution data was structured. Notice that the 0x00 that make either of these lists to end share one basic thing in common; they come after a learned move or an evolution has already been defined entirely. For example, a 0x00 byte located after a byte that stands for a level in which a move is learned—let's say the level is 30—won't make learnset data end, but move 0x00 be learned at level 30 (the move with an Index Number of 0x00 is glitched). Likewise, a 0x00 in the place of the level in which a Pokémon evolves won't make evolution data end, but the Pokémon will evolve from level 0 on. On the other hand, while the evolution data does not necessarily end at the first 0x00, the learnset data does always begin there.

As always, this is better understood with an example. 'M[00] is the most famous Glitch Pokémon and its data has enough variety to help us illustrate the theory we have just seen, so it will serve us well. From the picture above, 'M[00]'s pointer is the last one—that is, 0x4F 0x36. It points to 0x364F, so let's move to that address. It's Learnset / Evolution data is indeed very long, although it's nothing compared to the length of the data of some other Glitch Pokémon:

Let's go part by part. In green, you can see the data that stands for the evolution data. The big length doesn't mean that 'M[00] can evolve into lots of Pokémon though, since only the entries that follow the structure correctly are valid. For instance, [0x20] [0xF8] [0xEA] stands for nothing, and over 90% of the following "triplets" don't either. As we saw, not every 0x00 makes the evolutions list end, but only those that come after a previous evolution entry has ended. Even if invalid, evolution entires are read as three bytes long (or as "triplets") by default, as normal evolutions are three bytes long. So, unless there is a valid four-byte evolution entry (be it item or trade evolution), which is not our case, only 0x00 in the positions 1, 4, 7, 10... are treated as end markers. The first 0x00 that meets this requirement is the last byte of the code above, pictured in red. From the first byte of 'M[00]'s data at 0x364F to this ending 0x00, there is a total of two valid evolution entries, highlighted above in bold and green. The first one makes 'M[00] evolve into Clefable, whose Index Number is 0x04, at level 128, while the second one means that 'M[00] evolves into Kangaskhan at level 0, or, in other words, at any level.

What about the learned moves? If you remember, we said that learnset data starts with the first 0x00 regardless of whether it makes evolution data finish. This 0x00 and the learnset data is colored in blue (but notice that this data also belongs to evolutions!). Unfortunately, 'M[00]'s learnset list ends not very far from there at all, as there is an ending [0x00] three bytes later. This means that 'M[00] only learns one move, according to 0x88 0x01. This data signifies learning Pound at level 136. Not very spectacular as you see...

This doesn't mean that Glitch Pokémon don't learn many moves as a rule though. Some Pokémon enjoy a very wide learnset virtue of a very far-away ending 0x00. Some Pokémon can learn over 50 moves, including glitch moves and more than one instance of the same move. On the other hand, more than half the Pokémon don't evolve, since the Evolution structure is very difficult to match with random bytes.

An interesting note on 'M[00]

We saw some time before that 'M[00] shares the Pokédex Entry of MissingNo., as both have a Pokédex Entry of 0x00. Needless to say at this point, this means they share the General Pokémon data including front and back sprites, making them very similar in practice. Therefore, 'M[00] is often referred to as the "sister counterpart" to MissingNo. since both are the most well-known glitch Pokémon and, by far, the easiest to find (the Old Man Glitch makes the Pokémon with an Index Number of 0x00 appear very frequently). However, what goes unnoticed is the fact that 'M[00] has a Pokédex Entry of 0x00 just by chance! Not because it has been purposely set to 0x00 to match MissingNo's, but because the byte it takes its Pokédex Entry from happens to be 0x00. If you look at the Pokédex Order table pictured long above in the "Why do MissingNo. and Glitch Pokémon exist?" section, you can see that after the selected byte at offset 0x41122 that makes the Pokémon with an Index Number of 0xFF have a Pokédex Entry of 0x06, there comes the byte that makes 'M[00] have a Pokédex Entry of 0x00. This is something we can now deduce thanks to what we have read about data underflow. If the function the 0x00 is doing there was done with, say, 0x50 instead, now we would be saying that 'M[00] is a Slowbro hybrid instead. It is worth noting that 'M[00] happens to be the only Glitch Pokémon with a Pokédex Entry of 0x00, which makes it an even more improbable coincidence. In short, 'M[00] is a Glitch Pokémon by heart, so whenever you see or hear that MissingNo. and 'M[00] are extremely similar Pokémon or that "they are basically the same thing", remember that the qualities they share are just a mere coincidence! More specifically, a 1/66 coincidence considering there are a total of 66 Glitch Pokémon counting 'M[00].