Tag Archives: emulation


Cube64 GameCube to N64 Adaptor

Enjoy retro N64 games, but can’t stand the controller? That’s the situation I found myself in about 7 years ago, back in 2004. So I built an adaptor, to use Game Cube controllers on the N64.

The adaptor hardware is very simple- all you need is a PIC microcontroller. I originally designed the project to work with the very popular at the time PIC16F84A, or some smaller 8-pin chips. It bit-bangs both protocols, so you don’t need any more hardware than a tiny µC, a couple resistors, and optionally either a voltage booster or battery pack to run the “rumble” vibration motor.

I had a lot of fun building it, since it was an opportunity to reverse engineer a protocol that, as far as I could tell, had never been documented publicly. There were many web sites explaining the basics of the N64 and Game Cube protocols- enough to talk to the controllers with your own hardware. But there was significantly more to learn about emulating an N64 controller, since there are many features that you don’t really need to use the controller, but which games will use. The N64 also has the added complexity of having a memory card slot. The controller implements a protocol that tunnels SRAM reads/writes over the controller wire. Peripherals like the Rumble Pak pretend to be SRAM, but are actually memory-mapped I/O devices.

This is a very old project, but I thought I’d do a quick post with an update on it. I never really released the project, I just quietly posted the source code and the CIA feed. Since then, many others have found the project and built their own.

I recently heard from Jacques Gagnon, who went a step farther. He was frustrated by a few lingering bugs, most notably lack of support for the WaveBird wireless controllers. So he pulled the project into Google Code and has been hacking away! WaveBird controllers work now, and he’s added several other new features, such as the ability to store multiple sets of button mapping layouts in memory.

If you’re still interested in this classic gaming platform and you’d love to have your own Cube64 adaptor, I highly encourage you to check out Jacques’ work. The adaptors are easy to build, especially if you already have some experience with microcontroller programming.


Fun with FPGAs: SPI EEPROM emulator

I found a fun excuse to practice my digital logic design over the past few days:

Loading the SRAM

This is an FPGA emulating the SPI EEPROM (save game memory) in a modified Nintendo DS game cartridge. The emulated EEPROM is backed by 1 MB of SRAM, and there is a USB interface that you can use to simultaneously read or write the SRAM from a PC.

You can use it to really quickly modify or inspect the contents of a game’s save memory- for example, for developing save game exploits or reverse engineering save file formats. You can also use the large memory space as a fast shared memory buffer, for sending debugging information or memory dumps back to the PC, or for loading larger blocks of code from the PC.

The FPGA design is written in Verilog, and I’m running it on the popular Digilent Spartan 3 board. The upload/download tool that runs on the PC is written in Python, plus it can be used as a Python module for writing more complex tools that interact with the DS through this shared memory buffer. Source code is in Subversion, and released under an MIT-style license.


Robot Odyssey DS: First screenshots

This is nowhere near ready for prime-time, but:



Yep, it’s Robot Odyssey for the Nintendo DS. I literally just got this working yesterday, so please don’t ask for any precompiled binaries. If you don’t already know where the source code is, you really don’t want to see it 🙂

Before you ask, this is not a general-purpose DOS emulator for the DS. It’s actually a static binary translator which does most of the work in porting a DOS game to the DS, but there’s still an awful lot of manual intervention required. I only really developed the translator with Robot Odyssey in mind, so there are sure to be features missing that you’d need in order to use it with other games.

My intent is to turn this into a real port of Robot Odyssey to the DS, not just an emulation. In particular, I’d like to re-do the load/save game UI to support timestamps and thumbnails, and I’d like a soldering mode that makes use of the DS’s touchscreen.


Using an AVR as an RFID tag

Experiments in RFID, continued…

Last time, I posted an ultra-simple “from scratch” RFID reader, which uses no application-specific components: just a Propeller microcontroller and a few passive components. This time, I tried the opposite: building an RFID tag using no application-specific parts.

Well, my solution is full of dirty tricks, but the results aren’t half bad. I used an Atmel AVR microcontroller (the ATtiny85) and a coil. That’s it. You can optionally add a couple of capacitors to improve performance with some types of coils, but with this method it’s possible to build a working RFID tag just by soldering a small inductor to an AVR chip:



The above prototype emulates an EM4102-style tag- a very popular style of low-frequency RFID tag which stores a 40-bit unique ID. I can read my bogus ID value (0x12345678AB) using Parallax’s RFID reader. Below is another prototype, with a larger coil and a couple of capacitors for added range and stability. It is programmed to emulate a HID prox card, a simple FSK-modulated tag with a 44-bit payload. I can read this card successfully with my garage door opener. This one is a little large to conveniently carry around, but a smaller AVR package should help.


AVRFID Tag Prototype

So, the shiny electrical tape is beautiful, but how does this thing even work? The power pins on the microcontroller aren’t even connected!

As I said, this makes use of several dirty tricks:

  • The coil actually powers the AVR through two of its I/O pins. Nearly every chip out there has clamping diodes on its I/O pins, which prevent voltages on that pin from rising above the chip’s supply voltage or sinking below ground. These diodes are useful for arresting static discharge.When you first hold the RFID tag up to a reader, the chip has no power- the supply voltage is zero. When the coil starts to pick up power from the RFID reader, these two I/O pins are presented with a sine wave, a few volts in amplitude. Anywhere that sine wave exceeds the supply voltage, some energy is diverted from the coil to the chip’s supply rails, via the clamping diode. The end result is that the chip is powered, and the coil’s sine wave is truncated. The top and bottom of the sine have been chopped off, and it looks a lot more like a square wave now.
  • Power filtering using the AVR’s die capacitance. In the smaller prototype, there is no power filtering capacitor at all. In fact, the power is filtered by the internal capacitance of the power planes in the AVR’s silicon die. This isn’t much, but it makes the power supply stable enough that we can execute code even though the supply is pulsing at 125 kHz.
  • Very low voltage operation. This particular ATtiny85 chip is specified for operation at voltages as low as 2.5v. The extended voltage range version (I didn’t have any of these handy) is specified down to 1.8v. But I’m running these AVRs at barely over 1 volt. At these voltages, the normal AVR clock oscillators don’t work- but I can get away with this because of the next hack…
  • The coil is the AVR’s clock source. The inductor isn’t just hooked up to any I/O pin: it’s actually connected to the AVR’s clock input. Remember the square-ish wave we’re left with after the clamping diodes suck away some power? That waveform is now our clock input. The microcontroller is executing code at 125 kHz, in lockstep with the RFID reader’s carrier wave.
  • Firmware? What firmware? At such low speeds, the chip’s firmware looks less like a program, and more like a sequence of I/O operations to perform in sync with each carrier clock cycle. There aren’t a lot of cycles to spare. In the EM4102 protocol, you could potentially do some useful work with the 32 clock cycles you have between each bit. With the HID protocol, though, you need to output an FSK edge as often as once every 4 clock cycles. As a result, the firmware on the RFID tag is extremely dumb. The “source code” is really just a set of fancy assembler macros which convert an RFID tag code into a long sequence of I/O instructions.

The fact that this thing works at all is quite a testament to the robust design of the AVR. The latest AVRFID source is in Subversion, as usual.