I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO. I'd like to build a machine with straightforward I/O, that it, the design requirement: one should be able to use the computer by simply plugging a PS/2 keyboard, rather than hooking it to a RS232, USB-TTL stick or some exotic CRT terminal.

But how to incorporate a PS/2 keyboard input to my computer is unclear to me. According to my research, this problem has been solved by the following approaches.

  1. Shift Register. A simple shift register like 74HC595N should be able to translate the serial data from the keyboard to parallel, and it can be clocked by the keyboard, so it has no problem to follow the PS/2 protocol. But PS/2 is 8-bit data, 1-bit parity, not 7-bit data! Both the Z80 and the shift register can only handle 8-bit of data , so the parity bit is ignored (or requires additional parts), not elegant. I don't think parity is only for farmers, especially when bidirectional transmission is also needed for controlling Caps Locks, etc. So a parity bit is needed, also, we need to follow the timing, have some meaningful interrupts control - all of these requires extra parts, which makes it difficult to design and program (especially when routing it on a single-layer board).

  2. USART. Although PS/2 is not designed as a USART-compatible protocol, there are reports of success by simply running the USART at 12,000 bauds and connecting the DATA line to a USART interface, and handling the keymap decoding in software. It sounds convenient since the USART is general-purpose, may perform buffering, parity check, and interrupt generation. However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution.

    1. SPI. Obviously, putting the widely-used SPI interface in slave mode can allow the serial transmission to be clocked by the keyboard. But I think it's just another clever trick to exploit the functionality on a modern microcontroller than a standard solution. Historically, it seems a SPI controller is never used in this way.
  3. PIC, Atmel, or ARM microcontroller. It's the most common, easiest, flexible solution used in various retrocomputing projects. But to me, having a microcontroller with processing power comparable to (or greater than) the Z80 CPU defeats the spirit of a retrocomputing project. I don't have a problem of using one for inherently computational intensive tasks, such as Ethernet or Wi-Fi, but for a mere keyboard, seriously?

  4. 8042. In the original IBM PC/AT design, the underlying keyboard control sequence is managed by the 8042 connected to the Intel 8255 PIO. A 8042 is just a version of the MCS-48 (8048) microcontroller designed for interfacing peripheral devices, IBM must have written a customized firmware. It's difficult to find a 8048 today, nevertheless, MCS-51 (8051) is also a retro chip so this one can be used, too. But is there a reference implementation of the original 8042 firmware available under a free and open source license?

  5. I think there are also controllers specifically made to control inputs like PS/2 keyboards, but they typically integrates more functionalities, and I'm not aware of a chip from the late 80s. If there is one, I think I could just use that, provides it was a common design choice of that time.

Currently, I'm considering to interface the PS/2 keyboard by implementing the 8042 keyboard controller on a 8051 MCU if there's a free reference implementation available, if not, I think it should be okay for me to implement something simpler, too.

But I think programming for two separate chips makes my project more difficult, especially for the initial prototype. I must have missed something... I knew most keyboards from that era were parallel ones, not PS/2, but there must be some additional and possibly simpler methods to interface a PS/2 keyboard, are there? How was it being done historically?

  • 6
    This is very well-researched. Thanks for the question; I'll check back later to find out the answer. ☺
    – wizzwizz4
    Commented Mar 20, 2019 at 22:46
  • 2
    Send me your address and I provide you a dozen of 8741 chips.
    – Janka
    Commented Mar 21, 2019 at 7:42
  • 13
    Regarding your point 3 -- yes, seriously! By choosing to use a PS/2 keyboard, you've already got a CPU "comparable to the Z80" in the keyboard itself! If you want historical accuracy, find or make a parallel keyboard. Otherwise, bite the bullet and use a microcontroller to provide the interface -- as it was properly done on the original PS/2! Even the older PC/AT had a dedicated micro on the motherboard for the keyboard interface.
    – Dave Tweed
    Commented Mar 21, 2019 at 11:22
  • 1
    go4retro.com/products/ps2-encoder Commented Mar 21, 2019 at 20:29
  • 2
    @DaveTweed My objective here is NOT historical accuracy, I'm not trying to recreate any historical system. Rather, the goal is to construct the system in such a way that it only uses hardware available in the late 80s. Or, use historical methods to solve present problems, so... if there's Cortex-M3 in my keyboard, fine, as long as I'm not putting my own Cortex in. Use a microcontroller is fine, but a microcontroller after 1990 is not. Commented Mar 22, 2019 at 16:53

