S100 Computers

Home S-100 Boards History New Boards Software Boards For Sale
Forum Other Web Sites News Index    
An IBM Keyboard Adaptor Board 

  Keyboard Converter Board

Many S-100 users have some kind of ASCII style parallel port keyboard attached to their system.  The interface was just a simple 8 bit parallel input port with a second port single strobe bit.  Most of these keyboards came from old mini computer systems or simple CRT terminals. Today they are now quite difficult to find. If there are any parallel port keyboards on eBAY etc. from Atari systems and the like, they are usually not in ASCII format but instead deliver key press data in X,Y coordinates etc.  Today almost all PC systems interface the user via an IBM PC (AT) type keyboard.  This is in fact may be the single most lasting effect the IBM PC has had on the PC business in the past 30 years.
AT keyboard
However the IBM keyboard does not return data to the computer via a parallel port. Instead it does so in a more sophisticated manner via a bidirectional serial communication mode.  Each key returns its own (single or multiple 8 bit code) which is different on the key down and up strokes. It also depends on the status of the Ctrl, Num, Alt and other keys.  To make matters worse IBM took two try's at the process. The original IBM-PC started with a more simpler serial data format that actually worked fine. However (just when clones of these keyboards started to appear) IBM came out with a second more complex serial communication protocol for their Keyboard in their IBM-PC AT.  This protocol is what almost every PC-style keyboard uses today.   There are still some of the old PC and XT keyboards.  They will not work on modern systems (or with the board described below).

The Keyboard Serial Communication Protocol.
There are actually two types of sockets used for these IBM type keyboards (not counting the newer USB port driven ones). The original socket was the larger AT style socket shown below.  The much more common socket today is the PS/2 style socket. (Perhaps the only contribution/residual of the ill famed IBM PS/2 computer). The pinouts are different. The view shown is that of looking into the male socket of the keyboard cable itself.

Sockets AT   Sockets PS-2
In all cases communication between the computer and keyboard is bidirectional over only two data lines. A "Clock Line" and a "Data Line".  Both data lines are Open Collector TTL signals.  Let us look at communications in each direction separately.

Keyboard to Computer.
At any time the Computer has the ultimate priority over direction. It can at anytime send a command to the keyboard. That said, the keyboard is free to send data to the Computer when both the Keyboard Data and Keyboard Clock lines are high (Idle). The Keyboard Clock line can be used as a sort of Clear to Send line. If the Computer takes the Keyboard Clock line low, the keyboard will buffer any data until the Keyboard Clock is released, i.e. goes high. Should the Computer take the Keyboard Data line low, then the keyboard will prepare to accept a command from the Computer.

The transmission of data in the forward direction, i.e. Keyboard to Computer, is done with a serial frame of 11 bits. The first bit is a Start Bit (Logic 0) followed by 8 data bits (LSB First), one Parity Bit (Odd Parity) and a Stop Bit (Logic 1). Each bit should be read on the falling edge of the clock.


The above waveform represents a one byte transmission from the Keyboard. The keyboard may in fact not actually change it's data line on the rising edge of the clock as shown in the diagram, the data line only has to be valid on the falling edge of the clock. The Keyboard will generate the clock. The frequency of the clock signal typically ranges from 20 to 30 KHz on most systems. Note in particular in this protocol the Least Significant Bit is always sent first.

Computer to Keyboard
The Computer to Keyboard Protocol is initiated by taking the Keyboard data line low. However to prevent the keyboard from sending data at the same time that you attempt to send the keyboard data, it is common to take the Keyboard Clock line low for more than 60us. This is more than one bit length. Then the Keyboard data line is taken low, while the Keyboard clock line is released. The keyboard will start generating a clock signal on it's Keyboard clock line. This process can take up to 10mS. After the first falling edge has been detected, you can load the first data bit on the Keyboard Data line. This bit will be read into the keyboard on the next falling edge, after which you can place the next bit of data. This process is repeated for the 8 data bits.
After the data bits come an Odd Parity Bit.


