R/B/Y and G/S/C's Box Editing

[SuperSwampert67]

Hello all, I'm SuperSwampert67, hobbyist programmer and gamer. I just joined the forums for some advice and to give out some info that I know.

I discovered that, unlike the GBA-onward Pokemon games, there wasn't a lot of information on the net about R/B/Y or G/S/C (which I'll now refer to as the Color and Metal generations, respectively). One thing in particular I had trouble finding was information about the box systems. So, in pursuit of knowledge, I began to reverse engineer them myself.

To be honest, the systems weren't all that hard to understand, so this should hopefully be easily understood. However, I currently hit a snag in my Color Gen research. If you're interested in helping, go to the Color Gen section.

Update Log

• July 23, 2010: First post.
  

Credits

• Thanks to the writers at Bulbapedia for explanation of the structures of Party Pokemon and the character map used in both Color and Metal Generations, among other things.
  

General

The box systems in both the generations are very similar in size, and both follow the same pattern for ordering data.

1. Pokemon Deposited BYTE (1 BYTE)
   
2. Pokemon Sprite Buffer (21 BYTES)
   
3. Pokemon Data (660 BYTEs in Color, 640 BYTEs in Metal)
   
4. OT Name Buffer (220 BYTEs)
   
5. Nickname Buffer (220 BYTEs)
   

Pokemon Deposited BYTE

The very first BYTE of the box is the "Pokemon Deposited" byte. It's a number between 0 and 20 (unsigned) which tells the game how many Pokemon are in the box. Very simple.

Pokemon Sprite Buffer

The next 21 BYTEs are what I call the "Pokemon Sprite Buffer". It's named that because each entry in the buffer identifies what sprite to load for which Pokemon entry, by the Pokemon's index number. I don't know why it's done this way, but if you don't have the Sprite Buffer match the corresponding Pokemon data, you'll see the wrong sprite when you view it's stats. The list is terminated by BYTE "FF", aka 255 or -1, depending on how you look at it. The list is always 21 BYTEs long, so if there's less than 20 Pokemon in the box, you have to pad the end of the buffer with useless data, typically "00" or "FF".

Pokemon Data

After that, then the actual Pokemon data is saved. Each Pokemon is 33 BYTEs long (Color) or 32 BYTEs long (Metal). They follow the same order as the entries in the Pokemon Sprite Buffer, and have no gaps between one another. If there's less than 20 Pokemon in the box, the data is padded at the end with useless data until it's the same size as a 20 Pokemon data block.

OT Name Buffer and Nickname Buffer

If you look at the data, you'll see that the two things that aren't saved with the Pokemon data themselves are the OT Names and the Nicknames. These pieces of data come in their own buffers, the "OT Names Buffer" and the "Nicknames Buffer". Each buffer is 220 BYTEs long, and follow after the Pokemon data. The names aren't stored in ASCII format, they use their own system, though each character is one BYTE. At the end of the name is a terminator character, and then it's padded to 11 BYTEs if it's smaller. NOTE: OT Names are only 7 characters long, you can't have more than that! Nicknames, however, are 10 characters long, so you can reach 11 BYTEs with a long nickname. (10 characters + terminator character)

• A through Z (0x80 through 0x99)
  
• a through z (0xA0 through 0xB9)
  
• PK (0xE1)
  
• MN (0xE2)
  
• Hyphen (0xE3)
  
• Question Mark (0xE6)
  
• Exclamation Point (0xE7)
  
• Period (0xE8)
  
• Multiply Symbol (0xF1)
  
• "/" aka Slash Symbol (0xF3)
  
• Comma (0xF4)
  
• Left Parenthesis (0x9A)
  
• Right Parenthesis (0x9B)
  
• Colon (0x9C)
  
• Semicolon (0x9D)
  
• Left Bracket (0x9E)
  
• Right Bracket (0x9F)
  
• Terminator (0x50)
  
• Padding (0x00)
  

One final note that's very important to mention. I'm not sure what the byte ordering system is in the GBA+ games, but in these games, the bytes are Big Endian.

Example:

