what's the difference between LF(Line Fee) and NL (New line) ?

[Tsai Laurence]

hello listers,
I am confused that the difference between LF & NL ? It seems both will
get the printer prints the document on next line .
Can anybody advise me ?

Sincerely,
Laurence

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[p***@ibm-main.lst]

Hello Laurence

LF (Line Feed) only advances the old typewriter one row and works in conjunction with CR (Carriage Return) to return to (print)column 1

Per

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@ibm-main.lst
Sent: den 4 september 2006 15:15
To: IBM-***@BAMA.UA.EDU
Subject: what's the difference between LF(Line Fee) and NL (New line) ?


hello listers,
I am confused that the difference between LF & NL ? It seems both will
get the printer prints the document on next line .
Can anybody advise me ?

Sincerely,
Laurence

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Anne & Lynn Wheeler]

Post by Tsai Laurence
I am confused that the difference between LF & NL ? It seems both
will get the printer prints the document on next line . Can anybody
advise me ?

from rfc index
http://www.garlic.com/~lynn/rfcietff.htm

rfc 318 telnet protocol
http://www.garlic.com/~lynn/rfcidx1.htm#318

318
[Ad hoc Telnet Protocol], Postel J., 1972/04/03 (23pp)
(.txt=34928) (Updated by 435) (Updates 158) (Ref'ed By 739, 750,
755, 758, 762, 770)

clicking on the ".txt=" field in rfc summary retrieves the actual rfc

from rfc 318 ...

Telnet defines the end of a line to be indicated by the ASCII
character pair CR LR. Several of the real devices in the world have
only a single new line (NL) function. Several of the computer
systems have in some programs used the CR and LF functions to have
semantic meaning larger than the format effect they provide.
Further, several computer systems allow the CR and LF functions to be
used separately (e.g., such that a line may be overprinted). One
problem, for those Telnet (user) programs required to map the NVT
into a device which only has a NL function, is how is the CR LF to be
dealt with. One solution is to examine the character following the
CR. If an LF is found, then perform the NL function; if anything
else is found then back space to the beginning of the line. Another
problem is the case of a computer system which locally uses period,
".", to cause the new line function and which uses, in some programs,
CR and LF for semantically significant operations. Suppose the user
Telnet sends the sequence CR LF. Does this mean "new line" or the
"CR operation" followed by the "LF operation "? A solution to this
problem it to require that Telnet programs send a CR NOT intended to
be part of a CR LF pair as a CR NUL pair. Then the receiving program
can always hold a CR and examine the next character to determine if a
new line function is intended. This solution is strongly
recommended.

... and ..


Line Feed (LF) 10 Moves the printer to next line (keeping
the same horizontal position).

Carriage Return (CR) 13 Moves the printer to the left margin
of the current line.

[Chris Mason]

Laurence

In very strict terms the difference between the action of a Line Feed (LF)
character and a New Line (NL) character is that the action of a Carriage
Return (CR) is missing in the case of an LF character and present in the
case of the NL character.

You got the answer from the other two appends I have seen until now, but
I'll expand on what I just said in an effort to be as clear as I can.

Let us assume that somewhere along a line of print in the course of being
printed, the printer, whatever type of printer it is, has to handle one of
these characters: LF, CR or NL.

If the character is an LF, the printer arranges to start printing any
following graphic characters, that is, characters which cause something to
print rather than having a special purpose such as the three characters
under discussion, on the following line but starting at exactly the position
of the last character to be printed on the current line. Thus if 25
characters have already printed on the current line, there will be 25 blank
spaces on the left of the following line before any graphic characters can
appear.

If the character is a CR, the printer arranges to print any following
graphic characters starting at the left margin of the current line,
potentially overwriting characters which have already been printed.

If the character is an NL, the printer arranges to print any following
graphic characters starting at the left margin of the following line.

Note that, if an LF is followed immediately by a CR or, in the more usual
order, a CR is followed immediately by an LF, the action taken by the
printer will be identical to that taken for an NL.

The basic ASCII character set identifies a CR and an LF character and you
will tend to find ASCII data streams perform formatting of a printed page
using these two characters and, typically CRLF simply to begin a new line of
print. Clearly CR used by itself has potential for underlining and rendering
characters in bold "type". NL used by itself may have a role where the
layout of the page allows but this will not be very common as you can
imagine. In the days when data needed to be transmitted and line speeds of,
say, 300 bps had to be tolerated, using all the tricks at one's disposal to
help get a report printed as quickly as possible might involve NL and BS,
backspace, but the processing required to spot how to create the data stream
would be tricky.[1]

The SNA character string has all of the NL (X'15') character, as well as CR
(X'25') and LF (X'0D').

Now, I've just spotted something odd which may be the reason for your post.
In the "SNA Formats" manual, GA27-3136-20[2], in Appendix A, "SNA Character
Sets and Symbol-String Types", which you'd expect to be the model of
clarity, X'15' is identified as Line Feed - confusion worse confounded. Just
ignore it. It's wrong. I wonder if there is anyone still reading who has
access to anyone who might know the authors who can justify this nonsense.
What I described above is what I have taught and shown to work in
environments such as Unformatted Systems Services in VTAM, with both "pure"
SNA devices and, more importantly, with devices which require an EBCDIC
translation of ASCII characters.

Incidentally NVT, initials used in one of the reply posts, means "Network
Virtual Terminal" and is used in TELNET RFCs in order to define a generic
device. From RFC 854, "An NVT is an imaginary device which provides a
standard,network-wide, intermediate representation of a canonical terminal."

[1] I once wrote some APL functions to maximise the use of TAB characters in
order to speed up report printing at 300 bps. The very next release of VM
APL introduced a standard function to perform precisely the same result. :-(

[2] http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/d50a5007

Chris Mason

----- Original Message -----
From: "Tsai Laurence" <***@HOTMAIL.COM>
Newsgroups: bit.listserv.ibm-main
To: <IBM-***@BAMA.UA.EDU>
Sent: Monday, 04 September, 2006 3:14 PM
Subject: what's the difference between LF(Line Fee) and NL (New line) ?

Post by Tsai Laurence
hello listers,
I am confused that the difference between LF & NL ? It seems both will
get the printer prints the document on next line .
Can anybody advise me ?
Sincerely,
Laurence

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

Post by Chris Mason
Now, I've just spotted something odd which may be the reason for your post.
In the "SNA Formats" manual, GA27-3136-20[2], in Appendix A, "SNA Character
Sets and Symbol-String Types", which you'd expect to be the model of
clarity, X'15' is identified as Line Feed - confusion worse confounded. Just
ignore it. It's wrong. I wonder if there is anyone still reading who has
access to anyone who might know the authors who can justify this nonsense.
What I described above is what I have taught and shown to work in
environments such as Unformatted Systems Services in VTAM, with both "pure"
SNA devices and, more importantly, with devices which require an EBCDIC
translation of ASCII characters.

Bad History. UNIX in ASCII environments customarily uses LF as a single
character abbreviation for the NL function. And the "C" language standard
presumes a single character, represented by "\n" in character and string
denotations with the NL function. There's likely a causal relation; I don't
know which convention claims primacy.

Meanwhile, the EBCDIC 0x15 code point has long been used for serial device
control (3215?), and as a command separator by VM CP. Pragmatically, when
"C" compilers (from independents, not IBM) first appeared for 370 computers,'
they implemented "\n" as 0x15. IBM's "C" compiler went along with the
crowd. And when z/OS Unix Services appeared, it followed the trend.
And to support conversion, IBM supplied a translation table, OEMVS311,
which translates ASCII LF (0x0A) to EBCDIC 0x15 and ASCII NEL (0x85) to
EBCDIC 0x25 to preserve revertibility.

I agree with the behavior implemented by all these decisions; it's pragmatic
and convenient. I disagree at the point where OEMVS311 is named a conversion
from ISO8859-1 to IBM-1047. It isn't, because of the exception you observed.
And non-z/OS programmers (e.g. Linux) attempting to implement conversion between
ISO8859-1 and IBM-1047 by the book overlook obscure footnotes and appendices
which describe the exception. I believe the Right Thing to do is to preserve
the useful behavior of OEMVS311 while making the documentation correct by
defining a new EBCDIC code page with LF at 0x15 and NEL at 0x25, the de facto
convention. EBCDIC dogmatists disagree, saying that in such a code page
programmers could no longer rely on NL to perform its historic function (in
fact no such character would be defined at all) on hardware devices (are any
such still in use?), or that a code page which differed from all other EBCDIC
pages in the assignment of any code point below 0x40 can't be called "EBCDIC".

I remain unswayed; I see the need for a code page definition which matches
the translation that OEMVS311 applies to ISO8859-1, but with the names
properly corresponding. Don't even call it EBCDIC, if that violates your
dogma, but make it available, and make it the nominal definition of the
OEMVS311 conversion.

BTW, VM/CMS facilities converting ISO8859-1 to IBM-1047 generally map
ASCII LF to 0x25 and ASCII NEL to 0x15, thereby introducing an incompatibility
with the prevailing z/OS usage of OEMVS311 as that nominal translation.

-- gil

[j***@ecn.ab.ca]

Post by Paul Gilmartin
Bad History. UNIX in ASCII environments customarily uses LF as a single
character abbreviation for the NL function.

Yes. (Sort of.) Well, that's UNIX's problem.

The characters CR and LF made their existence felt back when page
printers were made which used a character code based on the five-unit
code of Donald Murray, with some modifications. This code is often
called "Baudot", but while Emile Baudot's code was a five-unit code, it
was still very different from ITA-2, the code used for Telex, for RTTY,
and for TDD.

And CR returned the printing element to the beginning of a line, while
LF advanced the paper by one line.

That's just what those characters _did_. When ASCII came into being, CR
and LF did exactly the same thing on the Teletype Model 33 Keyboard
Send-Recieve and Automatic Send-Receive and Receive-Only
teletypewriters.

People started connecting ASCII terminals from the Teletype Corporation
(now no longer gracing Skokie, Illinois with its presence) and other
manufacturers to computers. Usually, when they did so, they followed
the convention that the user would press the "Carriage Return" key to
signal that he (or she) was finished typing a line of data. The
computer would then echo first a carriage return code, and then, while
the carriage was busy moving along the width of the platen, it would
use the wasted time to transmit a line feed.

It did not need to transmit nulls as well, but if a less intelligent
device than a computer was at the other end - say a paper tape reader -
then a few of those would tend to be included at the end of each line
also.

For some bizarre reason, the default UNIX convention - which,
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose. This complicated software somewhat, since now it wasn't
possible to first echo every character typed, and then figure out what
to do extra later. Also, not all ASCII terminals have a "Line Feed"
key, or, at least, they don't have one in a convenient place. (Note
that, even "in UNIX environments", terminals did what they always did
with a line feed character, and thus the computer running the UNIX
operating system still had to echo a carriage return as well as a line
feed to the terminal - after receiving, as was its wont, a line feed
from the user.)

In the mean time, at the other end of the world... IBM took its
world-famous Selectric typewriter, and from it, it crafted the 2741
terminal. (Actually, before the 2741, there was the 1050, and the IO
Selectric, and so on.)

With a Teletype Model 33, you might have a switch to change it from
"full duplex" to "half duplex" operation. In "full duplex" mode, what
you typed on the keyboard just went to the computer; if you were to see
what you typed, the computer would have to send the same characters
back to you. In "half duplex" mode, what you typed was also sent
directly to the printing part of the terminal, so the computer at the
other end didn't need to - and shouldn't, of course - bother.

The 2741, being made from a typewriter, only ran in half duplex mode.
The carriage return key on a 2741 did exactly what the carriage return
key on a typewriter - as opposed to a Teletype Model 19 - does, it both
caused the printing element to return to the left margin, and it
indexed the paper. So the character transmitted to the computer when it
was pressed was called NL, or "New Line". As well, with the 2741, when
the computer wished to type, it locked the keyboard on the terminal,
and then, when it was finished, it unlocked it again. Since the
computer wasn't doing the typing when the keyboard was _not_ locked,
the code to lock the keyboard was the same as that for one of the
*printable* characters.

