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

[nerdhouse]

I wish mine worked right at 19.2k. 9600 baud is just a bit slow for a full-screen editor...

My understanding is that the reason the machine doesn't technically support 19200 baud because it can't write characters to the screen memory fast enough to keep up, but it has a buffer where data overflows until screen memory is caught up. If the buffer runs out of room, then you will have issues.

I was able to cat a huge text file though without any issues at all, so I'm not really sure why it was working. For things like a text editor, I don't think it should be a problem to run at 19200 since you shouldn't have more than a page of data being sent to the terminal at a time.

Maybe I will make a quick video of mine running at 19200 to show it off lol.

I'm really not that well versed with serial/agetty, but it's possible that the terminal is sending a signal for the host to wait to send more data until the terminal catches up, then it sends a signal asking for more. When I tried to SSH to another machine, then I started losing data, and the machine beeped to let me know it was out of buffer memory.

If that is the case then I imagine it actually is running somewhere in between 9600 and 19200.

It's still super fast for things like ls of big directories and tab completion showing all available options, which is a really big quality of life improvement over 9600 baud.

 

[durgadas311]

I ran an experiment. I setup two USB-RS232 adapters connect via a null-modem. I then started agetty:

# agetty ttyUSB0 9600 h19

and started my H19 emulation on the other end (/dev/ttyUSB1). I logged in and ran 'vi' and everything seems to be working. I don't have 'screen' or 'emacs' installed, so didn't try those. I confirmed that 'vi' was able to use reverse-video correctly and not mess-up the screen, and scrolling, etc, worked. I did not see any issues. I also ran 'top' (for a little while) and saw no problems. This is Ubuntu 20.04.

I believe that Linux will use XON/XOFF for flow control, but I don't recall whether the H19 supports that. Still, I'm not hearing evidence of a flow control issue. You said you still had problems even at slower bauds? My H19 emulator would probably not exhibit flow control issues, but this test should confirm that Linux is capable of handling an H19 terminal as far as screen control codes.

Note, I ran 'agetty' manually - i.e. I "su"ed to root and ran it one-shot from the root shell. I did not try to make a permanent setup, since these serial ports are only temporary. I also did not fine-tune handshake settings.

 

[nerdhouse]

I ran an experiment. I setup two USB-RS232 adapters connect via a null-modem. I then started agetty:

# agetty ttyUSB0 9600 h19

and started my H19 emulation on the other end (/dev/ttyUSB1). I logged in and ran 'vi' and everything seems to be working. I don't have 'screen' or 'emacs' installed, so didn't try those. I confirmed that 'vi' was able to use reverse-video correctly and not mess-up the screen, and scrolling, etc, worked. I did not see any issues. I also ran 'top' (for a little while) and saw no problems. This is Ubuntu 20.04.

I believe that Linux will use XON/XOFF for flow control, but I don't recall whether the H19 supports that. Still, I'm not hearing evidence of a flow control issue. You said you still had problems even at slower bauds? My H19 emulator would probably not exhibit flow control issues, but this test should confirm that Linux is capable of handling an H19 terminal as far as screen control codes.

Note, I ran 'agetty' manually - i.e. I "su"ed to root and ran it one-shot from the root shell. I did not try to make a permanent setup, since these serial ports are only temporary. I also did not fine-tune handshake settings.

AHH!! This didn't work on the laptop I'd been doing everything from, but I dug out an old laptop and it seems to be working perfectly! Or at least as well as it can! I'll have to do some more experimenting, and try to get something more permanent working, but !!! It's working !!!!!

I must be misunderstanding something about the agetty service, or how terminfo/termcap forks. It's all a pretty confusing mess.

Thank you so much!!

EDIT: Even the HOME key is working! What a day to be alive!!

 

[durgadas311]

Note, I only started agetty manually as a convenience for my testing. It is a "one-shot" in this case. Once I logout, the agetty needs to be started again. When setting up as a service (or running from 'init' as done in the old days) it gets restarted automatically. But, it is "just" a program and can be run from any 'root' context.

 

[nerdhouse]

The main remaining issue I've noticed so far is that reverse video isn't being disabled correctly by some programs. mainly tmux, which is kind of unfortunate, since i prefer it to screen. but screen does seem to resolve the issue.

