How was the clock frequency of the PS/2 keyboard protocol chosen?

Question

The PS/2 keyboard protocol allows the keyboard to generate a clock rate between 10 kHz and 16.7 kHz.

At 11 bits per scancode, 10 kHz is a massive 909 scancodes per second. World-record holder Barbara Blackburn peaked at 216 wpm ≈ 18 cps ≈ 54 scancodes/sec. on a Dvorak keyboard layout. Even with punctuation and modifier keys, there's still a ton of budget available.

Did IBM provide any reasoning for the chosen frequency?

---

References checked

I skimmed through the PC AT Technical Reference (1984), but had no luck. Checked the PS2 Hardware Interface Technical Reference (1991), and found this nice timing diagram on p230 mentioning "30–50 µs" clock timing parameters - a period that matches exactly the frequency range of 10kHz–16.66 kHz. I see no mention of why, though.

Answer 1

Why is the clock frequency of the PS/2 keyboard protocol so high?

I wouldn't call it high. It's quite in line with similar keyboard speeds - like Amiga operating a 17 kHz.

At 11 bits per scancode, 10 kHz is a massive 909 scancodes per second. World-record holder Barbara Blackburn peaked at 216 wpm ≈ 18 cps ≈ 54 scancodes/sec. on a Dvorak keyboard layout. Even with punctuation and modifier keys, there's still a ton of budget available.

While typing speed - and more important delay time (aka keyboard lag) - defines a lower boundary for a useful keyboard interface, it provides no argument for an upper limit. To keep latency low, the highest reliable speed is to be preferred.

But there are several issues with the number used. For one, actual English language records, using computer keyboards, are past 300 word/min or 25 char/s, which would mean 75 scancodes/s using above equation. That's already past a one per frame as many early computers did scan and past what can be done on a genuine IBM PC.

More important, the whole argument is at error, as average typing speed is exactly that, average. Levelled out over several minutes. Certain combination can be way closer to each other. Think of combinations like 'er' wich are more like a single move.

So a keyboard able to handle fast writers should go well past these number. At least double it, meaning 150 scancodes/s would make a good lower end for transmission speed. With an 11 bit word that's a 1,650 bit/s ... of course any controller will need some time to feed it, so selecting a value 2-3 times of that is applicable. It's obvious that we already get close to the 10 kBit IBM defined as lower limit.

On the PC the speed is defined by what the 8048 controller within the Keyboard can deliver, as the receiving side was a 74LS322 shift register, good for some Mbit instead :))

On the AT it was what the microcontroller in the keyboard and mainboard could do without any issue - that's BTW why there is such a wide range of 10..16 kHz, as it allows them to operate at less reliable clock sources as well.

Having recently bit-banged the PS/2 protocol on a 1MHz 6502, I feel like it sure would have been easier on keyboard port implementers if IBM had decided on a lower frequency, so we could have had some time to decode the protocol inside my interrupt handler, instead of offloading it to a circular buffer.

Why should IBM have cared about any implementation different from their own?

Did IBM provide any reasoning for the chosen frequency?

It's an obvious choice, and AFAICT artificial slowed down. In a setup with a HW shift register and a microcontroller (IBM-PC) or two microcontrollers (PC-AT), 16 kHz is a quite low rate, kept in a range of easy detection and leaving lots of room for slow controllers.

Answer 2

The user will perceive a delay (latency) between pressing a key and seeing the computer react.

The reactions are usually on its screen, such as displaying a typed character or motion in a game. This delay must be kept short for the user to have a feeling of sharpness in the computer's reactions.

The delay is the sum of:

• (a) the keyboard scanning interval and debounce period
• (b) the data transmission time
• (c) the computer software processing time

The keyboard scanning interval was originally 3 ms in these PS/2 keyboards. At least two scans are necessary to detect a key and debounce it, so (a) is at least 6 ms. (The PS/2 keyboard may use 3 or more scans before sending a key make/break code, it's been a long time since I read the keyboard microcontroller software disassembly.)

The keyboard clock frequency and 11-bit packet length puts (b) in the order of 1 ms.

The computer reaction time (c) depends on the application and is the variable sum of many elements. For example, if the display is scanned at 60 Hz, there could be up to 16 ms between the CPU attempting to display something and it appearing on the screen. But with games using schemes like double and triple buffering, (c) becomes a subject in itself.

So it is necessary to use a reasonably high keyboard clock to keep the overall latency down and produce a sharp response to keypresses and activity.

Answer 3

Until communications frequencies get fast enough to cause difficulties, communicating at higher speeds is no more difficult than at lower speeds. It sometimes makes sense to use a speed somewhat slower than the speed one expects to be able to handle easily and reliably, in case things don't work quite as nicely as planned, but the AT protocol used in the PS/2 is nowhere near the upper limits of what such protocols could use.

A more interesting design issue comparing the AT keyboard signaling versus the XT is that the former requires that an attached device be ready for data to arrive at any arbitrary time, whereas if memory serves the latter lets the computer decide when it wants each bit of data.

Answer 4

The PS/2 keyboard protocol allows the keyboard to generate a clock rate between 10 kHz and 16.7 kHz.

As far as synchronous communications go, this is not fast at all. Even the most rudimentary serial-to-parallel converter solutions could cope with MHz clock rates, and if you wanted a PS/2 interface that could deal with 1MHz clock rate, it'd need an internal FIFO but there was support for all that in the TTL databook, so not a big deal. A 16kHz clock rate is extremely slow, I'd say, at least from the point of the digital logic at the time.

Answer 5

Typematic Rate

Entering text is not the sole purpose of a keyboard. Anyone who played games would recognize the desire to be able to hold down a key for continuous, fine-grained inputs during gameplay. Even someone with a text editor would want to navigate the editor quickly with arrow keys. Being gated by the speed of the average typist would be an unnecessary and frustrating limitation.