Wishful Coding

Didn't you ever wish your computer understood you?

Pokemon GO Old

Pokemon GO for old ‘90 kids based on Pokemon Gold1.

When I did Pokemon Gringo I used Pokemon Red with an Arduino, GPS, and external battery. It worked, but it was kind of unwieldy and unreliable.

This hack solves all those problems. It’s based on Pokemon Crystal, and relies on a pedometer that is directly connected and powered by the Game Boy.

Unlike Pokemon Gringo, Pokemon GO Old features the complete Pokemon game-play in full sound and color, except you have to be physically walking to walk in the game.

This means you get to hatch eggs by walking! Assuming a game step equals one meter2, it’d take 1Km (Magikarp) to 10Km (Dratino) to hatch an egg.

I made one other small change to bring character selection up to date with current standards.

choose your style

In my previous post I explained how I managed to connect the accelerometer directly to the Game Boy. From there it is relatively easy to use the accelerometer as a pedometer to control your movement in Pokemon GO Old.

I configured the LIS3DH to generate an interrupt when acceleration exceeds 64mg. Then I added a function that checks the interrupt register in the code that moves the character. Finally I made the buttons sticky so that you keep walking as long as you walk.

In case anyone wants to try it out, the complete ROM and code are on Github. The hardware is super simple; except for the flash cart it’s probably around $15 of components.

ball of wires

The Game Link cable connects directly to the LIS3DH, but a small circuit is required to drive the CS line.

buffer

  1. Actually Crystal, but everything for the pun. 

  2. You take about 2 game steps in a real step, but no steps during battles. 

Pepijn de Vos

Connect SPI sensors to a Game Boy

In all my previous Game Boy hardware hacks, I always used an Arduino to talk to the Game Boy over the Game Link cable. But the Game Link protocol is essentially just SPI, so I was thinking it would be trivial to talk directly to SPI sensors.

So I ordered an LIS3DH breakout from Adafruit and connected it to the Game Link port of my Game Boy. I wrote some code to read the WHOAMI register of the sensor, which should return 0x33. Nothing happened. I double-checked all the code and wiring, but nothing worked.

On day two I probed around with my oscilloscope and dug around in the datasheet. The problem turned out to be that I tied the Chip Select to ground, which is actually required to indicate the start of a transaction1. But the Game Boy does not have a Chip Select pin, so that seemed like it would be the end of it.

On day three I figured I might be able to emulate the CS line somehow. I tried various things with low-pass filters, binary counters and even an Attiny25, but nothing quite worked. The highlight of the day was that the Game Boy would display 0x24 if the stars aligned, and random junk otherwise. I gave up again.

On day four I woke up with the winning solution. It was glorious.

33

A MOSFET buffer connected to the clock line pulls low the CS line and a capacitor combined with the 10k pull-up on the breakout keep the line low between clock pulses and release it after transmission.

33

I have never before been so excited about the number 0x33. After 4 days of despair, trial and error, it finally worked.

33

It should be noted a large delay between transactions is required to raise the CS pin, so transmission will be slow.

After setting up the control registers somewhat correctly, I was able to read accelerometer data from the sensor. I made a quick demo that moves a dot around by rotating the sensor, as seen in the video. It’s not hard to imagine you could easily make a tilting maze game out of this.

But I have other plans. To be continued.

  1. I checked various sensors, and every single accelerometer I found was dual I2C/SPI and bit-for-bit identical to the LIS3DH, so using another sensor was not an option. 

Pepijn de Vos

Does a compiler use all x86 instructions?

On the Z80 CPU there are so few registers and instructions that you can easily know and use them all and wish there were more of them. However, half of the time it feels like the only on you really use is ld. I imagine that if ld took half the number of clock cycles, average code would run twice as fast.

In modern x86(_64) there are so many that I even wonder if my compiler knows and uses them all, and how often. To get an impression, I ran this one-liner:

objdump -d /usr/bin/* | cut -f3 | grep -oE "^[a-z]+" | sort | uniq -c

Full output here. In total I counted 411 different mnemonics, topped by 15891451 mov instructions and a very long tail of instructions that only occur once or twice.

There are 33% mov instructions. Combined with callq, je, and lea making up over half of all code.

Opcode pie chart

Between the expected compare and jump instructions, “Load Effective Address”, “eXclusive OR” and “No OPeration” surprised me. Of course nop is probably padding and xor is the best way to zero a register, but I have no clue why there are so many lea everywhere.

Nobody really seems to know how many x86 instructions there are, but someone counted 678, meaning there are over 200 instructions that do not occur even once in all the code in my /usr/bin.

It would be interesting to break it down further in “normal” instructions, SIMD instructions, other optimizations, and special purpose instructions… if anyone can be bothered categorizing 600+ instructions.

Pepijn de Vos