rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/02/90)
In article <KINDRED.90May31185056@pyrite.telesci.UUCP> kindred@telesci.uucp writes: +--------------- | Along the lines a strange baud rates, I personally have run | into the all time favorite baud rates of 134.5 and 1050. The 134.5 | was used in a six bit commodities ticker... +--------------- Oh, 134.5 baud was used in stuff *far* more important than a commodities ticker -- that was the speed of the venerable (or damnable) IBM 2741 "Selectric I/O Writer". That is, a Selectric typewriter fixed up with a bit-serial interface. The 2741 was *the* hard-copy remote terminal in much (most? all?) of the IBM world for a number of years, not to mention a few folk who insisted on using it on TOPS-10 and Unix systems because the print quality was far better than any ASR-3x. (Well, it *was* better.) Of course, the 2741 wasn't all that easy to deal with: - It was truly half-duplex. - The keyboard locked when you hit <RETURN>, and didn't unlock until an unlock signal came out from the host. - The host couldn't send to you if the keyboard was locked. - *Some* (but not all) 2741's had an extra-cost option to allow the host to lock a keyboard even if you were typing, by sending a <BREAK>. There was another option that let you lock the keyboard and tell the host about it without typing <RETURN>. And another that let you send an <ATTENTION> to the host even while it was typing. - And of course, the character set wasn't within *miles* of ASCII, and wasn't even EBCDIC, but something all its own. (For example, the 2741 sent the bits in a byte backwards from TTYs.) - Like the TTY Model 29, it had "stateful" shifts. You sent a shift code and then you were stuck until you unshifted. (Or sent a <RETURN>?) - And of course, if you got a line error at exactly the wrong time, you could get stuck in a state you couldn't get out of. (At least, not easily. And not at all if you were an ordinary user without knowledge of the magic incantations to tease it out of its tiff.) I had the dubious honor of being one of the folk at Digital Communications Associates (circa 1977?) who helped to make a 2741 -- when connected through a DCA "SmartMux" -- be able to emulate an ASCII terminal to a DEC PDP-10... all the way up to and including being able to type ASCII control characters (you *do* want to be able to ^C your job, don't you?) and do (sort of) character-at-a-time I/O. That's right, we used all three "options" mentioned above plus a bunch of special code in the SmartMuxes and in a custom TTY driver for the PDP-10 to allow such abominations as editing with TECO ("sABC<ESC>DEF<ESC>0tt<ESC><ESC>" is the same as ed's "s/ABC/DEF/p") and debugging with DDT ("123/" caused location "123" to get typed out -- note there's no <RETURN>). Two notable installations were at the Wharton School of Business in Pennsylvania, and at Western Electric in New Jersey. (Many hours in the middle of several nights before we finally figured out how/why an unexpected "unlock" to the terminal could sometimes crash the PDP-10.) We later did a subset of the reverse, that is, making an ASCII terminal look to an IBM host as if it were a 2741. By the way, that commodities ticker you spoke of almost certainly was emulating a 2741. Nothing else I know of went at that speed. -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
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (06/02/90)
In article <61463@sgi.sgi.com> rpw3@sgi.com (Rob Warnock) writes: >Of course, the 2741 wasn't all that easy to deal with: >- And of course, the character set wasn't within *miles* of ASCII, > and wasn't even EBCDIC, but something all its own. (For example, > the 2741 sent the bits in a byte backwards from TTYs.) There were actually two different 2741 characters sets: Selectric code, which was basically the shift-tilt-rotate bits for the type ball, encoded in a character, and EBCD (Extended BCD), which was more like the code IBM used on its computers. You could generally tell which one was being used by artful parsing of the login sequence. For a long time, most car rental companies used Selectric based terminals for typing contracts (remember Wizard of AVIS?). After all, show me a dot-matrix or thermal printer that can do 3 carbons reliably. Marc Kaufman (kaufman@Neon.stanford.edu)
Leichter-Jerry@CS.YALE.EDU@venus.ycc.yale.edu (06/02/90)
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
jeh@dcs.simpact.com (06/03/90)
In article <1990Jun2.020635.28825@Neon.Stanford.EDU>, kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: > In article <KINDRED.90May31185056@pyrite.telesci.UUCP> kindred@telesci.uucp writes: >> Along the lines of strange baud rates, I personally have run >>into the all time favorite baud rates of 134.5 and 1050. The 134.5 >>was used in a six bit commodities ticker,... > > 134.5 was also the baud rate used by the (half-duplex) IBM 2740 and 2741 > Selectric typewriters. This works out to 14.9+ characters per second, since > they used a 9-bit code (1 start, 1 stop, 7 data - sent HIGH BIT first). Eh, not quite. These beasts used 6 data bits, plus parity. In practice the stop bit from the host was stretched a bit yielding a quoted throughput of 14.7 characters/second. I suspect that the commodities ticker referred to ran at 134.5 simply because it was hooked to an IBM host that already had async ports for that speed. > 1050 was what.. anybody.. I seem to remember Kleinschmidt reperforators > (tape punches) running at that speed. > > Marc Kaufman (kaufman@Neon.stanford.edu) 1050 used to be widely used for "high speed" wire feeds to newspapers. And, yes, some of them used Kleinschmidt gear. The newspaper would receive the stuff on punched paper tape and then feed the tape directly to their typesetter. In later days, of course, the stuff fed directly into the computer for editing. Coincidentally, "1050" was also the series number for several pieces of IBM equipment that collectively behaved sort of like an ASR 2741. There was a separate printer, keyboard, paper tape punch, p.t. reader, and also a card reader. All running at 134.5 bits/sec. Switches on the front of the printer connected the various items to each other, in various combinations for example you could be copying one tape to another "off line" while carrying on a dialog with the host computer via the keyboard and printer. As Jerry mentioned in another posting, both the IBM 2741 and the 1050 were an m.e.'s dream. (As are many pieces of IBM gear. Compare a typical high- speed IBM punched card reader to a Soroban unit; you'll find enough moving parts in the IBM unit to make at least five Sorobans.) They were NOT, as is commonly believed, Selectric mechanisms in different cases; the printers were far more rugged than those in the office Selectric. Early DEC RSTS timesharing systems supported the 2741, probably for the same reason that TOPS-10 did: The 2741 was, for many years, the only way that most folks could get what we now call letter-quality output out of a computer. (The 2741 was around in the mid-60s and so predated daisy-wheel printers and terminals by at least 10 years.) The large amount of DEC documentation that used to be printed in typescript, with an IBM Courier typeface, should tell you something. I used one of these RSTS systems (with Ascii terminals) at Cal Poly Pomona in the late 70s. A favorite way for clowns to lock up a terminal port was to type "SET TERMINAL 2741" and walk away... there of course being NO way to type the command to set the port back to Ascii, or to log out for that matter, without hooking up a 2741 to the line... and of course there were no 2741's available anywhere. Eventually the systems people would notice the dead port and fix it. After several months of complaining about this, with no response, I got desperate enough to post the following message on the state-college-wide computer bulletin board: "Please do NOT type the command SET TERMINAL 2741 on any RSTS port. This will make the port unusable until corrected by the local system manager." Needless to say, this caused lots more people to try SET TERMINAL 2741, and the command was taken out of the command tables within a week. --- Jamie Hanrahan, Simpact Associates, San Diego CA Internet: jeh@dcs.simpact.com, or if that fails, jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!jeh
rpw3@rigden.wpd.sgi.com (Rob Warnock) (06/05/90)
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 <RETURN>), 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<RETURN>"?), and used what they typed to figure out which code. This worked because the <RETURN> 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 <ATTN> key (for "attention"). When talking to APL hosts it worked as noted. When talking to ASCII hosts (e.g., TOPS-10), we used <ATTN> to fake full-duplex. The user typed <ATTN> to turn the line around, allowing typing in control characters. In fact, if the keyboard was unlocked <ATTN> was a normal character, and was used as a "Control" escape. To to type "^C" against output, you typed <ATTN> to turn the line around, then "<ATTN>c" for "^C". And "<ATTN><ATTN>" 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 ("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. +--------------- 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
bourman@hpccc.HP.COM (BobbHewlett-PackardCorpNetEngPaloAltoCa.) (06/06/90)
/ hpccc:comp.dcom.modems / kaufman@Neon.Stanford.EDU (Marc T. Kaufman) / 7:06 pm Jun 1, 1990 / In article <KINDRED.90May31185056@pyrite.telesci.UUCP> kindred@telesci.uucp writes: |> Along the lines a strange baud rates, I personally have run |>into the all time favorite baud rates of 134.5 and 1050. The 134.5 |>was used in a six bit commodities ticker,... | |134.5 was also the baud rate used by the (half-duplex) IBM 2740 and 2741 |Selectric typewriters. This works out to 14.9+ characters per second, since |they used a 9-bit code (1 start, 1 stop, 7 data - sent HIGH BIT first). | |1050 was what.. anybody.. I seem to remember Kleinschmidt reperforators |(tape punches) running at that speed. | |Marc Kaufman (kaufman@Neon.stanford.edu) |---------- WOW, It's nice to hear someone who used to work on the old Kleinschmidts ! The ANFGC20,25,26,56,57 Remember the 5A tickers and the M-15/ M-19 TTY's ??? We used to use old teletypes TTY M32ASR at 50baud 1/4 speed and 1/2 speed to Penang !