4 Answers 4


I'm attempting to build a Z80 homebrew computer to teach myself the basis of electronic design. I planned to start from something simple, like a ROM, some SRAM, a video chip and a Z80-PIO.

So there's a Z80-PIO? Isn't that already the solution to be used?

Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems. I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard interface?

A Z80 with a PIO can do everything (*1) a separate system can do. In this case it needs 4 port bits. Two for receiving data/clock from the keyboard/mouse, two to overwrite these to initiate an output sequence and control output data. Externally two drivers for the input signal, two resistors and two transistors, as shown, may be helpful.

External circuitry for PS/2

It may be helpful if the clock input pin can be set to interrupt the CPU so a response to a key press can be handled without polling, but it'll work as well by pulling clock low and only releasing it when ready to receive a byte (*2).

Everything after that is simply bit-banging the protocol. The CPU got 5 microseconds per bit to react, which can be done on a tight looped 4 MHz Z80. Of course it will need some fine tuning, but isn't that exactly the goal of your project?

On a sidenote:

USART. [...] However, PS/2 is clocked by the keyboard and its frequency lies at anywhere between 10.0–16.7 kHz, again, this method is NOT in compliance of the protocol at all, and could only work by chance, so it's more of a clever trick than a proper solution

Of course it is a proper solution - all that's needed is to clock the USART externally. Important here: the Z80 SIO is well fitted to do the required 8E1 data format. Neither a hack nor anything clever is needed - maybe except to detect the acknowledge bit on host to kbd transfers.

And further:

How was it being done historically?

This depends a lot on the machine we're talking about.

Parallel keyboards where somewhat common, when it came to ready made units to be added as component. These where either

  • hard encoded (diodes!) or
  • via a decoder circuit (think Apple II).

Serial was (in the beginning) even more common, usually when keyboards had to be complete OEM units just to be plugged in (DEC, Apple Lisa).

Home/custom build solutions for embedded keyboards operated by scanning a matrix from the main CPU

  • via some latches,
  • a PIO like port (PET),
  • some combinations of both (Tandy MC-10). Or worse:
  • By mapping the matrix as data into an address range (TRS-80 M1)

*1 - Well, next to that is, as separate controllers may be faster in some special cases - except, PS/2 is none of them.

*2 - Yes, very easy and a protocol conform way. Drawback here is that each poll will have to wait at least for 100 (better 200) microseconds after releasing the clock line to check if the keyboard wants to send at all. So not really cool.

  • 1
    "I mean, adding another whole computer system, even of greater performance than the main system, just for a keyboard interface?" - that's how PS/2 was used in the PC series, isn't it? Commented Feb 11, 2020 at 15:59
  • 1
    "Not to mention, that adding another micro controller for a job the main CPU can do as well is neither simple nor true to the spirit of early systems."Really? But Commodore literally did exactly that back in the day with their C64 Disk Drives. they were a separate computer so the main system didn't have to worry about the drive mechanism and file system. So I find it perfectly reasonable to use an MCU to handle unnecessarily time consuming tasks like decoding the PS2 Keyboard/Mouse protocol.
    – Proxy
    Commented Apr 29, 2021 at 7:00
  • @Proxy Beside that the PS2 protocol may be much, but it's not time consuming, comparing the decoding of a serial signal is a complete different task than low level handling a GCR drive (doing the file system is at that point just sugar coating) - in fact, Commodore left in the C64 the whole task of serial communication as well to the main CPU, didn't they? So no argument here.
    – Raffzahn
    Commented Apr 29, 2021 at 10:15
  • @Raffzahn sorry i got caught in the moment writing that. yes obviously handling a file system and serial reading and decoding are not very comparable. with "unnecessarily time consuming" i didn't mean that it takes very long, just that it's time the CPU can spend doing other things. Commodore didn't bitbang the serial by choice, they were kinda force to. though i still feel like people shouldn't be discouraged from using an MCU in their system if they want to, especially if it's the cheapest and most convenient option. (in this case they already have a PIO so it makes sense to use that)
    – Proxy
    Commented Apr 29, 2021 at 12:43