John Savard

[Peter Flass]

Post by j***@ecn.ab.ca
With a Teletype Model 33, you might have a switch to change it from
"full duplex" to "half duplex" operation. In "full duplex" mode, what
you typed on the keyboard just went to the computer; if you were to see
what you typed, the computer would have to send the same characters
back to you. In "half duplex" mode, what you typed was also sent
directly to the printing part of the terminal, so the computer at the
other end didn't need to - and shouldn't, of course - bother.

Au contraire. You needed to send enough NULs to fill up the time it
took to return the carriage, or the stupid thing woud start typing
during the return. At one time I did some TTY support in CICS, and I
seem to recall 3 NULs, maybe for a 300-bps terminal? The faster the
terminal, the more NULs needed. I can't remember the specifics just now.

[j***@ecn.ab.ca]

Post by Peter Flass

Post by j***@ecn.ab.ca
With a Teletype Model 33, you might have a switch to change it from
"full duplex" to "half duplex" operation. In "full duplex" mode, what
you typed on the keyboard just went to the computer; if you were to see
what you typed, the computer would have to send the same characters
back to you. In "half duplex" mode, what you typed was also sent
directly to the printing part of the terminal, so the computer at the
other end didn't need to - and shouldn't, of course - bother.

Au contraire. You needed to send enough NULs to fill up the time it
took to return the carriage, or the stupid thing woud start typing
during the return. At one time I did some TTY support in CICS, and I
seem to recall 3 NULs, maybe for a 300-bps terminal? The faster the
terminal, the more NULs needed. I can't remember the specifics just now.

II gguueess tthhaatt II ddiiddnn''tt qquuiittee mmaakkee
cclleeaarr jjuusstt

... what it was the computer at the other end shouldn't bother doing
when the ASCII terminal connected to it was in half-duplex mode. When
it received a carriage return (or a line feed), it would have to echo
its complement... and *either* send out a string of nulls, or just
remember to wait for a suitable interval before sending any more
characters to the terminal to type.

In half-duplex, where, unlike on a 2741, you can't lock the terminal,
if the user wants to type a character while the carriage is returning,
there isn't much the computer could do about it even if it tried.

John Savard

[Anne & Lynn Wheeler]

Post by j***@ecn.ab.ca
In half-duplex, where, unlike on a 2741, you can't lock the terminal,
if the user wants to type a character while the carriage is returning,
there isn't much the computer could do about it even if it tried.

re:
http://www.garlic.com/~lynn/2006p.html#45 what's the difference between LF(Line Fee) and NL (New line) ?

last week of jan68, three people from the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

came out from the science center to install cp67.

at the time, cp67 had support for (doing automatic terminal
recognition) for 2741 and 1050s. the university had some ascii tty33s
... so i found myself adding ascii tty terminal support to cp67. this
included having to decide how some ascii characters mapped to ebcdic
and back again.

i thot i could do the implementation so that tty support would be
merged into the existing cp67 automatic terminal recognition ... which
sort of worked. I thot the 2702 sad command which switched line
scanner between supported terminal types. this worked fine for leased
lines and terminals with the same baud rate. however, 2702 had
shortcut ... while sad command could change the line scanner on each
port/line ... the oscillator fixing the baud rate was hard wired to
each port.

this short comming led to a univ. project to build our own terminal
control unit, reverse engineer the channel interface and build our own
channel interface card for an interdata/3 programmed to emulate 2702
... with the added capability that it would automate baud rate
determination. somebody then did a write-up blaiming four of
us for the plug control unit business:
http://www.garlic.com/~lynn/subtopic.html#360pcm

here is a story about the tty support later resulting in 27
cp67 crashes on a single day.
http://www.multicians.org/thvv/360-67.html

I had done some one byte truncations related to tty line length
... and a local modification was made to handle some sort of ascii
device (plotter?) with line length on the order of 1k(?) ... the
maximum line length was increased w/o changing the one byte
fiddling.

later, the claim was that a primary motivation for FS
http://www.garlic.com/~lynn/subtopic.html#futuresys

effort was as counter to plug compatible controller business ...
from the following
http://www.ecole.org/Crisis_and_change_1995_1.htm

IBM tried to react by launching a major project called the 'Future
System' (FS) in the early 1970's. The idea was to get so far ahead
that the competition would never be able to keep up, and to have such
a high level of integration that it would be impossible for
competitors to follow a compatible niche strategy. However, the
project failed because the objectives were too ambitious for the
available technology. Many of the ideas that were developed were
nevertheless adapted for later generations. Once IBM had acknowledged
this failure, it launched its 'box strategy', which called for
competitiveness with all the different types of compatible
sub-systems. But this proved to be difficult because of IBM's cost
structure and its R&D spending, and the strategy only resulted in a
partial narrowing of the price gap between IBM and its rivals.

... &

This first quiet warning was taken seriously: 2,500 people were
mobilised for the FS project. Those in charge had the right to choose
people from any IBM units. I was working in Paris when I was picked
out of the blue to be sent to New York. Proof of the faith people had
in IBM is that I never heard of anyone refusing to move, nor
regretting it. However, other quiet warnings were taken less
seriously.

... snip ...

as i've mentioned a number of times in the past, i wasn't very
respective about the FS effort ... drawing an analogy with some cult film
that been playing down in central sq for over a decade ... something
about the inmates being in charge of the institution.

[j***@aol.com]

Post by j***@ecn.ab.ca

Post by Peter Flass

Post by j***@ecn.ab.ca
With a Teletype Model 33, you might have a switch to change it from
"full duplex" to "half duplex" operation. In "full duplex" mode, what
you typed on the keyboard just went to the computer; if you were to see
what you typed, the computer would have to send the same characters
back to you. In "half duplex" mode, what you typed was also sent
directly to the printing part of the terminal, so the computer at the
other end didn't need to - and shouldn't, of course - bother.

Au contraire. You needed to send enough NULs to fill up the time it
took to return the carriage, or the stupid thing woud start typing
during the return. At one time I did some TTY support in CICS, and I
seem to recall 3 NULs, maybe for a 300-bps terminal? The faster the
terminal, the more NULs needed. I can't remember the specifics just now.

II gguueess tthhaatt II ddiiddnn''tt qquuiittee mmaakkee
cclleeaarr jjuusstt
.... what it was the computer at the other end shouldn't bother doing
when the ASCII terminal connected to it was in half-duplex mode. When
it received a carriage return (or a line feed), it would have to echo
its complement... and *either* send out a string of nulls, or just
remember to wait for a suitable interval before sending any more
characters to the terminal to type.

This was only necessary when the stuff to type came from the computer.

Post by j***@ecn.ab.ca
In half-duplex, where, unlike on a 2741, you can't lock the terminal,
if the user wants to type a character while the carriage is returning,
there isn't much the computer could do about it even if it tried.

But no user would have done this. Everybody was trained to wait
until the platen was back in position. People's typing techniques
had the nulls built in. If you did type-ahead, you spent the next
five minutes unjamming the hammers which greatly reduced your WPM
rating.

/BAH

[Brian Inglis]

On Sat, 09 Sep 06 10:38:12 GMT in alt.folklore.computers,

Post by j***@aol.com

Post by j***@ecn.ab.ca

Post by Peter Flass

Post by j***@ecn.ab.ca
With a Teletype Model 33, you might have a switch to change it from
"full duplex" to "half duplex" operation. In "full duplex" mode, what
you typed on the keyboard just went to the computer; if you were to see
what you typed, the computer would have to send the same characters
back to you. In "half duplex" mode, what you typed was also sent
directly to the printing part of the terminal, so the computer at the
other end didn't need to - and shouldn't, of course - bother.

Au contraire. You needed to send enough NULs to fill up the time it
took to return the carriage, or the stupid thing woud start typing
during the return. At one time I did some TTY support in CICS, and I
seem to recall 3 NULs, maybe for a 300-bps terminal? The faster the
terminal, the more NULs needed. I can't remember the specifics just now.

II gguueess tthhaatt II ddiiddnn''tt qquuiittee mmaakkee
cclleeaarr jjuusstt
.... what it was the computer at the other end shouldn't bother doing
when the ASCII terminal connected to it was in half-duplex mode. When
it received a carriage return (or a line feed), it would have to echo
its complement... and *either* send out a string of nulls, or just
remember to wait for a suitable interval before sending any more
characters to the terminal to type.

This was only necessary when the stuff to type came from the computer.

Post by j***@ecn.ab.ca
In half-duplex, where, unlike on a 2741, you can't lock the terminal,
if the user wants to type a character while the carriage is returning,
there isn't much the computer could do about it even if it tried.

But no user would have done this. Everybody was trained to wait
until the platen was back in position. People's typing techniques
had the nulls built in. If you did type-ahead, you spent the next
five minutes unjamming the hammers which greatly reduced your WPM
rating.

I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

[j***@aol.com]

Post by Brian Inglis
On Sat, 09 Sep 06 10:38:12 GMT in alt.folklore.computers,

<snip>

Post by Brian Inglis

Post by j***@aol.com
But no user would have done this. Everybody was trained to wait
until the platen was back in position. People's typing techniques
had the nulls built in. If you did type-ahead, you spent the next
five minutes unjamming the hammers which greatly reduced your WPM
rating.

I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

The reason I was able to work so fast was because of typeahead
features. However, you had to know when to let the system
catch up; life could become <ahem>very interesting if one
of the type aheads got an error and the TTY pipe didn't get
flushed. In olden days there were flush bugs. Some days
I was really good at predicting the future. :-)

/BAH

[Anne & Lynn Wheeler]

Post by j***@aol.com
The reason I was able to work so fast was because of typeahead
features. However, you had to know when to let the system
catch up; life could become <ahem>very interesting if one
of the type aheads got an error and the TTY pipe didn't get
flushed. In olden days there were flush bugs. Some days
I was really good at predicting the future. :-)

local connected 3270 were significantly faster (hundreds of
kbytes/sec) ... however interactions were half-duplex and the keyboard
was locked during the interactions.

we had a couple hardware patches for the 3277 ... one was a FIFO box
that fit where the keyboard plugged into the displayhead which would
buffer keystrokes during the period that the keyboard would normally
be locked. another was piggypacking some resisters inside the keyboard
that controlled repeat key startup delay and rate of repeat. this was
useful for the cursor movement keys, for positioning the cursor on the
screen. one problem was that you could increase the rate to higher
than the screen update ... so the cursor position would lag ... and
then still "coast" after you had released the key. if you had your
keyboard modified for very high repeat rate ... it could take some
practice getting feel for releasing the key and still have the cursor
stop at the desired position.

these fixes were obsoleted in the switch-over from 3272 controller and
3277 terminals to 3274 controllers and 3278/3279/etc terminals
... since much of the 3277 electronics were moved back into the 3274
controller (reducing per terminal manufactoring costs).

