Alright, my approach is THIS! *slams evidence on table, dramatic music plays* • Amiga lowers 6 FIRE1OUT/CLOCKIN ready for clock pulse. • Amiga lowers 5 JOYMODE, singalling start of shift frame. • Triggers INT1: • • Disable Timer2 periodic directional button update. • • 6 FIRE1OUT/CLOCKIN is High-Z for input. • • Enable SPI2 module - owns 5 JOYMODE as SPI2 !SS, 6 FIRE1OUT/CLOCKIN as SPI2 CLK and 9 FIRE2OUT/DATAOUT as SPI2 SDO. • • Push CD32 reply word into SPI2BUF. • With SPI2 !SS lowered already, bit 1 of CD32 reply word is presented on 9 FIRE2OUT/DATAOUT, correct first output bit is present before 1st clock pulse takes place. • Up to 15 clock pulses may be received from the Amiga, transmitting contents of CD32 reply word from MSB to LSB. There's no reason why the Amiga would clock further than this, the data is meaningless, unless you're using software which expects something other than a CD32 pad to be present, in which case why are you using it with a PSCD32? • SPI2 updates 9 FIRE2OUT/DATAOUT on rising edges, Amiga samples shortly after falling edges. • Finally, Amiga raises 5 JOYMODE to return to dumb joystick mode. • Triggers INT2: • • Disable SPI2 module - 5 JOYMODE, 6 FIRE1OUT/CLOCKIN and 9 FIRE2OUT/DATAOUT are GPIO; in-progress transmission is aborted. • • 6 FIRE1OUT/CLOCKIN is OUTPUT. • • Enable Timer2 periodic directional button update. To be truthful, I'm not 1,000% confident that this ought to work. Looking at the CKE = 1 timing diagram, it strictly seems to be the case that the SPI frame is begun by the falling edge of !SS. However, in reality, either the activation of the SPI module causes various internal buses to fall in the correct way to be read as a falling edge, or the module is designed to allow this behaviour. One nice effect of this is I don't have to manually mess about with some of the tristate and output settings since when the SPI module is activated by the frame-response interrupt, it takes control of the pins and overrides their output until the SPI module is disabled. I've specified the SPI2 interrupts to be higher priority than any others I'm using, since it is imperative that the CD32's request be satisfied instantly. This means it can interrupt the PS2 communication sequence, but since the PIC is the master of that communication, the PS2 pad will just be made to wait for the communication to complete when the PIC is able to do so. Since the PS2 pad byte exchange is done in hardware, the clocked data exchange won't be affected by anything on the CD32 side - a whole byte will still be sent at a steady speed, but the PIC won't send the next byte of the message until the CD32 interrupt handler has completed.

And there we have it. Success. When Amiga Test Kit is on Joystick mode, it holds 6 FIRE1OUT, 9 FIRE2OUT and 5 high weakly (not too weakly, as I've described!) to be pulled low by the first, second and third joystick buttons respectively, if present. The PSCD32 implements CD32 pad behaviour, which maps Red and Blue to the first and second fire buttons respectively. It doesn't provide any way of pulling its own 5 JOYMODE down as a third fire button, since this would cause it to become a seven-button controller inadvertently. When Amiga Test Kit is on Gamepad mode, it performs the polling sequence I described earlier, using 5 JOYMODE to signal a polling frame and retrieving 10 bits of digital input from the shift register it expects to be interfaced with. Amiga Test Kit detects a CD32 pad by shifting in the seven button inputs, followed by three more test bits. Since the CD32 hardware shift circuit is designed to terminate the shift sequence with a high and recurring lows, if the final three bits it receives are 1, 0, 0, then it concludes that a valid pad has been inserted. These bits are shown on screen as the very small boxes in the lower left of the Gamepad display. All eleven digital inputs on the pad, Up, Down, Left, Right, Red, Blue, Green, Yellow, FF, Rew and Pause, are being reported correctly, and independently. It was very frustrating getting almost this far and seeing the X button cause all of the Gamepad display to light up as if the PSCD32 were incorrectly sending the X button state for all the button slots. But with the SPI module reacting in time to the initial framing and each of the clock pulses, everything is very dandy. Now I have to test it with some games! Tomorrow! Zzzzzz....