Just use Z84C40 SIO chip. SIO stands for Serial Input Output. It's a part of standard Z80 family chips and has two channels. I used it for PS/2 keyboard and USB connection to my breadboard Z80 computer running at 2.4576 MHz. Z84C40 can divide system clock by factor of 16, 32 or 64 thus I run my UART-USB bridge at 38,400 baud without use of 4-bit counter as system clock divider. Luckily PS/2 keyboards generate clock themselves. So all you need to connect a keyboard is this chip and PS/2 connector (female).

LCD 20x4 chars

Update: I have finally made adapter PCB for 2.8" TFT Arduino UNO shield which provides back compatibility with previous LCD screen (no need to rearrange connection wires). Also I've made a convenient EEPROM programmer shield for Arduino MEGA. So now I have a lot of fun coding my Z80 breadboard machine which now runs at 10 MHz. Also there is 7.3728 MHz clock generator for UART-USB bridge (115,200 baud). TFT 320x240

TFT shield

EEPROM programmer shield

  • 3
    That's a beautifully simple design. Do you have a writeup somewhere?
    – occipita
    Commented Oct 9, 2020 at 3:21
  • this is pretty much exactly what i was planning to build, if there's any schematics/writeup/blogposts/whatever about it i could take a look at to save me some headache, that'd be extremely appreciated :)
    – nonchip
    Commented Oct 10, 2020 at 21:17
  • 2
    Well.. my design was inspired by Ben Eater's one (youtube blogger), but his system is based on 6502 CPU and still is not completely developed. I didn't post yet my Z80 system anywhere but here. I probably could draw some schematics, but it would be kind of spoiling all the fun for you. As far as I understand, the essence of this kind of hobby is not to just GET a retro system, but to elaborate the design by yourself, build it and make it work. Besides my design is so simple and straightforward so there's practically nothing to explain, just get the chips and download corresponding datasheets. Commented Oct 12, 2020 at 1:03
  • 2
    @nonchip You can find some writeups now on extended modular PCB version of my design. Commented Dec 4, 2021 at 15:14
  • 2
    @PeterMortensen SIO stands for Serial Input Output. All you need to do is google Z84C40 for it's datasheet. Commented Aug 28, 2022 at 22:54

PS/2 is a SPI protocol. Talking to stuff like your keyboard is literally what SPI peripherals are designed for.

So the most obvious choice, if your micro has a SPI peripheral, is to use it. If you think that sounds too easy, wait until you start looking at the registers to set it up. It can be a lot harder than you think, if you're not used to following specs to the absolute letter!

But let's suppose you want to do it the hard way. Then you're looking at shift registers and some logic, which is how the peripheral works anyway. It's not just the parity bit you need to check. For a valid frame, there must be start and stop bits too. Two 8-bit shift registers are fine - just ignore the lower bits.

You could interrupt on a keyboard clock edge, read in both shift registers, and work out whether the top 11 bits form a valid message. That's cheap on components, but puts more load on the processor. At 16kHz, it's probably not too bad though.