misc. past posts mentioning 3272 and/or 3274 terminal cotnrollers
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/98.html#49 Edsger Dijkstra: the blackest week of his professional life
http://www.garlic.com/~lynn/99.html#28 IBM S/360
http://www.garlic.com/~lynn/99.html#69 System/1 ?
http://www.garlic.com/~lynn/99.html#193 Back to the original mainframe model?
http://www.garlic.com/~lynn/2000c.html#63 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#66 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#67 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000g.html#23 IBM's mess
http://www.garlic.com/~lynn/2001k.html#30 3270 protocol
http://www.garlic.com/~lynn/2001k.html#33 3270 protocol
http://www.garlic.com/~lynn/2001k.html#46 3270 protocol
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2001m.html#17 3270 protocol
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#48 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#50 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002j.html#67 Total Computing Power
http://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
http://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
http://www.garlic.com/~lynn/2002q.html#51 windows office xp
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives
http://www.garlic.com/~lynn/2003c.html#69 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003c.html#72 OT: One for the historians - 360/91
http://www.garlic.com/~lynn/2003d.html#23 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003d.html#24 CPU Impact of degraded I/O
http://www.garlic.com/~lynn/2003e.html#43 IBM 3174
http://www.garlic.com/~lynn/2003h.html#15 Mainframe Tape Drive Usage Metrics
http://www.garlic.com/~lynn/2003i.html#30 A Dark Day
http://www.garlic.com/~lynn/2003j.html#24 Red Phosphor Terminal?
http://www.garlic.com/~lynn/2003k.html#20 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003k.html#22 What is timesharing, anyway?
http://www.garlic.com/~lynn/2003o.html#14 When nerds were nerds
http://www.garlic.com/~lynn/2003o.html#36 When nerds were nerds
http://www.garlic.com/~lynn/2003p.html#44 Mainframe Emulation Solutions
http://www.garlic.com/~lynn/2004c.html#30 Moribund TSO/E
http://www.garlic.com/~lynn/2004e.html#0 were dumb terminals actually so dumb???
http://www.garlic.com/~lynn/2004f.html#54 [HTTP/1.0] Content-Type Header
http://www.garlic.com/~lynn/2004g.html#11 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004g.html#24 |d|i|g|i|t|a|l| questions
http://www.garlic.com/~lynn/2004g.html#27 Infiniband - practicalities for small clusters
http://www.garlic.com/~lynn/2004q.html#35 [Lit.] Buffer overruns
http://www.garlic.com/~lynn/2005e.html#13 Device and channel
http://www.garlic.com/~lynn/2005h.html#40 Software for IBM 360/30
http://www.garlic.com/~lynn/2005r.html#12 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#14 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#15 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#17 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#20 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005r.html#28 Intel strikes back with a parallel x86 design
http://www.garlic.com/~lynn/2005s.html#17 winscape?
http://www.garlic.com/~lynn/2005s.html#45 winscape?
http://www.garlic.com/~lynn/2005u.html#22 Channel Distances
http://www.garlic.com/~lynn/2006b.html#21 IBM 3090/VM Humor
http://www.garlic.com/~lynn/2006i.html#34 TOD clock discussion

[j***@aol.com]

Post by Anne & Lynn Wheeler

Post by j***@aol.com
The reason I was able to work so fast was because of typeahead
features. However, you had to know when to let the system
catch up; life could become <ahem>very interesting if one
of the type aheads got an error and the TTY pipe didn't get
flushed. In olden days there were flush bugs. Some days
I was really good at predicting the future. :-)

local connected 3270 were significantly faster (hundreds of
kbytes/sec) ... however interactions were half-duplex and the keyboard
was locked during the interactions.

I hated that. It was similar to listening to chalk squeaking on
the blackboard...or chewing stones.

Post by Anne & Lynn Wheeler
we had a couple hardware patches for the 3277 ... one was a FIFO box
that fit where the keyboard plugged into the displayhead which would
buffer keystrokes during the period that the keyboard would normally
be locked. another was piggypacking some resisters inside the keyboard
that controlled repeat key startup delay and rate of repeat. this was
useful for the cursor movement keys, for positioning the cursor on the
screen. one problem was that you could increase the rate to higher
than the screen update ... so the cursor position would lag ... and
then still "coast" after you had released the key. if you had your
keyboard modified for very high repeat rate ... it could take some
practice getting feel for releasing the key and still have the cursor
stop at the desired position.

I hadn't thought about this one. But yea even hard-copy coasting
required a feel to it.

Post by Anne & Lynn Wheeler
these fixes were obsoleted in the switch-over from 3272 controller and
3277 terminals to 3274 controllers and 3278/3279/etc terminals
.... since much of the 3277 electronics were moved back into the 3274
controller (reducing per terminal manufactoring costs).

I always admired most of our comm people (there were one ...
maybe just one) exception. Those guys pulled miracles out of their
hats. The miracles were always gibberish to me but they did the
work.

Post by Anne & Lynn Wheeler
misc. past posts mentioning 3272 and/or 3274 terminal cotnrollers

<snip ref list--sorry>

/BAH

[Peter Flass]

Post by Brian Inglis
I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

Must have been a bit hard to read...

[Brian Inglis]

On Sun, 10 Sep 2006 13:21:34 GMT in alt.folklore.computers, Peter

Post by Peter Flass

Post by Brian Inglis
I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

Must have been a bit hard to read...

Easy to read: system output only, but hard to debug if the system went
a different route and expected something different from what you'd
typed ahead.

[j***@aol.com]

Post by Brian Inglis
On Sun, 10 Sep 2006 13:21:34 GMT in alt.folklore.computers, Peter

Post by Peter Flass

Post by Brian Inglis
I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

Must have been a bit hard to read...

Easy to read: system output only, but hard to debug if the system went
a different route and expected something different from what you'd
typed ahead.

My work required an ability to read both. I just didn't have to
read it in real time as the interrupts were happening. That's
what type ahead is. You can continue to type stuff and eventually
it will all come out on your screen. Your fingers (and brain)
don't have to keep their interrupts in sync with the system's.

/BAH

[Anne & Lynn Wheeler]

Post by Brian Inglis
I greatly speeded up interaction with a remote TOPS-10 system from a
TTY over a slow link, by telling the system that the terminal echoed,
and the terminal that the system echoed: had to be careful using TECO
though. ;^>

re:
http://www.garlic.com/~lynn/2006q.html#10 what's the difference between LF(Line Fee) and NL (New line) ?

a large portion of cms retained 1052 line terminal input/output
paradigm ... with hypervisor emulating 1052 line operation on 327x
terminals (some applications, like various editors, were enhanced for
full-screen operation).

in the real line-terminal days ... cms would output a single line at a
time. the hypervisor had some scheduling sensitivity for terminal i/o
in support of "faster" interactive operation. moving to emulated line
terminals on very fast screen terminals (hundreds of kilobytes/sec)
placed some unnecessary overhead on resource scheduling. misc. collected
posts about resource scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

so one of the things i did was modifying cms dmscit to perform single
write (batched) operation for all/any queued lines. past post (including
email copy from long ago and far away)
http://www.garlic.com/~lynn/2003c.html#35 diffence between itanium and alpha

[John L]

Post by j***@ecn.ab.ca
For some bizarre reason, the default UNIX convention - which,
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose.

Nothing bizarre about it at all. Early Unix systems were connected to
model 37 Teletypes which had a Newline key which both returned the
carriage and advanced the platen. The single character newline
greatly simplified programming compared to the cr/lf which was popular
on DEC operating systems and still plagues descendants of MS-DOS as
well as many Internet protocols, notably SMTP.

Post by j***@ecn.ab.ca
This complicated software somewhat, since now it wasn't possible to
first echo every character typed, and then figure out what to do
extra later.

The emulation to make CR or LF on a model 33 act like a NL wasn't very
complicated. Look at the Lions book. Unix didn't send nulls to delay
after a CR, it just waited long enough and resumed sending.

Post by j***@ecn.ab.ca
In the mean time, at the other end of the world... IBM took its
world-famous Selectric typewriter, and from it, it crafted the 2741
terminal. (Actually, before the 2741, there was the 1050, and the IO
Selectric, and so on.)

The 2741 was quite popular, but seriously underengineered. I used a
terminal room at Princeton with about a dozen 2741s, and I don't ever
remember them all working. The 1050 was much sturdier but not very
popular other than as the attached console on 360s.

R's,
John

[Floyd L. Davidson]

Post by John L

Post by j***@ecn.ab.ca
For some bizarre reason, the default UNIX convention - which,

What is bizarre is that while the designers of UNIX saw the long
understood advantage, others didn't and apparently in simple
ignorance used a different convention.

Post by John L

Post by j***@ecn.ab.ca
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose.

Nothing bizarre about it at all. Early Unix systems were connected to
model 37 Teletypes which had a Newline key which both returned the
carriage and advanced the platen. The single character newline
greatly simplified programming compared to the cr/lf which was popular
on DEC operating systems and still plagues descendants of MS-DOS as
well as many Internet protocols, notably SMTP.

Of course the actual concept of using LF for a newline, rather than
requiring both LF and CR, goes *way* back... to Teletype machines
much older than the Model 37 and long before UNIX.

Post by John L

Post by j***@ecn.ab.ca
This complicated software somewhat, since now it wasn't possible to
first echo every character typed, and then figure out what to do
extra later.

I don't understand what that was supposed to mean.

Post by John L
The emulation to make CR or LF on a model 33 act like a NL wasn't very
complicated. Look at the Lions book. Unix didn't send nulls to delay
after a CR, it just waited long enough and resumed sending.

Even the delay goes much farther back than UNIX.

Before the Model 28 (which had a type box that moved), the Model
15 Teletype used a type basket (much like the old typewriters)
and the paper platen moved. A CR cause this *huge* and *heavy*
platen to go all the way to one edge. If it did that from the
far end, this was an earth shaking event (well, at least it
could shake a whole building). And a time consuming event.

Whatever, because a missed CR or LF would result in unreadable
garble, it was very common to mechanically configure Teletype
machines to do only a CR on CR, but to do first a CR and then an
LF when an LF was received. And the typical way that either
tapes were cut or that operators manually typed was to send CR,
then LF, and then a LTRS character one or more times. That
would give the carriage 3 or 4 character time intervals to
correctly position itself. For "five level Baudot" code, which
sends 7.5 bits per character, a 60 wpm (45.5 baud) machine would
take 165ms per character, so a three character delay would be
half a second.

A LTRS character was all of the holes in the tape punched. Most
machines were configured to return to Letters mode (as opposed
to Figures) when a newline was sent, but by sending a LTRS that
ensured that the results would be the same on any machine.

The LTRS character was also used to "correct" errors on a tape
(just back up the tape and punch all the holes over the error
and then retype it correctly) and to splice tapes (which was
very easy with "chadless" punches).

Post by John L

Post by j***@ecn.ab.ca
In the mean time, at the other end of the world... IBM took its
world-famous Selectric typewriter, and from it, it crafted the 2741
terminal. (Actually, before the 2741, there was the 1050, and the IO
Selectric, and so on.)

The 2741 was quite popular, but seriously underengineered. I used a
terminal room at Princeton with about a dozen 2741s, and I don't ever
remember them all working. The 1050 was much sturdier but not very
popular other than as the attached console on 360s.

Teletype machines on the other hand (until the more recent ones)
were designed to run 24/7. Model 15 and Model 28 machines were
used by news services, and simply worked. The Model 37 wasn't
as sturdy, but it was certainly what could be called reliable.
But Teletype also produced the low cost model 32/33 machines
beginning in the early 1960s, which did not match previous
models for reliability.

[Dennis Ritchie]

"Floyd L. Davidson" <***@apaflo.com> wrote in message news:***@apaflo.com...
....

Post by Floyd L. Davidson
What is bizarre is that while the designers of UNIX saw the long
understood advantage, others didn't and apparently in simple
ignorance used a different convention.

In fact what Unix did was just what Multics did, so it wasn't our
invention. But the single-character NL does obviate, for example,
questions like "what does just a single CR mean in a stream
ordinarily delimited by CR LF?"
"What about just a single LF?" What about LF-CR instead
of CR-LF?"
....

Post by Floyd L. Davidson
Of course the actual concept of using LF for a newline, rather than
requiring both LF and CR, goes *way* back... to Teletype machines
much older than the Model 37 and long before UNIX.

....
That I didn't know about earlier TTYs. The IBM 1050 and 2741 did
have a single-character line ender, and at least one also had an "index"
key that performed the function of LF (advance paper only).
The only earlier TTYs (33, 35) I used did, as you say, separate the
functions. Even on the 37 there was some sort of strap to select
between the NL and the LF behavior.

Dennis

[j***@ecn.ab.ca]

Post by Dennis Ritchie
In fact what Unix did was just what Multics did, so it wasn't our
invention. But the single-character NL does obviate, for example,
questions like "what does just a single CR mean in a stream
ordinarily delimited by CR LF?"
"What about just a single LF?" What about LF-CR instead
of CR-LF?"

I am not aware of any operating system that *doesn't* allow the user to
end a line of input by pressing just one key on a terminal.

