N64/Gamecube controller to USB adapter
Nintendo 64 and Gamecube controllers are excellent controllers which are quite appropriate
for many PC games, and of course are perfect for emulators!. The microcontroller
firmware in this projet implements a standard HID joystick which means that no
special device driver is required. It works perfectly well under Linux and Windows.
- Supports Wired Gamecube controllers and dance mats (Official and clones)
- Supports Wireless controllers (Known to work at least with the
Nintendo Wavebird (since firmware version 1.2) and an Intec wireless controller).
- Supports N64 Controllers (Official and clones, including the famous HORI-mini)
- NEW!: Supports the N64 "Rumble Pack" and the
Gamecube controller built-in vibration function. (Since release 2.0)
- NOT SUPPORTED YET: N64 Memory cards.
One of my friends wanted to play Nintendo 64 games on his PC using an original
controller... so I developped an adapter for doing this. But since Gamecube controllers
use a very similar protocol, it was easy to support Gamecube controllers
Gamecube and Nintendo 64 controllers both work at 3.3 volts. But on the USB bus,
only 5 volts are available. For this reason, a voltage regulator is required.
Apart from the different firmware, this is the only difference (and additional complexity)
this project has with my
Nes/Snes controller to USB
N64 or Gamecube to USB with regulator on-board:
Pictures of the printed circuit board with an lm1117 adjustable voltage regulator:
Pictures taken during development with the new PCB:
Pictures of the N64 to USB prototype. I used an lm317 adjustable voltage regulator:
The N64 Hori-mini and white Gamecube controller with extra long cable work!
Here are some pictures from Declan Williams (16 years old!):
built and used
my circuit in a few projects:
The Bliss 4-pack
The Bliss Worm
The bliss 4pack displayed here is NOT a 4 player version of the project. It is
only an USB HUB with 4 built-in GC/N64 to USB converters.
Ludivine built a N64 adapter based on this project. The voltage regulator is on the back side of the PCB.
Here are the schematics:
Some webpages mention that the Gamecube controllers work at 3.43 volts,
some other pages says it's any voltage between 3.3 and 3.8! volts... I read
an old message in the comp.emulators.game-consoles news group where the author
said that the Nintendo 64 supplies 5 volts to the controllers (Wrong!). I measured
3.36 volts on my N64 so personally, I choose to supply 3.3 volts to my Gamecube
and N64 controllers.
In order to obtain 3.3 volts, you can use a fixed voltage regulator such as the 78M33C or
an adjustable voltage regulator such as the lm317 or lm1117 (exemple
If you use an lm317 variable voltage regulator, here's a simple tool which can help you
find a good value for R1. Any voltage between 3.26 and 3.40 volts should do the job.
Wavebord color code
(for reference only)
I have been informed that the color of the wires running from the
gamecube connector to the PCB inside the receiver seem to be
- +3.3v: Rouge
- Data: Vert
- GND: Brun (broche)
- GND: Violet (bouclier)
Keep in mind that wire colors varies between manufactures, and sometimes between revisions of the same product. Blindly following color codes without any checks can be a good way to ruin electronics.
Printed Circuit Board
The PCB is an improved version of the PCB used for
the Nes/Snes controller to USB.
new PCB has a voltage regulator and reprogramming contacts on the bottom side.
Here are composite images of the top and bottom layers:
The regulator is an lm1117mp-adj. 0 ohm resistors must
be installed to select the power source (USB 5 volts or regulator output)
for the microcontroller and the controller. In this case, R5 and R8 must
Here is a wiring diagram for the board:
And finally, here are the gerber files which you can use produce this PCB:
Due to the fact that this board is two-sided and has numerous vias, building it at home may be a little harder than the ususal.
If you want, you can get professional PCBs from
my online store
The PCBs from my store, however, are a little older than the one above. I've had
a huge quantity produced with a small mistake: The 5 volts supply from the USB bus does
not reach the regulator!
In order to correct this, a small wire has to be installed on the bottom side:
HEX File and fuses
Here is the hexfile which must be programmed into the Atmega8 (or Atmega8a). Changelog in table below.
settings for this projet are: high_byte=0xc9 low_byte=0x9f
For details about how to program an AVR, please
visit my AVR programming
The source code is available under the GPLv2 license. See License.txt for more
information. The project compiles with avr-gcc.
||February 12, 2013
- Reduced USB interrupt-in poll interval. (Better responsiveness in games such as Super Smash Bros)
- Calibration fixer updated to support this new firmware.
- The calibration fixer source code is now included.
- Serial number now working again.
- Use a new USB Vendor ID.
||November 13, 2011
- Fixed USB detection when no controllers are present. This was broken in version 2.0.
Controller swapping still worked fine though.
- Changed the device name to allow easier version identification.
||November 1, 2011
- Force feedback support:
- N64 rumble pack and Gamecube controller built-in vibration supported!
- Implemented using standard HID PID (Physical Interface Device) which
means: No special driver required. Tested on Linux (fftest) and win7 (Project64/DirectX).
- Special thanks to Sean Green
for providing an updated device descriptor and an example main.c from his own project for me
to use and finally implement this feature. Without this, I don't
think I would have ever taken the time to add this feature.
- The L and R buttons analog feature on gamecube controllers can be
disabled. Useful when they are causing problems and you don't mind
using only the L and R digital switches. To disable the analog feature,
fully press L and R when connecting the controller.
- The calibration fixer windows executables are now provided with
the source code. See calibration_fixer/readme.txt for details.
- Code cleanups:
- New asm transmission code capable of sending many bytes with perfect timing.
- N64/Gamecube communication code is now shared between the N64 and
GC drivers. It's the same wire protocol so it makes sense.
||June 11, 2011
- Update gamecube reception code using the new N64 algorithm from 1.3. To my knowledge,
this does not fix a known problem but being more robust should be good.
- Synchronized controller polling with USB polling. This should prevent USB communications from
interferring with the timing sensitive N64/Gamecube protocol. At least with my equipment, this
seems to fix very rare spurious button presses (One in several minutes).
- Confirmed the adapter works with the new white gamecube controllers with extra long cable (Japanese import).
- More reliable support for N64 Hori-mini pads.Found out why some HORI pads were having issues (random joystick jumps and
spurious button presses). This is due to the HORI communication timing
being very different from original Nintento pads. (1.5 times slower bit
rate). Implemented a new reception algorithm that should be very tolerant
to timing variations and jitter. Works well with all my controllers.
- It is now possible hot-swap between N64 and Gamecube controllers.
With earlier versions, this would have required a disconnect/reconnect
of the USB cable to reset the firmware.
- It is no longer necessary to connect a controller (gc or N64) in
order for the adapter to be detected by the computer (USB).
- Updated USB code to vusb-20100715 from
- License changed to GPLv2
Older versions are available under the Objective Development license (modified GPL).
Read License.txt for more information.
Since firmware version 1.3, all Hori-mini N64 pads are expected to work
correctly thanks to a new algorithm which is tolerant to timing. A technical
explaination of the issue and solution is given below.
Hori-mini N64 pads are known to misbehave with many adaptors. After
testing a donated Hori-mini N64 pad with one of my adapters, they
seemed to work properly... Until someone reported problems. When
moving the axis, there would be sudden jumps to other positions, hindering
gameplay. I tried my Hori controller with a few of my adapters and
on a few computers. I eventually managed to find a unit which did
not work well with my controller and began looking for the cause.
I noticed something unusual as soon as I looked at the communication
between the Hori and my adapter. The Hori communication timing was
very different from what I expected. The image below shows the low/high
ratios for each bit being very different between the poll (from the adapter)
and the answer (from the controller). The HORI controller replies at 66% the
speed of a 'normal' N64 controller:
As you may already know, the bits are encoded as follows. Normally (at least with
Nintendo's hardware), the timing is 3μs low/1μS high or 1μS low/3μS high for
transmitting a 0 or 1 respectively. (See references for more information).
My original code simply waits for the initial falling edge and takes a
sample 2μS later. Under ideal conditions, the sample value (1 or 0) is
representative of the bit being sent. The 2μS delay means the sample
is taked perfectly in the center of the bit. This is nice but only works
if the controller uses the normal 1μS/3μS timing (or something close enough).
As we can see on the right, the sample position when receiving bits from a Hori-mini PAD
is near the rising edge. And it works. But this is bad because in this situation, a
small timing difference may cause malfunction ; there are not enough tolerances. And real life
has proven this to be a problem.
Why sampling near the rising edge is a problem:
Good: Sample centered
Bad: Sample near rising edge
The solution: (since version 1.3)
- The sampling cannot be done exactly at 2μS. There is some jitter introduced by
the polling loop used to detect the falling edge. In other words, some samples will
be taken even closer to the rising edge, or during the rising edge.
- The Hori-mini PAD internal oscillator frequency may vary between units and
with temperature. In other words, some controllers may send bits at a slightly
slower rate (does not help) or faster (helps).
- The relatively slow-rising of the data line may also hinder reliability. At what
point exactly will the MCU see a logic 1? This is in the MCU specs, but
it may change slighly from unit to unit or with newer version of the chip (e.g. Atmega8a)
And if an extension cable increases capacitance, the situation will be worst.
I concluded that I needed a better reception algorithm. Instead of sampling a little
later or writing a new version that would measure the timing and adjust the sample
position accordingly, I came up with something much better which will tolerate faster
and much slower timings within a good margin:
- Measure the time until rising edge (low level duration)
- Measure the time until falling edge (high level duration)
- Compare time spent low vs. high, if more time was spent low, we
got a 0. Otherwise, we got a 1.
Counting is done in assembler to be fast and predicatable
(i.e. no C compiler
optimisations in the way). At 16mhz, each polling cycle takes around 312.5nS.
This means a 1μS level will count as 3 cycles and a 3μS will count as 9 cycles.
If the timing is slower, the number of cycles will be greater, but the time spent low vs.
time spent high relation will still apply.
Since release 1.4, controller polling is synchronized with USB polls. The helps
maintain accurate timing during communication with the controllers. It is
hoped this will increase the (already quite good) compatibility and reliability
of the circuit. Technocal explaination follows.
Remember the USB implementation is all software. The MCU can therefore
be interrupted at any moment to take care of USB communications. Occasionally,
this happens right when we are in the middle of communication with the game
controller, messing with the timing. This is demonstrated on the picture
on the right. Red marks a pause in the transmission (top waveform) because
of USB communication (bottom waveform).
When an USB interrupt occurs at the wrong moment, the gamecube/n64 protocol
frame is potentially corrupted and if it is, it should be discarded. When trasmitting,
we rely on the game controller to detect the error and drop the frame. Then we
simply timeout waiting for the answer. If instead the interrupt occrurs during
reception, we will miss some transitions and won't receive the number of bits
Despite of the above theory, it would seem that occasionally (once in
several minutes) some errors are not detected. A few users had reported that
from time to time buttons seem to be reported active for a brief moment
(even though hey were not pressed) so I decided to eliminate this risk by
preventing these interrupts from occuring at the wrong time. And indeed, with
the new white Gamecube controllers, the only controller I could confirm the
problem with, the problem appears to be gone.
Disabling interrupts during the timing sensitive communication is not possible
due to the software USB implementation that does not allow us to disable
them for long enough a time to be useful. On the other hand, we have approximately
900μS between interrupts which leaves us enough of time to communicate with
the controller without being disturbed. We just need to synchronize with
the USB interrupts and poll the controller when USB is idle.
I thought of a very simple software solution. The logic which controls
the controller polling rate stays the same. But just before the actual
communication, the MCU is put in a sleep mode (IDLE mode). In this mode,
normal execution stops until an interrupt occurs. When the execution
resumes, we know an interrupt has occured and has been serviced so we
can just continue and poll the controller. A small delay before polling
helps us for cases where we receive a few interrupts in a burst.
With this solution implemented, the controller polling is always well
placed inside the 900μS slot available between USB interrupts, as
can be seen in the following screenshot:
GC/N64 and USB
L/R sliders calibration fixer
Uncorrected L/R sliders
Corrected L/R sliders
The Gamecube controller sliders are often problematic because they lack a central resting position. Many games assume
an axis to be active
when the value it reads is different, within a certain margin, from the center
position. Thus, when performing button assignments, the L and R sliders will often immediately register as
active and hinder (or most likely, prevent) successfully configuring the game for the controller.
The following tool must be run after
performing calibration (standard windows tools) . When it is run, it
looks for raphnet GC/N64 to usb adapters and alters the calibration data the system keeps for each
unit found. All axis are left as calibrated, except the L and R sliders which are recentered.
The tool can be downloaded right here:
Supports all firmware versions.
A successfull operation will output something like this:
Technical informations concerning Nintendo 64 controllers:
Technical information concerning the Gamecube controllers:
The N64 controller pinout appears on the following pages:
I cannot be held responsible for any damages that could occur to you
or your equipment while following the procedures present on this page.
Also, I GIVE ABSOLUTELY NO WARRANTY on the correctness and usability
of the informations on this page. Please note, however, that the procedures
above have worked in my case without any damages or problems.
Now you cannot say that I did not warn you :)