Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Anne & Lynn Wheeler Newsgroups: alt.folklore.computers Subject: Re: CR or LF? Date: Mon, 25 May 2020 15:04:57 -1000 Organization: Wheeler&Wheeler Lines: 57 Message-ID: <875zcj4ibq.fsf@localhost> References: <85f8db34-31c4-4e84-ac08-318f3d04364c@googlegroups.com> <365b2c24-3b9f-4eba-9c67-d31688bdfe5c@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: reader02.eternal-september.org; posting-host="5cd4a31c18c34ab5fd923f9056daf8e8"; logging-data="28037"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/yU5ZqIXNzDMF+agM2fwOQn1xFNInyPGo=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:GEKXVilfdu6MUWcBB8WeCIuv9VY= sha1:sAPyWQV82ScMzMDsY1pjJyA9/X8= Xref: csiph.com alt.folklore.computers:211605 Charlie Gibbs writes: > Multiplexor channels handled all sorts of low-speed record-oriented > peripherals as well, e.g. card readers, line printers, and slower > tape drives. However, when handling character-mode terminals, they > imposed as much overhead per byte as they would for an entire block > of data on those other peripherals - at least if you wanted the > flexibility of responding to each byte as the user typed it. 270x controllers handled terminals ... they had different type of terminal/port scanner for handling different kinds of terminals. The scanner buffered chars and only presented interrupt on specific signals (not each character) when cp67/cms was installed at the univ (last week Jan1968), it had automagic terminal type identification for 2741 and 1052 terminals and would use the controller "SAD" ccw to switch the type of scanner ... trying operations until it got the scanner that worked for that terminal type. the univ. had some number of ASCII TTY 33&35 terminals ... and so added ascii support ... extending the automagic logic of switching type of scanner until got the one for the type of terminal. I wanted to have a single dial-up number for all terminals (single "hunt group") ... which almost worked ... except that while IBM allowed the type of line scanner to be switched for each port ... the line speed was hardwired ... aka 2471 & 1052 were same line-speed ... so could share a common "hunt group" ... but TTY had slower line-speed and would only reliably work on ports that had been wired for that speed. That was part of motivation for the univ. clone controller project, build channel interface board for Interdata/3, programmed to simulate IBM terminal controller ... with the addition that line-speed was (internally) software controlled and could change speed for each line/port. Two early "bugs" ... 1) this was 360/67 with "high" resolution timer that updated storage on each tic. When the interface acquired the memory bus for data transfer ... if it held it for too long, the timer storage update would redlight and stop the machine. 2) turns out standard ibm terminal controller convention reversed the bit order in each byte ... leading bit went into low-order bit position (instead of high position). We had overlooked that detail until we were trying to figure out why data in memory was all garbage. Later this was enhanced to Interdata/4 handling the IBM channel interface and a cluster of Interdata/3s to handle the line/port interfaces. Interdata (and later Perkin/Elmer) sells the boxes as clone controllers and four of us got written up for (some part of) IBM clone controller business. In 80s, supporting UNIX on mainframe, IBM provided a Series/1 front end terminal controller, programmed to handle wider range of ascii character interrupting (and full-duplex) options -- virtualization experience starting Jan1968, online at home since Mar1970