Post by Dennis Ritchie
Even on the 37 there was some sort of strap to select
between the NL and the LF behavior.

In fact, this option existed even on early 5-level machines, such as
the Model 19, as is noted in many radio amateur publications.

(In helping to bring Unix to the world, you are of course a great
benefactor of humanity; do not feel I am denying this simply because I
am giving someone a hard time for, apparently, being a little of a Unix
bigot.)

Generally speaking, though, as far as I am aware, it is not customary
to take advantage of such a setting on ASCII terminals connected to
computers, even when they're running Unix. There is no need to do so.
It merely makes it impossible for the computer to do things like
printing a large expanse of underscored text - unless the terminal has
a backspace function, in which case unnecessary wear and tear is still
involved.

I take issue with the options chosen for Unix in two areas.

One is simply that Unix is in the minority, apparently. Most ASCII
terminals seem to be designed on the premise that the key generating CR
is the one to be placed where the carriage return key on an electric
typewriter would be placed - and thus, it is expected to be the one
that the host operating system accepts as indicating end-of-record from
terminals.

The other is the use of any character as a record delimiter *internally
on the computer*. Characters don't delimit records! One punched card is
a record. An inter-block gap delimits a record. And on disk, or on
blocked tapes, you can always precede a record with an indication of
how long it is - like a Pascal string, rather than a C string.

Unfortunately, as I've noted, the reason most of the *other*
microcomputer operating systems (i.e., CP/M, MS-DOS) weren't written by
mainframe bigots like myself is that there weren't enough of us. JCL
made an IBM mainframe a hard beastie to love - very few people had the
good fortune that I did, in being exposed to an IBM mainframe through
the medium of MTS, the Michigan Terminal System... which let its true
soft, cuddly nature shine through.

John Savard

[Brian Inglis]

On 4 Sep 2006 21:19:59 -0700 in alt.folklore.computers,

Post by j***@ecn.ab.ca
Unfortunately, as I've noted, the reason most of the *other*
microcomputer operating systems (i.e., CP/M, MS-DOS) weren't written by
mainframe bigots like myself is that there weren't enough of us. JCL
made an IBM mainframe a hard beastie to love - very few people had the
good fortune that I did, in being exposed to an IBM mainframe through
the medium of MTS, the Michigan Terminal System... which let its true
soft, cuddly nature shine through.

Oy! Soft, cuddly(TM) mainframes are a trademark of VM SHARE. ;^>

[j***@aol.com]

Post by Dennis Ritchie
....

Post by Floyd L. Davidson
What is bizarre is that while the designers of UNIX saw the long
understood advantage, others didn't and apparently in simple
ignorance used a different convention.

In fact what Unix did was just what Multics did, so it wasn't our
invention. But the single-character NL does obviate, for example,
questions like "what does just a single CR mean in a stream
ordinarily delimited by CR LF?"

But that was easy to answer. It meant that the characters
after the <CR> would overstrike the previous characters.
This was a feature. The platen didn't advance until it a
LF was sent down the wire.

A NL character makes the regular typewriter interface
ambiguous. You can't do anything with it other than
make a guess about what the data enterer wanted.

Post by Dennis Ritchie
"What about just a single LF?" What about LF-CR instead
of CR-LF?"

If you think typewriter (the old-fashioned kind) it's obvious.
CR was first because it saved shipping an extra null or two.

Post by Dennis Ritchie
....

Post by Floyd L. Davidson
Of course the actual concept of using LF for a newline, rather than
requiring both LF and CR, goes *way* back... to Teletype machines
much older than the Model 37 and long before UNIX.

....
That I didn't know about earlier TTYs. The IBM 1050 and 2741 did
have a single-character line ender, and at least one also had an "index"
key that performed the function of LF (advance paper only).
The only earlier TTYs (33, 35) I used did, as you say, separate the
functions. Even on the 37 there was some sort of strap to select
between the NL and the LF behavior.

These arguments were because the arguers were not typists waybackwhen.

I had always assumed the guys invented NL because it was becoming
increasingly impossible to make an educated guess about how
the user's TTY worked...especially after VT05s and all those
non-hardcopy TTYs.

In addition, if you wanted to ship an ASCII stream over the wire
that also included line terminations and did not want to
cause interrupts on the other end, people shipped NLs instead
of the any of those other platen moving characters (which
had to cause an interrupt).

/BAH

[Brian Inglis]

On Sat, 09 Sep 06 10:51:42 GMT in alt.folklore.computers,

Post by j***@aol.com
These arguments were because the arguers were not typists waybackwhen.
I had always assumed the guys invented NL because it was becoming
increasingly impossible to make an educated guess about how
the user's TTY worked...especially after VT05s and all those
non-hardcopy TTYs.

Overstriking never became an option on any glass TTY I ever used:
meant you had to print stuff to see that effect.
So NL was perfectly suited to glass TTYs.

[j***@aol.com]

Post by Brian Inglis
On Sat, 09 Sep 06 10:51:42 GMT in alt.folklore.computers,

Post by j***@aol.com
These arguments were because the arguers were not typists waybackwhen.
I had always assumed the guys invented NL because it was becoming
increasingly impossible to make an educated guess about how
the user's TTY worked...especially after VT05s and all those
non-hardcopy TTYs.

meant you had to print stuff to see that effect.
So NL was perfectly suited to glass TTYs.

We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

/BAH

[CBFalconer]

***@aol.com wrote:
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT. I have a utility to fix things published by
such non-thinkers:

[1] c:\c\toksplit>stripovr
No file specified or not found or too many params

Usage: stripovr [options] infile [> outfile]

strips overprinting lines, including <ch><bs><ch>
(An overprint is a line terminated with \r only)

Options:
-1 --savefirst (one) Save 1st of overprinted lines or chars
-b --stripbs Strip <char><bs><char>, see -1
-c --stripcol Strip overstrike backspaces also
-e --stripesc Strip ANSI terminal esc sequences
--help Give this help
default: All options off, saving last item
--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Roger Ivie]

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped.

Don't forget the mighty Tek 4010!

[Anne & Lynn Wheeler]

Post by Roger Ivie
Don't forget the mighty Tek 4010!

and the 3277ga (graphics attachment) which was a big rebanded
tektronics display that had special adaptor into the side of 3277.

it handled a lot of stuff that had been previously been done
on 2250 (and even some calma stuff)

a few past posts mentioning 3277ga
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2004l.html#27 Shipwrecks
http://www.garlic.com/~lynn/2004l.html#32 Shipwrecks
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006e.html#28 MCTS
http://www.garlic.com/~lynn/2006n.html#24 sorting was: The System/360 Model 20 Wasn't As Bad As All That

a few past posts mentioning calma:
http://www.garlic.com/~lynn/2002g.html#55 Multics hardware (was Re: "Soul of a New Machine" Computer?)
http://www.garlic.com/~lynn/2005r.html#24 What ever happened to Tandem and NonStop OS ?
http://www.garlic.com/~lynn/2005u.html#6 Fast action games on System/360+?
http://www.garlic.com/~lynn/2006e.html#9 terminals was: Caller ID "spoofing"
http://www.garlic.com/~lynn/2006n.html#41 Tek 4010, info and prices

[j***@ecn.ab.ca]

Post by Roger Ivie

Post by CBFalconer
Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped.

Don't forget the mighty Tek 4010!

Perhaps that's one reason they had an optional APL keyboard for it...

In the case of APL, of course, one could pre-program the terminal for a
*specific* set of overstrikes, using high-bit characters, and expect
the host computer software to convert overstrikes to the appropriate
character rather than the terminal doing it.

In the case of underlining, that, like inverse video, bright, dim, or
even (shudder) blink, could be a display mode... and, of course, there
might even have been conventional CRT terminals with the intelligence
to allow underscores to overstrike characters and produce their
underlined versions.

John Savard

[krw]

Post by j***@ecn.ab.ca

Post by Roger Ivie

Post by CBFalconer
Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped.

Don't forget the mighty Tek 4010!

Perhaps that's one reason they had an optional APL keyboard for it...

I thought that made it the 4013.

Post by j***@ecn.ab.ca
In the case of APL, of course, one could pre-program the terminal for a
*specific* set of overstrikes, using high-bit characters, and expect
the host computer software to convert overstrikes to the appropriate
character rather than the terminal doing it.

Sure, 2741s with an APL ball are an example of this.

Post by j***@ecn.ab.ca
In the case of underlining, that, like inverse video, bright, dim, or
even (shudder) blink, could be a display mode... and, of course, there
might even have been conventional CRT terminals with the intelligence
to allow underscores to overstrike characters and produce their
underlined versions.

IBM also had the PS (Programmed Symbols) option on the 3279s,
allowing some rather impressive (what we would now call "business")
graphics. They worked quite well for simulation results, though I
preferred the 3277GA that Lynn referred to earlier because I could
print locally.

[Brian Inglis]

fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

[j***@aol.com]

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

/BAH

[Steve O'Hara-Smith]

On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

[1] OK with a lot of extra logic you *could* have a set of line buffers
with at least one per line on the screen and having an indicator on each
line of which screen line it was for. AFAIK this was never done by glass
TTYs - although some Z80 boxes did something like it, the Newbrain springs
to mind, but then it would :)

[j***@aol.com]

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

Post by Steve O'Hara-Smith
[1] OK with a lot of extra logic you *could* have a set of line buffers
with at least one per line on the screen and having an indicator on each
line of which screen line it was for. AFAIK this was never done by glass
TTYs - although some Z80 boxes did something like it, the Newbrain springs
to mind, but then it would :)

/BAH

[Brian Inglis]

On Tue, 12 Sep 06 10:46:59 GMT in alt.folklore.computers,

Post by j***@aol.com

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

How did it display the previous 11 lines of input/output?

