Wishful Coding

Welcome to another episode of me grepping through Pokered. This time to figure out how the game decides to show the Pokedex menu or not.

You get your Pokedex from Oak after delivering the parcel, so Oaks Lab seems like a good place to look for clues.

After some unfruitful searching through the script for Oaks Lab I decided to approach it from the other way and look at the start menu. A wild guess:

git grep -i startmenu

Bingo! Done? I think not.

We can trace back wd74b to Oaks Lab and our old friend wram.asm, but this time I want to know where it is in the save file.

There are no direct references to our byte in any saving related code, so again, let’s start from the other direction. Another wild guess:

git grep -i save

After a lot of not so interesting files, I see some matches in engine/save.asm. What jumps out are calls to CopyData originating in SaveSAVtoSRAM.

CopyData is easily found, and copies bc bytes from hl to de.

At the start of all of the three saving functions are a few lines about SRAM_ENABLE and MBC1SRamBank. This is probably about switching banks in the cartridge, so that seems like a good point to look at the Game Boy pandoc.

It has a section on bank switching, and I found elsewhere that Pokemon Red used the MBC3 type.

So as you can see, addresses 0xA000-0xBFFF can be mapped to 3 battery backed RAM banks for save data. This corresponds to the de addresses we see in the code.

So starting with SaveSAVtoSRAM0 we can now try to figure out which piece of WRAM is copied to which SRAM location.

Here we see the second RAM bank is mapped to 0xA000, so writing to 0xA000 puts a byte in SRAM at 0x2000.

Next we see that 11 bytes of wPlayerName are written to 0xA598. To get the SRAM address, we subtract 0xA000 and add 0x2000, resulting in 0x2598.

We can verify this with the Bulbapedia article about the save file and it is indeed correct. Sadly, our beloved wd74b is not in the article, so on with our search.

Since the file does not reference our address directly, the only way to figure this out is to check all the copies in wram.asm to see if they include our byte. But we’re in luck.

The next copy copies from wPokedexOwned to W_NUMINBOX with wd74b right in the middle. Now all we need is math to tell the location in SRAM.

wPokedexOwned is copied from 0xD2f7 to 0xA5A3, giving us 0x25A3 as the SRAM starting address. Now we add to that the offset of wd74b, to give us:

0x25A3 + (0xD74B - 0xD2f7) = 0x29f7

TCPoke is my project that connects Game Boys over the internet to battle and trade with first and second generation Pokemon games.

Today the last parts for the TCPoke shield arrived, enough parts to make 9 test boards. I plan to give these away to people who can contribute to the project.

What’s included

• PCB
• Game Link Cable (second generation)
• LED
• 330 Ohm resistor
• 3x 1K Ohm resistor
• 2x header pins

What you need

• Game Boy (Pocket, Color, or Advance)
• Pokemon cartridge (Red, Blue, Yellow, Gold, Silver, or Crystal)
• Teensy 2.0
• A soldering iron (optional)

The software is compatible with the classic Game Boy and the Teensy 3.1, but the shield and Game Link Cable are not.

How to get it

Send an email to myfullname at gmail, containing at least

• Your interest in the project
• Your proposed contribution
• Your shipping address

I will select the best contributions and send them one of the prototype kits free of charge.

If you’d like me to assemble the kit, or if you would like to make a donation, please let me know.

State of the project and help needed

The most important thing works: You can connect to another player and trade first generation Pokemon to complete your Pokedex.

Trading on the second generation is in a “should work” stage, but needs testing.

Battle on the first generation works, but is buggy. Battle on the second generation does not work.

There is a partial connection state machine in the desktop client, but it is mostly a dumb proxy. Work in this area is needed for battle, UI feedback, and additional features.

The desktop client is both my first Chrome app and my first Angular app, and I’m not a designer either. So general improvement here is needed.

Once the basics are covered, I’m open to crazy ideas. A built-in Pokedex, ranked ladder games, connecting to an emulator, supporting other games, you name it.

I noticed one particular gear causing a lot of slipping, the large one driving the bogie. It misbehaved in two ways:

The large gear was pushed sideways by the force of the motor, pushing apart the frame and causing the top gear to slip.

The large gear exerted force on the bogie, pushing one wheel off the ground under force.

To solve these issues, I used a smaller gear and reinforced the frame. This helps keep all the gears together and all the wheels on the ground. The robot can now climb much bigger obstacles.