Hi-Tek 725 terminal keyboard

MMcM

01 Jun 2020, 03:00

I got his board with NMB Hi-Tek switches some time ago.
nmb-110695-top.jpg
nmb-110695-top.jpg (1008.48 KiB) Viewed 794 times
nmb-110695-bottom.jpg
nmb-110695-bottom.jpg (1.16 MiB) Viewed 794 times
All the chips have 84 datestamps, so I assume it was made around 1985. There is no OEM branding that I can spot. It shows no sign of ever having been used and came in its original(?) foam-lined box.

It appears that CHM has a very similar one. Theirs came with a spec sheet, but it went into their archives and hasn't been scanned yet, so that doesn't help.

There's clearly a 5V regulator on the left there, so it takes 12V (or did originally; since it just regulates it down to 5V, anything around 8-15V should work). So care was required to get the signals right before applying that higher voltage power.

The controller is an 8049 and it connects to the terminal with an RJ12. After a bit of tracing,
  1. switch 20 (Reset)
  2. -INT, so an input to keyboard
  3. P27, so an output from keyboard
  4. ground
  5. DC in
  6. chassis
The digital signals go through an inverter twice, a standard trick. As there is no clock signal, the protocol will just be serial. There is also a transducer (buzzer) connected to the controller, so input will be needed to work it. Most of the matrix goes through a pair of decimal decoders but the shifting switches connect to the controller directly.

It came with those red wires already and they turn out to be connected to the signals that really matter: power and data out. This made it easy to connect to a scope and bang on the keys.

Signal looks like TTL serial at around 10kHz. And the scope's decoder works when set to 9600 baud. Two bytes are transmitted for each normal key press. The first is a shift mask and the second is ASCII, with any shifts already applied. Nothing when just pressing the shift keys and nothing for key up.

At this point, the possibilities for what a USB controller can do are a bit limited. So I put the board aside for a while.

Recently there was discussion about what can be done for a USB keyboard without both make and break signals and with character conversion done by the keyboard. So I gave it a shot and the result is here.

A Teensy is usually preferable over Pro Micro for the same processor, because:
  • the bootloader is smaller
  • it has a reset button to put it into the bootloader when developing
  • there are more GPIO pins and they are somewhat more rationally laid out
But in this case there is plenty of room, the keyboard has its own reset button, and really only RX is needed.

And in favor of the Pro Micro:
  • cheaper
  • two ground pins next to the UART pins
nmb-110695-converter.jpg
nmb-110695-converter.jpg (303.82 KiB) Viewed 794 times
There is no question of having the Reset key work as an ordinary key. It is, in fact, wired in series with the Ctrl key and nothing happens unless that is also pressed. Furthermore it resets the 8049 itself. It would work to wire to the ATMega32U4 -RESET pin. But that would short the two sets of pull-ups and require that the keyboard be powered with its 12V for the converter to work, even just for programming. So, instead it's wired to another GPIO and the program jumps to the booloader when it notices that, so it still works as needed when iterating uploads.

Mapping out the keys reveals a couple of additional pecularities.
  1. The firmware is evidently confused about bracket keys, thinking that there are [ ] and { } keys: unshifted opens and shifted closes. Even though the key caps are normal. This isn't a big deal, except that it means that it was apparently impossible to type GS on this keyboard. Both keys send ESC with Ctrl.
  2. Most, but not all, of the function keys have different shifted codes. I could not figure what determines whether or not this is the case. None of these key codes are standard and the shift mask is also sent, so I am not sure why one would bother. Or, conversely, why one would not make all such keys distinguishable.
Searching for kb113, which the CHM's example called itself, had come up empty. It's clearly an attempt to do a DEC VT-220 one better by adding another column of keys. (LK201 turns out to be superior for our purposes in having much more control over which keys send break codes.) After a bit more diligence, I am now pretty certain that this keyboard goes with a TeleVideo 9220, for which there is some information on Bitsavers. (The whole ad is here, although sideburns dude in the champagne linen suit is cut by the fold.) The distinctive key layout matches the Operator Manual and the PCB matches the schematic in the Maintenance Manual. The latter also mentions Hi-Tek, though without any matching part number(s).
TeleVideo-9220-Keyboard.png
TeleVideo-9220-Keyboard.png (362.77 KiB) Viewed 794 times
This leaves the question of input to the keyboard. It has sometimes worked to just send junk to the serial port and see how the keyboard reacts. But, instead, I decided to finally get around to putting together a planned Arduino MCS-48 masked ROM reader project.
mcs-48-rom-reader.jpg
mcs-48-rom-reader.jpg (977.12 KiB) Viewed 794 times
I used a Teensy++ 2.0 because I liked to symmetry of two 40-pin microcontrollers; the regular Teensy 2.0 would be been sufficient. I added the barrel connector as a hedge in case the Aliexpress boost converter wasn't good enough. But it was fine: less than 1mA is needed on the 12V EA signal.

