> On Sep 4, 2016, at 8:10 PM, Fritz Mueller <[email protected]> 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
