A little less clever, I think? The keyboard's data line itself can pull /IRQ low ... and extra hardware appears to keep it low until the keyboard has clocked something in 9 times (i.e. ignoring the parity bit). So /IRQ appears to be asserted for the entire transmission. At 11 bits and 30-50µs per bit, each keyboard transmission will take 330-550µs, or roughly 600-1000 CPU cycles. The hardware assist does deserialize the bits—reads from (mask $F001) $5001 and $5000 return the most recent 4 bits clocked in or the 4 bits before that, respectively.rainwarrior wrote:Ah, so Krzysiobal's cartridge triggers an IRQ each time a byte is finished buffering.
Yeah? Might be able to just connect Kbd Clock to /IRQ ... I don't think the lack of acknowledgement will be a major flaw?More minimally, the buffer could be done in software? If we just trigger an IRQ on each falling edge of the clock and let the CPU read the data line directly.
NMI, other IRQs, and OAMDMA will interfere with keyboard receipt, but that's basically guaranteed of any solution that doesn't buffer the entire stream.
Really depends on whether you consider that an acceptable cost, of course.Requires the expansion port or cartridge access for the IRQ, but maybe not as bad as polling the clock, and relatively few parts?
I'll note that in the NES expansion port, 11 of the 15 signals of the Famicom expansion port (including /IRQ; notably NOT including OUT0,1,or 2) are on the same side as the Audio In pin. Seems like it would be practical to extend INL's audio mixing board.