When setting up as a service (or running from 'init' as done in the old days) it gets restarted automatically. But, it is "just" a program and can be run from any 'root' context.

I was having this issue when running agetty manually from my terminal on void linux, but on ubuntu, it works fine.

 

[durgadas311]

Interesting. I was running from a "static" root shell, not 'sudo'. Last time I actually worked with agetty (actually 'getty') was on Unix systems where there was no 'sudo'. Still, there could be issues I suppose, depending on the Liunux distro and how the utils were built. 'sudo' is certainly not the same as a login shell (i.e. "su -"). You can use 'sudo' to spawn a root shell, if your sudo configuration allows it, by "sudo -i". I'm not sure if that forces an interactive shell or whether you can also run a single command that way.

 

[bladamson]

I believe that Linux will use XON/XOFF for flow control, but I don't recall whether the H19 supports that. Still, I'm not hearing evidence of a flow control issue. You said you still had problems even at slower bauds? My H19 emulator would probably not exhibit flow control issues, but this test should confirm that Linux is capable of handling an H19 terminal as far as screen control codes.

I've tried both xon/xoff and rts/cts flow control on mine, and it didn't seem to make any difference as far as the hiccups, as far as I recall.

Come to think of it, I think I may have been using mgetty rather than agetty. Can't remember for sure....

I'm supposed to be picking up another H-19 this coming weekend, so it will be interesting to see if it has the same issues that I've had with my Z-19.

 

[durgadas311]

FYI, there have been a lot of changes over the years to how Unix and Linux handles process hierarchies, "terminal groups", "sessions", etc. If "*getty" is not started in it's own "session", then it may have undesirable side-effects when it does a SIGHUP to the "terminal group" when it exits. The exact behavior in this area has varied over the years, and perhaps even between flavors of Linux. Certainly it depends on how/where the getty has been invoked, too.

 

[nerdhouse]

I've tried both xon/xoff and rts/cts flow control on mine, and it didn't seem to make any difference as far as the hiccups, as far as I recall.

Looking at the h19 terminfo, it actually doesn't have the xon boolean set, which the vt100 terminfo does have.

It's possible that in Heath/Zenith mode, it doesn't actually send the ^S when the buffers are close to full. It works in ANSI mode though, so it might be possible to hack the terminfo to get it working correctly. It's not as simple as just adding the xon boolean though, I tried that, and the terminal hangs. It might just also need to be told what XON looks like. The terminfo man page is very detailed though, so I may do some more reading and report back.

 

[nerdhouse]

FYI, there have been a lot of changes over the years to how Unix and Linux handles process hierarchies, "terminal groups", "sessions", etc. If "*getty" is not started in it's own "session", then it may have undesirable side-effects when it does a SIGHUP to the "terminal group" when it exits. The exact behavior in this area has varied over the years, and perhaps even between flavors of Linux. Certainly it depends on how/where the getty has been invoked, too.

You might find chapter 6 of The Unix Haters Handbook to be funny (and relevant). The whole book is pretty fun overall, but it does have a few dodgy jokes here and there.

I really like *nix personally, but it is interesting to see how much people hated it back when there were a ton of proprietary versions of Unix. It's especially interesting because some of the problems than existed back then were just never really resolved properly, and are still a mess in Linux/BSD today.

 

[durgadas311]

Looking at the h19 terminfo, it actually doesn't have the xon boolean set, which the vt100 terminfo does have.

It's possible that in Heath/Zenith mode, it doesn't actually send the ^S when the buffers are close to full. It works in ANSI mode though, so it might be possible to hack the terminfo to get it working correctly. It's not as simple as just adding the xon boolean though, I tried that, and the terminal hangs. It might just also need to be told what XON looks like. The terminfo man page is very detailed though, so I may do some more reading and report back.

I can see in the H19 firmware that it does do XON/XOFF, but I can't tell easily whether this is an option that can be enabled/disabled. It is not documented in the dipswitches section, nor any ESC sequence. I suspect it is "always on". Note that XON and XOFF have different parity, so if parity is setup wrong (mismatched between terminal and computer) then you can get into situations where XON is recognized but the XOFF is not, leading to a "hang".

Also, I seem to recall that early versions of H19 had issues at 19200, but that later version had mostly "fixed" those. I don't think Zenith ever fully, officially, supported 19200, though. I suspect your H19A would work at 19200 well.

 

