The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: bqt@update.uu.se (Johnny Billquist)
Subject: [TUHS] Control-T (was top)
Date: Thu, 31 May 2018 00:10:19 +0200	[thread overview]
Message-ID: <fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se> (raw)
In-Reply-To: <32AC88B9-7065-407E-9687-F3BED82B39F2@ccc.com>

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

Clem...

On 30.05.18 02:19, Clem cole wrote:
> A few comments.
> 
> 1). If you grab ^s/^q from the alphabet it means you can send raw 8 bit data because they are valid characters (yes you can use escape chars but it gets very bad)

But this has nothing to do with 8 bit data. It's equally true if you are 
using 7 bit data. It is totally disconnected from the 8th bit.
You sometimes also have problem with 8bit data because of parity 
fiddling and whatnot, and thus any mention of 8bit data usually actually 
means something related to the topic of getting the 8th bit though 
cleanly, which is not always the case. Heck, there are even internet 
protocols to this day that don't guarantee that they are 8bit clean.

What you are talking about is simply the problem when you have inband 
signalling, and is a totally different problem than 8bit data.

> 2) RTS/CTS flow signaling was very much part of the standard but it’s optional  and was used differently by the bell modem interface spec as you point out. I have the spec full somewhere.  It was originally in the ECMA standard for RJE stations actually.  IIRC it was the one if the European firms like ICL that created it.  Again IIRC MacNamera describes it also in his early19079s classic book on data com.

RTS/CTS signalling is certainly a part of the standard, but it is not 
meant for flow control. It is for half duplex and the way to signal when 
you want to change the direction of communication.

It is meant for *half duplex* communication. Not flow control.

> 3) DEC did not stick to the standard on the DZ11 neither ECMA interface nor the WE/Bell system standards. either Paul is absolutely right.  It drove MacNamera crazy as I believe he was the lead designer of the original DH which did (the topic came up at a party once).  WE212 modems worked on dz11 for input but just barely and could not use a WE dialer for output (who’s number I now forget). Remember the AT command dialer stuff was not originally a standard from the telcos.  The modems were independent of the dialer (which used the RS-4xx standard and I also have some where and I forget the number).

The DZ11 explicitly says it only have limited modem control. It does 
indeed not support half duplex communication.

The AT "standard" was never actually a standard. It's only a defacto 
standard, but is just something Hayes did, as I'm sure you know.

   Johnny

> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> 
>> On May 29, 2018, at 6:45 PM, Johnny Billquist <bqt at update.uu.se> wrote:
>>
>>> On 2018-05-29 04:00, Clem cole<clemc at ccc.com> wrote:
>>> And the other issue was besides not enough buffering DZ11s and the TU58 assumes  software (^S/^Q) for the flow control (DH11s with the DM11 option has hardware (RTS/CTS) to control the I/O rate.  So this of course made 8bit data diificult too. And as Paul points out, with HW flow the priority could have been lower. But the HW folks assumed a so called 3 wire interface because they thought they were saving money.
>>
>> Uh? Say what? What does XON/XOFF flow control have to do with 8bit data?
>>
>> And no, DEC was not trying to save money. They were actually sticking to the standard. Something very few companies managed to do, especially when it came to the RS-232 standard.
>> The "hardware flow control" is actually an abuse of the half duplex signalling.
>> And it does not necessarily work as you might expect if modems are in the middle.
>> You could get by with just three wires on serial ports, but DEC usually did want people to have more wires connected, in order to detect when a device was connected or not. But no, they did not abuse the half duplex control to do hardware flow control. The DZ11 also have partial modem control. You cannot run them in half-duplex mode, and they do not support the secondary channel stuff, but they do support more than just the 3 wires.
>>
>>> A few years later when people tried to put high speed modems like the Trailblazers on them, let’s say the Unix folks quickly abandoned any hope.   Ken O’Humundro at Able Computer has quite a business in his ‘DHDM’ board that was cheaper than the DZ, more ports, full DMA and of course full hardware flow control.
>>
>> Yes. It's essentially a DH11 with a partial DM11 on just one board, while the original DH11/DM11 was a fully 9-slot backplane. So it was a really good alternative. The DH11 is much better than the DZ11, but did in fact cost more. The Able board gave the DH11 capabilities at a much lower cost, and taking much less space in the box. And it actually performed better than the DH11. But it did not support the full functionality of the DM11. But what was lacking was the half duplex stuff, which noone really cared about anymore anyway.
>>
>>     Johnny
>>
>> -- 
>> Johnny Billquist                  || "I'm on a bus
>>                                   ||  on a psychedelic trip
>> email: bqt at softjar.se             ||  Reading murder books
>> pdp is alive!                     ||  tryin' to stay hip" - B. Idol


-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol


  parent reply	other threads:[~2018-05-30 22:10 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1.1527559201.18622.tuhs@minnie.tuhs.org>
2018-05-29 22:45 ` Johnny Billquist
2018-05-30  0:19   ` Clem cole
2018-05-30  0:20     ` Clem cole
2018-05-30 22:10     ` Johnny Billquist [this message]
2018-05-30 23:14       ` Pete Turnbull
2018-05-30  1:10   ` Dave Horsfall
     [not found] <mailman.1.1527732002.17884.tuhs@minnie.tuhs.org>
2018-05-31 15:02 ` Johnny Billquist
2018-05-31 21:42   ` Nemo
2018-05-29 21:21 Norman Wilson
2018-05-30  9:06 ` arnold
  -- strict thread matches above, loose matches on Subject: below --
2018-05-29 18:49 Noel Chiappa
2018-05-30  1:05 ` Dave Horsfall
2018-05-29  2:55 Noel Chiappa
2018-05-29 17:10 ` Paul Winalski
2018-05-24 12:20 [TUHS] History of top Noel Chiappa
2018-05-24 14:09 ` Clem Cole
2018-05-24 14:50   ` [TUHS] Control-T (was top) Ronald Natalie
2018-05-24 15:01     ` Clem Cole
2018-05-24 15:48       ` Lars Brinkhoff
2018-05-24 15:08     ` Arthur Krewat
2018-05-28 22:32       ` Paul Winalski
2018-05-28 23:11         ` Clem cole
2018-05-28 23:32           ` Arthur Krewat
2018-05-29  1:12         ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=fae79614-4785-0c14-9ab8-6e81b2f2c265@update.uu.se \
    --to=bqt@update.uu.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).