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 (1008.48 KiB) Viewed 5615 times

: nmb-110695-bottom.jpg (1.16 MiB) Viewed 5615 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,

switch 20 (Reset)
-INT, so an input to keyboard
P27, so an output from keyboard
ground
DC in
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 (303.82 KiB) Viewed 5615 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.

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.
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 (362.77 KiB) Viewed 5615 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 (977.12 KiB) Viewed 5615 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

beep
turn off key click
turn on key click
set low three bits of P2
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.

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.

MMcM · 28 Mar 2021, 06:18

This keyboard looks only superficially similar from the outside.

: dti-510-case.jpg (390.89 KiB) Viewed 4969 times

But inside the PCB is nearly the same and moreover has its TeleVideo part number printed on it.

: nmb-130947-top.jpg (1.08 MiB) Viewed 4969 times

The layout matches the 905 and 965.

: TeleVideo-905-965-Keyboard.png (210.01 KiB) Viewed 4969 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.

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:

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.

TheInverseKey · 28 Mar 2021, 20:06

Spoiler:

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.

MMcM · 25 Apr 2021, 21:08

Another newer keyboard in this family, NMB 116535, for the Televideo ASCII 935 terminal.

: nmb-116535-top.jpg (1014.8 KiB) Viewed 4779 times

: nmb-116535-bottom.jpg (1.2 MiB) Viewed 4779 times

It is overall similar to NMB 130947 in both key and PCB layout.

There is no longer a 5V regulator; 5V power is direct.
There is no longer a RESET signal, just power and bidirectional serial.
So a 4P4C RJ connector replaces the 6P6C.
No RESET key means Clear Space can move over where it was.
This allows Line Feed to go where CLEAR SPACE was.
This allows ]} to go where LINE FEED was.
This standardizes []{} next to P.
Up-arrow can move up where {} was.
Home and the first two arrows can then move one to the right.
The space bar then gets wider.
0 and 00 swap so that the latter is now in the numpad proper.
The legend font is now lowercase.
There is no buzzer.
ALPHA LOCK becomes Caps Lock and now has an LED.

I assumed it would be the same shift + ASCII protocol at 9600 baud. And indeed it looks like that, with the bracket / brace shift confusion resolved.

A new feature is that 00 Cx, which was unshifted press of the top-left F keys on the NMB 110695, now indicates key transitions for the shift keys, in addition to their effect on a regular character's shift prefix. C0-C6 are Funct down, Funct up, Ctrl down, Ctrl up, Shift down, Shift up, Caps Lock down, respectively. That could possibly be used to maintain the shift mask ahead of an ASCII key press.

This still leaves how to turn on / off the LED. It doesn't just do it itself inside the keyboard. Presumably via serial input to the keyboard.

The first thing to try is each single byte one at a time per second. Often, in four minutes the command structure becomes clear. In this case, nothing happens.

Next I tried sending random bytes at higher speed just to see if anything ever happens. And, indeed, the LED starts flashing, but not very fast.

Hook up the scope to the register output that drives the LED and trigger when it goes on with another probe connected to the serial signal. This shows that most of the time the LED turns on with 16 and goes off with 11, with a few other cases in the same range. Narrowing the random space shows that it's the 2 bit that controls Caps Lock. I imagine the code is designed to handle a mask of up to 3 LEDs that way.

But just sending such bytes when the keyboard is idle still does nothing, as it did in the original byte scan.

Maybe the baud rate isn't quite right. Measure the timing of serial signals that the keyboard sends and they are very close to 9600 baud. The 8049 will be doing this without the benefit of a UART, so the programmer will have to design the timing carefully. But presumably they did it symmetrically. The ALE pin which shows the MCU's cycle time matches the 5.71MHz oscillator.

Maybe there is an issue with signal strength and pull-ups. Switch to measuring not the serial output from the ATMega32U4, but the /INT pin on the 8049, which goes through a 7414 inverter a couple times. And that is the same, too.

Maybe the firmware doesn't enable interrupts all the time. Since the LED command is idempotent, just send it all the time, like every 10 milliseconds. And, yes, that works.

