On Oct 23, 2022, at 9:36 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
On 2022-10-23 16:56, Paul Koning wrote:
On Oct
22, 2022, at 5:54 AM, Johnny Billquist <bqt(a)softjar.se> wrote:
Well, obviously COPOS/11 isn't P/OS, as you later noted. :-)
P/OS was the OS for the DEC Professions. Came in three models. 325, 350 and 380.
The 325 and 350 were F-11 based. 325 only had RX50 floppies, while the 350 had a
harddisk.
The 380 used the J11 CPU, but sadly at a low speed and without cache. And all software
had to work with the F11 as well, so none of the J11 improvements were used.
Basically, the Professional was a good idea implemented rather badly.
Its main
problem was that it had a completely different I/O bus and I/O architecture. And a lot of
that went poorly because Intel chips were used for it, and Intel rarely if ever has good
design for anything. The interrupt controllers, for example, are a mess. Fortunately,
most of its misfeatures are not used on the Pro (like edge-triggered interrupts).
True. But even the fact that they decided to make it incompatible with all previous
PDP-11s were a bad decision. No matter what chips they used.
The biggest blunder was a set of storage
controllers without DMA, even though the bus actually supports DMA according to the
documentation. So the hard drives -- not very fast to begin with -- have to be 4:1
interleaved to avoid missing the next sector after an I/O is done. That's true on
both F-11 and J-11 based machines, so clearly the CPU speed is not at fault.
That they don't use DMA is a mystery to me. Maybe some problems with it? I don't
know of a single option that uses DMA. Anyway, I believe an F-11 and a J-11 running at 10
MHz will pretty much perform rather similar. So the 4:1 interleaving, which obviously have
to do with CPU speed, is another sign of the problems with the system.
I don't know of any DMA options either. The only one that isn't severely crippled
from a data flow perspective is the DECNA, with its on-board memory. Provided the OS can
use that memory directly as comm subsystem buffers, and assuming bus memory isn't too
much slower than motherboard memory, the lack of DMA isn't a severe handicap there.
Of course, the CNA suffers severely from another very bad choice, which is to use the
worth Ethernet chip in recorded history.
On the Pro 380, a pile of discrete chips were
replaced by one or two gate arrays (so many of those Intel chips disappeared, but not
their ugly APIs). Apparently, the designers made the I/O gate array at 10 MHz, and made
it synchronous with the CPU clock on the assumption that Harris would deliver its promised
20 MHz J-11. When they did not (18 MHz was the best they could do), the Pro 380 was
forced to run the CPU at 10 MHz instead.
As far as I heard/know, the gate array was limited to 10 MHz. Wouldn't have mattered
how much faster the J11 could run. In the PRO-380, it would never be run at more than 10
MHz.
And I think it sounds weird if the fact that the J11 only reached 18 MHz would be a
reason to limit the PRO to 10 MHz. Why not run at 18, or 15, or whatever? The gate array
needs to run at the same speed as the CPU, so it couldn't be scaled or anything
either.
There are three ways to design a support chip:
1. Require it to use the same clock as the CPU
2. Allow it to run at an integer fraction of the CPU clock, i.e., data is latches every N
CPU clock edges
3. Implement synchronizers at the clock domain boundary, so CPU clock and I/O clock are
independent
#3 is more work and requires more care. My understanding is that #2 was done on the
theory that the I/O clock is 10 MHz and N would be 2. When that didn't work, the only
option (short of doing #3 after all) was to set N=1.
paul