The disassembled result is here.

Looking at the matrix scanning and key mapping routines and data shows the above mentioned strangeness about brackets.

Elsewhere it seems to show support for five commands.

Code: Select all

050E				NEXTBITIN:
050E : 97		" "		clr	c
050F : 86 14		"  "		jni	L0514
0511 : A7		" "		cpl	c
0512 : A4 17		"  "		jmp	L0517
				;
0514				L0514:
0514 : 00		" "		nop
0515 : 00		" "		nop
0516 : 00		" "		nop
0517				L0517:
0517 : 67		"g"		rrc	a
0518 : 00		" "		nop
0519 : BD 0D		"  "		mov	r5,#00DH
051B				L051B:
051B : ED 1B		"  "		djnz	r5,L051B
051D : 00		" "		nop
051E : EB 0E		"  "		djnz	r3,NEXTBITIN
0520 : 76 61		"va"		jf1	CMDARG
0522 : AF		" "		mov	r7,a
0523 : D3 05		"  "		xrl	a,#005H
0525 : C6 5B		" ["		jz	CMDIN5
0527 : FF		" "		mov	a,r7
0528 : D3 01		"  "		xrl	a,#001H
052A : C6 3F		" ?"		jz	CMDIN1
052C : FF		" "		mov	a,r7
052D : D3 02		"  "		xrl	a,#002H
052F : C6 43		" C"		jz	CMDIN2
0531 : FF		" "		mov	a,r7
0532 : D3 03		"  "		xrl	a,#003H
0534 : C6 49		" I"		jz	CMDIN3
0536 : FF		" "		mov	a,r7
0537 : 53 8F		"S "		anl	a,#08FH
0539 : D3 04		"  "		xrl	a,#004H
053B : C6 4F		" O"		jz	CMDINX4
053D : A4 63		" c"		jmp	RETCMD
				;
053F				CMDIN1:
053F : B4 69		" i"		call	RESETAUDIOCOUNTER
0541 : A4 63		" c"		jmp	RETCMD
				;
0543				CMDIN2:
0543 : B9 5E		" ^"		mov	r1,#05EH
0545 : B1 00		"  "		mov	@r1,#000H
0547 : A4 63		" c"		jmp	RETCMD
				;
0549				CMDIN3:
0549 : B9 5E		" ^"		mov	r1,#05EH
054B : B1 01		"  "		mov	@r1,#001H
054D : A4 63		" c"		jmp	RETCMD
				;
054F				CMDINX4:
054F : 0A		" "		in	a,p2
0550 : 53 F8		"S "		anl	a,#0F8H
0552 : A8		" "		mov	r0,a
0553 : FF		" "		mov	a,r7
0554 : 53 70		"Sp"		anl	a,#070H
0556 : 47		"G"		swap	a
0557 : 48		"H"		orl	a,r0
0558 : 3A		":"		outl	p2,a
0559 : A4 63		" c"		jmp	RETCMD
				;
055B				CMDIN5:
055B : A5		" "		clr	f1
055C : B5		" "		cpl	f1
055D : B8 60		" `"		mov	r0,#060H
055F : A4 63		" c"		jmp	RETCMD
				;
0561				CMDARG:
0561 : A0		" "		mov	@r0,a
0562 : 18		" "		inc	r0
0563				RETCMD:
0563 : B9 2A		" *"		mov	r1,#02AH
0565 : B1 01		"  "		mov	@r1,#001H
0567 : FA		" "		mov	a,r2
0568 : 93		" "		retr
				;
0569				RESETAUDIOCOUNTER:
0569 : B9 27		" '"		mov	r1,#027H
056B : B1 19		"  "		mov	@r1,#019H
056D : B9 28		" ("		mov	r1,#028H
056F : B1 00		"  "		mov	@r1,#000H
0571 : 9A BF		"  "		anl	p2,#0BFH
0573 : 8A 40		" @"		orl	p2,#040H
0575 : 83		" "		ret
  1. beep
  2. turn off key click
  3. turn on key click
  4. set low three bits of P2
  5. upload key bitmap