In hexidecimal, 1 million is 0F4240. (Unsigned, of course.)

When you write in Little Endian, the order of hexidecimal is from smallest place to largest place.

0F4240 in Little Endian is thus "40 42 0F" when written in a code-readable form.

Big Endian is from largest to smallest place. Thus, when written, it's "0F 42 40".

This is HIGHLY important when working with WORDs (2-byte variables) or larger variables.

Metal Generation

I pretty much have figured out the Metal Generation.

Things that still need to be figured out:

• Changing the Name of the Boxes
  
• How Crystal determines if the OT was Male or Female
  
• How Eggs are Stored
  
• How the Pokerus field works.
  

Pokemon Data Format

Species Index - BYTE

Held Item Index - BYTE

Attack 1 Index - BYTE

Attack 2 Index - BYTE

Attack 3 Index - BYTE

Attack 4 Index - BYTE

Original Trainer Numeric ID - WORD

Experience Points - 3 BYTES

HP Stat Exp - WORD

Attack Stat Exp - WORD

Defense Stat Exp - WORD

Speed Stat Exp - WORD

Special Stat Exp - WORD

DVs* - WORD

Attack 1 PP* - BYTE

Attack 2 PP* - BYTE

Attack 3 PP* - BYTE

Attack 4 PP* - BYTE

Happiness* - BYTE

Pokerus* - BYTE

Caught Data* - WORD

Level - BYTE

DVs

DVs are the IVs of the Color/Metal Generation. They can range between 0-15 for Attack, Defense, Speed, and Special. The Special DV applies to both Sp. Atk and Sp. Def in the Metal Gen.

Each DV is 4 bits in size, thus 16 bits total. (2 BYTEs or 1 WORD)

The DVs are ordered Attack, Defense, Speed, and Special.

The HP DV is special in that it depends on the other DVs. It takes the bottom bit of each of the other DVs to determine its value.

Hidden Power is affected by DVs in the Metal Gen.

Attack PP

The top two bits of the BYTE are the number of PP Ups used on the move. Thus, it can range from 0 to 3 PP Ups.

The bottom six bits are the actual PP of the move. Thus, it can range from 0 to 63.

Happiness

How happy the Pokemon is with its current trainer. Maximum happiness is 255, while maximum unhappiness is 0.

Pokerus

Unknown at this moment in time how to identify "Never Infected", "Infected", and "Cured".

Caught Data

The first byte is the index of the location the Pokemon was caught at.

The top two bits of the second byte is the time it was caught at. (1 is Morning, 2 is Day, 3 is Night)

The bottom six bits of the second byte is the level it was caught at. (Level ranges from 0 to 63.)

Save File Offsets

These offsets were retrieved from US copies of Gold, Silver, and Crystal. They may not work for different region and/or build version games.

Each box immediately follows the previous box in the save data, with the exception of BOX8, which is has a small block of useless(?) data between it and BOX7. Each box is 1,104 BYTEs long.

0x4000 - BOX1

0x4450 - BOX2

0x48A0 - BOX3

0x4CF0 - BOX4

0x5140 - BOX5

0x5590 - BOX6

0x59E0 - BOX7

---

0x6000 - BOX8

0x6450 - BOX9

0x68A0 - BOX10

0x6CF0 - BOX11

0x7140 - BOX12

0x7590 - BOX13

0x79E0 - BOX14

Indexes

Pokemon

http://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_by_index_number_%28Generation_II%29

Moves

http://bulbapedia.bulbagarden.net/wiki/List_of_moves

Items

http://bulbapedia.bulbagarden.net/wiki/List_of_items_by_index_number_%28Generation_II%29

Color Generation

Like I said above, I hit a snag. Once I can figure it out/get help, I can't perfectly say I understand the R/B/Y box systems.

When you view the boxes in the save data, you find that the current box actually is moved to it's own block of memory in the save (offset 0x30C0 in Red/Blue, not sure on Yellow/Green). The game only updates this block of memory whenever there are modifications made, and where you'd normally find that box's data in the save, you find that the "Current Pokemon Deposited" variable is set to 0 and the Pokemon Sprite Buffer empty.

