• Please review our updated Terms and Rules here

Heathkit H19A terminal doesn't work with VT100 terminfo on Linux

nerdhouse

Member
Joined
May 11, 2022
Messages
40
Location
WA
I was wondering if anyone had any experience getting an H19 or Z19 working well with Linux.

Currently, I'm getting a lot of garbage on the screen when I attempt to run some programs, and then I have to go into offline mode, type <ESC>[z to reset the terminal, go back online, and then redraw the screen to get it back to normal.

The dip switches in the terminal are set as follows:

S402: 11000100
  • discard past end of line
  • no auto LF on CR
  • no auto CR on LF
S401: 00110001
  • 9600 baud
  • no parity
  • odd parity
  • normal parity
  • full duplex

I'm starting my agetty service with

Bash:
GETTY_ARGS="-L"
if [ -x /sbin/agetty -o -x /bin/agetty ]; then
    # util-linux specific settings
    GETTY_ARGS="${GETTY_ARGS} -8"
fi

BAUD_RATE=9600
TERM_NAME=vt100

but I've also tried TERM_NAME=ansi and had even less success.

I've tried running programs with and without screen running, and have had various levels of success, but always some issues.

When launching screen, vim, or emacs for instance, the cursor never really moves past the current line and draws a bunch of garbage. If I then reset the terminal and redraw the program it will work, until it uses some incompatible control code, and then it gets full of garbage again.

Sometimes when screen reports something like This IS window 1 (zsh). in reverse video, reverse video then gets stuck on, and I have to manually disable it in offline mode.

I did find a compiled terminfo file for H19/Z19 here, and gave it a try, but it worked even worse.

I know this is a lot of info here, but if anyone has any advice for getting this terminal working well with Linux, please let me know.
 
The traditional environment variable to set the terminal type is "TERM". I don't know that "TERM_NAME" is supported, unless that is something specific to your getty startup script. Note that "TERM" generally needs to be exported (to all child processes) in order to be useful.

As Al mentioned, "vt52" often works for an H19 Terminal.

