The machines did not come with a keyboard, so i needed to knock something together.
The technical manual gave me some clues:
The keyboard clock was about 75kHz.
I wrote some keyboard code for Arduino Uno. It needs direct port reads and writes to be fast enough. I worked out pinout for the keyboard connector and made up cable to the Uno.
Initially I had no joy at all, but found a broken pin on the interconnect between the board and the I/O module used for the keyboard. This deceived me with the pinout – I had 5V and the data input reversed – lucky there was a current limiting resistor. Once fixed, the keyboard recognised when a key was hit but made no sense of the data.
The data seemed to be making it to the shift registers, but the control of the shift registers looks a bit random. There is a monostable involved. Perhaps a dead tantalum. I’ve had a few lately. Back to buzzing out circuits.
This is roughly what I found:
It’s not 100% accurate – I used a 2716 instead of the 2708 just because the symbol was already there, and I’m lazy.
The start bit triggers the monostable and, once it works its way through the registers, it disables the clock.
The monostable times out after about 250ms when it clears the shift registers which re-enables the clock. I found some glitches at the input to U50C which became pulses at the output and prematurely cleared the shift registers. I don’t know why the little filter is there, but it gives an opportunity for noise as much as it removes it. I halved the resistance and the problem went away.
The ROM is small but quite large for character mapping – 1024 possible inputs and 256 possible outputs. When the clock stops, 16 bits are captured in the shift registers. The first one is the start bit. The next 10 feed the EPROM. The last 5 may not be used at all, but could be used eg for a hard reset.
The manual suggests the scan codes are converted to ASCII. I needed to feed in the unknown scan codes. Being a 2708 i could not read the EPROM with my programmers (i can now). I had to catch up with Andrew P at the ARC to borrow his EPROM reader.
I was impatient though so I attempted to work it out.
There are a lot of codes to enter, and the system doesn’t respond to many of them. Often, it gives the same response to several codes. Sometimes the response is one-way and requires a power cycle. The manuals give some clues but not enough.
Curiously there is a monitor command that goes into a terminal mode where everything goes out the serial port. I had already discovered that depending on when I entered this character I sometimes got a “t” or the screen cleared and machine hung – this is the terminal mode!
I connected an oscilloscope and used its RS232 decoder to check the ascii characters. The port requires a null modem to transmit. It worked fine.
This was a much better way of seeing what was generated for each code, but there were still several codes generating the same ascii characters or the same ascii characters with the eighth bit set.
I used the first code that created a character to make a map which I added to the Arduino code. It’s kludgy to use the Arduino serial monitor, but it seemed to check out ok. It was good enough to try to boot the machine.