[Steve O'Hara-Smith]

On Tue, 12 Sep 06 10:46:59 GMT

Post by j***@aol.com

Post by Steve O'Hara-Smith
Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based
or dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

I've not seen the inside of a VT05 - but anything that drives a CRT
based raster must have a memory big enough to hold the whole screen in some
form otherwise the display cannot be generated every frame which it needs
to be. Storage tube based vector displays did not need to do this - OTOH
they could not be made to scroll.

[Peter Flass]

Post by Brian Inglis
On Tue, 12 Sep 06 10:46:59 GMT

Post by j***@aol.com

Post by Steve O'Hara-Smith
Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based
or dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

I've not seen the inside of a VT05 - but anything that drives a CRT
based raster must have a memory big enough to hold the whole screen in some
form otherwise the display cannot be generated every frame which it needs
to be. Storage tube based vector displays did not need to do this - OTOH
they could not be made to scroll.

And as I recall, faded rather quickly, and had to be refreshed
programmatically.

[Joe Pfeiffer]

Post by Peter Flass

Post by Brian Inglis
On Tue, 12 Sep 06 10:46:59 GMT

Post by j***@aol.com

Post by Steve O'Hara-Smith
Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based
or dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

I've not seen the inside of a VT05 - but anything that drives a CRT
based raster must have a memory big enough to hold the whole screen in some
form otherwise the display cannot be generated every frame which it needs
to be. Storage tube based vector displays did not need to do this - OTOH
they could not be made to scroll.

And as I recall, faded rather quickly, and had to be refreshed
programmatically.

No, a storage tube scope would hold an image a long, long time.
Certainly longer than I ever wanted to look at a single screen full of
text or image.

[Steve O'Hara-Smith]

On Tue, 12 Sep 2006 22:23:55 GMT

Post by Peter Flass

Post by Steve O'Hara-Smith
I've not seen the inside of a VT05 - but anything that drives a
CRT based raster must have a memory big enough to hold the whole screen
in some form otherwise the display cannot be generated every frame
which it needs to be. Storage tube based vector displays did not need
to do this - OTOH they could not be made to scroll.

And as I recall, faded rather quickly, and had to be refreshed
programmatically.

The ones I used would hold the display until the clear button was
pressed at which time the display flashed and went blank. I suppose it
would eventually fade left alone, but it was never left alone that long.

[William Pechter]

Post by j***@aol.com

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines... Upper case only IIRC.

I don't remember any terminal VT05 compatibility requirements in my DEC (82-86
)days. Pretty much everything was VT52 compatible (this requirement made
VT100's have that VT52 mode built in...). That was carried on to the
VT 220/240 and later ones.

Post by j***@aol.com
/BAH

Bill

[j***@aol.com]

Post by William Pechter

Post by j***@aol.com

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines...

Was it really 72? I can the screen in my head but I can't
count the bloody characters that are displayed.

Post by William Pechter
Upper case only IIRC.

Oh, yes. Definitely that. It made it useless to use for
editing purposes. The convention used was to prefix each
lower case character with a single quote.

Post by William Pechter
I don't remember any terminal VT05 compatibility requirements in my DEC (82-86
)days. Pretty much everything was VT52 compatible

Right. Which was VT05 compatible. That's why all SET TTY TTY
commands drop back to VT05.

Post by William Pechter
(this requirement made
VT100's have that VT52 mode built in...). That was carried on to the
VT 220/240 and later ones.

Yes. I wish I could remember the PITA "feature" that was put into
the VT05 and then proprogated forever after because the subsequent
generations had to be VT05 compatible.

/BAH

[William Pechter]

Post by j***@aol.com

Post by William Pechter

Post by j***@aol.com

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines...

Was it really 72? I can the screen in my head but I can't
count the bloody characters that are displayed.

Post by William Pechter
Upper case only IIRC.

Oh, yes. Definitely that. It made it useless to use for
editing purposes. The convention used was to prefix each
lower case character with a single quote.

Post by William Pechter
I don't remember any terminal VT05 compatibility requirements in my DEC

(82-86

Post by William Pechter
)days. Pretty much everything was VT52 compatible

Right. Which was VT05 compatible. That's why all SET TTY TTY
commands drop back to VT05.

Never set anything TTY... but of course I was using RT11/RSTS/RSX11
rather than TOPS10 and TOPS20.

I just looked up the VT05 docs on Google... 72x20 line. Octal 13
0x13 (Control-K) is cursor down, Octal 32 0x1A (Control-xZ) is cursor up,
Octal 10 0xA (line feed) is Control-J, Cursor up is Octal 30 -- 0x18
Control-x is cursor right, Cursor left is Octal-8 -- 0x10 -- Control-H
(backspace). Direct cursor addressing was Control-N Yaddress char
Xaddress char. Doesn't look anything like VT52. That was Escape Y
followed by the coordinates on the screen.


Never set mine to anything older than VT52. CP/M kermit did good VT52
on old 8-bit microcomputers so I could use KED/EDT etc from all my
stuff.

The Gemini/Telecon Zorba/H19/H89 even had the keypad IIRC.

Post by j***@aol.com

Post by William Pechter
(this requirement made
VT100's have that VT52 mode built in...). That was carried on to the
VT 220/240 and later ones.

Yes. I wish I could remember the PITA "feature" that was put into
the VT05 and then proprogated forever after because the subsequent
generations had to be VT05 compatible.
/BAH

Bill

[Charles Richmond]

Post by William Pechter

Post by j***@aol.com

Post by William Pechter

Post by j***@aol.com

Post by Steve O'Hara-Smith
On Mon, 11 Sep 06 10:59:25 GMT

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

Of course you can *all* glass TTYs have a screen buffer - they
couldn't drive the CRT without one[1]. The buffer can be character based or
dot based but it has to be there.

Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines...

Was it really 72? I can the screen in my head but I can't
count the bloody characters that are displayed.

Post by William Pechter
Upper case only IIRC.

Oh, yes. Definitely that. It made it useless to use for
editing purposes. The convention used was to prefix each
lower case character with a single quote.

Post by William Pechter
I don't remember any terminal VT05 compatibility requirements in my DEC

(82-86

Post by William Pechter
)days. Pretty much everything was VT52 compatible

Right. Which was VT05 compatible. That's why all SET TTY TTY
commands drop back to VT05.

Never set anything TTY... but of course I was using RT11/RSTS/RSX11
rather than TOPS10 and TOPS20.
I just looked up the VT05 docs on Google... 72x20 line. Octal 13
0x13 (Control-K) is cursor down, Octal 32 0x1A (Control-xZ) is cursor up,
Octal 10 0xA (line feed) is Control-J, Cursor up is Octal 30 -- 0x18
Control-x is cursor right, Cursor left is Octal-8 -- 0x10 -- Control-H
(backspace). Direct cursor addressing was Control-N Yaddress char
Xaddress char. Doesn't look anything like VT52. That was Escape Y
followed by the coordinates on the screen.
Never set mine to anything older than VT52. CP/M kermit did good VT52
on old 8-bit microcomputers so I could use KED/EDT etc from all my
stuff.
The Gemini/Telecon Zorba/H19/H89 even had the keypad IIRC.

ISTM that the Atari ST, used in "full screen" mode, supported the
VT52 escape codes. One could use those escape codes to write a
full screen editor for the Atari ST.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[David Powell]

Post by j***@aol.com

Post by William Pechter

Post by j***@aol.com
Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines...

Was it really 72? I can the screen in my head but I can't
count the bloody characters that are displayed.

Yup, 72*20. It was marketed as a KSR33 replacement, particularly for
environments (eg hospitals) where TTY noise, smell, etc were not
appreciated.

Post by j***@aol.com

Post by William Pechter
Upper case only IIRC.

Oh, yes. Definitely that. It made it useless to use for
editing purposes. The convention used was to prefix each
lower case character with a single quote.

Post by William Pechter
I don't remember any terminal VT05 compatibility requirements in my DEC

(82-86

Post by William Pechter
)days. Pretty much everything was VT52 compatible

Right. Which was VT05 compatible. That's why all SET TTY TTY
commands drop back to VT05.

Most of the VT52 commands were compatible with VT50. IIRC, nothing
was compatible with VT05. VT50 was the one with12 lines only.

Post by j***@aol.com

Post by William Pechter
(this requirement made
VT100's have that VT52 mode built in...). That was carried on to the
VT 220/240 and later ones.

Yes. I wish I could remember the PITA "feature" that was put into
the VT05 and then proprogated forever after because the subsequent
generations had to be VT05 compatible.

Guess: fill chars after LF. VT05 needed 4 nulls at 2400 after LF,
and for the fancy stuff - erase to eol, etc. No received char buffer,
so XOFF/XON flow control as used by the later stuff was a no-no. On
the PDP-8E, there was no easy way to generate software fill chars, so
the KL8JA TTY async interface card did it in hardware.

Regards,

David P.

[j***@aol.com]

Post by David Powell

Post by j***@aol.com

Post by William Pechter

Post by j***@aol.com
Did VT05s have a buffer? I didn't think so. And everything after that
had to be VT05 compatible.

VT05's were only 72 chars and 12 (IIRC) lines...

Was it really 72? I can the screen in my head but I can't
count the bloody characters that are displayed.

Yup, 72*20.

Definitely not 20. 20 lines may have been worth the other headaches
but I was using the first ones.

Post by David Powell
It was marketed as a KSR33 replacement, particularly for
environments (eg hospitals) where TTY noise, smell, etc were not
appreciated.

And trash. Don't forget the trash. Hospitals didn't, generally,
need the TTY hardcopy either. The printer (which ended being an
LAnn) was their hardcopy. The noise didn't abate. Besides,
hospitals are the most noisy places. They are never quiet
and the sounds are unique to the point that I can burst
into tears because it triggers a post partum memory from
the time JMF was sick.

Post by David Powell

Post by j***@aol.com

Post by William Pechter
Upper case only IIRC.

Oh, yes. Definitely that. It made it useless to use for
editing purposes. The convention used was to prefix each
lower case character with a single quote.

Post by William Pechter
I don't remember any terminal VT05 compatibility requirements in my DEC

(82-86

Post by William Pechter
)days. Pretty much everything was VT52 compatible

Right. Which was VT05 compatible. That's why all SET TTY TTY
commands drop back to VT05.

Most of the VT52 commands were compatible with VT50. IIRC, nothing
was compatible with VT05. VT50 was the one with12 lines only.

It's clear that I don't know what I'm talking about; this means
that the memories of conversations the guys had are gone or
they were talking about something other than what you guys think
of as compatibility.

Post by David Powell

Post by j***@aol.com

Post by William Pechter
(this requirement made
VT100's have that VT52 mode built in...). That was carried on to the
VT 220/240 and later ones.

Yes. I wish I could remember the PITA "feature" that was put into
the VT05 and then proprogated forever after because the subsequent
generations had to be VT05 compatible.

Guess: fill chars after LF. VT05 needed 4 nulls at 2400 after LF,
and for the fancy stuff - erase to eol, etc. No received char buffer,
so XOFF/XON flow control as used by the later stuff was a no-no. On
the PDP-8E, there was no easy way to generate software fill chars, so
the KL8JA TTY async interface card did it in hardware.

How about software settings like parity and stop bits and junk
like that (note I have no idea what I'm talking about except
that they were a FPITA to get any TTY to work).

/BAH

[Brian Inglis]

On Fri, 22 Sep 06 11:52:19 GMT in alt.folklore.computers,

Post by j***@aol.com
It's clear that I don't know what I'm talking about; this means
that the memories of conversations the guys had are gone or
they were talking about something other than what you guys think
of as compatibility.

Post by David Powell

Post by j***@aol.com
Yes. I wish I could remember the PITA "feature" that was put into
the VT05 and then proprogated forever after because the subsequent
generations had to be VT05 compatible.

Guess: fill chars after LF. VT05 needed 4 nulls at 2400 after LF,
and for the fancy stuff - erase to eol, etc. No received char buffer,
so XOFF/XON flow control as used by the later stuff was a no-no. On
the PDP-8E, there was no easy way to generate software fill chars, so
the KL8JA TTY async interface card did it in hardware.

How about software settings like parity and stop bits and junk
like that (note I have no idea what I'm talking about except
that they were a FPITA to get any TTY to work).

Speed, parity, and stop bits were hardware settings in the UART; easy
to remember: speed set was 1/16 of the line sampling clock rate;
parity had to agree with whatever the receiver expected; stop bits set
to 2 <= 110bps; 1.5 <= 200bps; 1 >= 300 bps.
Fill and XON/XOF were settings for what the software had to do.

[Joe Pfeiffer]

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

You can, but it would have been prohibitively expensive in 1970.

[Brian Inglis]

fOn 11 Sep 2006 08:10:07 -0600 in alt.folklore.computers, Joe Pfeiffer

Post by Joe Pfeiffer

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

You can, but it would have been prohibitively expensive in 1970.

Video output that disappears on the next field/frame is not very
useful to humans.

[Charlie Gibbs]

Post by Brian Inglis
Video output that disappears on the next field/frame is not very
useful to humans.

Except in subliminal advertising.

[j***@aol.com]

Post by Joe Pfeiffer

Post by j***@aol.com

Post by Brian Inglis
fOn Sun, 10 Sep 2006 10:28:05 -0400 in alt.folklore.computers,

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

There is an intermediate: a whole screen bit buffer (like Hercules
mono graphics) instead of just a character buffer, address counters,
character lookup ROM, scan line shift register, as in 6845-like glass
TTY and early PC designs.

You people have been windowed. You can't keep a screen buffer
when your work is purely timesharing, as in user interaction
in a linear TTY direction.

You can, but it would have been prohibitively expensive in 1970.

Point. It was possible but highly unlikely unless you were using
a CTY at an engineering school. Did you guys tell me these
were raster screens?

I've just been amazed how everybody seems to have forgotten
how touch typing typewriters used to work. :-)

/BAH

[Charles Richmond]

[snip...] [snip...] [snip...]
I've just been amazed how everybody seems to have forgotten
how touch typing typewriters used to work. :-)

There is an interesting point about touch typing on a typewriter.
The old-style typewriters with the type on the end of type bars,
you had to type in rhythm from letter to letter. If you typed
the "h" too soon after the "t" for the word "the", you ended up
with a key jam of colliding type bars.

With electronic typewriters that use type balls or daisy wheels,
it is impossible to jam non-existant type bars. You can get away
with typing out of rhythm. These typewriters usually contain
memory buffers to hold at least the next 20 keystokes or more.

It is the same for dumb terminals and for personal computers.
If you plot keystrokes over time, you will see undulating curves
of speed up and slow down...like playing a musical piece on a
piano.

BTW, "touch typing" is now called "keyboarding", and kids learn
it *no* later than the fourth grade.

"Computing is fundamental." ;-)

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Floyd L. Davidson]

Post by Charles Richmond

[snip...] [snip...] [snip...]
I've just been amazed how everybody seems to have forgotten
how touch typing typewriters used to work. :-)

