Spi

The way the PS/2 keyboard is handled has always been something we were never quite happy with. The key points being:

• The PS/2 controller had no way of signalling that there has been a new keystroke, the buffer had to be polled via SPI.
• The PS/2 controller had no way of talking to the keyboard and had to rely for the keyboard to initialize itself properly. Also, typematic rate and delay could not be set, as couldn’t the states of the keyboard LEDs.

Although mid- to long term, we likely might “upgrade” to USB anyway, but not without having done PS/2 right first. So, I will talk about integrating IRQ handling, and in a follow up post Marko will talk about how he got the PS/2 controller talking to the keyboard.

Frank van den Hoef, who is adapting the Steckschwein SPI & FAT32 code for his tiny65 machine made me aware of a classic mistake for a 6502 assembly coder to make. Namely in our sdcard driver, when waiting for the “proper” response from the card (which should have bit 7 cleared). The routine handling this looked like this:

1  sd_cmd_response_wait:
2 	ldy #sd_cmd_response_retries
3 @l:	dey
4         beq sd_block_cmd_timeout ; y already 0? then invalid response or timeout
5         jsr spi_r_byte
6         bit #80	; bit 7 clear
7         bne @l  ; no, next byte
8         cmp #$00 ; got cmd response, check if $00 to set z flag accordingly
9         rts
10 sd_block_cmd_timeout:
11        debug "sd_block_cmd_timeout"
12        lda #$1f ; make up error code distinct from possible sd card responses to mark timeout
13        rts

Classic. Obviously, line 6 should read: