Hacker News Reader

Comment by mmastrac | Hacker News Reader

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

View on HN

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!

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

I had the same thought, tell us more!

Reply on news.ycombinator.com