6 Sep
2016
6 Sep
'16
8:07 a.m.
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