🚀 go-pugleaf

hns...@sirius.com (Ron Hunsinger) writes:

>sla...@hearsay.demon.juuuunkguard.co.uk (Simon Slavin) wrote:

>> luc...@null.net (Luc Van der Veken) wrote:
 
>> > What terminal was it again that needed a CR, an LF and x NULs in order
>> > not to eat the first x characters of the next line?
 
>> Many teletypes -- unless they'd just been tuned by an engineer.
>> 'x' is defined as an integer varying between 1 and 4, depending
>> on how badly-adjusted and how hot the transport mechanism was.
 
>> If you need to set it to more than 4, you're probably wearing a
>> hole in some rubber part and should stop using that machine
>> before it explodes.

>C'mon! It had nothing to do with adjusting the machine. It takes time for
>the print head to return to the left margin, and if you try to print
>anything during that time, it'll print in the wrong place.

Au contraire: it had a lot to do with adjustment.  The mechanics of
the carriage return function had two phases: the high-speed flyback
of the carriage itself and the cushioning of the mechanism as it neared
the left margin.  Of course, if you had a high data speed compared to
the time required to return the carriage from wherever it might be
on the line you would get what was called "printing in flight" as
the character was impressed on the paper while the carriage was still
in motion, but a far more common problem was that the dashpot would
slow the return too much (or even stop it short of the left margin)
and the next character, intended to be printed in column one, would
appear well to the right of its proper position.  If you were lucky
the characters in the first two print positions were just closer
than they should have been, but it wasn't unknown for the two to
overlap enough to render them illegible, especially on the third-
hand pre-yellowed high-acid newsprint that was sold as "Teletype paper".

>Oddly, time fill continued to be important even with 'glass teletypes',
>even though they had no moving parts (except the keyboard). That's because
>some operations (clear screen, erase to end of line, etc.) required
>shuffling data around in RAM, and you could overrun your input buffer
>during this time. I've seen up to 10 NULs being required after a FF (which
>did a clear screen) on a Burroughs TD800, for example.

Yup...I ran into that problem with the late, unlamented Hazeltine Esprit II
terminals.  The original models disabled the XON/XOFF flow control 
logic at any speed other than 19.2 kbps, a "feature" that was quite
poorly documented.  At my shop (which used the Esprit II terminals with
the Yale ASCII (aka "Series/1") system to permit the use of common glass
TTY terminals with IBM mainframes) we used 9600 as the internal standard
speed and had all sorts of screen corruption problems until I discovered
that a design change had added a *second* DIP switch setting for 9600
bps that *did* implement flow control to allow the terminal to backpressure
the network.  Of course, the documented setting for 9600 bps still didn't
enable flow control; you had to know about the new and quite unobvious
setting.

We cussed that silly terminal design a lot, but I always made it a point
to remember that it could have been worse: we could have had DEC VT-50
(*NOT* VT52) displays instead.  My PPOE was infested with VT50 boxes
and just about anything would have been an improvement.

Joe Morris