N64 Controller Serial Protocol Sniffer

Posted onby

intendo 64 Controllers

If you open an NES controller, you will find how simple and elegant it really is. It consists of no more than a shift register and a few pull-up resistors. Specifically, it is a Parallel-In-Serial-Out, PISO for short. The shift register that is used inside these controllers is the 4021.

  • N64 Controller Serial Protocol Sniffer; X Force Adobe Cs6 Keygen Invalid Request Code; Download Mod Bus Euro Truck Simulator 2 Versi Indonesia; Cyberadmin Pro 5 Full Sin Publicidad Google; Whitney Houston Complete Discography Torrent; Ride On Time Yamashita Rar Download.
  • If you have an Android phone/tablet with USB-OTG, then you can play with the sniffer without a desktop/laptop computer. Just install “DroidTerm (v7.2)” and run its “USB Virtual Serial Port” option (Baud Rate 9600). See below for the screenshot from my phone. The procedure is simple: Open up Serial Monitor and set the baud rate to 9600.

N64 Controller Serial Protocol Sniffer Usb

While I was in Pittsburgh for an extended period of time for work, I got anurge to interface an N64 controller to one of my projects. Don't ask why, I getthese weird urges sometimes. heh.

Before we get too far into this -- I am only interested in the hardware levelcontrol of the controller and devices attached to the controller. I'm not interestedin emulation of the N64 or c0py1nG y3r 31337 r0m 1m4G35, so DON'T ASK. Thefollowing links are to places with similar technical or emulation interests. Idoubt they are interested in swapping ROMs, either.

Steven Hans' N64 Stuff
Ken Kaarvik's Gameboy Stuff

N64 Controller Serial Protocol Sniffer Device

Anyway, upon further inspection, the N64 <--> Controller protocol is relativelysimple to imitate. This page is dedicated to furthering the understanding of allaspects of the controller. Right now I can get it to return the button status,and with time I'll figure out how the RumblePak and MemPaks are talked to.

The electrical specification chosen by Nintendo seems very close to Apple'sDeskTop Bus protocol, where all data transfer takes place on a single wire,and the duty cycle of the signal determining the data. Since I'm not familiarwith the ADB protocol any more than that, I can't comment further.

However, it is important that anyone who is interested in talking to thisthing on a hardware level knows that there is a particular way in which you must interface -- DO NOT ever drive the line high! -- The N64 or thecontroller may bring the line low at any time and if you're trying to drive ithigh you may damage either the controller, the console, or whatever you're usingto talk to it! The controller has a built-in pullup resistor -- either makedamn sure that whatever you're using to play with it doesn't drive the line highor is incapable of driving it high. Open-collector outputs are handy for thiskind of thing.

Here's the first step: understanding the encoding of bits on the 1-wireinterface. It appears that all bits are 4us wide, and it's the amount of lowtime that determines the bit's value. Please note that the assignment of '1'and '0' has been done my myself; I could have them ass-backwards, but theyseem to make sense to me. :-)
Also, the communications format includes a stop bit at the end of everything.All this involves is letting go of the line and waiting 4us before doinganything else.

This is sent out to the controller upon powerup, and some games (StarFox64does this) send this every time they want to read button status as well. Why,I don't know. I don't have all the bits figured out yet, but I have 3 scopetraces that give some insight... A controller with a MemoryPak gives adifferent response from one with a RumblePak and they both give different responsesthan one without any kind of cartridge plugged in. (I'll put this up assoon as I get the scope software reinstalled.)

Sending 0x01 to the controller makes it respond with 32 bits of buttoninformation. Please note that the controller responds VERY QUICKLY -- within2 to 3us on my particular unit. Whatever you're using to talk to this thing hasto be very quick. An 8MHz PIC would have a difficult time doing this. Betterto use a 10-20MHz one and bit-bang it.

The information is in the following format:

(1 = button pressed, 0 = button released)
4Directional Up
5Directional Down
6Directional Left
7Directional Right
8unknown (always 0)
9unknown (always 0)
12C Up
13C Down
14C Left
15C Right

The next 16 bits are for the analog joystick.

The analog joystick is an optical module and operates very much the same asmost mice. If I recall correctly, it has 24 'positions' in each direction fromcenter, with center returning 0. If you're not interested in using the whole controller, this joystickis a seperate module and can be removed from the controller. It's easy touse... 6 pin interface, 2 for power, then the remaining 4 are for the X and YI/Q signals. Very nice. Not too bad in price, either.

The information returned in the last 16 bits from the controller is for thesigned X and Y information, respectively. i.e. the first 8 bits are the signedX position, and the last 8 are for the signed Y position. From center: up andright is positive, down and left is negative.

28 July 1999 - I finally got around to updating this page. I had made amistake in the first edition of this information -- The controller sends a stopbit which I was mistakenly including as data. The data above is now corrected.Thanks to those of you who emailled me with that correction.

The folks at the N64 Controller Interface link above have discovered how tomake the rumble pak function. That information is coming here shortly for inclusion. I am also close to having my N64 controller reconnaissance unitworking, so getting full info on the rumble and mempaks should be coming soon.:-)

