vt100 terminfo with padding for an actual vt100?

[Paul Koning]

> On Sep 4, 2016, at 8:10 PM, Fritz Mueller <fritzm at fritzm.org> wrote:
> 
> Hi all —
> 
> I’m trying to run a real-deal vt100 on a serial port connected to Linux (Xubunto 16.04).  I’ve got this working *pretty* well, but it looks like the padding values in the default vt100 terminfo entry are not quite correct — when running the vt100 at 9600 I still get occasional garbage characters on the screen, and 19200 is a hopeless mess.

19200?  I didn't think the VT100 supported that.

You've got to be careful with that setting, even on devices that claim to do it.  When it first appeared, it was often a "just barely possible" setting on the clock generator, with an actual bit rate off a couple of percent from the correct value.  If both ends used the same clock generators, no problem of course.  But if one end uses an accurate one, you may get framing errors.

> I did figure out that if the terminfo contains “xon”, the non-mandatory padding values in the terminfo are disregarded.  Removing this, then disabling xon/xoff on both the vt100 and the tty device actually produces *better* results — apparently the turnaround on xon/xoff isn’t quite fast enough to keep the terminal from being swamped at higher baud rates, and padding actually works better.  But tracking down the source for the default vt100 entry turned up a comment that admits that the padding values there are a total guess. :-( 

I have never heard of "padding" for any DEC video terminals other than the VT05.  And I have never seen messed up characters at 9600 baud.  

Flow control is by XON/XOFF, and the implementation has to react promptly to XOFF.  If you're seeing lost characters, it may be that XOFF processing in your host is too slow, either because its terminal driver is poor, or because the converter used introduces too much delay.

On the other hand, flow control issues do not result in "garbage" characters.  The only way you'd get what looks like garbage is if escape sequences are corrupted so a portion of that sequence is mistaken for text.  If you see garbage in a full screen editor, that could be the reason.  On the other hand, if you're just sending a large document to the screen and you're seeing garbage, flow control is not the cause.

Earlier on there was some discussion about modern interface devices with non-compliant "RS232" transceivers.  If your RS232 output is marginal, that could cause garbage.  If the clocks are off, ditto.  An oscilloscope could be used to test both those theories.

	paul