The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well.
[EMAIL PROTECTED] (Timothy Sipples) writes: > An awful lot of modems and serial connections had to handle 7-bit, > too, complicating the user experience for dial-up access to host > systems, BBSes, etc. Basically if you set your modem to 7 bits, you > struggled to transfer binary files (see: Kermit), and PC extensions > for things like line drawing characters looked like a jumbled mess. > If you set your modem to 8 bits you usually lost the parity bit, so > you lost what little error checking you had. And a lot of systems > still tried to use that high order bit for parity, so you saw a > jumbled mess on your PC again. Owners of modem dial-up pools > installed workarounds to try to detect what the end user had set, but > this was a mess, too. On some systems you wouldn't see anything, so > you didn't know what to do. (The correct answer: hit Enter a few > times, or maybe Escape, or....) I'm sure AT&T enjoyed some extra > earnings as dial-up modem users had to call over and over again, > hoping to get the configuration settings right through trial and > error, all because of the complications of 7 versus 8 bits. This > affected all sorts of serial connections, including hardwired ones: > plotters, ASCII terminals, etc. when cp67 was installed at the univ the last week of jan68, it had terminal support for 1052s and 2741s ... but the univ. had some number of tty/ascii devices. so one of the modifications to cp67 was to add tty/ascii terminal support. the base cp67 code had some stuff for dynamically determining the terminal type and "switching" the 2702 line scanner using the SAD command. so to remain consistent, i worked out a process to add TTY/ascii terminal support ... preserving the base cp67 dynamic terminal type determination. the univ. also was getting dial-up interface ... with base number that would roll-over to the first unused line. the idea that all terminals could dial in on the same phone number, regardless of type. this "almost" worked ... but it turned out that they had taken some short cuts with 2702 implementation. the issue was that while SAD command would switch the line scanner ... but the short-cut was that the line-speed oscillator was hard-wired to each port. for hard-wired lines ... the appropriate terminal types was connected to the appropriate 2702 with the corresponding line-speed wired (and then cp67 could dynamically determine the correct terminal type and switch the line scanner as needed with the SAD command). However, this wouldn't work for dial-up lines with common dial-in pool ... where any terminal type might get connected to any 2702 port. so somewhat because of this, the univ. decided to build our own clone controller that would also be able to perform dynamic line-speed determination. this involved reverse engineering the 360/67 multiplexor channel interface and building a channel interface board for an Interdata/3 minicomputer (platform for implemented controller clone). misc. past posts about the clone controller project http://www.garlic.com/~lynn/subtopic.html#360pcm i remember two "bugs" from the project. one bug involved "red-lighting" the 360/67. the 360/67 had high-resolution timer that tic'ed at approx 13mseconds. the timer had to update loc. 80 storage when it "tic'ed". If the timer tic'ed a 2nd time before the previous tic had been updated in storage (say because some channel/controller had obtained the storage bus for the period and failed to release it for that perioid), the timer would force a red-light/machine check. the other bug was initially getting ascii data into storage .. after running it thru standard ascii->ebcdic translation table, it was all garbage. we eventually figured out every byte was "bit-reversed" ... i.e. 2702 line-scanner would take leading bit off the line and store it in low-order bit position (in a byte ... reversing the order of bits off the line. the interdata/3 started out doing standard ascii taking leading bit off the line and storing it in the high-order bit in a byte. so initially, the ascii bytes was getting to 360/67 main memory in non-bit-reversed bytes and then being run through the standard 2702 ascii->ebcdic (bit-reversed) translation table. this project got written up as the four of us being instrumental in starting the clone controller business. of course, all the clone controller business was the major motivation for the future system project ... lots of past posts http://www.garlic.com/~lynn/subtopic.html#futuresys including a few with this reference http://www.ecole.org/Crisis_and_change_1995_1.htm from above: 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 ... snip .. there has been various speculation that the extremely boroque characteristics of the pu4/pu5 (vtam/ncp) interface was result of "box strategy", following FS being killed. The lack of attention to the 370 product line (because of the FS distraction) then appeared to provide openings for clone processor makers to gain traction. When FS was finally killed, there then was mad rush to get stuff back into the 370 hardware and software pipelines. I was at the science center during the FS days ... and didn't endure myself to the participants by drawing some analogy between their activities and a cult film that had been playing down in central sq. for over a decade (while continuing to do work on cp67 and 370). ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
