Re: [TUHS] Control-T (was top)

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)

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.

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).

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(a)update.uu.se> wrote: > >> On 2018-05-29 04:00, Clem cole<clemc(a)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(a)softjar.se || Reading murder books > pdp is alive! || tryin' to stay hip" - B. Idol