5 Sep
2016
5 Sep
'16
1:05 p.m.
Warner Losh wrote:
On Mon, Sep 5, 2016 at 10:30 AM, Peter Coghlan
<cctalk at beyondthepale.ie> wrote:
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.
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.