[TUHS] Control-T (was top)

[Clem cole]

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.  

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.  

Btw it was not just DEC.  The original hw version of Masscomp MC500 had the same issue in cpu board brcause Jeff Mitchell (who had been one the 11/34 designer) did not know any better. I fixed the MPU board when it was relaided out and our first 8 port serial controller had rewritten microcode from the original OEM to allow trailblazers to work right (fortunately then HW was there on the serial board but it was just being ignored in the original firmware).

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On May 28, 2018, at 6:32 PM, Paul Winalski <paul.winalski at gmail.com> wrote:
> 
>> On 5/24/18, Arthur Krewat <krewat at kilonet.net> wrote:
>> 
>> * a DZ11 is UNIBUS and was only available on a KS10 - but I'd imagine
>> any straight serial port on a KA/KI/KL10 would do the same. If you were,
>> say, on a DCA mux, that had a 14.4K serial link straight into the
>> UNIBUS, there was much less of an effect.
> 
> DZ11s were available on PDP-11s and VAXen as well as the KS10.
> Because the controller had no buffer it was dirt cheap.  OK, perhaps,
> for a realtime or lab application, but if you were doing timesharing
> it could bring the CPU to its knees in short order.  Some idiot
> decided to use the same idea (no buffer in the controller) to reduce
> the cost of the TU58 (aka DECtape II),  Unlike the original DECtape,
> which was extremely reliable, the TU58 was prone to frequent data
> overrun and underrun errors even if you set things up such that it got
> top scheduler priority.
> 
> -Paul W.