Category Archives: Unicone


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.


Gitaroo Man + DDR Pad

As much as I like the long, complicated projects that involve weeks of soldering, gluing, coding, tweaking, re-tweaking and debugging, it’s really refreshing to occasionally do something cool with no more than an hour or two of work.

This mini-project was my boyfriend’s idea. It’s an experiment in cooperative two-player Gitaroo Man, played using a gamepad for attack/charge and DDR pad for defense.

For those who aren’t familiar with it, Gitaroo Man is a rhythm game where you do battle using music. You play music on your gitaroo to attack or to charge your health bar. To defend against the enemy’s attacks, you dodge by pressing buttons in time with icons that fly toward the center of the screen. We thought the dodging phase of the game might map well to a DDR pad.

Videos first, tech details below. My boyfriend is on the gamepad, and one of my friends defends with the DDR pad. Theoretically you can play this with one person, but we suck too much at the moment. When we filmed this, we hadn’t played Gitaroo Man in years.. so we definitely could have done better with some more practice ๐Ÿ™‚


Bee Jam Blues, Master mode

Implementation Details

This turned out to be such a quick project because it was really just some special-purpose firmware for my old Unicone2 controller emulator project. The firmware combines inputs from the gamepad and DDR pad, maps the DDR arrows to the buttons used for blocking in Gitaroo Man, and it includes a one-shot timer which converts sustained pressure on a dance pad arrow into a brief tap of the corresponding controller button. This way, standing still on the DDR pad won’t affect your ability to use the controller buttons normally during the attack phase.

Overview of all hardware and software components:


The Unicone2 hardware:




Playstation 2 Dual Shock protocol, revisited

Last summer I did some hard-core reverse engineering of the Playstation 2 Dual Shock controller protocol, so I could build a fully-featured Playstation controller emulator/extender device. I wrote up a fairly minimal protocol document, and published source code for an emulator that could impersonate a Dual Shock 2 controller well enough to fool every game in Paul’s comprehensive library ๐Ÿ˜‰

Anyway, this device has been working really well for Paul and I, and we’ve made good use of it. I wasn’t sure if anyone else had noticed my docs and code, though, or found them useful.

Well, recently I heard from Julian Bleecker, who is using my emulator for a pretty nifty project. He also pointed out a very well-organized guide to the Playstation controller protocol, which prominently sites my reverse-engineering work. Cool.

If you’re interested in interfacing anything with a Playstation or a Playstation controller, I highly recommend this guide. It includes information about all of the advanced configuration commands I reverse-engineered, plus it includes all of the basic electrical information that my little document totally glossed over. It sites multiple sources, and they have independently verified everything and provided their own protocol traces.


Playstation controller extender

The little hardware project I started almost 2 months ago is finally done. Completely finished. Bug free! Well, almost. It is, however, in a fully assembled state with firmware that is actually pretty usable.


The Unicone2 is the result of my mini-quest to extend Playstation 2 controllers over long lengths of cat5 cable. A while back I did something similar, extending Game Cube and N64 controllers over ethernet. That was the original Universal Controller Emulator, or Unicone. It used an FPGA, and a pair of Linux boxes. This time the design focus is low-latency, no PC required, and full support for Playstation 2 Dual Shock controllers and the Guitar Hero controller.

The Unicone2 went through a few redesigns before I settled on something I liked. The final version is based on a pair of microcontrollers and an asymmetric RS-422 link over cat5 cable. The remote end, where the physical controllers live, runs a PIC16F877A microcontroller. The base station, where all the consoles sit, uses the awesome Parallax Propeller, an 8-core microcontroller.

The remote unit’s job is pretty simple. It initializes and polls its two controllers, attempting to maintain a constant polling rate. The controller data is streamed over a very low-latency 250kbps RS-422 link. In its spare time, the PIC reads lower-bandwidth data (LED status, force feedback state) over an incoming 19200-baud RS-422 link.

The base station has a much harder job. It needs to emulate four controllers and receive data from two remote units simultaneously. These are all high-speed (250 to 500 kbps) asynchronous serial streams, with no flow control. It’s pretty much an intractable workload for most microcontrollers. I spent a long time trying to solve this problem with an FPGA, just like I did with the original Unicone project. This was working okay, but it was tedious. Playstation 2 controllers are even more complex than N64 controllers, and the problem doesn’t map well to the hardware domain.

