Were there any parallel port keyboards?

Question

I was reading this QA ( Why is the clock frequency of the PS/2 keyboard protocol so high? ) and read in the replies that a high frequency was chosen (at least in-part) to reduce the latency between a keypress and the computer receiving the event.

I wondered what if a keyboard interface was designed using a clock-less parallel port interface to the computer (by "parallel port", I mean any cable or connection using parallel data lines, not just a PC parallel printer port).

For example, one using 8 data conductors to represent a 7-bit scan code and a 1-bit Pressed/Not-pressed state bit. Each change in the data lines would be triggered immediately on any change in physical keyboard state. This could hypothetically be done entirely with analog circuity, so no need for clock signal or polling. This means it would also support unlimited N-key rollover.

The host-device would be responsible for tracking keypress state, but it would only need 127 hardware bits. It would raise the CPU/OS keyboard interrupt when a keyboard state-change was sensed on the port's lines.

(This approach wouldn't preclude port multiplexing either. Just add additional bits to represent a device-ID).

I did a quick-search online for "parallel port keyboard" and "scsi port keyboard" but I didn't find anything relevant.

---

Somewhat related: my primary-school in the UK had BBC Micros and some of them had concept-keyboards attached to them (probably this exact model, actually). I remember it having a blue casing and a ribbon cable attaching it to the computer. So I suppose that's one example but it's not a "true" keyboard.

AFAIK, while the "user port" was a parallel port, it did require polling by software instead of being capable of raising hardware keyboard interrupts.

Answer 1

Early Wang basic computers used a backplane keyboard with an enormous bespoke parallel interface to the detached style keyboard device.

Wang's 2200 and 2600 BASIC-only minicomputers were available with the 2215 BASIC keyword KBD, the 2222 alphanumeric typewriter KBD, and the 2223 upper/lower case BASIC keyword KBD. None of these keyboards contained a key scanner in the peripheral itself -- Wang Labs found the scanner too bulky to slip under the keys -- so the scanner was in the peripheral controller that plugged into the backplane. The keyboard peripheral contained only the keys connected via diodes to a scannable matrix.

The matrix rows and columns, plus a few switches and lights and some signal housekeeping, were connected to the controller with a bundle of wires. That's right, a parallel connection to each row and column of keys. The wires, about 30 of them, were bundled into a kind of 3/8" gray plastic hose with robust strain reliefs at both ends.

This had the effect you would expect. You couldn't move the keyboard around without knocking things off your desk. Sometimes the keyboard would creep about under the influence of the stiff cable. I think the thing had weights in it to hold it down.

Answer 2

Of the variants produced in a relatively large series - let me remind you about the keyboard connection on the Commodore 128D - it was connected using a 25-pin interface, 23 lines of which directly represented the matrix of keys.

Answer 3

Early micro/home computer used parallel keyboards. These were (usually) called 'ASCII' Keyboards. A good example is the Apple II, which implements a protocol almost exact like you imagined - sans interrupt that is. A key press was presented as 7 data bits with ASCII like encoding plus a flag at bit 7 indicating a key press, cleared whenever the port was read.

Like serial keyboards they need decoding 'intelligence' able to turn some input matrix into a keyboard word. The Apple II for example use used a MM5740 encoder originally designed for a TTY-like keyboard delivering a simple 7/8 bit plus strobe output. Others, like the Intel 8279 offered a direct microprocessor compatible interface with higher functions.

---

Direct scanned keyboards are often mistaken for being parallel. But they are not. They are simply a matrix. Many home computers tried to save cost of a keyboard controller/decoder by using some parallel port to 'manually' decode a keyboard matrix. A good example is Commodore's PET series, all the way to the C128.

---

In general a serial interfaces did prevail as they need way less wires in your cable (if detached) and less port bits on the host side - similar leaving more port bits on the keyboard controller side. A great pre micro example are DEC terminal keyboards (copied by the Apple LISA keyboard). Many micros used the inherent advantages, IBM-PC, Amiga or Atari ST - the later used for example the 'freed' controller bits for the joystick interface.

Answer 4

For a keyboard that includes a shift key to be useful, either the CPU must poll it often enough to observe the state of the shift key whenever another key is pushed, or the keyboard must capture enough information without CPU intervention to know whether a keystroke represents a shifted or unshifted character.

In systems that use the former approach, there's not much benefit to having hardware report scan codes versus having the software directly perform row/column scanning. In systems that use the latter approach, but only try to capture one key event (e.g. the Apple II) using a key matrix which is arranged in ASCII order, and applying the effects of shift and control keys before latching a key stroke, is cheaper than separately latching the main key and the state of the modifier keys. On the PC and AT, a microcontroller in the keyboard includes enough internal buffering to ensure that changes to the modifier key states will be reported in sequence with respect to changes in any other keys' states, but using a microcontroller means a serial interface may be used as easily as a parallel one.

Answer 5

The LINC (Laboratory Instrument Computer), the first computer I programmed in 1965, had a one-key rollover. When a key was pressed on its Soroban Engineering keyboard, a solenoid locked that key down and all the other keys up, sending a signal to the computer. Whatever computer program was running could then take its time (sometimes a sizable fraction of a second) to get around to polling the keyboard using the KBD instruction. The 6-bit keycode would then be read (yes, in parallel) by the computer and the keyboard lock disabled by that instruction. This scheme, while not supporting touch typing, at least ensured that keystrokes were read without any possibility of error.

It didn't take as many keystrokes to write programs for the LINC, since program locations were encoded as a letter and numeric digit combination (giving 260 possible program labels for each program), and most instructions were three or five characters long.

If no program was running (the LINC could be in the HALTed state), pressing a key would simply lock the key down until you released it manually by pressing a reset button in back of the keyboard.

Later designs switched to the Teletype KSR 35 and 37 floor keyboard console models which, while far more complex mechanically, at least had no keyboard locking mechanism. They may have included serial to parallel conversion, as they contained a motor that scanned the keys to generate the keycode.

Source: https://en.wikipedia.org/wiki/LINC#Keyboard

Answer 6

Not exactly a parallel interface, but the TRS-80 (models 1, 3 and 4) had a memory mapped keyboard! 8 address lines were matrixed to 8 data lines by the keys (and some diodes). The keyboard scan routine would start by looking at 0x38FF and if it got back 0x00 then no keys were pressed. If non-zero it would check 0x3801, 0x3802, 0x3804, up to 0x3880 and check each result to figure out what keys were pressed. It did 2-key rollover and debounce in software. My favorite code used PEEK(14400) to check state of the 4 arrow keys, space, and enter (perfect for flying spaceships or what have you). 42 years later that address is still something I remember.

[edit] I just saw that "direct scanned" was covered above. Since I expanded slightly on how they work, I'll leave this here.

Answer 7

My first computer was a Big board by Fregusion. It ran CP/M and had a parallel keyboard as one of three console options (The others being a rs232 keyboard or a rs232 console). Since it was a kit It did not come with a keyboard (or power supply, crt, floppy drives, etc.) but expected ascii (or eight bit, one keyboard had a binary key which was wired to a 8x dip switch whet could send any value) and shift and control were handled by the keyboard. no key rollover was possible. If memory serves it was eight data lines plus strobe, but I haven't looked at it's schematics since the 90s. The main advantage of this is that the host required no processing for the keyboard beyond a port read.

Answer 8

The IBM 1130 used a keyboard mechanism from a keypunch. It constructed a 12 bit code for each key press mechanically, in parallel. The code was the sparse character code used on punched cards. The keyboard driver translated this to 8-bit EBCDIC.

When computers were built from discrete transistors (or even vacuum tubes), serial interfaces were rare unless the keyboard was a teletype machine. Serial->parallel conversion required hundreds of expensive transistors.