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

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

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

On Tue, May 29, 2018 at 9:10 PM, Dave Horsfall <dave at horsfall.org> wrote:

> On Wed, 30 May 2018, Johnny Billquist wrote:
>
> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>>
>
> Err, how do you send data that happen to be XON/OFF?  By futzing around
> with DLE (which I've never seen used)?


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.
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180530/ddd78c79/attachment.html>

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

[Dave Horsfall]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 946 bytes --]

On Wed, 30 May 2018, Clem Cole 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).​ 

Actually, the closest I've seen DLE being used was in SLIP and PPP; if you
needed to send a Frame End then it was escaped with (I think) 0xFF, and that
in turn was escaped.  All it took was a finite state machine...  Of course,
those links used RTS/CTS, but you had to flag the end of a frame (packet)
somehow.

-- Dave

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

[Paul Winalski]

On 5/30/18, Dave Horsfall <dave at horsfall.org> wrote:
>
> Actually, the closest I've seen DLE being used was in SLIP and PPP;

I dimly recall that DLE was used by the IBM bisync half-duplex
protocol used by HASP RJE stations and 2741 golfball terminals.  I
think it was made part of ASCII to support those sorts of protocols.

-Paul W.