So, what in the game save tells the game to place the box data if you were to change boxes? I had found a couple possible areas, but they were close to the beginning of the save, and whenever I modified them, I always got a "Save is corrupted!" error on load.

So, is there a checksum for the early part of the save? Or is the box number saved in multiple locations, and the game must check each one to ensure they all match? Any help would be appreciated on this.

Pokemon Data Format

Species Index - BYTE

Remaining HP - WORD

Unknown - BYTE

Status* - BYTE

Type 1* - BYTE

Type 2* - BYTE

Capture Rate/Item* - BYTE

Move 1 Index - BYTE

Move 2 Index - BYTE

Move 3 Index - BYTE

Move 4 Index - BYTE

Original Trainer Numeric ID - WORD

Experience Points - 3 BYTES

HP Stat Exp - WORD

Attack Stat Exp - WORD

Defense Stat Exp - WORD

Speed Stat Exp - WORD

Special Stat Exp - WORD

DVs* - WORD

Attack 1 PP* - BYTE

Attack 2 PP* - BYTE

Attack 3 PP* - BYTE

Attack 4 PP* - BYTE

Status

Identifies status conditions.

If bit 3 is set, then the Pokemon is asleep

If bit 4 is set, then the Pokemon is poisoned.

If bit 5 is set, then the Pokemon is burned.

If bit 6 is set, then the Pokemon is frozen.

If bit 7 is set, then the Pokemon is paralyzed.

Type

Identifies the two types of the Pokemon. If the Pokemon only has one type, then both Type variables are set to the same value.

Do not currently know the type indexes.

Capture Rate/Item

When a Pokemon is captured in the Color generation, this field is set to it's Capture rate. This field will not change even if it evolves into a Pokemon with a different Capture Rate.

However, when a Pokemon is traded from the Metal Generation into the Color Generation, the index for the item the Pokemon is holding, if any, is saved here instead.

DVs

DVs are the IVs of the Color/Metal Generation. They can range between 0-15 for Attack, Defense, Speed, and Special. The Special DV applies to both Sp. Atk and Sp. Def in the Metal Gen.

Each DV is 4 bits in size, thus 16 bits total. (2 BYTEs or 1 WORD)

The DVs are ordered Attack, Defense, Speed, and Special.

The HP DV is special in that it depends on the other DVs. It takes the bottom bit of each of the other DVs to determine its value.

Hidden Power is affected by DVs in the Metal Gen.

Attack PP

The top two bits of the BYTE are the number of PP Ups used on the move. Thus, it can range from 0 to 3 PP Ups.

The bottom six bits are the actual PP of the move. Thus, it can range from 0 to 63.

Save File Offsets

These offsets were retrieved from US copies of Red/Blue. They may not be valid for different region and/or different build version games.

See above for explanation of the "Current Box" buffer.

There is a small gap between BOX6 and BOX7. Other than that, there are no gaps between boxes.

Each box is 1,122 BYTEs long.

0x30C0 - Current Box

---

0x4000 - BOX1

0x4462 - BOX2

0x48C4 - BOX3

0x4D26 - BOX4

0x5188 - BOX5

0x55EA - BOX6

---

0x6000 - BOX7

0x6462 - BOX8

0x68C4 - BOX9

0x6D26 - BOX10

0x7188 - BOX11

0x75EA - BOX12

Indexes

Pokemon

http://bulbapedia.bulbagarden.net/wiki/List_of_Pok%C3%A9mon_by_index_number_%28Generation_I%29

Moves

http://bulbapedia.bulbagarden.net/wiki/List_of_moves

[Morfeo]

[english]

Hello, I noticed that this topic recently bought Pokemon Crystal and Pokemon Green Japanese (original) and one years since I own the GB transfer 2, a device that allows me to backup and restore saves the GB and GBC games (among other things), because I can pass this tool saves all my Game Boy cartridges and manipulate using VisualBoyAdvance, very long loading code to use the traditional GameShark to load the saves in the Pokemon Stadium 2 (for my versions American) or the Pokemon Stadium Gold & Silver (for my Japanese versions), thanks to that found more easily the location of CheckSum for different games, although I do not Serb much because I have no programming skills and I can not make a program modifications made to fix a hex editor.

