While this is interesting, the project page is a little light on what it can do. Can the RPi feed streams of instructions to the N64? Can it act as a co-processor?
The N64 flash cartridge feeds data to the N64 on a 16 bit parallel bus. It's used to store the game ROM.
I suppose by writing clever self-modifying "ROM" code, you could hack the Pi into acting as a coprocessor, but in this configuration, it's just feeding arbitrary game data to the N64 - emulating the ROM that would be seen in a normal N64 flash cart.
Unlike in older consoles like the SNES where cartridges often contained processors and other logic, N64 flash cartridges were by and large just ROM, save data EEPROM or SRAM, and a serial bus for simple peripherals like an RTC or modem that I think was only used in a few very rare games.
The particularly interesting thing about N64 flash cartridges is that they have a seed/key/checksum security mechanism implemented using a chip called CIC. There's a good video about it here : https://av.tib.eu/media/32818 .
The N64 cartridge bus is just a parallel bus. Commercial cartridges may not have included coprocessors, but there isn't anything that prevents them.
(Edit: The cartridge bus is set up to be most efficient when reading/writing blocks of memory (address is latched w/ auto-increment). It would still work for accessing devices though.)
64DD is something we would like to support fully eventually. Since the cart code is all written in C (+PIO), it opens up a lot of flexibility for implementations like this. Not everyone is well-versed in verilog/HDL, but there's plenty of C-coders out there, and iteration time is really fast (build-depoly-test cycle).
The RP2040 runs at 133MHz, with the capability to run even faster (supposedly 420MHz).
With a CPU and GPU running at 94 and 63MHz, the console this chip is driving is barely faster than the chip itself. Build your board right (the 420MHz clock) and it's not even much of a challenge.
So, which one is the coprocessor, really: the super fast chip processing and transmitting instructions to execute, or the N64's VR4300?
At this point, I'd argue that the entire console is just the graphics and sound coprocessor for the RP2040 instead of the other way around!
There are a bunch of potential ways that could go with varying levels of interest to myself.
The PIO of a Pico is quite fast and could theoretically be utilized to pretend to be a specific chip. The question is at what speed. That's what would interest me the most. It would be a fun project to make a Pico pretend to be an SRAM and measure what kind of access speeds it could support. If could be fast enough to hack into old 8 bit machines you could make some awesome Frankensteinian creations.
For N64, in practice, it would only need to be fast enough for the N64 cartridge bus. Whether it can emulate SRAM at full speed is irrelevant, since the cartridge bus is basically just doing bulk transfer operations.
It might be worth your while to have JLCPCB (or another PCB fab) do all the surface mount assembly. They can even do USB C connectors these days, so you just place an order for the boards, receive them in the mail, take them out of the box, and plug them in.
This would of course require laying out a circuit for the bare RP2040 chip instead of using an RP2040 stamp, but it's not a complicated design, and you'll save a lot of time and money if you're planning on producing a decent sized batch of these.
I really think this is the best way to enjoy retro games. Original hardware + cart/cd emulation with games loaded on sd card. Access to every single game in every region for the entire console that runs flawlessly.
The hiccups and bugs you experience with emulation totally ruins immersion. Also best played on CRT.
I still remember there used to be a Hong Kong vendor that sold these flash carts and you could load N64 roms on a CD drive attached to the console. V64
I remember in the late 90s reading about a device that sat in the N64 cartridge slot and loaded games from a zip drive. I think it may have been called z64.
I remember similar units for SNES that loaded from floppy disk.
When the network adapter came out on the PS2, you could stick a standard IDE hard drive into the console and use a special boot disc CD to FTP games to it and load it from the hard drive.
It’s pretty wild that in a span of ~10 years or so you had these devices go from floppy disks > CD drives > ZIP drives > hard drives.
This was also done before on the Dreamcast - it had a "BBA" (broadband adapter) peripheral that could also be used to read / write disc images to / from network locations iirc... so that was around 22 years ago :)
I think you are remembering Gamecube, which could load disc images using an exploit in Phantasy Star Online (PSO). You could point it to your local PC instead of Sega's servers, where a server could inject code (in this case to load games over ethernet). It wasn't a good experience for any game that had CD audio streaming or FMV (so most games).
Funnily, this exploit was based on a previous exploit in PSO for Dreamcast, which was used for cheating.
Back in the day a serial cable was used to rip dreamcast games, and people removed copy protection and FMV to get games working on CDRs (dreamcast discs held more than a CD but the drive could read both types).
Someone also got the BBA for dreamcast working to rip and load games, but I think this was only about 10 years ago.
Also related, insomuch as it is Pico-based hardware for Nintendo console hacking, this is an IPL-injector based GameCube modchip built on the RP2040 as well:
Uses an STM32, a tight loop responds to changes on the Atari's address bus to emulate a ROM, all through STM32 GPIO. Atari 800 has a 1.8 MHz bus, but it's still cool that microcontrollers are fast enough for this to work.
Alternative straightforward way is to use an FPGA, the UltimateCart:
Not a retail release, but 2MB is plenty for homebrew development. For example, there is a clone of Flappy Bird[1] written for the open-source LibDragon SDK[2] that works great on PicoCart64. With FPGA-based flash carts increasing in price and decreasing in availability, I welcome any solution that lowers the barrier to entry for testing homebrew on real consoles.
You could swap the flash to 16MB, or use a third party (almost) pin compatible clone with 16MB flash if you really want. I implemented a very simple compression scheme as well so you can load 16MB ROMs that compress to a few kilobytes less than that, leaving room for the firmware.
The project has just started. I made the proof of concept, and now I am building the full project. There's tons of work left to do. We are building a small community around this and any help is appreciated, be it programming, testing or just ideas/discussion. If you're interested to join in, just come by and say hi in the discord. Everything is, and will stay, open source (BSD-2-Clause).
EDIT: more info on Twitter apparently: https://twitter.com/kbeckmann/status/1539738410063208454