There is an interesting point about touch typing on a typewriter.
The old-style typewriters with the type on the end of type bars,
you had to type in rhythm from letter to letter. If you typed
the "h" too soon after the "t" for the word "the", you ended up
with a key jam of colliding type bars.
With electronic typewriters that use type balls or daisy wheels,
it is impossible to jam non-existant type bars. You can get away
with typing out of rhythm. These typewriters usually contain
memory buffers to hold at least the next 20 keystokes or more.

With Teletype machines (e.g., model 15 and model 28) in the days
when most Teletype circuits ran at 45.5 baud (60 wpm), the
keyboard provided feedback to set a rhythm for the operator.
When a key was pressed, that would *lock* all of the other keys
in the up position; then when the letter had been typed/sent,
they keyboard would *push* the key back up and then unlock the
keyboard. Hence there was no typeahead, but anyone who could
type at 60 wpm could sit there and bang out text at *exactly*
machine speed.

However, the tape punch alone (e.g., on a 28 ASR) could be
driven, and then the keyboard would run at something like 150
wpm, and the lack of feedback was very difficult for those used
to it.

Likewise when a Teletype operator moved to a typewriter or to a
computer, that lack of feedback was a very difficult adjustment.

Post by Charles Richmond
It is the same for dumb terminals and for personal computers.
If you plot keystrokes over time, you will see undulating curves
of speed up and slow down...like playing a musical piece on a
piano.
BTW, "touch typing" is now called "keyboarding", and kids learn
it *no* later than the fourth grade.

In 1960, for the 9th grade I attended High School in a district
with 3000 HS students. They could not figure out how, in a four
year program, to put a *boy* into a typing class, even though
they had one every hour. I was frustrated and furious, but had
no idea how to fight that.

Fortunately, my family moved and for the 10th grade I was in a
different school district. This school had about 500 students
in High School, and I initially assumed that they would be if
anything *far* less flexible. They only had 1 typing class per
semester. When I asked about a typing class I assumed, since I
was registering just a couple weeks before classes started, that
I would again be told there just was no way to fit me into a
typing class...

Much to my surprise, the fellow said, "Sure! When do you want
to take it? Hmmmm... we can put you in either the first
semester or the second semester, which one would you like?"

(Hey, in 1961, being one of two boys in a class with 20 girls
was *really* fun too!)

Post by Charles Richmond
"Computing is fundamental." ;-)

These days I occasionally visit a pre-school class (which
happens to be in "the most expensive per square foot school ever
built in the US", thanks to Prudhoe Bay oil dollars in the
1980's). They teach 3 and 4 year old children how to keyboard.
I also often escort a 4 year old on trips to the local library,
and watch him sit down to a computer and bring up games on the
Internet. He can't read yet, but...

Mind boggling.

[Charlie Gibbs]

Post by Charles Richmond
BTW, "touch typing" is now called "keyboarding",

Not to me it isn't. And I don't do it to "input" anything, either.

Post by Charles Richmond
and kids learn it *no* later than the fourth grade.

I took a typing class in junior high just for the hell of it.
It turned out to be one of the best things I ever did.

[j***@aol.com]

Post by Charlie Gibbs

Post by Charles Richmond
BTW, "touch typing" is now called "keyboarding",

Not to me it isn't. And I don't do it to "input" anything, either.

Post by Charles Richmond
and kids learn it *no* later than the fourth grade.

I took a typing class in junior high just for the hell of it.
It turned out to be one of the best things I ever did.

Yup. My youngest brother was not the school type and had
my sister do his work for him. I told him that he could fuck
off all through high school as long as he took the typing
class and learned how to type. It's 40 years later, and he's
still thanking me for that one piece of advice.

/BAH

[s***@rohan.sdsu.edu]

Post by Charlie Gibbs

Post by Charles Richmond
BTW, "touch typing" is now called "keyboarding",

Not to me it isn't. And I don't do it to "input" anything, either.

Post by Charles Richmond
and kids learn it *no* later than the fourth grade.

....where they're "taught" to use PowerPoint and Excel, and to
drive the mouse with one hand *all* *the* *time*. Or so it seems
from what I hear from my sister. "They have PowerPoint homework
tonight..."

Post by Charlie Gibbs
I took a typing class in junior high just for the hell of it.
It turned out to be one of the best things I ever did.

I was 20 when I decided I really needed to learn how to touch-type. In
hindsight, I shouldn't have waited, but I should've signed up for one
of those typing classes.

[CBFalconer]

... snip ...

Post by s***@rohan.sdsu.edu

Post by Charlie Gibbs
I took a typing class in junior high just for the hell of it.
It turned out to be one of the best things I ever did.

I was 20 when I decided I really needed to learn how to touch-type.
In hindsight, I shouldn't have waited, but I should've signed up
for one of those typing classes.

I was out of high school at 15, and took a year off before going to
college, working for Canadian Pacific Railways as an office boy and
then 'junior clerk'. It all meant filing things. There was a
typewriter on my desk, considerably older than I was, with two inch
key travel. The powers had an attitude towards idle personnel, so
I took a book for a typing course and taught myself, thus looking
extremely busy, and never getting caught reading science fiction.
Those were the days when you worked on Saturday mornings. That
armored me later for Saturday morning classes, but I could skip
those with fewer evil consequences.

[Anne & Lynn Wheeler]

Post by CBFalconer
I was out of high school at 15, and took a year off before going to
college, working for Canadian Pacific Railways as an office boy and
then 'junior clerk'. It all meant filing things. There was a
typewriter on my desk, considerably older than I was, with two inch
key travel. The powers had an attitude towards idle personnel, so
I took a book for a typing course and taught myself, thus looking
extremely busy, and never getting caught reading science fiction.
Those were the days when you worked on Saturday mornings. That
armored me later for Saturday morning classes, but I could skip
those with fewer evil consequences.

old thread from last year:
http://www.garlic.com/~lynn/2005e.html#63 Mozilla v Firefox
http://www.garlic.com/~lynn/2005f.html#2 Mozilla v Firefox

and thread about school:
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
http://www.garlic.com/~lynn/2002o.html#1 Home mainframes
http://www.garlic.com/~lynn/2002o.html#2 Home mainframes
http://www.garlic.com/~lynn/2003n.html#41 When nerds were nerds
http://www.garlic.com/~lynn/2004c.html#19 IT jobs move to India
http://www.garlic.com/~lynn/2004e.html#45 going w/o sleep
http://www.garlic.com/~lynn/2004g.html#0 Usenet invented 30 years ago by a Swede?
http://www.garlic.com/~lynn/2004k.html#41 Vintage computers are better than modern crap !
http://www.garlic.com/~lynn/2006j.html#26 virtual memory

[Joe Pfeiffer]

I took typing in high school, since I knew I'd be doing computers.
But I dropped the class in the middle of the trimester when they
started going over the number row, since keypunch machines didn't put
numbers up there, and I was never going to be using a standard
keyboard.

Oops.

[j***@aol.com]

Post by Joe Pfeiffer
I took typing in high school, since I knew I'd be doing computers.
But I dropped the class in the middle of the trimester when they
started going over the number row, since keypunch machines didn't put
numbers up there, and I was never going to be using a standard
keyboard.
Oops.

ROTFLMAO. Oops, indeed. When I was working for the university,
my fingers had to know, at one point, ~6 flavors of key arrangements.
It was not unusual to type a three different key arrangements within
an hour. My method was to sit down at the machine I was going to use,
close my eyes, and have an ooohhhhmmmmm moment. There were always
certain keys that my fingers would "forget" about. I had a specific
mental exercise of "pretend typing" for each piece of equipment; I
moved my fingers to get the feel of the touch but I didn't strike.
This mental exercise all took about 5 seconds.

/BAH

[Charles Richmond]

Post by Joe Pfeiffer
I took typing in high school, since I knew I'd be doing computers.
But I dropped the class in the middle of the trimester when they
started going over the number row, since keypunch machines didn't put
numbers up there, and I was never going to be using a standard
keyboard.

Speaking of the different items covered in a typing class: The
typing book was arguably *the* most structured presentation I
have ever seen. The folks who write these books must be anal/
retentive. Each incremental step from lesson to lesson is laid
out with extreme care. And their prescribed ways to do things
allow for little variation.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Charles Richmond]

Post by Charlie Gibbs

Post by Charles Richmond
BTW, "touch typing" is now called "keyboarding",

Not to me it isn't. And I don't do it to "input" anything, either.

Post by Charles Richmond
and kids learn it *no* later than the fourth grade.

I took a typing class in junior high just for the hell of it.
It turned out to be one of the best things I ever did.

ISTM that many valuable things are done "just for the hell of
it", instead of following the crowd and "doing what you are
supposed to do". And there tended to be a lot of females in
a typing class...that had to be a plus for a junior high boy.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Peter Flass]

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.
If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT. I have a utility to fix things published by

Underlining is a special case. Later 3270s had underline as well as
blink attributes. On VGA displays I think underlining is handled by the
same logic as the underline cursor.

[j***@aol.com]

.... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

It's impossible. An overstrike of the underline erased the previous
character.

If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT.

Slam noted. Fuck off. We were good but we didn't do the
impossible.

<snip>

/BAH

[Rich Alderson]

Post by j***@aol.com

Post by CBFalconer
If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT.

Slam noted. Fuck off. We were good but we didn't do the
impossible.

Barb, it's not impossible. The on-line man pages, which are produced with a
RUNOFF derivative, do underlining _^He_^Hx_^Ha_^Hc_^Ht_^Hl_^Hy that way: On a
hardcopy terminal (or a later CRT with appropriate microprogramming), you get
underlines, but on a glass TTY you at least get readible text even if you miss
the emphases.

[Carl Lowenstein]

Post by j***@aol.com

.... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

It's impossible. An overstrike of the underline erased the previous
character.

If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT.

This is one of the fundamental differences between DEC RUNOFF and Unix nroff.
RUNOFF outputs <char><backspace><underline>
nroff outputs <underline><backspace><char>
So on a CRT display of RUNOFF output you see only the underlines.

There are filter programs that will sort this out and show the underlines
on a separate text line, just to show on the CRT that they are really there.
This of course messes up the vertical spacing on the page.

carl

[j***@aol.com]

Post by Carl Lowenstein

Post by j***@aol.com

.... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

It's impossible. An overstrike of the underline erased the previous
character.

If your people had been smart they would have ensured that the
underlining came first, so that it would be overwritten by the
actual line on a CRT.

This is one of the fundamental differences between DEC RUNOFF and Unix nroff.
RUNOFF outputs <char><backspace><underline>
nroff outputs <underline><backspace><char>
So on a CRT display of RUNOFF output you see only the underlines.

Ah, another mystery solved. Thank you, thank you, thank you.

Post by Carl Lowenstein
There are filter programs that will sort this out and show the underlines
on a separate text line, just to show on the CRT that they are really there.
This of course messes up the vertical spacing on the page.

And this is all a PITA if the line printer does something different.
Doc prep'ing was a bunch of fun. It is a good example of how
getting a machine to do what a human hand does every day
was next to impossible and required bit god incantation
interventions.

/BAH

[CBFalconer]

Carl Lowenstein wrote:
... snip ...

