Building a USB SNES Controller (opens in new tab)

And I'll add my controller hacking as well:

https://imgur.com/a/Mu43dqg

As a poor college student, I home-built a dance pad for Dance Dance Revolution, out of wood and foil and by soldering the connections into a controller. Worked perfectly!

A while ago I was a little into controller hardware hacking and did almost the same thing but for an MSX! Even wrote a blog entry, but unfortunately in Japanese (with pictures though): https://blog.qiqitori.com/2022/09/%E6%9D%90%E6%96%99%E8%B2%B...

And one year later I also used a Raspberry Pi Pico to convert a USB controller's signals to MSX: https://blog.qiqitori.com/2023/09/using-a-usb-hid-game-contr...

(And later, USB controller to Nintendo Switch, https://blog.qiqitori.com/2023/09/playing-on-the-nintendo-sw...)

Yes. I got my start, back in the day, following along a magazine article on modifying an Atari 2600 joystick for use with the Tandy Color computer. Worked fairly well too, though I ended up modifying my Galaxian arcade game clone to work with it.

It's extremely loose! Using a custom PCB to connect the controller over RJ45 to a custom Pi hat I wrote some code to simply display the button presses on screen, to test the functionality of the controller (we are modifying hundreds). I had to play around a lot with the timings to match up the response of the program with the speed of my finger pushing a button, else the program would return "you pushed B" a dozen times on a single push.

I do wonder how much original SNES devs had to consider similar scenarios.

I converted a DOS-era joystick like this, and the shift registers inside were stable at higher speeds, I don't remember needing to care about the timing much. I may have just run the clock in a for-loop during the polling loop.

Thanks for teaching me about SPI, I might have a play around and see if I can get that working.

RGMX has a video series on a lot of the low-level SNES functions. If you've ever wanted to know how Mode-7 works, it's great.

The video below goes over the controllers, Super Scope, mouse, etc. A brief discussion of the multi-tap starts around 16:00. You are correct that it leverages the spare pins.

https://www.youtube.com/watch?v=2Dw7NFm1ZfY

The schematics for the multitap are out there in the SNES developer manual [1]. I actually made one on a breadboard for fun [2] and eventually turned it into a PCB. It's a pretty simple circuit with an analog mux and some tri-state buffers.

[1] https://archive.org/details/SNESDevManual/book2/page/n385/mo...

[2] https://www.downtowndougbrown.com/2013/04/homebrew-snes-4-pl...

The NES also had “multitaps”. One model was wired (the “Four Score”), the other was wireless (battery powered; the “Satellite”) with an IR receiver unit that plugged into both controller ports.

The IR wireless one was, in my experience (it was the only one I had) far less janky and failure-prone than one might suppose. Actually worked quite well.

The way I saw it, I'd rather have a memento of the past that I can actually use than one that will sit around in a drawer.

If you're making a home made arcade stick, check out the GP2040-CE project - https://github.com/OpenStickCommunity/GP2040-CE

It's got low latency and good compatibility for a bunch of platforms. Even some compatibility for PS4.

Thank you! Glad you liked it :)

They are if you have anything else that needs to be done at the same time. I would say they're fine if you have nothing else to do while waiting, or you need microsecond delays to generate a signal like in this case.

Wow, that would be incredible! Did you document the project at all? I'd love to know more and maybe attempt something similar.

Don't forget that these controllers operate at 5V logic and the ESP32 at 3.3V. Supposedly the ESP32 can tolerate 5V inputs [0], but it's probably best to put a level shifter between the two.

Yeah I too wondered why the author would target 60Hz at all. The fact that the SNES controller is polled at 60Hz is simply a consequence of the game reading the input at that rate. As mentioned in the other comment in this setup the polling of the controller is not in sync with the game reading the input at all. Thus even if you target a polling rate of 60Hz perfectly you'd actually have worse input latency than the original hardware.

It would be much better to target 120Hz or higher to reduce input latency and bring it as close to the original hardware as possible by ensuring there is always an up-to-date input state ready for the game to read.

If for the sake of argument we are plugging this into an SNES emulator running at 60Hz, then the stack between the USB gamepad and the emulator already has to handle that the gamepad is not rigidly synced to the emulated SNES and will presumably take every input from the gamepad and use it as the emulated input to the SNES next time it asks, unless a new one comes in first.

At slightly faster than 60Hz, the net effect will be that the delay between input and having an effect on the SNES will wander about 1/60th of a second over time, as the sync varies, and every once in a while a particular input will be overwritten before it makes it into the emulator. It may be very difficult to perceive this, though, due to other delays already built into such a set up. On a real SNES, it would be right on the edge of perception anyhow.