I am interested in the information you published (most already knew of bulbapedia) but if that is the case maybe you can make an editing tool saves and creator codes to work directly with game saves from these generations. This would save me much time manipulations I've done so far. Though what disturbs me most so far is to locate the address that allows me to create a GameShark code to activate the GS Ball event on Pokemon Crystal (when the nurse hands you the GS Ball in the PCC), but I think even I need to do further research.

Anyway, I wish you success in your purpose and be of much use to other users and gamers. And if I can help you with something, I'll be happy as possible.

[spanish]

Hola, me llamo la atención este Tema por que hace poco adquirí Pokemon Crystal y Pokemon Green japonesas (originales) y desde hace 1 año poseo el GB Transferer 2, un dispositivo que me permite respaldar y restaurar saves de los juegos de GB y GBC (entre otras cosas), gracias a esta herramienta puedo pasar los saves de todos mis cartuchos de GameBoy y manipularlos usando el VisualBoyAdvance, cargando códigos muy largos como para usar el GameShark tradicional y hasta cargar los saves en el Pokemon Stadium 2 (para mis versiones americanas) ó el Pokemon Stadium Gold&Silver (para mis versiones japonesas), gracias a esto encontré de forma más fácil la locación del CheckSum para los diferentes juegos, aunque no me serbia de mucho por que no tengo conocimientos de programación y no puedo hacer un programa para fixear modificaciones hechas en un editor hexadecimal.

Me interesa la información que publicaste (gran parte ya la conocía de bulbapedia) pero si se da el caso tal vez puedas hacer una herramienta de edición de saves y creador de códigos para trabajar directamente con los saves de los juegos de estas generaciones. Esto me ahorraría mucho tiempo en manipulaciones que he hecho hasta ahora. Aunque lo que más me inquieta hasta la fecha es localizar la dirección que me permita crear un código de GameShark para activar el evento de la GS Ball en Pokemon Crystal (cuando la enfermera te entrega la GS Ball en el PCC), pero creo que aun debo seguir investigando para lograrlo.

Sea como sea, te deseo éxito en tú propósito y que sirva de mucho para otros usuarios y jugadores. Y si yo puedo ayudarte en algo, con gusto haré lo posible.

[Juan-K]

morfeo alguien hiso algun programa con estos datos?

[Morfeo]

No que yo sepa, solo esta la informacion. Aunque me gustaria que lo pudieran hacer, o de tener los conocimientos, me gustaria poderlo hacer yo

[ekx]

If anyone's still interested, I recently wrote a Pokemon R/B save editor and in doing so discovered that there is in fact a checksum for part of the save file.

Here's a little tool that will fix the checksum for Pokemon R/B save files: http://suiken.square7.ch/pkmnHashfixer.zip

And here the algorithm in c#: http://pastie.org/2042674

Edited June 9, 2011 by ekx

[RedJiggly]

Why wasn't I able to find this topic before? Thank you very much for your research. With this, I might be able to write a RBY/GSC pokemon editor.

~RedJiggly

[Delta Blast Burn]

I may have found the types.

Normal 00

Fire 14

Water 15

Electric 17

Grass 16

Ice 19

Fighting 01

Poison 03

Ground 04

Flying 02

Psychic 18

Bug 07

Rock 05

Ghost 08

Dragon 1A

EDIT: The link to your checksum fixer seems to be broken.

EDIT2: Using this I Extracted several pokemon from my Yellow version (Attached)

1st Gen..rar

Edited December 5, 2011 by Delta Blast Burn

[camperdave]

Hey, I've been working on a new tool lately and have been inspecting some Pokemon Crystal saves.

I've used the information in this thread to find and decode the pokemon in boxes, and two different memory locations that seem to contain information on the active party (0x1A65 and 0x2865).

However, i'm having trouble modifying the file without corrupting the save. Does anyone know if there is a checksum in Generation II save files (specifically Crystal, but I'd be interested in any information) and if so, how I can re-calculate it?

