N64 Cartridge Bus
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
N64 Cartridge Bus
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.
Re: N64 Cartridge Bus
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.
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.
Re: N64 Cartridge Bus
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.
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.
- mikejmoffitt
- Posts: 1353
- Joined: Sun May 27, 2012 8:43 pm
Re: N64 Cartridge Bus
Nope. Even if the attached computer can capture game state, you'd need a way to verify that states match and adjust as necessary.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.
Re: N64 Cartridge Bus
There's actually a lot more than just three.calima wrote:There's three unused pins, the two audio pins and the video pin.
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.
Online play really requires the cooperation of the game, unfortunately. Especially in a console as complicated at the N64.I was wondering how hard would it be to hook those via the bottom to a rpi or similar, to get online play.
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.
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.would it have to bitbang on both sides, using way too much 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).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.
Similarly, bitbanging an I²C or SPI host is easy.
Re: N64 Cartridge Bus
Thanks folks.
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.
Of course only for new homebrew, not existing games.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.
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.There's actually a lot more than just three.
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.
Re: N64 Cartridge Bus
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 forcalima 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.
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.
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.BTW, do you happen to know how much current is safe to pull via the 12v or 3.3v lines?
On the other hand, I have no guess as to how much headroom is available for the 3.3V supply.
Re: N64 Cartridge Bus
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.