Note that you posted while I was composing this reply; I'm using my phone, and have been typing and editing for over an hour, it feels like...but I have learned, especially when composing a lengthy reply on my phone, to refresh the thread in another tab, so I have seen your updated pseudocode, and have trimmed my reply down somewhat since you did address the timing constraint that makes the protocol not as simple as it first appears. I'm still going to go ahead and elaborate just a bit, since I overgeneralized about back-to-back lows and edge transitions.
The protocol diagram seems to indicate that the protocol would be exactly as simple as the schematic suggests, no more or less.
Well, the "NOT quite as simple" remark I made was about a not quite obvious constraint on the presence and timing of rising edges in the data line's stream. Any time level-sensitive and edge-triggered inputs are mixed on one signal the logic can become non-obvious, and here we have two such signals, the data and the clock for the keyboard.
The clocking is rising edge for both U6 and U17; you need to make sure your data line (which rising-edge
clocks U17) doesn't have a rising edge while the keyboard clock (level-sensitive
data input to U17) is low
anywhere in the bitstream other than the stop bit, and so the protocol diagram shows a controlled rising edge after each low level on the data line for every time clock is high.
Failing to account for the restriction on the timing of any rising edges in the data line could cause a false trigger of U17 and thus the IRQ. Edit: this wording is clumsy; there was more here before some edits. "Trigger" here should be read as "latching the state of a low clock to the output driving BUSY and KBIRQ."
Now, if you can constrain all rising edges on the data line to happen during a high level on clock you might be able to do it without the "return to high during high clock, if data is low" dance; regardless, this is a non-obvious timing restriction that does warrant a non-cursory look at the schematic and at the spec sheets for both U6 and U17 to prevent spurious IRQs and corrupted keystroke data.
The project you mention looks really neat, if you want a vintage look and feel. I've been following your progress for quite a while now, and I'm pretty confident you could make this relatively simple serial protocol work.
The converter I mentioned is to be able to use any standard (yes, and boring) USB PC keyboard; I have a couple older PS/2 Model M's I plan to use with a PS/2 to USB converter with one. I honestly don't want to duplicate the Model II layout; there are keys in the "wrong" places relative to what my touch-typing fingers are used to! Edit: when I'm using a real keyboard; I don't think I'll ever get used to typing on a phone-y touch screen.....
But I can see the appeal of your project, for sure.