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.
Quote:
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.
Quote:
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.
Quote:
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.