I didn't make a schematic when I built it, but this could be a good excuse to go play with KiCad; if so I'll come back here and post the result.

In the mean time, here's a picture of the circuit:

Thanks!

_________________
BB816 Computer YouTube series

Here's a schematic for the bidirectional PS/2 keyboard. I created this from a working circuit, but if anything looks off, I would appreciate feedback:

When not initiating a send of data to the keyboard, KBD_CLK_OUT should be high, to avoid interfering with receiving data from the keyboard.

To receive data from the keyboard:

1. IRQ will transition from low to high when a byte has been received from the keyboard
2. In the interrupt handler, set !REG_OE low
3. Read D[0..7] and DP and check for correct parity
4. set !REG_OE high

To initiate a send of data to the keyboard:

1. !REG_OE should be high so that the shift registers which receive data from the keyboard are not outputting data
2. Set DE high (to leave data line high when clock is pulled low)
3. Set KBD_CLK_OUT low (pull clock low and enable async load of the output shift registers)
4. Wait for at least 100 microseconds (per the PS/2 specs)
5. Set D[0..7] and DP to the byte to be sent to the keyboard plus parity
6. Set DE low (when clock goes high with the data line low, keyboard will begin toggling the clock to receive data)
7. Set KBD_CLK_OUT high (output data latched; signal to keyboard to begin receiving data)

Caveats:

• An interrupt will be generated after the send has been completed. The interrupt handler will need to distinguish between a completed send and a completed receive, e.g. via a flag that's set when initiating a send.
• There's a narrow window where you're not supposed to pull the clock low if the receive of a byte is almost complete, or a byte from the keyboard could be lost. I wrote code that tracks when a receive is in progress and waits for the receive to complete before initiating a send. This involved switching back and forth between IRQ triggering an interrupt on high to low vs. low to high transitions, but in reality even without this extra logic I think it would be rare to experience problems.
• I've not bothered trying to check the presence of the 'ACK' bit sent by the keyboard immediately following receipt of the stop bit.

That is fascinating, thanks for sharing it in detail

_________________
BB816 Computer YouTube series

Fascinating indeed - and, as I notice you are newly signed up, welcome, pjdennis!

Thanks for the welcome, BigEd. I joined recently but have been lurking for a while before that; I should probably post an intro soon.

sburrow has a highly curious approach to character set encoding which I don't recommend:

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

I have an idea for an ABI which solves many of the character encoding problems while being sufficiently portable for output via LCD, CRT and UART. RegA contains one byte to send. RegX specifies how to handle the data in RegA. Specifically:

• RegX = 0: Set output channel.
• RegX = 2: Set tab spacing.
• RegX = 4: Set cursor X co-ordinate to value in RegA. May be ignored.
• RegX = 6: Set cursor Y co-ordinate to value in RegA. May be ignored.
• RegX = 8: Clear display. May be ignored.
• RegX = 10: Output raw character and increment cursor X co-ordinate.
• RegX = 12: Output raw ROT13 character and increment cursor X co-ordinate.
• RegX = 14: Output baked ASCII character where tab, new-line and carriage return work as expected.
• RegX = 16: Output akohlbecker's preferred encoding where $00-$1F are accented characters.
• RegX = 18: Output Sheep64's preferred encoding where $80-$BF is Greek and $C0-$FF is Cyrillic.
• RegX = 20: Output sburrow's preferred encoding of PS/2 key-codes.

The trick is that RegA is a fully populated 8 bit encoding and RegA/RegX is a partially populated 16 bit encoding. This satisfies everyone who wants a 256 characters for display because it resolves conflicting use of the same code-points. Furthermore, it can be easily implemented with two invocations of JMP (abs,X). Each branch may LDX zp to load channel number and perform a second JMP (abs,X). From here, for each output channel, a best effort can be made to output the appropriate symbol. To output strings, this ABI may be called within a loop. For conciseness, you might want to store strings backwards so that a loop may terminate with BEQ. This leads to an old joke:

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!