N64 Cartridge Bus

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

N64 Cartridge Bus

Post by mikejmoffitt »

Does anyone have any good details on how the N64 cartridge interface works? I have found a few shreds of information, but nothing comparing to proper (reverse-engineered) documentation.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 Cartridge Bus

Post by lidnariq »

The icequake/crazynation mirror does actually have enough information, although it's a little obtuse.

Basically:
Multiplexed 16-bit wide bus.
Byte access is not supported.
Address is 32 bits wide, and specifies a byte offset, even though the bus is not byte-addressable. (i.e. ignore the contents of A0)
Upper 16 and lower 16 bits of address bus go through two transparent latches inside the ROM, effectively latching the address on a falling edge of ALE_H or ALE_L.
A rising edge of /RD or /WR automatically adds 2 (i.e 16-bit aligned) to the current address. There are 8 bits of this behavior. (i.e. A1 through A8)

This flashable board uses a pile of 74-series parts with an ordinary 3V flash ROM. It's good enough for any of the save-less games.

The N64 bootstrap expects to be able to read from the cart ROM starting at address 0x1000_0000. I think I remember reading that it reads a few bytes, setting properties of the Parallel Interface (the name for the cart/expansion port), then loads the first 4 KiB somewhere... and I think that in turn loads the first 1 MiB into RDRAM and the game "really" starts.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: N64 Cartridge Bus

Post by calima »

Tangentially related question that I was going to ask lidnariq eventually, sorry for the hijack.

There's three unused pins, the two audio pins and the video pin. I was wondering how hard would it be to hook those via the bottom to a rpi or similar, to get online play. I'm a software guy, I don't really know yet how things happen on the hw wires - would it have to bitbang on both sides, using way too much cpu?

I read that there are several protocols suitable for 3 wires or less, but even the good old serial uart bitbanging uses a lot of cpu.
User avatar
mikejmoffitt
Posts: 1353
Joined: Sun May 27, 2012 8:43 pm

Re: N64 Cartridge Bus

Post by mikejmoffitt »

calima wrote:Tangentially related question that I was going to ask lidnariq eventually, sorry for the hijack.

There's three unused pins, the two audio pins and the video pin. I was wondering how hard would it be to hook those via the bottom to a rpi or similar, to get online play. I'm a software guy, I don't really know yet how things happen on the hw wires - would it have to bitbang on both sides, using way too much cpu?

I read that there are several protocols suitable for 3 wires or less, but even the good old serial uart bitbanging uses a lot of cpu.
Nope. Even if the attached computer can capture game state, you'd need a way to verify that states match and adjust as necessary.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 Cartridge Bus

Post by lidnariq »

calima wrote:There's three unused pins, the two audio pins and the video pin.
There's actually a lot more than just three.

Of the 50 total pins, 20 are for the "Parallel Interface", 10 are for power supply, another 8 are for protecting against reverse insertion, 4 are for the CIC and "Serial Interface", two seem to be just completely unused, 3 are various CPU control signals (/NMI, /IRQ, /RST), and finally the three you mention.

Anyway, the "video" pin is only the composite sync signal, not the full video. And it's not connected on PAL units; only on NTSC units.
I was wondering how hard would it be to hook those via the bottom to a rpi or similar, to get online play.
Online play really requires the cooperation of the game, unfortunately. Especially in a console as complicated at the N64.

In contrast, in the case of NES, the total game state is small enough, simple enough, and that just brute-forcing it (and sending the entire 4K of RAM, plus coming up with some way to force the CPU-internal registers synchronized) is ... ridiculous, but plausible.

But ... if you're writing all-new homebrew, sure, there's something here. The N64's Serial Interface is identical between the controllers and the on-cartridge EEPROM. It's a comparatively slow interface—only 250kbit/sec—but there's already a linux kernel module to interface to the controllers ("gamecon_gpio_rpi"). I don't know how hard it would be to make the RPi emulate a SIO endpoint instead of host, but I bet it's doable.
would it have to bitbang on both sides, using way too much cpu?
Only for things for which there's no native support. The N64 natively has both the Parallel and Serial Interfaces; although the former would be very awkward to emulate, it would connect easily and conveniently to, say, the ENC624J600 ethernet IC. And the latter is slow enough that bitbanging it is mostly within scope.
I read that there are several protocols suitable for 3 wires or less, but even the good old serial uart bitbanging uses a lot of cpu.
Depends on what you're doing, of course. If you use something shaped like asynchronous serial, you can save a lot of CPU time either by using an extremely slow timebase (e.g. sending 5N1.5 at 45.45 baud won't really tax anything) or an extremely fast timebase (Because then you're done with each byte in so little time that you can probably get back to whatever else you were doing).

Similarly, bitbanging an I²C or SPI host is easy.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: N64 Cartridge Bus

Post by calima »

Thanks folks.
mikejmoffitt wrote:Nope. Even if the attached computer can capture game state, you'd need a way to verify that states match and adjust as necessary.
Of course only for new homebrew, not existing games.
There's actually a lot more than just three.
Those were the only ones that no cart uses AFAIK. The other pins would also go to the cart, needing the cart's cooperation to use, no? I'd like the unit to be compatible with all cartridges, not requiring its removal when playing any game.

BTW, do you happen to know how much current is safe to pull via the 12v or 3.3v lines?

Certainly, using one of the controller ports would also work, if it would produce a faster line with lower cpu use.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 Cartridge Bus

Post by lidnariq »

calima wrote:Those were the only ones that no cart uses AFAIK. The other pins would also go to the cart, needing the cart's cooperation to use, no? I'd like the unit to be compatible with all cartridges, not requiring its removal when playing any game.
Well, other devices could be put on the Serial Interface via the expansion port. The protocol is a little janky, but does seem to support multiple endpoints per host. (See: the NUS-07A PCB, exclusively used for Animal CrossingDoubutsu no Mori, which connects both an EEPROM and an RTC to the Serial Interface)

But then, if you're going to just use the Serial Interface, you really may as well just use the controller ports instead. Sure, it limits you to a three-player game (or else building a special Y cable), but that's probably ok.

I think a much more practical option is to not aim for an expansion port thing. If your device is the only one attached (via the cartridge slot) you don't need to worry about what you'd conflict with.
BTW, do you happen to know how much current is safe to pull via the 12v or 3.3v lines?
The 12V supply seems to be barely used—just used by ENC-NUS (video standard encoding), AMP-NUS (audio), made available to the cartridge and RF modulator—so you probably have the vast majority of the 0.8A that the power supply specifies is available. I assume most of the spare ampacity was intended for the 64DD.

On the other hand, I have no guess as to how much headroom is available for the 3.3V supply.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: N64 Cartridge Bus

Post by calima »

So a controller port thing that takes power via the expansion port, or optionally via other means when using the Pikachu edition. This clarified things nicely, thanks.
Post Reply