> John Cowan wrote:
>> On Wed, 2000-07-05, john wrote:
>>> John Cowan wrote:
>>> IIRC, the Model 37 Teletype interpreted 0A as a newline function,
>> Also models 33 and 38, which also interpreted x0D as carriage return.
> Definitely not true of the model 33; it interpreted 0A as a line-feed,
> and if it received one not preceded by 0D
> it would do this.
> (Hopefully, you are all reading this email with a fixed-width font as
> God intended.)
Hmmm, well, of course, my memory could be faulty, but my recollection
is that x0A was line-feed and x0D was carriage return, and each
caused behavior accordingly (except that it was not the paper
carriage that returned, but the type cylinder carriage) on all
the Teletype models mentioned.
>>> so ASCII allowed 0A to be interpreted as either LF or NL.
>> That's non sequitur, but folks are like that.
> How so? The LF behavior is different from the NL behavior.
In my own thinking, it is more a matter of NL being ambiguous
by reason of generally being taken to (but not necessarily)
combine the functions of returning the carriage and feeding
a new line. I did not run across the term new-line until the
mid-1980s, though, of course, had known of systems that assumed
CR when processing a LF and vice versa as well as systems that
retained the separation of function.
>>> DEC OSes notoriously distorted or misused the control characters, thus
>>> ^U = NAK was used to kill an input line instead of ^X = cancel.
Ahh, I see the confusion. You were writing strictly of DEC
systems, and I am not. Since other systems did things in such
a way that the above usages were not a "notorious distortion" or
"misuse" by comparison, these do not seem unreasonable.
>> Since some of these editing commands were actually
>> merely echoed back from the main processor to the comm control
>> unit through which the terminal was connected,
> Definitely not true of any DEC OS; control characters were
> echoed as ^A, ^B, etc.
I did not mean to address "a character pressed in combination
with the control character", or "character codes in the ASCII
sequence 000-040 plus 177", but "a character whose function is
to control the process of communication", which are not
necessarily the same. Nor did I intend to address the way
things worked only on DEC systems, but how they fit into the
scheme of behavior of other systems I'd used at that time.
>> there was some fogging over of the concepts of source and destination.
>> The comm controller would buffer up what was typed until it got a
>> CR (0x0D) and so these editing controls were actually commands to
>> that comm controller to clear its buffer.
> Again, not true of any DEC OS; characters were interpreted one by one
> and selectively echoed by the CPU only...
Yah, different systems had different practices, and I don't
recall the PDPs all that well, but they did not have separate
comm units, but merely a single CPU.
On Cybers could choose to have the comm controller echo chars or
not, but that was a different matter from the processing of these
control chars. Actually, it was in the development of e-mail
on them in the mid to late 1970s that it became glaringly
significant, because people would, on a prank, send others e-mail
containing the "log off" control character, which would cause
the receiver to be logged off when s/he tried to read the
message because when it went from the CPU to the comm controller,
the comm controller merrily complied with the request. When you
issued a "log" or "bye" on those systems, they would send the
command to the CPU, which would send the control char back out
to the comm controller. But, of course, they did not use
ASCII, either, having their own 6-bit and 12-bit character
code sets.
John G. Otto Nisus Software, Engineering
www.infoclick.com www.mathhelp.com www.nisus.com software4usa.com
EasyAlarms PowerSleuth NisusEMail NisusWriter MailKeeper QUED/M
My opinions are probably not those of Nisus Software, Inc.
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:05 EDT