Also, installing additional terminfo entries can be tricky - make certain it truly is being selected and used. The program 'tput', combined with something like "cat -v", can be used to check that your terminal selection is effective. For example, on my Linux system (Ubuntu) I have both "vt52" and a (different) "h19" entry (following output has been cleaned up):
Code:
$ TERM=vt52 tput clear | cat -v
^[H^[J
$ TERM=ansi tput clear | cat -v
^[[H^[[J
$ TERM=h19 tput clear | cat -v
^[E
$ tput clear | cat -v
^[[H^[[2J^[[3J
The last example shows my default TERM setting of "xterm". Note that the "vt52" clear screen codes do work on an H19, I'm not sure if the "h19" clear screen sequence works on a VT52.
 
H19s emulate a VT52
Oof. That would do it. I'll give that a try and see if it resolves the issues.

Also, installing additional terminfo entries can be tricky - make certain it truly is being selected and used.
FYI, you can use infocmp on linux to check what terminfo is being used by your current terminal. It even gives you helpful errors saying where it looked for the terminfo file. (I've just been installing all of mine in the ~/.terminfo directory and that seems to work well.)

That | cat -v trick is neat though. I will definitely use it to troubleshoot stuff.
 
Last edited:
Okay, I've tried using vt52 instead of vt100, and it somehow works worse?

Not sure why that would be. With TERM=vt100 emacs, emacs seems to work without any issues. With TERM=vt52 emacs, the cursor never moves off of the line the cursor started on. emacs half works with TERM=ansi, but works so much better when it thinks the terminal is a VT100. vim doesn't work correctly with any of them.

Even something as simple as TERM=vt52 clear does not work at all, but doing TERM=vt100 clear works perfectly. Same thing with tput clear.

I've also had no luck setting the terminal in "Heath mode" and using the h19 terminfo I have. durgadas311, if you could upload your h19 terminfo file somewhere, or direct me to where you found it, I'd appreciate that.
 
Last edited:
That is starting to sound like your H19 is set to default to ANSI mode, not Zenith (vt52-like). Your S402 settings seem to indicate Zenith mode, provided you are running in a 50Hz environment - does "WA" stand for West Australia (vs. WA = Washington state, US)? One thing to note about terminfo is that there is an init/deinit (ti/te?) sequence defined, which may change the mode of the H19 (ANSI vs. Zenith). I am not all that familiar with terminfo, having cut my teeth on termcap and not having to do much with terminfo.

I'm not sure where my h19 terminfo came from, I'll see if I can extract it. I'll see if I can track that down. If I wrote it myself, it may not be complete. I used it for my simulations, and while my H19 emulator is pretty complete I may not have tested it. I'm not an emacs user, so 'vi' may use the terminal differently.
 
That is starting to sound like your H19 is set to default to ANSI mode, not Zenith (vt52-like). Your S402 settings seem to indicate Zenith mode, provided you are running in a 50Hz environment - does "WA" stand for West Australia (vs. WA = Washington state, US)? One thing to note about terminfo is that there is an init/deinit (ti/te?) sequence defined, which may change the mode of the H19 (ANSI vs. Zenith). I am not all that familiar with terminfo, having cut my teeth on termcap and not having to do much with terminfo.

I'm not sure where my h19 terminfo came from, I'll see if I can extract it. I'll see if I can track that down. If I wrote it myself, it may not be complete. I used it for my simulations, and while my H19 emulator is pretty complete I may not have tested it. I'm not an emacs user, so 'vi' may use the terminal differently.
I'm in the US. I have an H19A, and it's running at 60 Hz, and is in ANSI mode, but I've tried it in both ANSI and Heath modes.

I think there are differences between the H19A, H19 and Z19 configuration stuff, I really need to scan my manuals and put them on archive.org.

Here are the relevant sections of my manual:
S402:
S402.jpg
I have 11000100 set.

S401:
S401_1.jpg
S401_2.jpg
I have 00110001

It really feels like TERM_NAME=vt100 is working perfectly, except for a few control sequences, guessing maybe standout/bold and some sort of screen scrolling thing. other than that it works fine. TERM_NAME=vt52 doesn't seem to work at all, in either ANSI or Heath mode.
 
Last edited:
What they call "ANSI" mode in the manual is an older spec that predates what we usually think of as an "ANSI" terminal.

I've had most luck with Heath mode and the H19 termcap entry. Starting screen as soon as you log in helps get rid of some of the glitches.

It works better with a "real" 8250/16550 serial port than with a USB-serial dongle. I suspect that the USB-serial dongles I've tried don't implement hardware flow control exactly just-so, because it sometimes drops characters at 9600 baud through every usb-serial dongle I've tried. Doesn't do that when hooked up to my Prolinea's real serial port though.

One of the projects on my list is to stick an ESP8266 inside of mine, between the board and the serial port. I'll program it so you can connect to tcp sockets over the wifi or to the back panel connector via softwareserial. Part of it will be some code that interprets vt100 control codes and converts them to heath codes, and hopefully do it better than the H11 termcap entry. But that's kind of far down on the project list. :(
 
What they call "ANSI" mode in the manual is an older spec that predates what we usually think of as an "ANSI" terminal.

I've had most luck with Heath mode and the H19 termcap entry. Starting screen as soon as you log in helps get rid of some of the glitches.

It works better with a "real" 8250/16550 serial port than with a USB-serial dongle. I suspect that the USB-serial dongles I've tried don't implement hardware flow control exactly just-so, because it sometimes drops characters at 9600 baud through every usb-serial dongle I've tried. Doesn't do that when hooked up to my Prolinea's real serial port though.

One of the projects on my list is to stick an ESP8266 inside of mine, between the board and the serial port. I'll program it so you can connect to tcp sockets over the wifi or to the back panel connector via softwareserial. Part of it will be some code that interprets vt100 control codes and converts them to heath codes, and hopefully do it better than the H11 termcap entry. But that's kind of far down on the project list. :(
Maybe you have a different h19 termcap entry than I do (mine is from a Debian install)? Using Heath mode and the h19 termcap entry makes my terminal work way worse, and screen doesn't work at all.

I'm really interested in that project of yours, and would be happy to help/contribute if you wanted. I was thinking about doing something similar with just a raspberry pi sitting between the terminal and host.
 
Last edited:
Oh, I see, you are showing the switch settings LSB-first, i.e. 01234567 as opposed to 76543210. So, your H19 powers-up in ANSI mode. As noted, Heath/Zenith ANSI mode is not exactly VT100 nor is it modern ANSI.
My h19 termcap dumps (infocmp -I) as:
Code:
#       Reconstructed via infocmp from file: /usr/share/terminfo/h/h19
h19|heath|h19-b|heathkit|heath-19|z19|zenith|heathkit h19,
        am, OTbs, hs, mir, msgr, eslok,
        cols#80, it#8, lines#24,
        acsc=+h.kaiggjdkclfmenbozqas{tvutvuwsx`~\^, bel=^G,
        cr=\r, clear=\EE, el=\EK, ed=\EJ,
        cup=\EY%p1%' '%+%c%p2%' '%+%c, cud1=\EB, home=\EH,
        cub1=^H, cnorm=\Ey4, cuf1=\EC, cuu1=\EA, cvvis=\Ex4,
        dch1=\EN, smacs=\EF, smir=\E@, smso=\Ep, rmacs=\EG, rmir=\EO,
        rmso=\Eq, fsl=\Ek\Ey5, ip=$<1.5/>, kbs=^H, kcud1=\EB,
        kf1=\ES, kf2=\ET, kf3=\EU, kf4=\EV, kf5=\EW, kf6=\EP, kf7=\EQ,
        kf8=\ER, khome=\EH, kcub1=\ED, kcuf1=\EC, kcuu1=\EA,
        lf6=blue, lf7=red, lf8=white, ind=\n, ri=\EI, ht=^I,
        tsl=\Ej\Ex5\EY8%p1%' '%+%c\Eo\Eo,
I see that this is identical to the h19 terminfo you posted (checksums are the same). This terminfo entry is for "Zenith Mode". Also, this h19 entry uses sequences that are not available in a (plain) VT52.

Maybe double-check your parity setting (both H19 and getty)?
 
Sigh. I don't know what I'm doing wrong. Trying different parity options, no changes. The screen won't even clear when term is set to z19.
 
It works better with a "real" 8250/16550 serial port than with a USB-serial dongle. I suspect that the USB-serial dongles I've tried don't implement hardware flow control exactly just-so, because it sometimes drops characters at 9600 baud through every usb-serial dongle I've tried. Doesn't do that when hooked up to my Prolinea's real serial port though.
FYI, I got one of these and it works great. It doesn't drop any characters at 9600 baud, and seems to work perfectly at 19200 baud too.
 
IIRC there is a table of the Heath mode terminal control codes in the manual. What happens of you echo them directly to the serial port? Does the screen clear then? Does throttling it back to 4800 baud help any?

These things are really just a z80 computer with very little RAM and no disk drive. It uses a regular 8250 UART (which surprises me that you are able to get a reliable 19.2k out of, although maybe if your hardware flow control is working right that would explain it) and a regular ROM to hold the firmware. I've thought about trying to replace the 8250 with a 16550 and mod the ROM to enable the FIFO and change the serial clock divider and see if I could get 38.4 or more out of mine. But considering the dropped characters I get when I saturate the serial line at 9600 with serial dongles with sketchy flow control, I suspect that the CPU is barely fast enough to keep up as it is. :p

I have the Zenith version, for what it's worth, but I am 95% sure that they are exactly the same.
 
... draws a bunch of garbage. If I then reset the terminal and redraw the program it will work, until it uses some incompatible control code, and then it gets full of garbage again.

I missed this before. That sure sounds like dropped bits to me. Try it at 4800 baud and see what happens?
 
The H19 and Z19 are the same machine, barring any modifications made by vendors or end-users. I used an H89 (which is an H19 plus a Z80 computer built-in) at 19200 without issues - as I recall. But, that was a 2.048MHz Z80 computer driving the H19, which may not have been able to achieve the full 19200. It was also direct-connect 8250-to-8250 (about 3" of wire) and included the hardware handshake.

Note, dropping bits would be a sign of baud clock issues (mismatch). Dropping bytes would indicate problems keeping up on either end. There are Zenith ESC sequences that change the baud rate, so it is possible (but unlikely) that something is changing the H19 baud incorrectly. Can you tell what vintage of H19 you have? I believe the earlier models may have had issues at 19200. But, it seems your problems don't depend on baud?

I'm not sure what it would take for me to setup a similar environment with my H19 emulator, probably requires installing and configuring telnet server - if that still exists. My emulator can save the output to a file, so if I could reproduce the same issue then I could see what is being sent to the H19.

I would suggest setting the H19 dipswitches to their defaults as described in the manual, as that ensures you are running in the Zenith mode. Then use the "h19" terminfo and see what works and perhaps what doesn't. I don't see anything obviously weird in the terminfo entry, but perhaps one of those is sending codes to the H19 to mess it up.
 
IIRC there is a table of the Heath mode terminal control codes in the manual. What happens of you echo them directly to the serial port? Does the screen clear then? Does throttling it back to 4800 baud help any?
The Heath control codes work perfectly fine when I input them manually in offline mode.

I missed this before. That sure sounds like dropped bits to me. Try it at 4800 baud and see what happens?
I've actually tried it at 4800 and even lower speeds and the error is the same. It's not a persistent error, it only happens when starting certain programs. For instance, starting screen or vim, I get a bad control sequence, things get garbled, then I reset the terminal with the escape sequence in offline mode, pop back online, and redraw the screen, and things work again. I don't get garbage when cat-ing a big file for instance, it's only when certain control codes get sent to the terminal, though I haven't been able to pinpoint what codes specifically are causing the issue. emacs doesn't send them though, because it works nearly perfectly.

But, it seems your problems don't depend on baud?
Nope, I get the same garbled characters caused by certain programs which must be using unsupported control codes.

I would suggest setting the H19 dipswitches to their defaults as described in the manual, as that ensures you are running in the Zenith mode. Then use the "h19" terminfo and see what works and perhaps what doesn't. I don't see anything obviously weird in the terminfo entry, but perhaps one of those is sending codes to the H19 to mess it up.
I did try this, and it's still not working correctly unfortunately. I even turned on the key beep back on lol.

When i run screen, I get a bonus J and K at the beginning and end of my prompt. I assume these are from the "Erase to End of Page" control sequence and "Erase to End of Line" sequence which are not working correctly (although they are correct codes). If I go into offline mode, and hit ESC J or ESC K they both work correctly. The screen also does not scroll down when I get to the final line. So weird.

My prompt does look and work correctly in ANSI mode on the terminal and VT100 mode in agetty. the clear command works perfectly. the screen scrolls correctly, etc. none of that works right in Heath mode.
 
Last edited:
Note that ANSI, XTERM, VT100 all have some similarities to VT52 (and H19). For example, H19 "erase to end of page" is ESC J while the others use ESC [ J. Thus, if you send the ANSI sequence to an H19 it will "gobble" the first character after ESC and then print the following character as regular data for the screen(Actually, in Zenith mode the ESC [ means "enter hold screen mode" so it is not exactly being ignored). That is, sending ESC [ J to an H19 (in Zenith mode) will result in a 'J' appearing on the screen. If I understand what you are saying, it would seem that your Linux program is sending ANSI/VT100/xterm sequences to the H19. So, maybe your Linux setup is not properly selecting the terminal type. Is the TERM environment variable getting set (and exported)?

Note, "hold screen mode" turns off automatic scrolling, essentially doing what "more" or "less" do in Linux.
 
When i run screen, I get a bonus J and K at the beginning and end of my prompt. I assume these are from the "Erase to End of Page" control sequence and "Erase to End of Line" sequence which are not working correctly (although they are correct codes). If I go into offline mode, and hit ESC J or ESC K they both work correctly. The screen also does not scroll down when I get to the final line. So weird.

My prompt does look and work correctly in ANSI mode on the terminal and VT100 mode in agetty. the clear command works perfectly. the screen scrolls correctly, etc. none of that works right in Heath mode.

Do you suppose it's possible that getty is not picking up your term type setting correctly, and defaulting to "ansi" or "linux" or something?

I've only run it out of /etc/inittab. I don't know the ins and outs of making it work right with systemd, unfortunately, which is what I assume you are using. :(
 
That is, sending ESC [ J to an H19 (in Zenith mode) will result in a 'J' appearing on the screen. If I understand what you are saying, it would seem that your Linux program is sending ANSI/VT100/xterm sequences to the H19. So, maybe your Linux setup is not properly selecting the terminal type. Is the TERM environment variable getting set (and exported)?
This is a good point, and you're probably right. Using infocmp shows that I'm using the h19 terminfo, and echo $TERM does too, so I think it's working correctly, but you are right about that being what would show up if it was doing the VT100 style escape codes.
Do you suppose it's possible that getty is not picking up your term type setting correctly, and defaulting to "ansi" or "linux" or something?

I've only run it out of /etc/inittab. I don't know the ins and outs of making it work right with systemd, unfortunately, which is what I assume you are using. :(
I actually use runit on void linux, but agetty runs as a service similar to how it would work with systemd I think. But, like I said above, infocmp and $TERM seem to show the right things, so it seems like it's working. Who knows. I'll mess with it some more, and maybe try using a vm or raspberry pi with a different distro with inittab and see if anything is different.

I appreciate both of your help though. Thanks very much.
 
Yeah man, sorry I can't be more helpful. All I know for sure is: Mine kinda works in Devuan with a FDTI dongle (that supposedly implements hardware handshaking correctly according to the Amazon reviews) but anything faster than 4800 baud starts spamming garbage like you describe when the serial link gets saturated, until I reset the terminal or (sometimes) ^V^O. But at 4800 baud and lower, or at 9600 baud on a machine with a real UART, it works with some cursor movement glitches until I start screen, after which it works correctly for the most part. Mine always drops characters at 19.2k when the serial link is saturated, regardless of the UART on the server side.

Although..... The machine with the real UART is a 486 running Slackware 12. But the terminfo database is so ancient that I can't imagine it's changed since then, at least not in regard to these old boat anchor terminals.....

This is assuming I am remembering correctly. My Z-19 and that 486 are both packed away at the moment.

Do please let us know what you figure out. I wish mine worked right at 19.2k. 9600 baud is just a bit slow for a full-screen editor...
 
Back
Top