Finish keyboard driver

[thejpster]

Pull clock line low to belay keyboard output. Release during v-blank when we can process messages.

[thejpster]

Or, pull clock line low just during scan-line setup period (which is a very high priority interrupt). We should be OK to process signals during the scan-line rendering if we're quick about it.

Interrupt latency is 12 cycles in and 10 cycles out. Plus a bit-banded GPIO pin read, a global variable write (the bit) and a global variable read/increment/write (the bit index). That's about 30 cycles, or 7.5 screen pixels. At 10 kHz we have to do that every 100us, so at most once every 4 scan lines (26.4us). At 16.7 kHz that's once every 60 us, or every other scan line.

Actually that's a thought - can we just poll the keyboard in the horizontal blanking interval?

[thejpster]

Or, pull clock line low just during scan-line setup period (which is a very high priority interrupt). We should be OK to process signals during the scan-line rendering if we're quick about it.

Pulling clock low cancels any existing message, so this won't work. Plus V-blank isn't long enough - a 10 bit message at 10 kHz (minimum) is 1ms and the blanking interval is only ~790us. We need 38 clear scan-lines and the blanking interval is only 28 scan-lines.

• We could delete/shrink the borders to give up to 52 clear scan-lines (28 v-blank and up to 24 reclaimed border) at the bottom/top of the screen.
• We could add a PDIP AtTiny to buffer the PS/2 scan codes for us, which we can then read out over I2C: https://www.mouser.co.uk/ProductDetail/Microchip-Technology-Atmel/ATTINY24A-PU?qs=sGAEpiMZZMvqv2n3s2xjsXXO6c5bDp3yUAOhzhsMC9w%3d
• We could add a small ARM (harder to find 5V-tolerant and very hard to find in PDIP).
• We could add two 8-bit 74-series shift registers and an MCP23S17 I/O expander to read them in in parallel.
• We could cheat and increase the v-blank interval, reducing the frame rate from 60 Hz to 59 Hz. This would be a non-standard video resolution.

[thejpster]

Used an external chip.