Many of the games released on the Nintendo 64 have aged remarkably well, in fact a number of them are still considered must-play experiences to this day. But the years have not been so kind to the system’s signature controller. While the N64 arguably defined the console first person shooter (FPS) genre with games like “Goldeneye” and “Perfect Dark”, a modern gamer trying to play these classics with the preposterous combination of analog and digital inputs offered by the N64 controller is unlikely to get very far.
Of course, you could play N64 games in an emulator and use whatever controller you wish. But where’s the challenge in taking the easy way out? [Ryzee119] would much rather take the insanely complex route, and has recently completed work on an add-on board that let’s you use Xbox 360 wireless controllers on Nintendo’s 1996 console. He’s currently prepping schematics and firmware for public release, with the hope that support for additional USB controllers can be added by the community.
Nintendo historians may recall that the N64’s controllers had an expansion port on the bottom where you would connect such accessories as the “Rumble Pak” and “Controller Pak”. The former being an optional force feedback device, and the latter a rather oddly named memory card for early N64 games which didn’t feature cartridge saves. Only “90’s Kids” will recall the struggle of using the “Rumble Pak” when a game required the “Controller Pak” to save progress.
Thankfully [Ryzee119] has solved that problem by adding battery backed storage to his adapter along with some clever code which emulates the “Controller Pak”. Similarly, the “Rumble Pak” is emulated by the Xbox 360 controller’s built-in force feedback and a bit of software trickery. Specific button combinations allow for enabling and disabling the various virtual accessories on the fly.
But the best part of this modification might be how unobtrusive the whole thing is. Not only does it allow you to still use the original controllers and accessories if you wish, but it only requires soldering a handful of wires to the console’s motherboard. Thanks to the surprising amount of dead space inside the system’s case, it’s not even a challenge to fit the board inside. You do need to use the official USB Xbox 360 controller receiver, but even here [Ryzee119] opted to put a USB port on the board so you could just plug the thing in rather than having to cut the connector off and trying to solder it to the board yourself.
It probably won’t come as a surprise that this isn’t the first time [Ryzee119] has fiddled with the internals of a classic Nintendo system. We’ve previously covered his fantastic custom PCB to fit a Raspberry Pi Zero into a GameBoy Advance.
[Thanks to Gartral for the tip.]
Why is there nothing like this for ps2? i have had 4 dead ps2 controllers in the past year. its like the ps2 controlers are disintegrating/
Because PS controllers are better than XBOX ones ?
No they aren’t. The placement of the ps2 analog sticks are ergonomically incorrect. The fact that you’ve gotten used to them doesn’t make them better.
I’d like to know the technical reasons that forced the use of a battery over flash.
Any more detail on that?
Flash isn’t forever and some of these batteries can last decades, prolonging the flash. The cheapest of the FLASH memories tend to get corrupted after many years of sitting dormant.
Sure, but Flash doesn’t suffer from potential leakage. Even other non-battery methods still last ‘decades’.
Other than preference, were there any show-stoppers which made the target battery-backed?
Write lifetime. Depending on the game, you could see a write ever few minutes which means you might get a few days out of these since there will be no wear leveling.
Most small flash can still be 10K or even 1K write limited. Some does go 100K or 1M, but that depends wildly on process. It’s not exactly a searchable option on Digikey.
N64 memory cards are all SRAM, but they can be modified to be FRAM instead. I would have chosen FRAM as I have had so many problems with ControllerPaks (even official ones).
This design makes no sense to me. The whole thing could be achieved using a single STM32 microcontroller and an SPI flash chip. Why use 2 separate microcontrollers, a separate USB host IC and a battery backed SRAM?
He’s not exactly mass producing these. I’ve answered my thoughts on the BB SRAM.
He’s not optimized it, but I do respect his thoughts on this
“There isn’t too much to it. Most of the magic happens in the firmware. I had a single microcontroller dedicated to all the low level N64 Controller protocol functions. This can be computationally heavy and the responses to the N64 console must happen in real time using a custom protocol. This has a direct bus to an SRAM chip storage chip which acts as my Memory Pak. To achieve this I implemented a fairly power STM32F3 series microcontroller.”
and
“One thing I implemented with the USB host controller side is that it is effectively a clone of the Arduino Pro Mini (https://store.arduino.cc/arduino-pro-mini) with the USB Host Shield Mini (https://www.circuitsathome.com/usb-host-shield-hardware-manual/) Therefore it is 100% compatible with the Arduino USB Host Shield Library (https://github.com/felis/USB_Host_Shield_2.0) which made it alot easier to develop the USB side of things. In theory it should be possible to add support for any number of USB Controllers. If you’re familiar with Arduino’s, the chip is just programmed with the Arduino IDE using an FTDI serial interface (Same as the Arduino Pro Mini) so it’s quite easy for me to debug and update.”
Do we always need a comment saying “wtf ? this can be done with just a [insert your favorite cheap chip here]” ?…
It’s like if there always was a comment like “why is Hackaday reporting another (mostly) closed-source retrogaming-clickbait product ?”…
I kind of agree with you. Often bloat is the maker taking the easy road (or using tools tools they’re familiar with), but could also be for a valid reason (like Sentinel points out above). There’s also the chance the maker didn’t think of doing it another way, and for that reason it’s often worthwhile readers pointing out alternative methods.
An example, a friend was recently telling me about a DNS box he put together to filter ads, might have been pi-hole or similar. This was done using a SBC that had been gathering dust, put in a nice box yada yada – an interesting conversation about a weekend project. I couldn’t help but ask though if he could implement the filter in his OpenWRT router, and it simply hadn’t occurred to him that this may have been an option.
It makes sense if you forget about the inner complexity of the chips, which does not really concern us, and think of each of them as a module which does one thing but does it well. Myself, I’m also a bit wtfied by this approach. But if using several microcontrollers means that the project is finished earlier or finished at all, it wins over equivalent super elegant but never finished project implemented with a single 555.
Not the creator of this, but I know him well. SPI Flash was attempted, but the response times were too slow and too variable for the strict timing of the N64 comms protocol.
The same goes for the separate microcontrollers, there weren’t enough cycles left to manage USB as well as the comms protocol. Maybe there was a way around this without using a faster MCU, maybe not.
> Many of the games released on the Nintendo 64 have aged remarkably well
Am I the only one to think that early 3D games have *not* aged well? Unlike the 2D era consoles like the SNES and the NeoGeo.
It’s the gameplay that has aged well despite the low polygon count.
In many cases the graphics have aged well as well. Games like Mario Kart 64 used sprites for the main characters and then there are game’s like Shadows of the Empire which inexplicably look pretty decent despite their age.
I’d say the N64 has aged pretty well. all the modern features of a proper 3D game are there, just with fewer polygons and lower res. PSX on the other hand… it’s just a mess of pixels and jumping polygons.
You should read the project before commenting
“I had a single microcontroller dedicated to all the low level N64 Controller protocol functions. This can be computationally heavy and the responses to the N64 console must happen in real time using a custom protocol. This has a direct bus to an SRAM chip storage chip which acts as my Memory Pak. To achieve this I implemented a fairly power STM32F3 series microcontroller.
To enumerate the Xbox 360 Wireless Receiver over USB I implemented a MAX3421 USB Host Controller which is driven by a small Atmega328PB microcontroller. This section handles all the complex USB enumeration and polling of the Xbox 360 Wireless Controllers.
Finally there is a simple power supply which takes the 12V available within the N64 console and converts it to 5V for the USB, and 3.3V for the logic.”
I would like to do the same thing is it possible to follow the step which is mentioned in this article or any other tips to do this properly?
I miss just one feature in this whole product… Status leds that turn on when a player connects.
If this board lets you use dual analog in GoldenEye/PerfectDark, by using 2 controller ports, I’ll buy it right now.