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.

  • 3
    Note that the question has a specific criterion -- that a scancode is transmitted on the parallel interface, rather than scan rows and columns -- which may disqualify most examples of keyboards with parallel interfaces. – DrSheldon Jul 16 '20 at 4:24
  • 3
    Why are you requiring the interface to be "clockless"? The keyboard controller still needs to scan a matrix, so there'll be a clock in the keyboard anyway. Requiring scancodes and key up/down information (rather than just "key pressed") further limits the range. Many early machines, including the original Apple II, had ASCII keyboards, which gave you the 7 bit parallel ASCII code of keys pressed. – Michael Graf Jul 16 '20 at 6:04
  • 4
    @alephzero The C-128D keyboard did effectively use a 25-pin parallel printer cable. And yes, it was quite unwieldy. The keyboard itself didn't contain any logic, the cable had separate connections for each row and column, the scanning was done by the computer itself. – Michael Graf Jul 16 '20 at 6:15
  • 2
    There's quite a few homecomputers that used this approach for an internal keyboard, either with a "scancode" or even exposing rows and columns of the keyboard matrix. For an external keyboard, the issue is the number of wires needed. – dirkt Jul 16 '20 at 10:47
  • 1
    I would argue that the ASR-33 TTY had a "parallel" interface between keyboard and printer. – Hot Licks Jul 16 '20 at 11:55

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.

  • 6
    This answer certainly is an example of a parallel port keyboard. However, the question specifically asks for a scancode (rather than the rows and columns of a matrix) transmitted on the parallel lines. This answer does not meet that specific criterion in the question. (Although I am skeptical that there was any system which met that criterion.) – DrSheldon Jul 16 '20 at 4:19
  • 6
    @DrSheldon I've updated my question to make it clear that the idea of using scancodes was only an example. – Dai Jul 16 '20 at 5:13
  • 3
    @Dai: The Apple II keyboard should meet that criterion. The keyboard yields ASCII, but that's because the key matrix is laid out in ASCII order. – supercat Jul 16 '20 at 19:54

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. enter image description here

  • 1
    Do you have a pinout for the connector? 23 lines for the matrix? That makes no sense. Theoretically could be as few as 7 (for up to 128 keys). Practically, 3 for row (up to 8 rows, and there are only 6 rows including the lone spacebar) and 5 for column (up to 32 columns, far more than this keyboard) = 8 pins. So 23 is either an incredibly inefficient layout or includes other stuff - alternating ground pins? feedback of some sort? – manassehkatz-Moving 2 Codidact Jul 16 '20 at 14:06
  • 14
    @manassehkatz-Moving2Codidact There's no logic in the keyboard, not even an encoder / decoder :-). It's an 8x11 matrix (= 19 pins), plus three extra pins for the locking 40/80 and caps lock keys and restore (giving 22 pins), plus GND, plus 2x N/C. That's it. – Michael Graf Jul 16 '20 at 14:51
  • 1
    Very similar to the Wang minicomputer technology. Judging by the picture, Commodore was able to achieve a thinner and presumably more flexible cable than Wang Labs did. – A. I. Breveleri Jul 16 '20 at 15:01
  • 4
    @manassehkatz-Moving2Codidact There's a pin-out at oldcomputer.info/8bit/c128/51.gif – Chris J Jul 16 '20 at 18:51
  • Looks similar to the 23-pin D-connector they used in the SX-64 – scruss Jul 17 '20 at 1:08

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.

  • I wonder if there were any keyboard designs that sought to minimize the number of wires without externally decoding keys, e.g. by having a scanning counter which would run until it either found a key was pushed or it reached the end of count, but which could be nudged to restart it until the next keypress or end of count. Such a design could be fairly easily accommodated using 3-4 chips on the keyboard side, and a counter with 3-state outputs and a controllable open-collector output on the host side. Host would read the counter until it is stopped, then strobe and release its output... – supercat Jul 17 '20 at 16:52
  • ...and then watch to see where the counter stops next. If two consecutive stops are separated by 64 or 128 (depending upon counter length), no keys are pushed, and the host's counter will report the no-keys value (eliminating the need to hardware-synchronize the counters). – supercat Jul 17 '20 at 16:54

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.


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

  • Teletype series 30 keyboards had a coded lever on each key which, when depressed, activated or deactivated codebars for the 7 ASCII bits (8 if parity); the positions of those codebars were then serialized by a motor+clutch-driven distributor. Those keyboards did interlock so you couldn't depress two keys at once (except special cases like SHIFT) but were not locked by the 'remote' system (although on ASR models the tape reader could be stopped and started from remote). – dave_thompson_085 Aug 17 '20 at 9:02

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.


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.

  • Did the company actually design or sell such a keyboard, or was the end user supposed to come up with it themselves? – DrSheldon Jul 18 '20 at 14:11
  • @DrSheldon, as I said, It was a kit so there was no standard keyboard, but there were a number of existing commercial off the shelf keyboards that could be used with minimal modification. – hildred Jul 18 '20 at 22:54

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.