Equally interestingly, in the process of trying random bytes, I discovered that sometimes the keyboard got into a mode where instead of sending two bytes shift + ASCII, it sent one byte of raw key code, with the high bit indicating key up. So this keyboard actually does have the ability to do that, which makes remapping for modern use significantly more flexible. Also that the keyboard sometimes sends FF 44 in response to some command.

With a more reliable way of sending commands now, it is possible to determine that 10 (hex A) turns on raw mode and 9 turns it off. And that 8 elicits the answerback.

It occurs to me that this raw mode might just be for QC, rather than part of the released interface. But since it seems to be the basic serial receive that if tricky, and that is definitely needed for the Caps Lock LED, I am not sure.

Since the connector is different, a new converter is needed.

: nmb-116535-converter.jpg (366.65 KiB) Viewed 4779 times

Building this seems to uncover a bug in the raw mapping: both Del and keypad-period send 53.

If the 8049 were socketed, I probably would have pulled it out sooner, since that only risks bent pins. Desoldering has somewhat greater risks of damage to the PCB and introduces yet another variable into the debugging. But now that it is basically working, it seems worth confirming that way. And, indeed, bytes 70A and 767 both contain 53.

Reviewing the disassembly shows a few more commands, evidently to control soft caps lock and do some dynamic key mapping. It also confirms that the cycle timing for serial receive matches that for serial transmit. And that the timer interrupt and external interrupt seem to never be enabled at the same time. Consequently, there are periods where the keyboard isn't handling serial receive. Most of the time, the repeating the command trick seems to work fine, though a character typed immediately after plugging in the keyboard is sometimes sent as ASCII (which the converter now ignores).

MMcM · 25 Apr 2021, 21:15

jsheradin wrote: ↑
28 Mar 2021, 19:39
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.

The photo isn't quite clear enough to make out what the chips other than the MCU are, or where the traces go. But it should be straightforward to determine whether a given pin is input or output (or both). That helps narrow down the search.

If nothing is working, then the next step might be to desolder the 8049 (or just pull it out, if socketed) and disassemble it.

Al Kossow · 16 Mar 2022, 05:12

I've been working on decoding the ADDS protocol recently
https://twitter.com/bitsavers/status/15 ... 2222430217

I'd be really interested in dumps of the ADDS ANSI and 1010 microcontrollers, which I currently don't have on bitsavers under adds/keyboards

ADDS mode requires a 26uS polling pulse from the terminal. The very first thing sent by the terminal appears to be a pair of pulses which I think makes the keyboard return a keyboard type.

TheInverseKey · 16 Mar 2022, 05:55

Spoiler:

What keyboard are you referencing for the ADDS ANSI?

Is it the ADDS PC+?

https://sites.google.com/view/vintkeys- ... DS_PC_PLUS

Al Kossow · 16 Mar 2022, 17:22

ADDS NMB with ANSI layout instead of ASCII, jumperable ADDS or AT
3413-k455-v001 discussed here
viewtopic.php?f=62&t=20868

If it isn't generally known, Cindy is out of the surplus business now...

Also, I'm the person who runs bitsavers. I do a lot of work with the MAME
team to emulate terminals, so I'm very interested in archiving keyboard firmware
and disassemblies, since the emulations include fully emulated keyboards when
the firmware is available.

TheInverseKey · 16 Mar 2022, 23:30

Spoiler:

Ahh, the ADDS 220VT keyboard. I still have this one on hand but I lack the hardware to dump the keyboard ROM. Feel free to reach out if you need additional information.

MMcM · 18 Mar 2022, 01:17

Al Kossow wrote: ↑
16 Mar 2022, 05:12
I've been working on decoding the ADDS protocol recently

Maybe not the same protocol, but did you see this? Code for that is here.

I see that you have uploaded the ADDS ASCII firmware to Bitsavers (thanks), so reading that (or looking at traces where a real terminal is connected) should be enough to work out how to control the LEDs, too.

Al Kossow · 18 Mar 2022, 22:30

I just added a different revision of the VP60+ kb to bitsavers with a firmware dump
It appears to be an earlier 2-board version
http://bitsavers.org/pdf/adds/keyboards ... 0+_2-board