Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!yale!venus!leichter
From: Leichter-Jerry@CS.YALE.EDU@venus.ycc.yale.edu
Newsgroups: comp.dcom.modems
Subject: Re: 134.5 baud == IBM 2741 (was: Re: Why 300 baud?)
Message-ID: <269.2667a0e0@venus.ycc.yale.edu>
Date: 2 Jun 90 16:20:00 GMT
References: <9686@discus.technion.ac.il> <1990May31.025608.18545@Neon.Stanford.EDU> <KINDRED.90May31185056@pyrite.telesci.UUCP> <61463@sgi.sgi.com>
Organization: Yale Computer Center (YCC)
Lines: 68

Rob Warnock brings back some old memories of the 2741.

Actually, he leaves out some of the fun details.  There were TWO different
encodings available for the beast - "encoding" in this being the mapping from
bytes received to positions on the typeball.  Since typeballs were inter-
changeable, this did NOT necessarily correspond to a map between bytes on
the line and glyphs on the screen!  I used 2741's mainmly for APL, and usually
without an APL ball - I got to the point where I could actually read and type
stuff that to most people would look like pure line noise.  (At least the
letters were in the right positions.  However, NONE of the special characters
were.  If you wanted a left paren, you typed ", for example.  I think left
bracket was #.

Anyhow, back to the two mappings:  One was called bit pairing; I think the
other was something like key pairing.  The mapping was determined by the
mechanical inteconnections - the 2741 was a mechanical engineer's dream (or
nightmare).  I think one of the mappings was essentially what you got by
taking a Selectric and making the obvious connections.  The other was a
modification that was loke EBCDIC.

APL supported both maps.  It had a clever way of deciding which map to use:
The login command had the form ")nnnn", where nnnn was your id number.  (The
system operator - "root" - logged in as ")314159".)  Close paren was different
in the two mappings.  APL ignored stuff until it saw either of the two codes
for close paren; at that point, it assigned you to one map or the other.  If
you got assigned to the wrong map, you'd see nothing by gibberish.  The only
way to recover was to disconnect your line - you couldn't even type a logout
command.  If you were on a hard-wired line, you were in trouble!  This was all
in my hacking days, and a friend and I wrote code to change your map.  The
big challenge then was to log in with the WRONG map and and get your session
fixed up in the fewest keystrokes.  We had a pair of functions whose names
were chosen to appear as "fix" in one mapping and as giberish in the other.
Once you got into our hack workspace, in either mapping, typing fix would set
you to the other mapping.

(Few people knew about this feature of APL.  Even fewer knew that there was
a THIRD mapping.  It wasn't used on the 2741, but on some other odd device
that IBM made, which I think only attached to an 1130.  This had a smaller
keyboard, so to fit all the APL characters, to had TWO shifts, with some com-
plex rules for automatic movement among the shift states in certain circum-
stances.)

"Shift" on a 2741 turned the typeball half a rotation - each shift position
gave a map between the input bytes and a position on the current half of the
typeball.  Since "SHIFT" was a character, with suitable hacking you could
send a stream of bytes that made the typeball turn back and forth without
typing anything.  We had some code that clicked out an SOS....

Mr. Warnock mentioned the INTERRUPT key, the only key you could type while
your keyboard was locked.  APL used that to interupt the current program.
A really nasty thing you could do to someone was sent them a very long stream
of UNLOCK's.  Whle their keyboard was unlocked, they couldn't send an INTER-
RUPT....

Now, as to:

> such abominations as editing with TECO ("sABC<ESC>DEF<ESC>0tt<ESC><ESC>"
> is the same as ed's "s/ABC/DEF/p")

Watch yourself there, guy!  This message is being typed to you in TECO - well,
in a screen editor written in TECO.  I've never seen any reason to give it up.

BTW, your example is wrong.  The command you wanted as "FsABC ... ".  The
command you actually gave would (a) find the next "ABC"; delete the character
immediately after it; close the current output file (without writing the
current buffer out first); and then display the current line.

							-- Jerry