[davidrg]

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.

If H19 emulators are of interest, C-Kermit for Windows (formerly Kermit 95) can apparently emulate it - you can grab the current beta from here and the source is on github. I've no idea how strictly it emulates it though - I don't have one so don't have anything to compare it with. There is a debug mode ("set terminal debug on") which will show you all the escape sequences being received which might be handy. I think saw code code for some sort of pass-through mode in there too so CKW can sit between the physical terminal and host and I guess if everything is working CKW and the physical terminal show identical output. Don't recall where I saw it or how to enable it though - might be a build-time option.

 

[nerdhouse]

If H19 emulators are of interest, C-Kermit for Windows (formerly Kermit 95) can apparently emulate it - you can grab the current beta from here and the source is on github. I've no idea how strictly it emulates it though - I don't have one so don't have anything to compare it with. There is a debug mode ("set terminal debug on") which will show you all the escape sequences being received which might be handy. I think saw code code for some sort of pass-through mode in there too so CKW can sit between the physical terminal and host and I guess if everything is working CKW and the physical terminal show identical output. Don't recall where I saw it or how to enable it though - might be a build-time option.
View attachment 1244599

Wow! this looks super useful, and I'll definitely give it a try! Thank you.

 

[davidrg]

Digging through the code and the Kermit 95 manual I think the copy-print function might have been the pass-through mode I saw (or possibly there is another - there is a lot of code). I got out my VT520, set it to emulate a VT320, and hooked it up to my PC with a serial cable and usb-serial widget. I then entered the following commands in the command screen to setup the COM3 as the printer plus the terminal emulator with settings matching what the VT520 was configured for:

set printer /dos-device:com3 /bidirectional /character-set:latin1-iso /flow-control:xon/xof /parity:none /speed:9600
set terminal type vt320
set terminal remote-charset latin1-iso

Then I SSHd somewhere (coming soon once I've fixed the bugs), switched back to the command screen (alt+x) and entered set terminal printer copy, switched back to the terminal (alt+x), and from there the C-Kermit for Windows terminal window and the VT520 matched each other perfectly. What ever I typed on one showed on both. The terminal emulator even runs at the same speed as the attached terminal - htop isn't great at 9600bps. Could be handy if you want to compare CKWs emulation directly to the real thing.

 

[Bruce Tomlin]

because it can't write characters to the screen memory fast enough to keep up

Actually, writing characters to the screen isn't the problem. The problem is scrolling. While the H19 does the sensible thing to scroll by simply changing the CRTC pointer to the first line of the screen, a quick check of the source shows at least two pessimal cases where large chunks of screen data get moved around. I also see moves being done 16 bytes at a time, and one uses unrolled 8080 code instead of LDIR. Even more fun, it looks like the input FIFO is implemented by using LDIR to keep the next byte at the start of the buffer, rather than the more normal circular style buffer.

If you use the "delete line" code, it has to move the actual bytes around in screen memory. For some reason it does this by using LDIR 16 bytes at a time. Then it still has to clear the newly exposed line. The other case is when there is a fixed line 25, it has to move it down in memory every time the screen is scrolled up. There isn't much that can be done about either of these without video hardware that lets you randomly assign lines with a display list, but if you can avoid line 25 mode, that will help.

The code is a bit of a mess by modern standards, and I'm sure it could be optimized somewhat if someone cared enough. Maybe I'll feel like it someday, I have an H19 and a Z80 ICE.

The main remaining issue I've noticed so far is that reverse video isn't being disabled correctly by some programs.

If they're using termcap, maybe that needs to be added to the 'te' string?

I can see in the H19 firmware that it does do XON/XOFF, but I can't tell easily whether this is an option that can be enabled/disabled.

There appears to definitely be no way to disable it.

 

[bladamson]

It would certainly be interesting to write a new firmware. Especially one that properly supported the 16550 uart.

 

[Bruce Tomlin]

It wouldn't be the first new firmware. There's at least three out there which I could find all of thanks to the MAME/MESS project and ROM sites.

 

[bladamson]

Oh neat. I'll have to try some of them and see if it alleviates my glitches.

 

[durgadas311]

There are also good resources associated with the SEBHC google group. One is https://sebhc.github.io/sebhc/software.html.