Re: [TUHS] Serial Interfaces (was ^T and Top)

On Tue, May 29, 2018 at 9:10 PM, Dave Horsfall <dave(a)horsfall.org> wrote: Right - you have to escape things and it is a real mess. I have seen some of the SI/SO/DLE stuff in mechanical systems like ticker tape. I never saw a real 8-bit interface try to do it and succeed -- its messy and suspect when data overruns occurs all hell break loose. By the time of 8 bits and speed of 9.6K protocol's like UUCP, or IP over serial did not even bother. I suspect in the old 5-bit baudot code times, it was more popular to get a larger character set, but the speeds were much slower (and the UART not yet invented by Gordon Bell).​ By the time of the PDP-11, hardware flow was the norm in many (most) interfaces. I never understood why DEC got ^S/^Q happy. You can really see the issues with it on my PiDP-8, running DOS/8 because the flow is done by the OS and its much to late to be able to react. So you get screens full of data before the ^S is proceeded. Once Gordon creates the UART, Western Digital licensed it and made it into a chip which most folks used. DEC started to use the WD chipset in PDP-8 serial interfaces - it always struck me as strange that HW flow was not used more. The KL11/DL11 supported the wires, although the SW had to do the work. As I said, MacNamara supported it in the DH11, if I recall (I don't have the prints in any more), he put an AND gate in the interrupt bit, so the OS does not get an transfer complete interrupt unless the "I'm ready" signal is available from the other side. When I lectured data com to folks years ago, I liked to express the ECMA serial interface in this manner: There are 6 signal wires and one reference (signal) ground: 1. Data XMT (output) 2. Data RCV (input) 3. I'm Alive (output) 4. He's Alive (input) 5. I'm Ready (output) 6. He's Ready (input) Everything else is either extra protocol to solve some other problem, or is for signal quality (*i.e. *shielding, line balancing etc.). The names of which signals match to which actual pins on the ECMA interface can be a little different depending on the manufacturer of the 'Data Communicating Equipment (DCE - *a.k.a.* the modem) and the Data Terminating Equipment (DTE - *a.k.a.* the host). BTW: ECMA and the WE did specify both signal names and the connectors to use and I think the European Telco's did also (but I only ever saw a German spec and it was in German which I do not read). DCE's are supposed to be sockets (female and originally DB25)s and DTE's were suppose to plugs (male). If you actually follow the spec properly, you never have issues. The problem was the a number terminal manufactures used the wrong sex connector, as a lot of them never read the specs [the most famous being the Lear Siegler ADM3 which was socketed like a DCE but pinned as a DTE - probably was it was cheap and thus became very popular). Also to confuse things where it got all weird was how the DCE's handled answering the phone. And it was because of the answering that we got all the messy stuff like Ring, Data Set/Terminal Ready/Carrier and the like. The different DCE manufacturers in different countries had different answer protocols, than the original Bell system. IIRC the original WE103 needed help from host. Support for Auto-answer was a later feature of the WE212. The different protocols are all laid in well in another late 60s/early 70s data com book from an UMass Prof, who's name I now forget (his book is white with black letters called 'Data Communications' , as opposed to MacNamaras dark blue DEC Press book 'Principles of Data Communications'). So ... coming back to Unix for this list... AT&T owned Western Electric (WE) who was the largest US manufacturer of DCE's [see 1949 law suit/the consent decree et al]. In fact at Bell Labs, a lot people using UNIX did not have 'hardwired terminals' - they had a modem connection. So, Unix as a system and tends to have support for DTE/DCE in the manner WE intended it to be as a result. It's not surprising that see it in the solutions that are there. ᐧ