When I first read about the Propeller, it seemed like a perfect solution to this problem. Just write one controller emulator, and run four copies of it simultaneously on different processors. The controller emulators and the RS-422 receivers communicate over shared memory, making the whole device quite low-latency. This also leaves plenty of CPU power and memory to emulate other flavours of video game controller, as well as leaving space to implement special effects like controller mixing and synchronized record/replay of controller events.


I’ll end the hardware rambling for today. Paul or I might have to post soon with some more info about the gameplay implications of the Unicone2. Besides acting as an extender, it can already act as a controller crossbar switch and mixer, which will let us experiment with improvised multiplayer action on single-player games.

More photos of the Unicone2 are on my gallery. Firmware and schematics are in Subversion.


Hardware hackery and the Dual Shock protocol

The hardware-tinkering mood I’ve been in lately shows no sign of subsiding. The theme this time: Everything over cat5.

Backing up a bit… It’s summer! Hooray. So, how does one make the most of the season without actually doing something crazy like going outdoors? Of course the answer is to play video games in a different room which has more fresh air and a better view of the day-star.

Some people would pick up the Playstation and move it to the other room, but my solution is to run the video over inexpensive cat5 cable. This isn’t a new idea, or even a complicated one, but component-video-over-cat5 baluns still sell for around $80 each! I recently made my own pair out of a couple more altoids tins and some parts from the junk drawer.

These work really well. There is a little bit of ghosting visible on a black screen, but during normal use the quality looks perfect, or at least no worse than the quality of the TV it’s connected to. Unfortunately, and I started testing it with a little Megaman 2 and quickly noticed an unrelated problem: the distance is a little too much for our wireless controllers. Time to build a Playstation-controller-over-cat5 extender.

I can think of three different approaches for building such an extender:

  1. Purely electrical: Each PSX signal gets an RS-422 driver and a separate twisted pair. This is very simple, but it would require two cat5 cables per controller! I want at least two controllers running over a single cable.
  2. Low-level multiplexing: Compress multiple signals onto each twisted pair by multiplexing below the protocol level. This would be bit-for-bit identical to plugging a controller in locally, but it has a few big disadvantages. It requires quite a fast clock on the twisted pair, since it requires several bits of information to be sent for every bit in the original protocol. It also doesn’t add any flexibility. You couldn’t, for example, add a crossbar switch for controllers which could let you switch one controller between multiple video game consoles via a button combination.
  3. High-level multiplexing: The console-end of the link includes an FPGA which fully emulates one or more Dual Shock controllers. The controller-end consists of a microcontroller that polls a bank of controller ports and sends updates over an RS-485 link to the FPGA. This is very powerful, and it’s the method used by my old Unicone (Universal Controller Emulator) project. Unfortunately, it’s also relatively complex and it introduces a few milliseconds of latency.

I’m currently working on (3), but I haven’t ruled out (2) completely. First step, I need to know how to emulate a Dual Shock controller. The internet is full of pages that describe the very basics of the Playstation controller protocol, but I couldn’t find a single document that described the protocol in anywhere near enough detail to emulate a controller properly. Time for some reverse engineering…

This was quite a lot like the job I did a while ago to reverse engineer the Nintendo 64 controller protocol enough to build a microcontroller that could emulate a controller. Instead of an HP logic analyzer borrowed from work, this time I have a Saxo board from fpga4fun acting as a real-time Playstation packet sniffer. I should be able to use the same packet sniffer setup to finish reverse-engineering the Playstation 2 memory card protocol so that I can add PS2 support to my psxcard USB adaptor. ๐Ÿ™‚

A Verilog core to emulate the Dual Shock controller will hopefully be coming up soon. In the mean time, I published my Notes on the Playstation 2 Dual Shock controller protocol. It’s actually surprisingly more complex than I was expecting. There are several backward-compatibility features, two rumble motors (one with 8-bit speed control), analog buttons… The protocol has several features that the Dual Shock controller doesn’t take advantage of, like support for 254 different force-feedback actuators that you can arbitrarily map into your polling packets. Crazy.