Being very close to the poll rate but not quite there is probably near the theoretically worst case. It would probably be much better to poll at 240+Hz, cutting the latency between input to a consistent 1/4ish of a frame. However, I doubt this improvement could be "felt" by very many people at all.

Have fun!

The Arduino is a single-threaded microcontroller running a single code loop, plus interrupts.

delayMicroseconds is a busy-wait loop, so is relatively precise (to within a few instruction's execution time.

However, interrupts can happen during that sleep, and the time spent handling interrupts won't be accounted for properly.

It isn't a real real-time system, but for a project like this, it'll be good enough.

Yes, it is real time, but due to interrupts you have to manage critical sections with cli() and sei() and your time base is a 16.000 MHz crystal.

Most instructions for ATmega and ATtiny execute in 1 clock cycle so writing deterministic, time-critical code is straightforward.

Largely, yes. Arduino code runs on bare metal, and delays simply block execution so they should be accurate with some constant overhead.

:thumbs_up:

I did try different 8BitDo controllers, and one issue with them is the "multi-mode": in order to make them work with Android/iOS/Windows/whatever, you need to press some key before connecting them, to change the way the OS recognizes the input. Which is a deal-breaker for small children, and prevents keeping things simple (e.g. "remember to disconnect and reconnect the USB before turning the power on", e.g. when using a Raspberry Pi-based console emulator). For wireless controllers, it's even worse (extra Bluetooth mode). If only they had mechanical switches to select this behavior... You may need to keep the instructions booklet with it, just to remember which keys must be pressed before turning it on, to see which mode will be activated. The controller in TFA is more useful in this scenario, since it will always behave in the same way.

I speed run Zelda 2, though using an SNES controller. My experience with 8BitDo controllers is that they're stiffer than OEM, especially with the d-pad arrow keys. If you can use the analog inputs, they're great -- I use a Pro 2 with my Switch all the time. The d-pad, though, is a deal-breaker for classic gaming. iBuffalo used to make a controller that really did feel like OEM, but they've been out of the business for a few years.

There is also the 8BitDo Mod Kit for SNES/SFC Classic Edition Controller which allows to convert original SNES controllers to bluetooth. https://shop.8bitdo.com/products/8bitdo-mod-kit-for-snes-sfc...

Maybe if you want to play super mario, the 8bitdo sn30pro works.

But it has a huge problem of false diagonals, making is absolutely worthless to play tetris, or any fighting game that requires precise control. If you need precise controls, avoid this model.

8BitDo makes great controllers. I have an SN30 Pro, a Zero 2 and a pair of Ultimate Cs. All of them have been used extensively and they are all excellent quality.

On the other hand I've had back luck with generic NES and SNES knockoff USB controllers. The quality is much worse than the originals especially in the D-Pad. It seems nobody but 8BitDo can get this right.

If you stick with 8BitDo you'll have great quality but they don't necessarily match the form factor of the originals. I can see why OP would want to convert a real one.

It's not the same... It's like buying a non-nintendo controller in the past. They simply don't feel and respond the same

I wish they would have proper Linux and fwupd support, which they seem to have dropped.

I'm using the 8BitDo wireless pads on my Switch and am very happy with them— vastly more comfortable than joycons, but a fraction of the price of the official pro controller.

In that case, you’ll love tom7’s Reverse Emulation video: https://youtube.com/watch?v=ar9WRwCiSr0

I once designed a custom PCB that fits inside the original NES four score case. You can connect 4 NES controllers to it and the inputs were sent to a Raspberry Pi via UDP (so no wire between couch table and TV was needed).

I think my PCB had more parts for its simple power supply than all 4 NES controllers combined.

These things are an absolute masterpiece of simplicity!

SNES can go up to a whopping 3.58Mhz (NTSC clock, not sure if exactly the same for PAL) but I believe due to some bus/architecture weirdness slows down to 1.79Mhz (which is what the NTSC NES runs at) when reading the controllers.

Now the SuperFX chip, in Star Fox, ran at 10Mhz. Later versions like the one in Doom on SNES went up to 21Mhz.

That 16MHz of processing power is doing a pretty magical thing, though. It's encapsulating what is basically a serial bus, into a universal serial bus — i.e. it's making it so that:

• you can plug this controller into any USB host, and the host can probe the device and discover that it's got a USB HID gamepad device

• the SNES buttons get mapped onto standard USB HID event codes (HID Usage IDs), such that you could have a SNES controller plugged into one USB port and a Sega Saturn controller plugged into another USB port on the same computer, and they'd both be using a common language for events like "D-Pad Up button pressed", such that a framework like DirectInput or SDL can understand that out of the box. The SNES just uses the same 16 bits of input register no matter what's plugged in (gamepad, mouse, super scope, etc) — with games either assuming a specific static input device type and thus parsing those 16 bits in terms of that; or telling you to have a gamepad on P1 and whatever on P2, and then asking you on startup what type of thing you've got plugged into P2.

• And — not so applicable to the SNES — but with USB, you can also have more than one of any given HID Usage ID reported by the same device. A gamepad with two analogue sticks can† just report analogue data for X/Y/Z-axis Usage IDs twice.

• You can also have as many USB HID gamepads plugged into the same host machine at the same time as you like†. Even USB 1.1 is a very fast bus compared to the SNES's input polling rate; tons of HID reports will "fit" down the pipe as packets. The SNES, meanwhile, fundamentally only supported four input devices at once, because the hardware had exactly 64 bits mapped starting at $4218, representing the 16-bit readouts from polling of up to four input devices. And even then, if you wanted all four inputs to be polled, then you'd only be getting input for devices 1+3 refreshed on even frames, and 2+4 polled on odd frames.

• You can have tons of other things — more data-intensive things! — plugged into the USB bus at the same time as the gamepad, and it'll still work just fine, because USB HID reports are given high QoS by USB host controllers and hubs. The SNES needs a separate bus for the cartridge, but on a PC the equivalent of a "cartridge" (an eGPU + eFPGA + NVMe, let's say?) could be connected to a USB4 dock, that your gamepad is also plugged into — and a single USB cable will take all that into your computer.