Right now, here is the base info on how to do it:
To Init: send 03 80 01 followed by 34(!) 80's
To Start Rumble: 03 c0 1b followed by 32 01's
To Stop Rumble: 03 c0 1b followed by 32 00's
After starting or stopping a rumble, the controller returns with 3 bytes. I havenot personally done this before, so I don't know what those three bytes are (yet).Thanks go to Ken Kaarvic for posting this info to the Gameboy development list, andfurther thanks go to Stephen Hans for providing Ken with the original information.

Ken Kaarvic has used this information here to successfully connect an N64controller to a Gameboy through the link port. Head over to his page for moreinformation on that.

When I get some time I want to get a little PIC connected up inbetween thecontroller and the console and start having it do reconnaissance so I can getmore information regarding RumblePaks and MemPaks. After that I'd like to getthe services of a skilled Windows 95 VXD writer to create a nice VXD so I canuse the N64 as a gaming device, complete with functionality for RumblePaks andMemPaks. Who knows, this could be marketable. I know there are some out therenow that have adapters but AFAIK nobody can talk to RumblePaks and MemPaks.

Ideas for N64 data:

  • ROOMblePak - modify a standard Rumblepak to drive a small AC motor with an offsetweight and place it under your couch :-)
  • TerrorPak - Same idea, but give the user a mild electrical shock instead of rumbling
I've actually had emails regarding the latter idea! My suggestion: optically isolateand on the side where you connect to your body -- USE A BATTERY -- very important.You don't want any kind of link to AC or significant current. That keeps your masochistictendencies at least safe. :-)

Ideas I'm using this information for:

  • N64 Controller Reconnaissance - a PIC which intercepts and echoes console <--> controller communications and spits out the data to a PC through RS-232.
  • N64-PC Interface - There are a number of people already doing it. Here is why mine'sdifferent:
    • uses VERY simple interface -- one or two ICs
    • interfaces to game port like any other joystick
    • useable by any game through DirectX style interface
    • open-source, open design model
    • works with any N64 controller. Jittery third party units will work okay
    • works with Rumble and Memory Paks through standard interface
  • N64 Macro controller?
  • N64 Keyboard?

Email me if you're interested.


Last updated: 28 July 1999

N64 Controller Interface

Authored by Francisco Martin and Andrew Smith

The Nintendo 64 Controller Interface is an mbed library that allows one or more Nintendo 64 controllers to be used as input devices for the mbed. With this library, one will be able to control games created for an mbed using a Nintendo 64 controller. In addition, the library can easily be used to forward N64 inputs to a computer. Using the N64 Controller executable, one can communicate with multiple controllers.

The N64 Controller executable is it's own stand alone program. It is highly configurable including modifying keybindings to be used with an emulator or changing background colors for streaming and recording. The N64 also allows passive listening. During this setting, one can connect the N64 Controller Interface adapter to an Nintendo 64 and play normally. Connecting the computer simply displays button presses in the GUI . For more information on the N64 Controller program, check its section below.

The N64 Controller Interface requires the following additional devices:

  • 1x Extension Cable for Nintendo 64 N64 Controller
  • 1x Nintendo 64 Controller
  • 1x Switch
  • 1x 2.2K Ohm Resistor

Wire Stripping and Soldering

1. Cut and strip the extension cable closer to the female end. Strip each internal cable on both ends.

N64 Controller Serial Protocol Sniffer