Once the Parity Bit has been sent and the Keyboard Data Line is in a idle (High) state for the next clock cycle, the keyboard will acknowledge the reception of the new data. The keyboard does this by taking the Keyboard Data line low for the next clock transition. If the Keyboard Data line is not idle after the 10th bit (Start, 8 Data bits + Parity), the keyboard will continue to send a Keyboard Clock.

All this to save one extra wire on a keyboard cable! An extra wire (directional flow etc.) could make things so much easier to emulate. Anyway this is what we have to work with.

An S-100 Board to accept an IBM PC keyboard input.

In order to use the above keyboard format in a S-100 system we have a bit of a challenge.  Not only is the data is a serial format, but the actual format itself is not one that could be spliced into a standard UART chip.  We need to emulate exactly what a PC computer reads.   Now fortunately for us the only significant communications going from the
computer to the keyboard are signals to turn on/off the caps lock, shift etc. LEDs on the keyboard.  All other communication is from the keyboard to the computer. We'll address the LED's issue later.  The complication we have is that the actual keyboard key codes  (scan codes as they are called), sent from each key is somewhat complex and depends on whether the Shift, Ctrl, Alt, Number Lock of Function  keys are pressed.  To make matters worse in some case pressing one key generates code to for more than a single scan code.  Also every UP key is the same as its DOWN key code except it is preceded by a 0F0H scan code. The figure below shows a simplified diagram of the key DOWN key scan codes.
Scan Codes

Over the years many have tackled this challenge in various ways to hammer an ASCII code out of these keyboards.  Some use elegant single chip CPU/IO chips (PIC etc.), others various TTL logic chips.  I decide to tackle the problem head on by using the age old Z80 CPU, RAM/ROM and a few Zilog PIO's.  This not only allows one to completely control the data sent from each and every key combination simply (lookup tables), but the keys can be dynamic, function keys can return varying strings depending on the application.   I chose the Z80 because almost everybody in the S-100 bus world knows the opcodes and can easily program a simple common 2716 EPROM or the like, for their own specific applications/desires. 

Years ago back in 1986 I wrote up an article for Sol Libes Micro/Systems Journal about a simple Z80 based board to convert the original IBM-PC scan codes to an ASCII parallel port keyboard format. This article can be seen here.  This board worked for the earlier first generation PC keyboards mentioned above.  This new S-100 board is an extension of that board with more bells and whistles.   Here is a picture of the S100 prototype board.

keyboard Prototype Board

The board is really a small microcomputer system with its own RAM, ROM and I/O ports.  Its only function in life is to watch the data coming in from the keyboard and translate each key scan code into an ASCII letter or string.   While this process could probably be done by carefully watching a one bit data and clock input with careful timing. It is just easier to shift the serial data into 2+2 74LS164 serial to parallel IC chips.  A detailed schematic is shown here.