Post by Carl Lowenstein
This is one of the fundamental differences between DEC RUNOFF and
Unix nroff. RUNOFF outputs <char><backspace><underline>.
Unix nroff outputs <underline><backspace><char>
So on a CRT display of RUNOFF output you see only the underlines.
There are filter programs that will sort this out and show the
underlines on a separate text line, just to show on the CRT that
they are really there. This of course messes up the vertical
spacing on the page.

One of which is my stripovr. Std C source available on request.

[1] c:\c\stripovr\2.0>stripovr
No file specified or not found or too many params

Usage: stripovr [options] infile [> outfile]

strips overprinting lines, including <ch><bs><ch>
(An overprint is a line terminated with \r only)

Options:
-1 --savefirst (one) Save 1st of overprinted lines or chars
-b --stripbs Strip <char><bs><char>, see -1
-c --stripcol Strip overstrike backspaces also
-e --stripesc Strip ANSI terminal esc sequences
--help Give this help
default: All options off, saving last item
--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

[Charles Richmond]

Post by Anne & Lynn Wheeler
... snip ...

Post by j***@aol.com
We considered it a design bug that overstriking would no longer
work on a TV TTY. It's how we underlined documentation. When
you had to underline titles using a typewriter, all you wanted
was a <CR> and not a <LF>. There was a very good reason
to keep these two characters separate.

Overstriking on a CRT is just not feasible, unless the entire
system is bit-mapped. Then you have (wait for it) windows gui.

During my college days, we used a very cheap video terminal. It
did *not* even have an addressable cursor. Yet with the APL
character set, it *appeared* to support some overstrikes. Perhaps
it only replaced the entire character with another that did
*not* appear on the keyboard. I think it was a model of Tel-Ray
terminal.

--
+----------------------------------------------------------------+
| Charles and Francis Richmond richmond at plano dot net |
+----------------------------------------------------------------+

[Joe Pfeiffer]

Post by Brian Inglis
meant you had to print stuff to see that effect.
So NL was perfectly suited to glass TTYs.

Tektronix?

[Brian Inglis]

On 10 Sep 2006 16:59:09 -0600 in alt.folklore.computers, Joe Pfeiffer

Post by Joe Pfeiffer

Post by Brian Inglis
meant you had to print stuff to see that effect.
So NL was perfectly suited to glass TTYs.

Tektronix?

As Barb might say, that was a feature mainly when the line feed got
dropped in transmission.
I never really got the hang of how you were expected to use those
beasts in glass TTY mode: similar to VM, where you had to hit CLEAR at
the bottom of the screen?

[j***@ecn.ab.ca]

Post by Floyd L. Davidson

Post by j***@ecn.ab.ca
This complicated software somewhat, since now it wasn't possible to
first echo every character typed, and then figure out what to do
extra later.

I don't understand what that was supposed to mean.

If the user typed a CR to signal a line of text was finished, then if
the CR is echoed immediately, and *then* the computer adds an LF, while
the print element is moving back to the beginning of the line, no time
is wasted.

In the other case, you have to examine characters _before_ you echo
them, or you waste time doing the LF before the CR.

John Savard

[Floyd L. Davidson]

Post by j***@ecn.ab.ca

Post by Floyd L. Davidson

Post by j***@ecn.ab.ca
This complicated software somewhat, since now it wasn't possible to
first echo every character typed, and then figure out what to do
extra later.

I don't understand what that was supposed to mean.

If the user typed a CR to signal a line of text was finished, then if
the CR is echoed immediately, and *then* the computer adds an LF, while
the print element is moving back to the beginning of the line, no time
is wasted.
In the other case, you have to examine characters _before_ you echo
them, or you waste time doing the LF before the CR.

But you still do have to examine each character.

if (ch == LF) {
putc(CR, fp);
putc(LF, fp);
} else putc(ch, fp);

As opposed to,

putc(ch, fp);
if (ch == CR) putc(LF, fp);

I don't see difference as a significant economy (saving one
function call added to the code). And since in fact that would
usually be a switch-case construct and signficantly more
complex, it would be even less significant.

On the other hand I suspect that a bare CR is much more useful
than a bare LF; hence, encumbering LF is less of a loss in
functionality. Which is, I believe, the reason LF was chosen
rather than CR.

[Joe Pfeiffer]

This whole discussion strikes me as an unfortunate historical artifact
reflecting the fact that ASCII confused the information being
represented with low-level device control. While it was necessary
(given the limits of the early TTYs) to be able to intermix
information with device control when communicating with a terminal,
the American Standard Code for INFORMATION Interchange should never
have had just about anything I can think of in the codes from 0 to 1F.
That stuff is all an incredible jumble of device control (CR) and packet
description (STX, ETX), and has hurt us to this day.

[Floyd L. Davidson]

Post by Joe Pfeiffer
This whole discussion strikes me as an unfortunate historical artifact
reflecting the fact that ASCII confused the information being
represented with low-level device control. While it was necessary
(given the limits of the early TTYs) to be able to intermix
information with device control when communicating with a terminal,
the American Standard Code for INFORMATION Interchange should never
have had just about anything I can think of in the codes from 0 to 1F.
That stuff is all an incredible jumble of device control (CR) and packet
description (STX, ETX), and has hurt us to this day.

I don't understand your complaint. I'm also not sure that
"device control" is not a correct description for all of the
control characters. Initially codes like STX and ETX *did*
control the device, just as much as CR did. The device was
mechanical...

But whether it is "device control" or "packet description", none
of the control codes are part of the information itself, and
hence did need to be distinct in some way. And there was never
any requirement that control codes be used exclusively for the
designated control function; those were merely the defaults and
the most common usage.

The method chosen isn't all that bad either! The alternative
would have been embedded escape sequences, which off hand I
can't see any advantage too. What would have been nicer, though
it is hard to fault them given circumstances at the the time,
would have been using all 8 bits rather than just 7.

Maybe you can explain better what difference you see, and how
that has "hurt us to this day"???

[Peter Flass]

Post by Floyd L. Davidson
The method chosen isn't all that bad either! The alternative
would have been embedded escape sequences, which off hand I
can't see any advantage too. What would have been nicer, though
it is hard to fault them given circumstances at the the time,
would have been using all 8 bits rather than just 7.

It's all SMOP anyway. Systems support all kinds of terminals with all
kinds of conventions, and that's all handled by the appropriate drivers.
As far as the conventions for storing data internally are concerned,
the Unix method has one advantage and two disadvantages.
A. The line delimiter (LF) takes up only one byte.
D. Text data can't contain imbedded linefeeds.
D. Text data also can't contain imbedded nulls.
Personally I prefer methods that keep text lines "pure", for example
storing data with a count prefix, or, as I believe CMS does, storing the
count separately from the line.

[Anne & Lynn Wheeler]

Post by Peter Flass
It's all SMOP anyway. Systems support all kinds of terminals with all
kinds of conventions, and that's all handled by the appropriate
drivers. As far as the conventions for storing data internally are
concerned, the Unix method has one advantage and two disadvantages.
A. The line delimiter (LF) takes up only one byte.
D. Text data can't contain imbedded linefeeds.
D. Text data also can't contain imbedded nulls.
Personally I prefer methods that keep text lines "pure", for example
storing data with a count prefix, or, as I believe CMS does, storing
the count separately from the line.

re:
http://www.garlic.com/~lynn/2006p.html#45 what's the difference between LF(Line Fee) and NL (New line) ?
http://www.garlic.com/~lynn/2006p.html#50 what's the difference between LF(Line Fee) and NL (New line) ?

that not only applies to terminal stuff ... but also all kinds of
string construction as a countermeasure to numerous kinds to various
buffer related vulnerabilities. lots of past posts on buffer related
vulnerabilities
http://www.garlic.com/~lynn/subpubkey.html#overflow

[Brian Inglis]

On Tue, 05 Sep 2006 10:47:45 GMT in alt.folklore.computers, Peter

Post by Peter Flass
Personally I prefer methods that keep text lines "pure", for example
storing data with a count prefix, or, as I believe CMS does, storing the
count separately from the line.

On CMS every blank line has to contain one space. Duh!

[Joe Pfeiffer]

Post by Floyd L. Davidson

Post by Joe Pfeiffer
This whole discussion strikes me as an unfortunate historical artifact
reflecting the fact that ASCII confused the information being
represented with low-level device control. While it was necessary
(given the limits of the early TTYs) to be able to intermix
information with device control when communicating with a terminal,
the American Standard Code for INFORMATION Interchange should never
have had just about anything I can think of in the codes from 0 to 1F.
That stuff is all an incredible jumble of device control (CR) and packet
description (STX, ETX), and has hurt us to this day.

I don't understand your complaint. I'm also not sure that
"device control" is not a correct description for all of the
control characters. Initially codes like STX and ETX *did*
control the device, just as much as CR did. The device was
mechanical...
But whether it is "device control" or "packet description", none
of the control codes are part of the information itself, and
hence did need to be distinct in some way. And there was never
any requirement that control codes be used exclusively for the
designated control function; those were merely the defaults and
the most common usage.
The method chosen isn't all that bad either! The alternative
would have been embedded escape sequences, which off hand I
can't see any advantage too. What would have been nicer, though
it is hard to fault them given circumstances at the the time,
would have been using all 8 bits rather than just 7.
Maybe you can explain better what difference you see, and how
that has "hurt us to this day"???

We can debate whether there are two or three different "kinds" of
information being stored in an undifferentiated way in ASCII and its
descendants without affecting the basic point that both information
and non-information is stored together. The best example I can think
of why it's a problem is this very thread: if ASCII had had a
standard newline character we wouldn't have three different ways for
Mac, UNIX, and MS to mark end of line in a file; we wouldn't have RFC
822 specifying that lines end with a crlf pair, file transfer
utilities wouldn't have separate binary and text modes....

The alternative would have been to recognize that only information
should be stored in files, and that device control should be generated
on the fly by the OS (or utilities) depending on the device being
driven.

[Anne & Lynn Wheeler]

Post by Joe Pfeiffer
The alternative would have been to recognize that only information
should be stored in files, and that device control should be generated
on the fly by the OS (or utilities) depending on the device being
driven.

are we talking about gml (precursor to sgml, html, xml and various
other markup languages)?
http://www.garlic.com/~lynn/subtopic.html#sgml

in addition to cms being done at the science center
http://www.garlic.com/~lynn/subtopic.html#545tech

previous ref in this thread
http://www.garlic.com/~lynn/2006p.html#51 what's the difference between LF(Line Fee) and NL (New line) ?

gml was invented at the science center in 1969 and support added to
cms script ... recent cms script ref:
http://www.garlic.com/~lynn/2006p.html#27 What part of z/OS is the OS?

[j***@ecn.ab.ca]

Post by Anne & Lynn Wheeler

Post by Joe Pfeiffer
The alternative would have been to recognize that only information
should be stored in files, and that device control should be generated
on the fly by the OS (or utilities) depending on the device being
driven.

are we talking about gml (precursor to sgml, html, xml and various
other markup languages)?

I think he is just talking about something *way* simpler - that the
fact that a DECwriter, say, will prefer to receive CR, then LF, at the
end of every line it prints is really *not* a good argument for
including a CR and an LF at the end of every record sitting on a disk
drive.

Some means of delimiting records in a file, though, is required in
addition to the data in the records. Thus, the statement "only
information should be stored in files" could be misconstrued as
something that wouldn't work in practice.

John Savard

[Joe Pfeiffer]

Post by j***@ecn.ab.ca

Post by Anne & Lynn Wheeler

Post by Joe Pfeiffer
The alternative would have been to recognize that only information
should be stored in files, and that device control should be generated
on the fly by the OS (or utilities) depending on the device being
driven.

are we talking about gml (precursor to sgml, html, xml and various
other markup languages)?

I think he is just talking about something *way* simpler - that the
fact that a DECwriter, say, will prefer to receive CR, then LF, at the
end of every line it prints is really *not* a good argument for
including a CR and an LF at the end of every record sitting on a disk
drive.

Exactly.

Post by j***@ecn.ab.ca
Some means of delimiting records in a file, though, is required in
addition to the data in the records. Thus, the statement "only
information should be stored in files" could be misconstrued as
something that wouldn't work in practice.

