On Mar 5, 2021, at 9:15 PM, Chris Zach via cctalk
<cctalk at classiccmp.org> wrote:
> Can't run split I/D space on any version
of P/OS. Neither does it support supervisor mode. Also, the J11 on the Pro-380 is running
a bit on the slow side. Rather sad, but I guess they didn't want to improve the
support chips on the Pro, which limited speed, and they didn't want to start having
Pro software that didn't run on all models, which prevented the I/D space and
supervisor mode.
That sucks. I sometimes wonder how hard it would be to code the hard disk driver, if it
doesn't do DMA it's probably simple as dirt to be honest. Any idea if it worked
like MCSP or was it totally off the wall?
The Pro hard disk driver is indeed pretty simple. Nothing like DDCMP; it's more like
an old style disk controller with CSRs to tell the device what to do. Basically, you
convert linear sector number to cylinder/track/sector (which requires knowing the specific
drive type), then load that into the CSRs along with a command. Then for a write
operation you write the words of data, 256 of them, to the data buffer CSR. For a read,
you wait for the data ready interrupt, then read the data one word at a time from that
same CSR. Repeat for the next sector.
The floppy is similar except that the transfer is byte-at-a-time, and the address mapping
is more complicated because the software has to deal with the sector interleave, track
skew, and funny cylinder numbering.
An entirely different odd design is the Pro Ethernet card, which uses the evil 82568
Ethernet chip. That does DMA -- into a 64kW memory that's part of the DECNA card. So
the OS would allocate Ethernet buffers to that memory space and can then do DMA.
That's not too bad, and 64kW is a decent amount of memory. The real problem is that
the 82568 is by far the worst DMA engine design ever created. It actually implements
design errors that were well understood and well documented (and solved) 20 years earlier,
but such considerations never stopped Intel.
The most
embarassing blunder with the Pro is that the bus supports DMA, but no I/O cards use it.
Even though a bunch of them should have -- hard disk controller obviously, network adapter
possibly as well.
I think they used an intel chipset to handle the CTI bus, so the normal Q-Bus DMA methods
just doesn't work. Hm. Wonder if the problem is they just didn't build the driver
to support DMA, or if they found some problem that made DMA just not work at all....
The documentation clearly describes DMA operation of the CT bus on both 350 and 380 (see
the Technical Manual on Bitsavers). I don't know why it was never used, I never heard
any rumors about it.
I don't believe the bus control uses Intel chips. The interrupt controller does, yes,
which is another bad design decision but one that can be worked around adequately. The
Pro 380 implements only a subset of the full interrupt controller, the parts that
aren't totally absurd.
The 380 *was* a mess, mine is a formidable bit of kit
with DECNA and everything, but without I/D space it's really not too very useful as
more than a really nice VT terminal.
I/D space is just an OS issue; it works fine in the 380. As for a VT terminal, it's
actually reasonably good at that but not great; the video can't quite do the full
VT220 video.
paul