The last is interesting because bytes sent after command 5 (for a while?) are stored in RAM to replace what was originally copied from 380. I did not trace this through completely, but it may have something to do with the terminal's mode for switching between Lock shifting all keys and just shifting alphabetic.

Commands of the form 0b0xxx0100 take those three bits and output them on port 2. This seems pretty clearly intended to drive three LEDs. But this keyboard does not have any LEDs. In fact, the PCB does not even have room for them. Even the traces around those pins (top-left of the large chip in the center of the photo above) don't look to have enough room. Perhaps this same firmware was also used with some entirely different PCB?

I was not able to get these commands to work in a few attempts, even adjusting for potential confusion between bit on because interupt set and bit on because signal high. But it is clear that none of them really help make it more than minimally usable as a USB keyboard for a modern system.
Last edited by MMcM on 28 Mar 2021, 06:19, edited 1 time in total.

User avatar
kralcifer

01 Jun 2020, 03:23

So cool. I'd love to learn how do ROM reading.

MMcM

01 Jun 2020, 03:46

kralcifer wrote:
01 Jun 2020, 03:23
I'd love to learn how do ROM reading.
It's all in the data sheet. Start with regular 5V power and a crystal with a couple capacitors. Set RESET low and apply +12V to EA. Put the address to read into DB and a few bits of P2. Then set RESET high, which will latch the address and put its contents into DB.
Attachments
TMP8049P-read-rom.png
TMP8049P-read-rom.png (82.1 KiB) Viewed 773 times

MMcM

28 Mar 2021, 06:18

This keyboard looks only superficially similar from the outside.
dti-510-case.jpg
dti-510-case.jpg (390.89 KiB) Viewed 148 times
But inside the PCB is nearly the same and moreover has its TeleVideo part number printed on it.
nmb-130947-top.jpg
nmb-130947-top.jpg (1.08 MiB) Viewed 148 times
The layout matches the 905 and 965.
TeleVideo-905-965-Keyboard.png
TeleVideo-905-965-Keyboard.png (210.01 KiB) Viewed 148 times
The protocol is the same. The key arrangement has a number of differences, but the same keys have the same codes. Which explains the business with the bracket / brace keys notes above. This earlier keyboard had them that way, matching the keycaps.

It is straightforward to have a single firmware with a synthetic layout that just adds the few keys that aren't common to both.

User avatar
jsheradin

28 Mar 2021, 19:39

I've been messing with an ADDS 1010 board that looks pretty similar to yours. It sports 725s, the same Mitsubishi 8049, and a very reminiscent PCB. It's just branded NMB HI-TEK Corporation internally.

I'm not sure the protocol is the same; I haven't had any luck getting it to talk. Giving the board power just causes it to click every second or so which corresponds to a low pulse on one of the two pins. I did a bit of fuzzing on both pins at a couple bauds and couldn't manage to get any response or even a beep. Neither pin output anything in response to keystrokes.

Tying the pulsing pin to Vcc (even through a 1k) does cause a singular loud beep but then the board has to be power cycled for it to repeat. It doesn't seem to enable keystroke sending or anything.
Spoiler:
Image
Image
Image
Image
There was another thread with a different ADDS board that could be configured to output AT keycodes by setting some jumpers but I don't think that's the case with these boards. I might give dumping the ROM a try but given that it's at best 2KRO I might as well just do another PCB swap.

User avatar
TheInverseKey

28 Mar 2021, 20:06

Spoiler:
jsheradin wrote:
28 Mar 2021, 19:39
I've been messing with an ADDS 1010 board that looks pretty similar to yours. It sports 725s, the same Mitsubishi 8049, and a very reminiscent PCB. It's just branded NMB HI-TEK Corporation internally.

I'm not sure the protocol is the same; I haven't had any luck getting it to talk. Giving the board power just causes it to click every second or so which corresponds to a low pulse on one of the two pins. I did a bit of fuzzing on both pins at a couple bauds and couldn't manage to get any response or even a beep. Neither pin output anything in response to keystrokes.

Tying the pulsing pin to Vcc (even through a 1k) does cause a singular loud beep but then the board has to be power cycled for it to repeat. It doesn't seem to enable keystroke sending or anything.
Spoiler:
Image
Image
Image
Image
There was another thread with a different ADDS board that could be configured to output AT keycodes by setting some jumpers but I don't think that's the case with these boards. I might give dumping the ROM a try but given that it's at best 2KRO I might as well just do another PCB swap.
Correct from what I was able to determine it looks like that the terminal initializes the keyboard. I haven't been able to go further than this unfortunately.

Post Reply

Return to “Workshop”