29 May
2018
29 May
'18
5:11 a.m.
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(a)gmail.com> wrote:
On 5/24/18, Arthur Krewat
<krewat(a)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.