The keyboard is attached via SPI, clocked at 8MHz. Pi Pico is SPI slave. Unlike most emulators that connect a PS/2 or USB keyboard, the keyboard matrix is scanned by the actual software. So each OUT to the column select port is sent over to the keyboard, and each IN from the rows port is then channeled back. There are exceptions for the keys that are off-matrix, those are scanned once per frame because some programs poll them frequently and SPI transactions are slow.

Some takeaway points from this stage:

• implementing an SPI slave sux
• RP2040 SPI can transfer more than one byte without raising CS line only in mode 3
• to send a command and get a response in the same transaction, you need at least 3 bytes
• ESP32 SPI peripheral is abstracted af, I still have no idea how to just send a bloody byte without making a fuss about it
• The minimum wait time for transaction to complete in spi_device_polling_end() and spi_device_polling_transmit() is 1 FreeRTOS tick, which is insane when you're running a tight loop at the beam speed.
• RP2040 SPI in contrary is easy to track down to the registers, but the standard driver and the peripheral hardware seems to be janky af

Please correct me if I'm mistaken in any of the above points, or point to solutions. I'm particularly interested in lower-level, more barebone access to ESP32-S3 SPI peripheral. For example, I can't properly output LED status in due time without hiccupping the main loop because it must wait for a whole FreeRTOS tick. It's not a problem in 100%-o(n) cases because nobody uses keyboard LED for anything useful, but I know that it's not right and it bothers me.

Things that need to be done for this thing to be a useful Vector-06c:

• 512 pixel mode
• Beeper support and better 8253 sound
• SD card support
• A case

Not many games use 512 pixel mode. It is essential for everything MicroDOS or CP/M. It's not the most amazing stuff v06c-wise, but it's sometimes also the most advanced stuff. The problem with it is that it 1) adds a conditional to the very very tight loop of the pixel filler and 2) can't use the same pixel-filling trick that I'm using for the regular 256-pixel mode. In other words, I'm not sure if it's possible to do at all.

8253 support is currently limited, beeper is not supported at all. I need to implement them differently, taking notes from the AY implementation from ZX-ESPectrum project.

SD card support is just dead boring because it also means some UI to be usable and that's some completely separate project that I don't really find entertaining.

A case... I have some cardboard boxes.