PicoCart64: Nintendo 64 flash cart using a Raspberry Pi RP2040 | Hacker News Reader

PicoCart64: Nintendo 64 flash cart using a Raspberry Pi RP2040

github.com

134 pointsazhenley41 comments

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?

EDIT: more info on Twitter apparently: https://twitter.com/kbeckmann/status/1539738410063208454

I had the same thought, tell us more!

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 even can output HDMI https://github.com/Wren6991/PicoDVI

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 .

I'll add that this makes preservation a lot easier.

For example, there's the 64DD. It's a disk drive peripheral for the N64. It's Japan-only--for various reasons.

Some people thought it would be difficult to emulate. Nope, it turns out it's basically just some disk I/O. Games are just data.

Data which, with fairly simple patches, can be run from the same flashcarts you can run normal game data from!

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 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.)

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!

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.

If you made a 0.8mm board you don't even need a usb-c connector as the board fits into the cable.

Supposedly this works great (havent tried myself though)

https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

For peace of mind I'd go with the connector, which should be sturdier and doesn't dictate a board thickness.

The one I use starts at $0.27 for 1, and goes down with bulk pricing:

https://lcsc.com/product-detail/USB-Connectors_Korean-Hropar...

It needs to be 1mm for the n64 cartridge edge connector.

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

Probably Lik-Sang. [0]. RIP.

[0] https://en.wikipedia.org/wiki/Lik_Sang

Most likely it was Bung Enterprises: https://en.wikipedia.org/wiki/Bung_Enterprises

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.

AFAIK, this has been the go-to method by scene groups to do their rips - this thread goes back to at least 2007: https://dcemulation.org/dumpcast/viewtopic.php?t=153

Edit: but yeah, you're probably right about the early dumping ways...

Oh cool, goes back farther than I thought!

Related: Reverse emulating a SNES (on a NES)

https://www.youtube.com/watch?v=ar9WRwCiSr0

"Reverse emulating the NES" looks a lot like "forward emulating a cartridge". Badass technical trick though.

An EverDrive 64 sells for $100-200 and is often marked up to $300+ territory. The idea of a $10 EverDrive is really exciting.

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:

https://github.com/webhdx/PicoBoot

The UnoCart is the Atari 800 version of this:

https://github.com/robinhedwards/UnoCart

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:

https://github.com/robinhedwards/UltimateCart

We’re there any retail games that are 2MB in size? Fun project but for real use I would wait until v2 for larger rom sizes.

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.

  [1] https://github.com/meeq/FlappyBird-N64/
  [2] https://dragonminded.com/n64dev/libdragon/

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.

i thought pretty much everything on the pico was on the same chip including the flash rom (which is 2MB)?

No, the flash is an external QSPI part.

Here's an N64 memory pak that uses FRAM, so you don't need a battery anymore (original part uses battery backed SRAM):

https://github.com/Element18592/N64-FRAM-Memory-Pak

Awesome to see the recent adoption of Pi modules in game consoles. I can’t wait to see where this goes

Have you see the RP2040 based GameCube modchip?

https://github.com/webhdx/PicoBoot

Argh...I had an idea for this, looks like I was beaten to it.

Unfortunately good ideas don't count unless you act upon them :)

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).

Konrad is an amazing hacker <3

Reply on news.ycombinator.com