27 Feb
2013
27 Feb
'13
2:02 a.m.
The VT100 doesn't need padd characters IIRC (VT05 and VT52 definitely
do), but it uses a signalling scheme to tell the host that it's
internal buffer is full. This signalling scheme can be either in the
hardware signalling (DTR/CTS) or it can be XON/XOFF (DC1/DC3) control
characters in the data stream.
According to my VT102 manual, DTR is only turned off when the terminal is
offline or performing a line disconnect. It doesn't seem to turn off DTR or
any other signal in response to the input buffer becoming full.
Under "Input Buffer Overflow Prevention", it goes on to say that there are
three methods of input buffer overflow prevention and lists XON/XOFF, fill
characters and low speed operation.
A table shows the requirement for fill characters for various functions at
various baud rates. It suggests that all functions require at least one fill
character (null) at 9600 baud, even when not in smooth scroll mode.
Regards,
Peter Coghlan
27 Feb
27 Feb
9:27 a.m.
On Wed, Feb 27, 2013 at 5:02 AM, Peter Coghlan <cctech at beyondthepale.ie> wrote:
Hardware flow control in the DEC world (and many other places) is commonly
RTS/CTS (Request To Send, Clear To Send).
DTR (Data Terminal Ready) is, as you say, for indicating the device (terminal)
is operational and on-line. I won't say nobody has ever done something
"creative" with that signal, but IME, when you power up a terminal
or when you open a serial port on a computer, DTR asserts after all
the initialization stuff is done and the device is good to go.
The VT100
doesn't need padd characters IIRC (VT05 and VT52 definitely
do), but it uses a signalling scheme to tell the host that it's
internal buffer is full. This signalling scheme can be either in the
hardware signalling (DTR/CTS) or it can be XON/XOFF (DC1/DC3) control
characters in the data stream.
According to my VT102 manual, DTR is only turned off when the terminal is
offline or performing a line disconnect. It doesn't seem to turn off DTR or
any other signal in response to the input buffer becoming full. Under "Input Buffer Overflow Prevention", it
goes on to say that there are
three methods of input buffer overflow prevention and lists XON/XOFF, fill
characters and low speed operation.
Yep.
A table shows the requirement for fill characters for
various functions at
various baud rates. It suggests that all functions require at least one fill
character (null) at 9600 baud, even when not in smooth scroll mode.
Back in the day when I used real DEC terminals 8-10 hrs a day,
every day, we ran them at 9600 baud, jump scroll, no fill chars,
with no problems, but we were feeding them from a slow VAX
(11/730 or 11/750) or a medium-grade PDP-11 (11/24 or 11/34,
usually). There's no way we were saturating the line with that
equipment, in that environment.
Where we _did_ have problems is 9600 baud connections for file
transfer between machines. Notably, we had to ensure flow-control
(hardware or software) was on and working to successfully Kermit
files between our MicroVAX and 11/750 (we had Emulex
serial cards on our 11/750 with DMA capability on transmission
but I don't think there was even a 3-char silo on input - one
received character, one interrupt to handle. Humans didn't
type fast enough to cause problems, but Kermit could spew
plenty fast enough to make either end choke).
-ethan
10:13 a.m.
On Wed, Feb 27, 2013 at 5:02 AM, Peter Coghlan
<cctech at beyondthepale.ie> wrote:
Hardware flow
control in the DEC world (and many other places) is commonly
RTS/CTS (Request To Send, Clear To Send).
Generally DEC systems used xon/off.
Cable lengths can be a factor as well as bad grounds between units (term
and system)
but cables have to be long for that to take effect (50ft or more).
Also the Vt100 was 8080 (later Vt102 was 8085) clones used everything on
earth.
The Vt100 had little hardware help for IO and video so the highest cost
operation was
anything that did screen controls (ansi escapes) as they were multiple
cars and if the
buffer was flodded before the escape was processed havoc would reign.
There two tricks to help, one was slow the baud rate to 4800 or 2400,
also adding
nulls could help save for they could still crush the buffer. The other
was tho switch the
terminal to Vt52 mode (assuming the apps could handle that). Vt52
processing had lower
overhead though they were less versatile.
with all that said, it also relies on the PC/platform hosting the
emulation where if that doesn't
support hardware flow control then you plain can't use it. Same for
software flow control
especially if the host has latency in its response and also has large
buffers.. That means by
time the emulated 11 gets the xoff the terminal may be crushed.
Allison
The VT100
doesn't need padd characters IIRC (VT05 and VT52 definitely
do), but it uses a signalling scheme to tell the host that it's
internal buffer is full. This signalling scheme can be either in the
hardware signalling (DTR/CTS) or it can be XON/XOFF (DC1/DC3) control
characters in the data stream.
According to my VT102 manual, DTR is only turned off when the terminal is
offline or performing a line disconnect. It doesn't seem to turn off DTR or
any other signal in response to the input buffer becoming full. 
12:57 p.m.
In article <CAALmimkfj=h8BwmUsAeRHc_PmjOY8Puuq8D91ibNzJjAGmPE1A at mail.gmail.com>,
Ethan Dicks <ethan.dicks at gmail.com> writes:
Hardware flow control in the DEC world (and many other
places) is commonly
RTS/CTS (Request To Send, Clear To Send).
Another mistake on my part, sorry :)
I meant RTS/CTS.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
1:06 p.m.
On Wed, Feb 27, 2013 at 12:57 PM, Richard <legalize at xmission.com> wrote:
And what good will that do for you on a real VT100?
http://manx.classiccmp.org/mirror/vt100.net/docs/vt100-ug/chapter2.html#S2.…
Request to Send (from VT100) ? Pin 4
Asserted at all times when terminal is powered up.
Clear to Send (to VT100) ? Pin 5
Ignored at all times.
Hardware flow control in the DEC world (and many
other places) is commonly
RTS/CTS (Request To Send, Clear To Send).
Another mistake on my part, sorry :)
I meant RTS/CTS.
2:18 p.m.
Dear all, please consider RTS/CTS/DTR nit sufficiently picked. Thanks.
--
"The Direct3D Graphics Pipeline" free book
<http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
2:22 p.m.
Back to possible ways of solving the original poster's question- Any
chance you have a terminal server, for example a Digi PortServer? Or
have any hobby budget to pick one up? Mine cost me around $35.
As an experiment I just set up SIMH V3.9-0 on a Windows 8 system
running RT-11 Version 5.3 and connected a real CIT-101 (VT100 clone)
to the SIMH console through a Digi PortServer 16. (Too lazy to dig out
my real VT100 right now).
On SIMH I did this:
sim> set console telnet=1173
Listening on port 1173 (socket 180)
Then on the real CIT-101 at the PortServer prompt I did this:
#> telnet 192.168.1.103 1173
Then back on SIMH I did this:
sim> boot rl0
And then the real CIT-101 terminal was connected to the SIMH console
running RT-11.
On the real CIT-101 terminal in the SET-UP B screen Auto XON-XOFF was
enabled in the Group 2 Position 4 bit, which is the default.
On the Digi PortServer if I disabled its XON/XOFF flow control for
output data and output a large amount of text to the CIT-101 terminal
(for example "TYPE DU.MAC") I would get some of the buffer overflow
error characters displayed on the CIT-101 terminal. If I enabled
XON/XOFF flow control on the PortServer and output the same amount of
text I wouldn't get any of the buffer overflow error characters and
the OFC Output Flow Control LED on the PortServer would blink at times
indicated that the output was being flow controlled.
So with your real VT100 terminal connected to a SIMH console you most
likely need XON/XOFF flow control at the far end serial port where the
terminal is directly connected and not flow control running in the
emulated CPU software. I was able to get the far end serial port
XON/XOFF flow control by connecting the real terminal to a port server
which was doing the flow control. If your real terminal is connected
to a Linux console I don't know enough about that to know whether or
not or how you can enable XON/XOFF flow control there.
-Glen
4099
days inactive
4099
days old
6 comments
5 participants
participants (5)
-
ajp166＠verizon.net -
cctech＠beyondthepale.ie -
ethan.dicks＠gmail.com -
glen.slick＠gmail.com -
legalize＠xmission.com