I knew this would be a long haul, because i had no technical documentation and my c was very rusty. Without the user manuals, it would have been impossible.
Teensy++ 2.0
The Teensy+ 2.0 is often used for keyboard projects. It is about the same size as the microcontroller and has sufficient I/O to cover it.
It has a lot more computing horsepower than the microcontroller, so I don’t have to do a great coding job.
It is compatible with the Arduino IDE.
Reverse engineering
I was doing this in 2019. In Jan 2025 i got access to a working keyboard which confirmed some things and contradicted others. I’ve put updates in [] brackets.
I spent many hours trying to get the basics of the circuits on both the keyboard and the microprocessor board. I needed pretty much the whole keyboard circuit and some of the microprocessor circuit.
I worked from both sides of the interface. Both boards use 74 series logic, so there were a lot of connections to trace!!
With a 25 pin interface, I was guessing it was parallel. [Yes]
The front panel switches come in through the keyboard.
The keyboard has LEDs, so there was a pretty good chance that the interface was bidirectional. [Yes]
There is also a speaker in the keyboard, maybe for keyboard press feedback or for a bell. [Both yes]
The keyboard has a register for receiving data from the microprocessor board. There is a write line from the microprocessor board for the register. The LEDs are not controlled directly by the register. It is read by the microcontroller. Perhaps it has an interrupt. {Yes, although i didn’t use it as such]
It has two 4 bit muxes that are used to read from either the front panel switch states or from an 8 bit port on the microprocessor. There is a read line and a select signal from the microprocessor board for the muxes. [There are a couple of other status lines indicating key down and autorepeat.]
There are two strobes from the uC that are ORed and sent to the uP board. Both operate the buzzer but one is fixed volume and the other is adjustable with a pot. If both are asserted, there is no sound. Some of this I only worked out after I started trying some code. [The two lines are coded for 3 functions.]
On the uP board, the strobe sets a flip-flop which I expect is cleared by an interrupt routine.
The front panel switches work without uC software.
I have created a rough schematic of the keyboard.
Based on this i made up a plug-in replacement for the microcontroller.
A replacement with a USB port proved to be quite handy for other purposes. I recorded the port assignments etc in the source file for the software.
Keyboard Scanner
This is an unusual keyboard. Each key has a small ferrite core transformer which is saturated by a magnet when the key is unpressed. When a key is pressed, the ferrite core can pass a pulse from one side to the other.
The keyboard has 10 stimulation lines and 8 detection lines for a total of 80 keys. There is a shift key and a special shift key to generate more characters – 240 in principle – or even 320 if both were used.
There seems to be no reason why the scanner can’t happily detect all the keys that are pressed at any time.
Of course, any one time is one complete scan of the keyboard. I was thinking that somewhere between 50 and 100ms would be acceptable. Nobody is going to do any serious typing on this old machine. That gives about 1ms per key. [This turned out to be a bad idea. It’s too easy to miss the register writes. It now checks one key and then checks whether the register has been written.]
Generating characters
I wrote a sketch to enter a byte which would be transmitted once to the uP board. I used a scope to watch what was going on.
Part of this was discovering the timing for the data and the strobe. I could see the read in response to the strobe which is about 100us after the strobe.
The uP board seems to check the state of the strobe so it’s not just about the leading edge. Keeping it down for too long gives repeat characters.
I went through all 256 values to see what each does. Some were obvious; others less so. They certainly aren’t ASCII. The highest bit seemed to indicate shift.
The standard characters were easy to detect, but the function keys were very challenging. There is a lot of guessing involved. Trial and error. It would be impossible without the manual.
[It worked remarkably well, but my timings were out by a mile.]
Scanning the keyboard
Having bit 3 of the scan register asserted prevents the uP card from recognising characters transmitted using the code above. I could not work out why. [This line indicates that a key is down and is fed into the status register. If the 8085 software doesn’t see it, then it thinks the key is up.]
All the scan lines are driven from one register. 4 to set the stimulation line. 3 to set the sense line. 1 to generate a pulse. Timings were unknown but i was hoping it could be done in less than a millisecond. [A few microseconds works. The actual keyboard has the pulse low for about 50us and high for about 12us.]
The secondary pulse was quite short. About 100ns but the stimulation circuit needs to reload – there’s a capacitor that provides a small reservoir of charge and after that the current falls back to the DC level.
The pulse is about 500mV peak. The comparator inputs are set pretty close (about 15mV) so it shouldn’t have taken much to get a logic pulse. I couldn’t get one. I couldn’t provoke the comparator to ever go low so concluded that the LM319N was faulty.
A replacement LM319N did the trick. Keystrokes were recognised easily and within a 1us, I found there were false alarms, so I set it up to scan several times and need multiple hits to recognise a keystroke.
[I realised just recently that there is a uC output, pin 21, that affects the comparator threshold. It is normally high but goes low when a key is released. I suspect it provides some hysteresis. I’m not using it at the moment.]
I messed around with the dwell on each key to make sure I didn’t get multiple characters and I didn’t miss any keystrokes. I added code to work with shift keys and to auto-repeat.
Once the keystrokes were working, it was easy enough to collect the scan codes for each key.
Mapping Keys
Determining the key mapping without a working keyboard was quite an exercise, and I got remarkably close considering i had no understanding of the underlying protocol. [A working keyboard resolved the last of the protocol and mapping issues.]
And with this i had a working system with a pretty awful looking screen and a new USB interface!