IC3A and 4A (74LS164's) collect the serial data bits and send them back to the Z80 (via PIO #1) as 8 raw data bits.   IC1A and 2A simply count the clock bits. Stopping further shifting when 11 clock pulses have been received and sending a strobe to the Z80
 (pin 5 of IC1A to PIO #1 pin 27).  The Z80 then reads the scan code and via lookup tables etc. sends the ASCII character to PIO #1, (pins 15-7) with a strobe pulse from PIO #2 pin 14.

All this is handled in a small program in a 2716 EPROM.  The listing for this code (called SKey1.Z80) can be seen here.
The program itself (
and all the other code mentioned below) can be downloaded here

The code itself is written for the SLR Z80ASM.com CPM assembler which can be obtained here.  The documentation can be obtained here.  However almost any assembler the recognizes the Zilog opcodes should work fine.

The real fun is writing the software for this board was the fact that you have complete and total control of the CPU all the time. There are many ways you can tweak the system. Currently I just have a series of character translations tables.  A number of the PIO pins are unused. They are purposely set with jumpers and OC gates to the clock, data and interrupt lines to better fine tune things if required.  Things like communicating from the board to the keyboard for example.

Currently the board does NOT control the keyboard LED's. I took the easy way out and put these LED's at the top of the S-100 board.  Since I have a transparent cover on my box this works fine. You may wish to bring them out to the front of yours or to the keyboard itself.  Alternatively somebody could spend some heavy duty time communicating back to the keyboard with the "free bits" described above. 

As an extra, I added LED HEX displays to show the SCAN code values of data from the keyboard coming to the board and a  LED HEX display of the translated ASCII going to the computer.  These LEDs are the now rare but wonderful HP 8 bit HEX display LED's (called HP5082-7340's).  Most single digit LED displays today only display characters 0-9 these do 0-F.  I think there are some other equivalent ones but they are expensive.  For example the Avago HDSP-0762 (Jameco #1551189) or TI TIL311 (Jameco 32951).  For this reason in the production board (see below) there is an option to use an 8 bit Bar LED display as a substitute.

The short video here shows the S-100 board in action.  The characters 1,3,4,5,6,7,8,9,0, ESC are being typed in. The left pair of HEX displays (and LED Bars) shows the Scan code received from the IBM-PC keyboard. The right hand side Hex display and LED bars shows the translated ASCII code being sent to my S-100 video board parallel port keyboard port.

To play the video click on the arrow within the window.
(Note: You must have Adobe Flash installed on your computer to see this video. You can download the latest Adobe Flash Player for your Browser here).

S-100 PC Converter Board
Future Use Of The Board
The board has great potential for many applications. Because the key scan codes are processed and translated  using a Z80 it is easy for anybody to take my KEY-DIAG.Z80 code (see below) and adapt it for their own specific application and test it under CP/M.  Things like buffering whole lines of character input before sending it to the computer with a CR,  or program specific character lookup tables to control the screen cursor in special ways are two simple examples that come to mind, or convert function keys into special character strings for common commands for special programs.

The board has multiple jumpers for allowing users to have much more control on the system. These are not currently implement but you can use all of the PIO status signals with software if needed. These are brought up to the P55 connector.  There is the ability to trigger any of the S-100 interrupt lines  and in fact the ability to communicate back to PC keyboard (see jumpers P68 and p69).

Building The Board.
For people that are interested in building this board here are some comments and step by step instructions.
First install the voltage regulator, capacitors and IC sockets.  You have a choice of using the HP 5082-7340 hex displays or the LED bar displays (or both).  If you are using the HP hex display you need to arrange a special socket for this board. Take a 40 IC socket and cut it in two so the spacing is as shown in the picture below.  Insert the (costly) HEX displays carefully. Note the position of pin one on each chip and where it is on the board. Left to right there is a one pin spacing, two pins, and then one pin spacing.  Make sure you jumper the S-100 Reset (or better) slave clear connection to the S-100 bus.

Hex Display Socket

Insert the board in the S-100 bus and check that +5 volts is getting to each socket.  Now install only the 4MHZ oscillator, IC5 (74LS06)  U6 (74LS32), and the Z80. Do not connect up any jumpers etc. yet.  Burn a 2716 EPROM with just 76H in every position in it and insert it in the ROM socket (U8).  Turn on the power. The LED at the bottom of the board should come on indicating the Z80 has read the EPROM correctly. Do not go further until you see this result. If the "Halt" LED does not come on you may have a bad chip and/or solder connection. 
If all is OK then install the two PIO's and the RAM chip (U9, a 2KX8 6116). Repeat the above test.

Halt Test

You now have a working Z80/ROM system! Next install all the IC's except the Zenier diode D8 and R40 and the bell/buzzer circuitry (74LS123).

On the back of the board we have to make a few small corrections.  Connect a wire between pin 3 of U13 (74LS123) and +5V. Cut the trace coming from the IBM keyboard data line going to U13 pin 13 and connect the data line to U13 pin 4. (This has the effect of having the LED flash on when a character comes in, rather than normally being on and going off when a scan code is received. You can leave it as is if you like).  Connect a wire between the + terminal of the buzzer and +5 volts. Lastly, but very important pin 17 of both PIO's must not float. They go to the P55 connector but normally are not connected to a keyboard. At P55  jumper both pins to ground . This is absolutely essential for this board to function reliably. A floating input will cause the board to randomly lock up.   See the picture below which illustrates these jumpers.
Converter Board (back)
Before you use the board you need to setup a number of board jumpers for your particular hardware configuration.
First the PC Keyboard In socket connection. This 10 pin socket is at the top left of the board.  Only the bottom 4 out of the 5 bottom row of pins are used. They are Ground, +5Volts (to the keyboard), and the clock and data signals from the keyboard. Below this socket is a set of jumper positions to allow you to match up any socket connection you may have with what this board needs.  The signals must be as follows:-
Keyboard Connections
You can jumper the wires on the front and back of the board if they must cross.  Please be absolutely sure you send the correct +5Volts and ground to the correct pins on your keyboard. See the diagram above at the start of this article. It shows the male pins of the keyboard socket at the end of the cable as you look into it.

Next we need to collect the output ASCII data lines in a format that your parallel video board recognizes.  Since they are many possible formats for the different S-100 video boards, the connection to these boards via the top right connector goes through a series of jumpers. You will minimally need to determine which lines are for data bits 0-8 of your keyboard input. Also you will need a strobe line. Depending on your video board the strobe can be a positive or negative going pulse. Jumper K4 with a short wire bridge to suite your video board keyboard input. The output from PIO#2 pin 14 is normally low, pulsing high when a character is sent.  On my SD Systems 8024 Video board the strobe should be high to low so I run the signal through the inverter IC6D (74LS06).

Some slow video keyboards may require the board to wait for an acknowledge signal indicating it received the character and is now ready for the next one. IF your board requires this (i.e. you cannot flood the system),  jumper K5 to recognize a positive or negative strobe signal.  The software PROM example I have below has this requirement commented out. If you need it, you need to include that code. The reason I did it this way is that not only do few video boards have this requirement but if the Ack signal is not sent the software will hang waiting for the signal giving the appearance the board is not working.

Ok, we are now ready for a functional system. First see if you can get the board running without the need for diagnostic software (see below).  Download the SKEY.Z80 code, assemble it to a hex file and burn it into a 2716 EPROM.  I have used old 350ns EPROMS with a 4MH Z80 on this board. I have run it up to 5MHz with no problems, so the simple logic and timing on the board should be no problem with standard 2716 EPROMS.

Insert the board into your system with the keyboard in and out connections as described above and power up. The board should display 13 in the Keyboard Out display. This indicates the board ran through its diagnostic test OK and is ready to work. See the software for error codes.  If working correctly whatever you type no matter how fast you type the board should keep up. For example pressing the "1" key should display 16 & 31 on the In and Out displays.  If you do not see this go to the diagnostic section below.

The final thing we need to do is activate the "bell" function.  You may not want this but if your S-100 video board sends out a signal that the ASCII 07H has been received it can be user to sound a bell/buzzer.  This goes back to the old teletype days.  Having the ability to ring a bell is nice.  The problem is different S-100 board manufactures used different signals to do this. They would either pulse high or low for a fraction of a second where a buzzer in hardware was expected to generate its own sound, remain high/low for a length of time, or actually generate the high/low tone signal themselves in software.  The bell circuitry on this board should allow most formats to work by selecting the appropriate jumpers on P67.    The one complication of using the direct high/low level approach is the bell sounds if the P55 connector is disconnected from the board. This can be annoying. I use the low to high transition triggered signal approach with the 74LS123 with my SD Systems 8024 Video board.  This way whenever the P55 connector pin 23 goes from low to high the bell will sound.  Changing the values of C20 and R33 will vary the length of time. Anything between 47 and 100uF seem fine.  Do NOT use the resistor Zenier diode circuit to power the buzzer. There was an error in the layout design. Going above 5 volts causes the buzzer to stay on.  Buzzers like the Jameco #76065 work fine at 5 volts.

Here is a short video demonstration of the board in action. Random keys are struck on the keyboard. The left most pair of HEX displays shows the arriving scan code. The right pair shows the corresponding ASCII character sent to the computer.

Diagnostic Software.

In theory you should not need any of this, but just in case you run into problems I have written a few very simple programs to help identify the problem.  Much depends on the nature of the problem. Assuming your board passed the above "Halt" test. The next question is do you see 12 on the data out Hex or LED display? The SKEY.Z80 code after initializing the PIO's, first fills the 2K of RAM with 0's it then checks that's the case.  If there is a RAM problem the output code will be 10H.  Check hardware.   If the Z80 somehow jumps to non-existent RAM/ROM it will see 0FFH on the data lines causing it to jump to 38H in the ROM which will put 38H on the display. Again a hardware issue.

Check the PIO's are working correctly.
This is a simple loop test. We first input from  PIO#1 and output the value to PIO#2. The values then increase by 1 each time in a loop on the output display.   You can see Key-DIAG(PIO-Test1).Z80 here. See above, for the source code itself.

This is a slight variation. We first input from  PIO#1 and output to PIO#2 continuously. There may be problems with the 74SL164's (see below)  but whatever appears on the input display should appear exactly the same on the output display.  Note neither of these programs requires RAM. You can see Key-DIAG(PIO-Test2).Z80 here. See above, for the source code itself.

Using the Diagnostic Connector Port
The board has actually two distinct hardware sections. It really helps if you can establish where the problem lies.  Is it in the signal processing section or the Z80 translation section. The first section of the board takes the raw clock and data serial data and runs it through the four 74LS164's.  The resulting scan code is presented the Data IN Display and on pins 1-15 of the P66 "test Connector".  Pin 17 on the  test connector will go low as well. Normally this same signal is see by the Z80 via pin 27 of PIO #2 (indicating a complete scan code is in). The Z80 then sends out a clear signal to the 74LS164's via pin 15 of PIO#2 for the next scan code.  What we do is remove PIO#2, bend out pin 15 and reinsert the chip. We will control this line ourselves with a separate connection.

To do this you need to have your current S-100 system working (without this board for actual keyboard input) or use another computer . You will need to have two parallel input ports and one parallel output ports. You will see in the software (see below) I use the following equates.  If you are using a separate computer/ports to control this S-100 board be sure to use a common ground line (P66 connector pin 23).

KEYOUT    EQU 01H       ;Data port for direct output to SD Systems video board
KEYIN       EQU 04H       ;Raw data port for IMB keyboard (Diagnostic port)
KEYCLEAR EQU 07H       ;Pulsing bit 0 high clears 74LS161 Shift Regs
KEYSTAT   EQU 07H       ;Input bit 0 is zero if IBMPC Key char ready

Diagnostic Probe 

Download the program SKEY-DIAG.Z80 from here. Set the equates to your system and assemble it. Run this CPM program.  It is the exact same EPROM code used to run your board except it is surrounded (front & back) with diagnostic code. When you send a scan code to the board the program will show you what it got going in and what is getting translated for output. The input values should show up on the input HEX/LED display however the Output display will not. Instead it will appear of your Computer screen. Here is an example:-

Diagnostic test

This should help you track down any hardware/software problems you have with the board.
Also a good Logic probe can help. Here is a sample of a few key signals.

Logic Probe Data

Improving the EPROM Software.

If you wish to add more software functions to the EPROM based software rather that burning 2716 EPROMS each time for debugging you can modify the above diagnostic code (make sure the DEBUG equate = TRUE) check it out with the board itself under CPM as described above and when it is perfect  set the DEBUG equate to FALSE and reassemble the ROM only code with the ORG at 0H.

If you have suggestions, comments or updates for this board please do so using the Forum section of this web site .

A Production S-100 Board
Realizing that a number of people might want to utilize a board like this together with a group of people on the  Google Groups S100Computers Forum, "group purchases" are made from time to time.  Please see here for more information.
Please note all the above clearly applies only to people who know what they are doing and can  do a little soldering and board assembly.  There will be little hand holding at this stage.

The links below will contain the most recent schematic of this board.
Note, it may change over time and some IC part or pin numbers may not correlate exactly with the text in the article above.

Most current KiCAD files for this board  (S100 Parallel ASCII Keyboard-002.zip  11/6/2014)

Other pages describing my S-100 hardware and software.

Please click here to continue...

This page was last modified on 11/29/2017