Once I get a little bit farther along (and actually have the active party documented properly) I''ll post my 010 Editor-formatted templates and scripts that make everything look really nice.

Edited February 17, 2012 by camperdave
spelling

[Antidote]

that C# code is a poor implementation, don't use it. you should be calculating ALL bytes not just until it's equal to 0, that's not a valid checksum.

here is a valid function (easily translated to C# by changing const char* buf to byte[] buf)

int GetChecksum8(const char* buf, int pos, int len)
{
   int sum = 0;
   for (int i = pos; i < pos + len; ++i)
       sum += buf[i];

   return (sum & 0xFF) ^ 0xFF;
}

EDIT:

I've taken another look, and it seems as though it IS calculating all the bytes, but it's using unnecessary code to do so, a simple check of:

if (bc <= 0) break;

is plenty no OR'ing required. and a for loop is optimal.

My code gets the same thing done with less CPU cycles and less thrashing of the VM if ported to C# therefore it's much faster.

[TimDerHenker]

Hey guys,

I know this thread is very (VERY) old, and I'm sorry for reviving it, but I have a few questions.

In metal generation, did anyone find something out about OTs gender?

And does anyone know how to find unowns shape?

I'm a hobbyist programmer too and I'm writing a program wich allows to trade pokemon from generation 2 to generation 3 games (the only thing, the pokemon developers didn't include in their games -.-) and those two things are the only things I wasn't abled to find out. My generation 3 part is complete right now.

Thanks,

Tim

Edited February 24, 2013 by codemonkey85
Let's leave out the harsh language.

[codemonkey85]

Metal generation (Gen II) OT gender info: http://bulbapedia.bulbagarden.net/wiki/Pok%C3%A9mon_data_structure_in_Generation_II#Caught_data (2 bytes at 0x1D)

Unown's shape: http://bulbapedia.bulbagarden.net/wiki/Individual_values#Unown.27s_letter

[TimDerHenker]

Thanks for your fast reply, the unown thing is nice now

I knew the caught data info on bulbapedia, but it is only for crystal.

In generation I (r/b/y), I think, there's only the name saved, is it the same in gold/silver?

Tahnks for your help :wink:

[codemonkey85]

There was no female trainer in Gold and Silver, so yes.

[TimDerHenker]

Well.... Again it's a long time since I last wrote.

I just accidently found out some false gender calculations for Pokemon.

It's kind of weird, because I think my program is right and the rom fails ^^

It's like this:

In crystal, the gender of Pokemon is calculated based on their attack IV. This value is than checked against a predefined gender value. If the IV is less than the predefined value, the Pokemon is female. Else it will be male. And here is my case:

I've got one Togepi and one Togetic.

Based on bulbapedia entries (Togepi: http://bulbapedia.bulbagarden.net/wiki/Togepi_(Pok%C3%A9mon) Togetic: http://bulbapedia.bulbagarden.net/wiki/Togetic_(Pok%C3%A9mon) ), both have a gender ratio of 87.5% male, 12.5% female (1:7). So the border-value is: 16 (IV's max value)/8*7, wich is exactly 14.

That would normally mean, that every Togepi or Togetic with an Attack IV less than 14 is male.

Well, my Togepi has an AttIV of 9 while my Togetic has exactly 0. That would result in both being male, but the game displays Togetic (with 0) as female.

I rechecked the IVs with PikaSav, but it displays the same values.

Does anyone have an idea, why?

I hope, my thoughts and my questions are understandable.

Greetings,

Tim

[Kaphotics]

you've got the relationship wrong; female is always on the low end while male is the high end.

a simple way to deduce a species border-value is "what fraction is female"

(1-0.875)=2/16

0-2=female

3-16=male

[TimDerHenker]

Aaaaaaah I see ^^ I've got to turn it round.

Bulbapeia entry saying "87.5% male, 12.5% female" is "12.5% female, 87.5% male" for Gen II?

I'll try it ^^ Thanks

Edit:

Perfect calculates more than 150 Pokes correct, so I think it works like it should ^^