Or you can decode in hardware - basically build yourself a small version of the SPI peripheral you've got in your micro. You can do this in stages of increasing complexity.

  1. The most basic version would just use a 4-bit counter to count clocks, interrupting the micro and resetting itself after every 11. Assuming there are no framing errors, that will work. With any framing errors, it will always be wrong though.

  2. Then we look at the start bit. Now the counter needs the data line to be low before it'll start counting. Once the counter is non-zero, it keeps counting until it reaches 11. OR together the data line and the 4 counter bits, and you're set. Now if there's a framing error, repeated sends will eventually sync up and you're sorted.

The neat thing now is that you can get back to only using an 8-bit shift register, by only enabling the shift register clock when the counter is between 1 and 9. Other bits won't come through.

  1. Then the stop bit. The 11th bit has to be high. So only interrupt the processor when you get to 11 clocks AND the data line is currently high.

  2. And then parity, which is not a good way of error-checking, but anyway. You want a second counter, clocked normally, and enabled when the counter is between 1 and 9 and the data line is high (or low, depending on how you want to do it). Then you need a flip-flop which captures this on clock 10, and you AND this with the conditions from step 3.

And now you have a working SPI receiver.

  1. For full compliance with PS/2, you should also check the length of the initial clock low pulse, which makes you better at detecting framing errors. Trigger a monostable on the falling clock edge, feed the monostable into the S and enable inputs of an SR flip-flop, and feed the clock input to the R input. If the clock stays low for that time, the flip-flop output stays set. If not, the flip-flop output gets cleared at some point. Use this as another condition for starting the counter. Note that this is actually something you can't do with a regular SPI peripheral.

A naive version might disable this detection whilst the counter is non-zero. After all, we know we've got a frame start, right? The correct version keeps it running though, because what happens if you lose the connection mid-frame and then get it back again? So if you get an extended low clock pulse at any time, it will reset the counter back to 1 to pick up the new frame, and just overwrite anything currently in the shift registers.

I'm not going to get onto the Tx side, because that's a whole nother world of pain. Left as an exercise for the reader, as they say. :)

  • 1
    Another variation is to use the shift register as the "bit counter", so that when a particular bit becomes 1, the next clock will capture the state of the shift register and clear it.
    – supercat
    Commented Aug 17, 2020 at 21:35
  • 1
    PS/2 protocol is similar in some ways to SPI, but that doesn't make it an instance of SPI. For example, PS/2 sends data LSB-first and SPI sends MSB first. Also, the handling of parity and stop bits differ. Commented May 26, 2021 at 12:30
  • Re "PS/2 is a SPI protocol": The devil may be in the details, even if sending from the host to the keyboard is not considered. There must be a reason such a solution is nowhere to be found (usually, with a microcontroller, that does have hardware SPI and I²C hardware support, it is either bit banging or using an edge-triggered interrupt pin connected the PS/2 CLK signal). What are the actual adaptions, incl. helper hardware, if any, of this four-wire protocol to a two-wire protocol (ignoring GND) for this to actually work? Commented Aug 27, 2022 at 20:00
  • cont' - How are the 9 bits of information mapped to the available SPI hardware? Commented Aug 27, 2022 at 20:02
  • OK, here is an attempt to describe some of the mapping (e.g., tying signal SS to ground). But the rest is using a CPLD with standard SPI parts, but using a custom number of bits, 11, and have the LSB first. Commented Aug 27, 2022 at 20:49

If you really want to do it the shift-register way, there are 9 bit shift registers available. If you do a search at digi-key for '9 bit shift register', then sort the resulting table by number of logic elements, you can see a few varieties on that theme.

Alternately, you could use chain two 8 bit shift registers and ignore the other 7 bits of the second shift register.

  • 3
    Or even an 8-bit shift register and a single D-type latch (eg half of a 7474).
    – occipita
    Commented Apr 24, 2020 at 8:55
  • 2
    The 9-bit shift registers at Digi-Key are ECL parts, which cannot directly use CMOS, NMOS, PMOS, or TTL logic levels.
    – supercat
    Commented Oct 8, 2020 at 19:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .