Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!mips!sgi!rpw3@rigden.wpd.sgi.com From: rpw3@rigden.wpd.sgi.com (Rob Warnock) Newsgroups: comp.dcom.modems Subject: Re: 134.5 baud == IBM 2741 (was: Re: Why 300 baud?) Message-ID: <61576@sgi.sgi.com> Date: 5 Jun 90 06:37:00 GMT References: <9686@discus.technion.ac.il> <1990May31.025608.18545@Neon.Stanford.EDU> <61463@sgi.sgi.com> <269.2667a0e0@venus.ycc.yale.edu> Sender: rpw3@rigden.wpd.sgi.com Reply-To: rpw3@sgi.com (Rob Warnock) Organization: Silicon Graphics, Inc., Mountain View, CA Lines: 94 In article <269.2667a0e0@venus.ycc.yale.edu> Leichter-Jerry@CS.YALE.EDU@venus.ycc.yale.edu writes: +--------------- | 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,... +--------------- Yes, I left out a lot of details, but you've reminded me of some more of them. For one thing, we did support both line codes (Selectric & EBCD), and since DCA's muxes did autobaud detection from 110 to 2400 (based on user typing a ), when we saw a 134.5 baud terminal we did a second phase of "semi-auto" detection -- we typed out a hello banner in *both* codes, asking the user to type something or other (I forget, maybe like "1"?), and used what they typed to figure out which code. This worked because the and unlock controls were the same for both codes. Yes, the user saw a line of garbage and a line of readable text, but that was o.k., as most 2741 ports in those days didn't even *give* you a choice. +--------------- | 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... +--------------- Aha! Now it comes back! More than that, as Jerry points out, there were *lots* of Selectric type balls, with different sizes, fonts, and characters in different places on the ball. So not only did you have to find out the user's line code, but also their typeball number. So what we had them type in was the 3-digit number stamped into the top of the ball, e.g. "071". Since numbers were disjoint between the two line codes, we could tell what line code and what type ball. If we didn't support a particular ball, we typed out an apology and told them we were defaulting to (usually) Courier 10. (This usually generated an RFE which eventually led to supporting it...) Hmmm... Seems Selectric typeball numbers have experienced some bloat -- they're now up to 5 digits. Some numbers I just saw: 52002 == Courier 10pt (96 char) 52003 == Prestige Elite 12pt (96 char) As I recall, there was at least one case when supporting an older APL ball where we had to try and synthesize characters from the newer balls by overstriking. And for all the balls we had to have ways to represent ASCII characters that didn't exist on the ball. Usually, we did that we underlining or with overstriking to avoid messing up column alignment. Anyway, once we knew their line code and typeball, we could ask them in plain ASCII (on the *other* side of the converter), "Connect to which system?" +--------------- | 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. +--------------- I remember that as the key (for "attention"). When talking to APL hosts it worked as noted. When talking to ASCII hosts (e.g., TOPS-10), we used to fake full-duplex. The user typed to turn the line around, allowing typing in control characters. In fact, if the keyboard was unlocked was a normal character, and was used as a "Control" escape. To to type "^C" against output, you typed to turn the line around, then "c" for "^C". And "" turned the line back around again. But we worked really hard to avoid having the user use ATTN too much. Much of the code added to the TOPS-10 TTY driver had to do with guessing whether the job was blocked waiting on input, whereupon we'd unlock the keyboard. +--------------- | > such abominations as editing with TECO ("sABCDEF0tt" | > 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. +--------------- For one who was such a former TECO fanatic, I nevertheless seem to have fallen prey to the "vi" heresy about a decade ago. ;-} +--------------- | BTW, your example is wrong. The command you wanted as "FsABC ... ". +--------------- Sorry. As you might imagine, it's been a while... -Rob ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311