vt100 terminfo with padding for an actual vt100?

[Peter Coghlan]

Warner Losh wrote:
>On Mon, Sep 5, 2016 at 10:30 AM, Peter Coghlan <cctalk at beyondthepale.ie> wrote:
>>>
>>> The usual answer, from back in the day, was to make sure hardware flow
>>> control was on and working at higher speeds. If you don't have that,
>>> you are going to lose > 9600 baud. I spent way too much time pulling
>>> fat cable to enable this after we'd wired the building with 3-wire
>>> cable for the VT52's and cute 'headphone' plug-in jacks back in my
>>> high school days...
>>>
>>
>> Generally, DEC didn't have hardware flow control at that time because it was
>> not in the standard.  I'm pretty sure there was no hardware flow control
>> available on the VT100.  It used XON/XOFF.
>
> I may be misremembering when we did this: with the VT100, VT102 or VT220's.
>

I may be misremembering too but my feeling is that it was much later on than
that even when DEC only reluctantly began to offer RTS/CTS hardware flow
control on terminal servers in order to support "high speed" async modems.

As far as I recall, big bunches of serial ports on a VAX etc had gone away
in favour of network attached terminal servers before that time and I don't
think the directly attached serial ports ever provided hardware flow control.
They could optionally provide "modem control" though, in that they could
signal a modem to hang up and the modem could signal the machine that a
connection had been established or gone away.

I had a look in the VT102 guide and it explicitly says that there are only
three ways of avoiding buffer overruns - XON/XOFF, fill characters and using
a lower speed.

On the other hand, it also says that the VT102 printer port can respond to DSR
being dropped by stopping sending characters to it.  It suggests that the
printer can drop DTR when it's buffers are full and this should be wired to
DSR on the terminal printer port so there is hardware flow control available
there at least.

Regards,
Peter Coghlan.