Morrow MDT-60 / Zenith Z-29 / Heath H-29

[MMcM]

This keyboard supposedly came from a Morrow MDT-60.

MDT-60-case.jpg (1.05 MiB) Viewed 1835 times

I have no reason to doubt that, but as far as I know there is no difference in the keyboard itself between that and a Zenith Z-29 or a Heath H-29. The layout is a bit like a VT100, but tries having the arrow keys poke out from the differently colored function row into the top row of the normally colored keys. It has Alps SKCC Cream switches, so it's still pretty nice to type on.

The controller is an 8021 and it has a 5V regulator. The Service Manual variously says 8V and 9.6V. It doesn't really matter and I'll power it with 12V, because that's what I have here.

MDT-60-top.jpg (1 MiB) Viewed 1835 times

The PCB 12KC138F does not have any other branding.

MDT-60-bottom.jpg (1.41 MiB) Viewed 1835 times

The soldering job isn't great. I don't know whether one soldered in the switches with the Heathkit version or it came already assembled from Japan. It also turns out the F7 key doesn't work on this one, so that'll need to be dealt with at some point.

Besides the attraction of quirky early '80s terminal keyboard design, the Theory of Operation had this tantalizing bit:

The detachable keyboard communicates directly with the terminal CPU through a proprietary 8 bit, bit serial closed loop transmission protocol. There is one signal line out to the keyboard and one signal line returned from the keyboard. Upon an interrupt from a depressed key, a special handshaking routine is executed in firmware that allows the terminal CPU to determine which key has just been pressed on the keyboard. Also the host may transmit certain special status codes to the keyboard to turn on status lights or or beep the beeper.

Powering it without anything other than a scope attached gives this on the transmit line:

MDT-60-startup.png (12.93 KiB) Viewed 1835 times

Which appears to be the keyboard trying hard to get the terminal to notice transitions on the XMIT line. So that aforementioned handshaking needs to be taken care of.

Like the recent TeleVideo board, it has a dedicated RESET line, which activates at the same time as it resets the microcontroller, based on a hard-wired key chord. In this case, SHIFT-BREAK.

So the converter ends up looking very much the same, up to exactly which wire goes where.

MDT-60-converter.jpg (687.49 KiB) Viewed 1835 times

Fortunately, when one bought an H-29, included was a binder with a printout of the Z-29 source code, which someone has scanned.

The designers evidently didn't trust bit-banged RS-232 with the bit width implied by the baud rate. The serial protocol basically acknowledges every bit by toggling the other signal, and so gets delicate when the terminal wants to send a command at the same time as the keyboard is ready to send a key.

As usual, the keyboard controller tries to save work in the terminal by doing a bunch of the ASCII encoding up-front. Most of the ASCII control keys send the corresponding control character: ESC, BACK SPACE, DELETE, RETURN, LINE FEED. But not SPACE and TAB, which are instead encoded like function keys. That is because CTRL-SPACE sends NUL. This probably could have been arrived at successfully by AND'ing, but maybe that didn't fall out of how the CTRL code is arranged. SHIFT-TAB variously sends ESC - or ESC [ Z, so that would indeed have been hard to arrange in the controller.

The other function keys also send different codes from the terminal to the host when CTRL or SHIFT is applied. So they each send from the keyboard to the terminal a non-ASCII code with the eighth bit set, further arranged so that two of the bits indicate which of the two shift keys is pressed. But then the encoding runs out of bits, so the F1 - F9 keys need to be two-byte sequences with a preceding ACCESS escape code. I suppose this was deemed more compact than the simpler alternative of always sending two bytes, the first of which gave the shifts.

It is possible to undo much of this to produce a minimally functional QMK implementation.