True -- especially since I never defined 'information'. But you've
got the idea.

[Anne & Lynn Wheeler]

Post by Joe Pfeiffer
True -- especially since I never defined 'information'. But you've
got the idea.

i had met to include a :) ... sorry

ref:
http://www.garlic.com/~lynn/2006p.html#52 what's the difference between LF(Line Fee) and NL (New line) ?


are we talking about gml (precursor to sgml, html, xml and various
other markup languages)? :)
http://www.garlic.com/~lynn/subtopic.html#sgml

[Brian Inglis]

On 04 Sep 2006 20:10:29 -0600 in alt.folklore.computers, Joe Pfeiffer

Post by Joe Pfeiffer
This whole discussion strikes me as an unfortunate historical artifact
reflecting the fact that ASCII confused the information being
represented with low-level device control. While it was necessary
(given the limits of the early TTYs) to be able to intermix
information with device control when communicating with a terminal,
the American Standard Code for INFORMATION Interchange should never
have had just about anything I can think of in the codes from 0 to 1F.
That stuff is all an incredible jumble of device control (CR) and packet
description (STX, ETX), and has hurt us to this day.

This was standardized long before packets: those were line control
characters used by some terminals (inc. Diablo daisy wheels IIRC)
similar to ASR TTY DC1-DC4.

[Jim Haynes]

Post by j***@ecn.ab.ca
For some bizarre reason, the default UNIX convention - which,
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose.

The bizarre reason was the coming of 1968 ASCII, and the desire of some
participants for a combination carriage return and linefeed like the
typewriter-based terminals had. So 1968 ASCII provided for keeping the
CR and LF but as an alternative using LF as a "new line" character that
would do both. And Teletype implemented this as an option in its short-
lived Model 37 printer (upper-lower case, 150 wpm, heavy-duty) which
the people at Bell Labs working on Unix had in mind to use.

[Floyd L. Davidson]

Post by Jim Haynes

Post by j***@ecn.ab.ca
For some bizarre reason, the default UNIX convention - which,
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose.

The bizarre reason was the coming of 1968 ASCII, and the desire of some
participants for a combination carriage return and linefeed like the
typewriter-based terminals had. So 1968 ASCII provided for keeping the
CR and LF but as an alternative using LF as a "new line" character that
would do both. And Teletype implemented this as an option in its short-
lived Model 37 printer (upper-lower case, 150 wpm, heavy-duty) which
the people at Bell Labs working on Unix had in mind to use.

I found a document titled "Some Notes on Teletype Corporation",
which it seems is written by "someone" who worked (?) there, and
may have been directly involved:

I remember newline being talked about, but not much of
what was said about it. The basic idea was to make the
TTY machine more typewriter-like; and typewriters have a
single key for carriage return and line feed. It takes
some extra learning for a typewriter typist to use a
Teletype machine.

One might wonder why the LF character was chosen as NL
rather than the CR character. I believe the reason was
compatibility. If you send CR-LF to a machine that is
set up for NL, then the carriage returns and the line
spaces once, which is what you had in mind. Whereas if
CR had been used for the newline character then sending
CR-LF would result in two line spaces rather than one.

http://www.baudot.net/docs/haynes--notes.pdf

This fellow seem to know what he's on about! ;-)

I got a particular kick out of this sentence,

It takes some extra learning for a typewriter typist
to use a Teletype machine.

Going from a Teletype machine to a computer keyboard was an
interesting learning experience too...

[Philip Homburg]

Post by j***@ecn.ab.ca
For some bizarre reason, the default UNIX convention - which,
fortunately, can be changed depending on one's terminal type - was to
have the user type a "Line Feed" rather than a "Carriage Return" for
this purpose. This complicated software somewhat, since now it wasn't
possible to first echo every character typed, and then figure out what
to do extra later. Also, not all ASCII terminals have a "Line Feed"
key, or, at least, they don't have one in a convenient place. (Note
that, even "in UNIX environments", terminals did what they always did
with a line feed character, and thus the computer running the UNIX
operating system still had to echo a carriage return as well as a line
feed to the terminal - after receiving, as was its wont, a line feed
from the user.)

What Unix are you talking about?

The Unix versions I know want a CR from the terminal. Internally Unix
uses a LF to signal end of line but that is not a hardware interface issue.

On output, the Unix terminal driver also converts that LF into a CR-LF pair.

So, Unix software doesn't know anything about the CR-LF business (unless you
put the tty device in raw mode). Applications get LF from the terminal
driver and also send LF to the terminal driver. This is quite consistent.

The advantage of the Unix approach (as opposed to the Mac approach of using
a lone CR to signal EOL) is that a Unix application can use a CR to cause
a carriage return without causing a linefeed as well.

I guess the best solution would have been to have a completely separate
EOL character.

[j***@ecn.ab.ca]

Post by Paul Gilmartin
And the "C" language standard
presumes a single character, represented by "\n" in character and string
denotations with the NL function. There's likely a causal relation; I don't
know which convention claims primacy.

As the first C compiler was written in order to facilitate the
implementation of UNIX, the two are intimately related.

There's nothing wrong with C doing that. The *operating system* takes
care of handling the requirements of the various printing terminals,
display terminals, and line printers attached to the computer. So if
the convention is that a user program sends a line feed character to
the operating system to start printing on a new line, that is perfectly
well.

In the world I'm familiar with, to print text, you might call a routine
that uses the convention that the first character of the string you are
transmitting to be printed indicates where the text shall be put -
perhaps at the top of a new page, perhaps at the beginning of a new
line, perhaps overprinted on top of the last text printed.

You might have the *option* of assigning a logical input-output unit (I
think you call them "file handles") to a device in 'binary' mode, in
which case your program could actually transmit control characters and
expect them to do something. In that mode, of course, it is helpful to
read the manual for the device, and the operating system shall not add
line feeds after your carriage returns for you. This mode is very
helpful, for example, if you would like to draw pictures on the screen
of a Tektronix 4010 terminal.

But for the ordinary computer user, there *are* no control characters.
Those are for telecommunications engineers to worry about. A disk file
is made up of a bunch of Pascal strings, not C strings, and so you can
mix binary data with text data in files without the slightest fear that
one might tamper with record boundaries thereby.

I can't, for the life of me, think of a good reason for the makers of
CP/M, MS-DOS which came after it, the Commodore-64, the Apple
Macintosh, and so many other microcomputers, to follow the lead of UNIX
in this regard - even if they did use CR or CRLF to delimit records
instead of LF -instead of following the practice on a *real*
computer... i.e., an IBM mainframe.

Of course, it may have helped that most people who *used* IBM
mainframes had to struggle with JCL. If only the Michigan Terminal
System had been more popular... then people would have _seen_ what a
computer is supposed to be like, and they would have gotten it right!

John Savard

[Brian Inglis]

On 4 Sep 2006 13:04:46 -0700 in alt.folklore.computers,

Post by j***@ecn.ab.ca
But for the ordinary computer user, there *are* no control characters.
Those are for telecommunications engineers to worry about. A disk file
is made up of a bunch of Pascal strings, not C strings, and so you can
mix binary data with text data in files without the slightest fear that
one might tamper with record boundaries thereby.
I can't, for the life of me, think of a good reason for the makers of
CP/M, MS-DOS which came after it, the Commodore-64, the Apple
Macintosh, and so many other microcomputers, to follow the lead of UNIX
in this regard - even if they did use CR or CRLF to delimit records
instead of LF -instead of following the practice on a *real*
computer... i.e., an IBM mainframe.

Mainframes of the time were not very interactive and did not store
record delimiters; most interactive systems of the time distinguished
between text and binary data files and used CR-LF line terminators for
text.

[Floyd L. Davidson]

Post by Brian Inglis

Post by j***@ecn.ab.ca
But for the ordinary computer user, there *are* no control characters.
Those are for telecommunications engineers to worry about. A disk file
is made up of a bunch of Pascal strings, not C strings, and so you can
mix binary data with text data in files without the slightest fear that
one might tamper with record boundaries thereby.
I can't, for the life of me, think of a good reason for the makers of
CP/M, MS-DOS which came after it, the Commodore-64, the Apple
Macintosh, and so many other microcomputers, to follow the lead of UNIX
in this regard - even if they did use CR or CRLF to delimit records
instead of LF -instead of following the practice on a *real*
computer... i.e., an IBM mainframe.

Mainframes of the time were not very interactive and did not store
record delimiters; most interactive systems of the time distinguished
between text and binary data files and used CR-LF line terminators for
text.

The use of fixed records, as with punch cards, was acceptable
with data files stored on magnetic tape, but that was also where
the usefulness ended and the gross misapplication began...

When data storage moved to media that was not strictly
sequential, where rapid random seeks were possible, things
either changed or became a monstrosity.

I suffered from one example, the SOS operating system used by
Bell Northern Research on the DMS line of telephone switching
systems. This is hard to imagine today, but in the late 70s
when they added Winchester disk storage to the DMS switching
system, they (apparently being mainframe bigots of the first
order) retained the IBM 9 track tape format to the degree that
they could. It was a abomination (to put it mildly) that was
not recognized until it was fully embedded into the system and
could not easily be removed. Worse yet, the programmers who did
it... left BNR.

I recently met a fellow who was telling me about having done
some contract work for Northern Telecom in the late 80's
cleaning up their system software. I made a crack about the
@#$%^&* disk filesystems, and he all but burst out laughing.
That was indeed one of the nastier things he'd been hired to
sort out and correct. I thanked him for ending the misery,
because before his work it just caused me no end of trouble
every time anyone at Northern Telecom had tried to "fix" the
problems it caused.

[shmuel+ (Shmuel Metz , Seymour J.)]

Post by Paul Gilmartin
ASCII NEL (0x85

There is no '85'x in ASCII, although there is in ISO 8859.

Post by Paul Gilmartin
EBCDIC dogmatists disagree, saying that in such a code page
programmers could no longer rely on NL to perform its historic
function (in fact no such character would be defined at all) on
hardware devices (are any such still in use?),

AFAIK there are still 3270 printers in use. There's also an issue of
multi-line USS messages, which, flowing in the LU-SSCP session, use
SCS.

Post by Paul Gilmartin
BTW, VM/CMS facilities converting ISO8859-1 to IBM-1047 generally
map ASCII LF to 0x25 and ASCII NEL to 0x15,

Translating ASCII LF to EBCDIC LF and ISO 8859-1 NEL to EBCDIC NL
looks like they DTRT. I may be an MVS bigot, but in this case I must
agree with the VM folks.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

Post by Tsai Laurence
I am confused that the difference between LF & NL ?

LF in ASCII is defined as moving down one line while remining in the
same position. NL does not exist in ASCII[1], but does in EBCDIC, and
is defined as moving to the first character of the next line. The
ASCII sequence CR LF[2] has the effect of an NL character.

C and Unix use the LF character as though it were NL.

Post by Tsai Laurence
Can anybody advise me ?

For some languages, e.g., Perl, \n will generate CR, CRLF, LF, NEL or
NL as appropriate. For others you need to know enough about your
environment to use the appropriate character or character sequence.

[1] It does exist in many newer character sets that match ASCII at
code points 0-127, e.g., ISO 8859.

[2] On some devices you need to add the stray NUL to avoid timing
problems.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

Post by Tsai Laurence
I am confused that the difference between LF & NL ?

LF in ASCII is defined as moving down one line while remining in the
same position. NL does not exist in ASCII[1], but does in EBCDIC, and
is defined as moving to the first character of the next line. The
ASCII sequence CR LF[2] has the effect of an NL character.

C and Unix use the LF character as though it were NL.

Post by Tsai Laurence
Can anybody advise me ?

For some languages, e.g., Perl, \n will generate CR, CRLF, LF, NEL or
NL as appropriate. For others you need to know enough about your
environment to use the appropriate character or character sequence.

[1] It does exist in many newer character sets that match ASCII at
code points 0-127, e.g., ISO 8859.

[2] On some devices you need to add the stray NUL to avoid timing
problems.
--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html