Date: Mon, 31 Dec 2007 09:41:58 -0600
From: John Foust <jfoust at threedee.com>
I beleive the
original intention was that 0x7F would be _ignored_. The
point being you could overpunch any characeter on paper tape to turn it
into 0x7F (all holes), and thus you could effectively delete that
character from the tape
Wasn't it used to indicate that the previous character could
be ignored?
No--the use is "Rubout"--erase an erroneous character by overpunching
all holes. Deleting characters from punched paper tape is otherwise
very difficult without a pair of scissors.
Back on topic, one thing that seems to be confused here is the
*function* of the newline/carriage return/whatever. One function is
as a format effector (i.e. print control; the other is as a record
delimiter. Confusing the two roles leads to problems.
For example, if CR is used as a record delimiter, then there's no
easy way to indicate that the next line on a printing device should
overprint the next line on the current one. By the same token, using
linefeed as a record delimiter forces the next record to insert
spaces in the next record to simulate a vertical motion of the
printing position without a corresponding return to the beginning of
line.
If one is to have character-delimited records, better to use a
character whose function is to delimit records rather than control
printing behavior.
I believe that the Beehive SuperBee sent 1/15 as an end-of-line
character rather than CR, at least in screen editing mode.
By the same token, 0/8 BS does not imply that a character is to be
erased when the printing position is moved back; the implication is
that the next character will overprint the previous one. CRT
terminals and their simple-minded mode of operation pretty much
forced this behavior and it's curious that with our GUI displays that
we still mimic the faulty behavior. I recall that this was an issue
in the original Videotex spec--IIRC, certain characters could be
combined using BS.
Cheers,
Chuck
