5 Sep
2017
5 Sep
'17
8:55 p.m.
On 9/3/17, Pete Turnbull <pete(a)dunnington.plus.com> wrote:
That's not right. Yes, the ASR33 runs at 110 baud (10cps), but all -
including mine and those of my friends - take more like half a dozen
character times to perform a CR from the right hand side. Moreover, the
time it takes depends in a non-linear fashionon how far along the line
the printhead has travelled; it's driven by a spring and decelerated and
stopped by an air dashpot. Even an LF takes more than two character
times. That's why ASR33 drivers send a string of nulls after a CR.
Many are smart enough to send the LF instead of the first null, if they
see that LF is the first character after CR.
I distinctly recall the ASR33 printing exactly two characters while
the print head is in motion, if a CR is issued while the print head is
at the right margin. The ASR33 had a very fast and forceful print
head return mechanism--you definitely didn't want to get your fingers
in the way! In my programs that sent data to an ASR33, I always
followed CR with two non-printing characters (typically LF/NUL) and I
never had a problem with characters printing during the print head
return.
I don't recall LF taking more than one character time to execute on
the ASR33. If it did, I never noticed it.
The DEC LA36 dot matrix terminal had a rather leisurely carriage
return mechanism, but it also could buffer up characters received
while the CR was in progress. It would then speed up over the normal
printing rate to catch up and empty the buffer. There was a third
party mod to the LA36 that you could buy that would cause it to always
think it was in catch-up mode and to print at the higher speed all the
time. This shortened the life of the print mechanism, but at our shop
we found the extra speed in printing worth the expense of repairing
early breakdown of the mechanism.
-Paul W.