N64 Controller Serial Protocol Sniffer Tool

2. Solder stripped ends to pin wires.

3. Hide exposed wires with electrical tape and/or shrink tube.

Suggested Hookup

The following image is our suggested wiring schematic. Refer to this image when reading the following hookup tables.

Male End Extension Cable

Only necessary if you plan to have controller plugged into genuine N64 as well, and passively read inputs from controller instead of actively polling for them (not yet supported by the mbed library).

+ (red)Vout
- (white)GND
SignalParallel to Female End

Female End Extension Cable

+ (red)Vout
- (white)GND
Signalp25 (pull-up with 2.2K Ohm Resistor)

2.2K Ohm Resistor

N64 controller serial protocol sniffer download

Set to High parallel to the female end of the extension cable. The data pin (p25) should be pulled high, and must be set to OpenDrain mode in order transmit low values as well.

Test Video

To understand how to interface with an N64 controller, one must first understand the protocol that a genuine N64 uses to interface with the controller. All data is transmitted on a single, half-duplex wire (the signal wire plugged into pin 25 above). When this wire is idle, it is high (hence the pull-up resistor). If a falling edge is detected, it means that bits are being transmitted. Bits are transmitted in 4μs intervals. For a 0, the wire is low for 3μs and high for 1μs. For a 1, the wire is low for 1μs and high for 3μs. In order to read a bit, you must simply wait for a falling edge, and then read the wire 2μs after the falling edge. If the wire is high, the value is a 1, if it is low, the value is a 0. All transmissions end with a 1 bit that is not followed by a falling edge, called the signal bit.

The mbed has a built-in wait_us(int) function that waits a set number of microseconds. However, a microsecond is the smallest resolution that the built-in clock has, so relying on it to wait exactly 1, 2, or 3 microseconds (as our code requires) is not reliable. Instead, a custom assembly function was written to wait an arbitrary number of microseconds. Because the mbed has a clock frequency of 96 MHz, it was calculated that 96 clock cycles should equal 1 microsecond. Assuming a throughput of 1 instruction per clock cycle, this corresponds to 96 instructions. The assembly code does bogus add instructions to consume time equal to 1 microsecond. It does this in a loop, with the number of iterations equaling the parameter that was passed in. NOPs are not used, since according to the ARM assembly reference NOP instructions are liable to be optimized away from the processor.

To request data from the controller, the mbed must write the byte 0x01 onto the wire. The controller then responds with 4 bytes, indicating the inputs on the controller.


S = Start, D = D-Pad, C = C-Buttons, * = Unused

Bit16 - 2324 - 31
DataAnalog XAnalog Y

Each button is indicated by a specific bit of the response. A 0 in that bit means the button is not pressed, a 1 means it is pressed. The analog values are signed 8-bit integers. For X, negative is left, and positive is right. For Y, negative is down, and positive is up.

The mbed library polls for this data 100 times a second (using a Ticker), and stores the result. It has methods that allow client code to check the stored result to see which buttons are currently being pressed, and what the values of the joystick are.

Source Code


The Nintendo 64 Controller Interface is an mbed library that allows one or more Nintendo 64 controllers to be used as input devices for the mbed. With this library, one will be able to control games created for an mbed using a Nintendo 64 controller. In addition, the library can easily be used to forward N64 inputs to a computer. Using the N64 Controller executable, one can communicate with multiple controllers.

Last commit 28 Apr 2016 by

The source code for the GUI program is available at the link below. It is divided into three main sections:

  • N64GUI: Takes care of the UI of the program and loading important components.
  • ControllerListener: Runs on its own thread and listens the serial port for signals.
  • ControllerEventHandler: Takes care of mbed commands and simulates button presses.

One can choose which COM port to connect in the Conneciton tool strip. One can choose the Quit command to close the application. Test Connection is used during debugging and will write to the Output window in Visual Studio if the connection is successful. Layout currently allows to hide/show the controller outline. Future updates will allow new layouts. Finally, Settings Allows to set key bindings and background color. Under Key Bindings, you turn off or on Emulator Mode. When on, Emulator Mode simulates the key pressed with the corresponding button.

Source Code

The source code and installer can be found at its GitHub page here or the following website:https://github.com/fomartin/N64_Controller

Please log in to post comments.