> On Mar 5, 2021, at 9:15 PM, Chris Zach via cctalk <cctalk@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
