The double-shot keycaps are divided into two colors, roughly between graphic and function keys, though this scheme breaks down in a few cases. The bottom row of keys in the main area aren't sculpted, which feels a little strange, though it did make it easier to correctly replace the arrow keys. The bottom row of the numpad is interesting looking with the 1.5u Enter that then leaves a gap in the lower right.
The switches are Futaba Linear. It appears that the switches were meant to be individually numbered. However, on this particular board there are lots of duplicates and some switches are upside down, so I don't think the assembler was trying to take advantage of that.
The PCB has lots of unpopulated chips, both on snuci's 950 and the one here. There is plenty of technical information in Bitsavers for both the TS 800 and the 950 and that explains what is going on.
There are two possible significant upgrades to the keyboard, one for a custom key mapping EEPROM and the other for LEDs. To enable these, some soldered jumpers also need to be changed. That is what the lone letters A through N near pairs of holes on the PCB are about.
To accomplish the custom mapping with only the added EEPROM and a few gate changes, the matrix scanning by the 8048 / 8035 is somewhat unusual. Instead of using a decade counter and demux, the row bit is output as the address for a movx read instruction. If there is no EEPROM, the data returned by this read is just the columns for any pressed keys. With an EEPROM, this data becomes, in turn, the address fed to the ROM and the controller sees the contents of that mapping entry.
To support LEDs, the terminal to keyboard data line on the 4P4C RJ, which normally connects directly to the speaker, is switched by jumper to go through an inverter twice and then to the controller's INT pin. The keyboard firmware on Bitsavers includes an interrupt routine that reads a byte from this line in a timed loop and passes it to a movx write. The schematic there shows how this is latched into the flip-flop that would drive LEDs.
On the terminal side, this line is normally (no LEDs) driven by the R6522A VIA, otherwise (with LEDs) by an R6551 modem.
The keyboard to terminal data line is connected to this same modem. The output from the keyboard is 1200 baud TTL serial.
Power to the keyboard goes to a 5V regulator, so 9-12V is needed. Both the board itself and the serial signals have 5V TTL levels.
The data from the keyboard is basically just ASCII. Some of the function keys are ASCII control characters and some are single bytes with the high bit set. So, RETURN and ENTER are 0D, LINE FEED is 0A, ESC is 1B, DEL is 7F and BACK SPACE is 88. The actual F and some other keys send a FF prefix byte: F1 is FF 01 and SEND is FF 21; LOC ESC (that is, shift ESC) is FF 29.
In terms of USB conversion, this means that the keyboard is just a virtual serial port. And since the output is already serial, all that's really needed is a TTL serial to USB serial converter chip like an FTDI or CP2102. Now, long ago, back when these terminals were actually in use, there was a somewhat well-known Usenet discussion about standard / preferred keyboard layouts on net.info-terms, right before it got renamed to comp.terminals. In this discussion, der Mouse said:
Which struck me as an odd second choice. I see that they later revised this to Sun Type 3.If I had to use one keyboard the rest of my life, it would be a Lisp Machine keyboard. Second choice is the TeleVideo 950.
Anyway, that same Usenet post's list of keyboard wants included "Keyclick." And the TeleVideo does have a speaker and the terminal did offer key click as a configuration option.
Making it work isn't hard, but it does mean that a microcontroller is now needed.
Code: Select all
void setup() {
Serial.begin(115200);
Serial1.begin(1200);
}
void loop() {
static uint32_t tone_start = 0;
static bool tone_playing = false;
if (tone_playing && millis() - tone_start > 50) {
noTone(5);
tone_playing = false;
}
if (Serial1.available() > 0) {
uint8_t ch = Serial1.read();
tone_start = millis();
tone(5, 200);
tone_playing = true;
Serial.write(ch);
}
}