[simh] RSTS processor identification

[Paul Koning]

> 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