It's been far too long since I've started a challenging but useless programming project, and longer still since I've finished one.
The idea is simple: using the 84+'s Link port (the 2.5mm barrel jack), communicate with a Gamecube or Wii using the Nintendo Gamecube Controller Protocol. The protocol is bespoke, but incredibly simple, especially compared to trying to manually implement more functional serial standards by bit-banging like USB.
For the purposes of this program, the protocol is as simple as listening for a 24-bit command over the single data line (clock speed ~250kHz) and responding with a 64-bit response: 12 1-bit values for digital buttons, six 8-bit analog axes, and some unused filler bits. For my purposes (playing SSBM) polls can be expected to occur around a 125Hz rate, though ideally the calculator should be able to handle polling rates up to 1000Hz. The protocol does not require a consistent polling rate. If we assume a consistent 125Hz polling rate, some quick math tells us that:
The 84+ Link port and the GCC port are both designed to work with a bi-directional data line, pull up to ~3.3V, so this should be in the realm of possibility with some simple cable splicing. From what I've read, I don't think there's much history of successful attempts to bit-bang a digital communication protocol from the 84+ Link port. If such a project does exist already, please let me know!
The biggest problem may end up being signal timing. I'm told that the Gamecube is very picky about the timing of the response, though to what extent I am not yet sure. z80 out and in instructions take 11 or 12 cycles, meaning that reads can only occur at most 5x the clock of the incoming signal (1.25MHz vs 250kHz). Though I've never done it before, I imagine that returning a bitstream at a lockstep 250kHz should be possible by telling the processor to wait for exact numbers of cycles calculated by regularly measuring the current frequency of the processor. This is because each 4us bit expected by the console is divided into four 1us sections, which is therefore the minimum speed at which the link port must be able to flip a bit twice. The link port is theoretically capable of flipping a bit twice in 800ns at a clock of exactly 15MHz, which should leave room enough even for a very slow processor.
It's been a very long time since I've written raw assembly like this, and I've definitely never written anything with such tight timing requirements. We'll see how it goes.
The idea is simple: using the 84+'s Link port (the 2.5mm barrel jack), communicate with a Gamecube or Wii using the Nintendo Gamecube Controller Protocol. The protocol is bespoke, but incredibly simple, especially compared to trying to manually implement more functional serial standards by bit-banging like USB.
For the purposes of this program, the protocol is as simple as listening for a 24-bit command over the single data line (clock speed ~250kHz) and responding with a 64-bit response: 12 1-bit values for digital buttons, six 8-bit analog axes, and some unused filler bits. For my purposes (playing SSBM) polls can be expected to occur around a 125Hz rate, though ideally the calculator should be able to handle polling rates up to 1000Hz. The protocol does not require a consistent polling rate. If we assume a consistent 125Hz polling rate, some quick math tells us that:
- There will be a poll every 8ms
The poll command will take 96us and the response will take 256us, meaning the total conversation will take 352us.
This leaves ~7.6ms to poll for keypresses, do any additional math or calculations that need to be done such as constructing values for the analog stick to assume, and updating the buffer containing the list of bits to be sent.
This drops to 648us at a 1000Hz polling rate.
The 84+ Link port and the GCC port are both designed to work with a bi-directional data line, pull up to ~3.3V, so this should be in the realm of possibility with some simple cable splicing. From what I've read, I don't think there's much history of successful attempts to bit-bang a digital communication protocol from the 84+ Link port. If such a project does exist already, please let me know!
The biggest problem may end up being signal timing. I'm told that the Gamecube is very picky about the timing of the response, though to what extent I am not yet sure. z80 out and in instructions take 11 or 12 cycles, meaning that reads can only occur at most 5x the clock of the incoming signal (1.25MHz vs 250kHz). Though I've never done it before, I imagine that returning a bitstream at a lockstep 250kHz should be possible by telling the processor to wait for exact numbers of cycles calculated by regularly measuring the current frequency of the processor. This is because each 4us bit expected by the console is divided into four 1us sections, which is therefore the minimum speed at which the link port must be able to flip a bit twice. The link port is theoretically capable of flipping a bit twice in 800ns at a clock of exactly 15MHz, which should leave room enough even for a very slow processor.
It's been a very long time since I've written raw assembly like this, and I've definitely never written anything with such tight timing requirements. We'll see how it goes.