• You can hotplug USB devices, without confusing either the client input device or the running program on the host. Both sides of a USB link (well, assuming the client retains power when unplugged) have knowledge of the connection lifecycle state. "Device unplugged" or "device plugged in" or even "a new, second device plugged in" are just like any other gamepad events, that your game can have a handler for. Meanwhile on the SNES, both input ports are just assumed to be populated at all times — and are therefore electrically live‡ and receiving a polling clock at all times. The distinction between there being 1/2/3/4 input devices connected, has to be made manually, by the game asking. There's no way for the game to know that a device was plugged/unplugged.

---

† Consumer OSes mostly don't like this — but that's because consumer OSes are dumb, and have to this day never surfaced a high-level "gamepad API" that actually exposes the full extensibility of USB HID reporting.

A high-level API that was actually designed to reflect the HID spec, would have an input-event report be a dictionary where the keys are usage IDs and the values are arrays of sensor readouts. Or a stream of polymorphic Usage-ID-keyed sensor-readout records. And either way, each report would at the very least identify which USB device it's coming from, so that you can tell apart reports from two identical controllers.

But instead, what most gamedevs get from using industry "best practices" when writing an app-game using e.g. DirectInput or SDL for input, is an API that's even more naive than the SNES joypad input registers — it assumes that there's exactly one gamepad, and that it's reporting exactly one of each HID Usage ID. (And even worse with XInput, which assumes a fixed set of Usage IDs corresponding to "what an XBox controller has!")

As such, most USB HID gamepads sold to consumers for use with PCs, in practice, don't take real advantage of what USB HID gamepads can in theory report.

USB HID gamepads made to be used in proprietary ecosystems, on the other hand — think "the Nintendo Switch Pro controller" or "the input board on an arcade machine" — are free to be designed to actually use USB HID correctly. Which is why such devices usually need special drivers on PCs. They're not speaking a brain-damaged wire protocol; rather, they're living in the present and taking full advantage of USB HID features... while consumer OSes are still stuck in the past, unable to cope. :)

This is also why so many systems like emulators that support these proprietary input devices — or games complex enough, that they expect USB HID devices that are themselves complex enough to only be possible if using the spec the modern way (think, uh, this thing: https://www.amazon.ca/Logitech-Saitek-Vehicle-Panel-945-0000...) — just skip the high-level gamepad-input-handling frameworks, and just register to listen to USB HID events directly. Because that's the only level at which they'll receive the information they actually care about, without the OS first mangling it into incomprehensibility.

‡ I believe polling for the input ports get zeroes rather than garbage if the ports aren't connected — but this is likely more for hardware protection than anything else, with pulldown resistors on the read path to prevent you from shorting out the input pins by unplugging while the console is on. Nintendo at least learned the lesson of the PS/2 bus.)

Raphnet adapters (designed by one guy in Canada) are the most popular option among serious speedrunners, if you want minimum latency.

Their equivalent product is currently out of stock: https://www.raphnet-tech.com/products/snes2usb_1player_adapt...

Kind of amazing that you can get a whole controller (including buttons etc.) for a fraction of the cost of an adapter. Probably a less authentic experience though: https://www.aliexpress.com/item/1005005998083106.html

I just got a RetroUSB Genesis adapter to use a 22-year-old Asciiware Power Clutch SG I had rotting in the basement for some JavaScript Gamepad API experiments. The adapter works great, feels good to breathe new life into an ancient peripheral!