Qbus split I&D?

[Noel Chiappa]

    > From: John Wilson

    > But for 18-bit machines, emulating the Enable thingy might be fun for a
    > tiny handful of people, which is always enough to justify months of
    > work in my book.

D'accord! :-)

    > But thinking about how it must work hurts my head.

OK, let me give you my best understanding/recollection of how it works.

The UNIBUS from the CPU is pretty much only used as a CPU<->ENABLE bus. The
CPU does reads/writes (which all go to the ENABLE) on it, and interrupts from
devices come in on it, but that's all. (I don't think the CPU did NPR
arbitration any more.)

The CPU's internal PARs are used to distribute various chunks of CPU address
space across that UNIBUS' address space. Most code set up that mapping
statically at startup, and afterwards played only with the PARs in the ENABLE
(which could map chunks of the UNIBUS space to the 22-bit address space) from
then on. With a total of 256KB of UNIBUS address space, that means it will
hold a full-sized Kernel I+D, and a full-sized User I+D. There is therefore no
Supervisor (I or D), _unless_ you skimp on one of the other 4, or dynamically
re-allocate the address space in the CPU<->ENABLE UNIBUS (e.g. when switching
from User to Super).

The Enable had two (maybe three) other bus connections: one was a device
UNIBUS in/out (for all DMA, and possibly other, devices), one was the 22-bit
address memory bus, and the potential third was the bus to the optional cache.
(Except I think maybe the latter two were combined into one; see below.) In
theory you could put non-DMA devices on the CPU<->ENABLE UNIBUS, but I don't
know if anyone did.

The second UNIBUS had a UNIBUS map on the end of it inside the ENABLE,
through which all incoming DMA cycles were fed to the 22-bit memory. So, NPR
cycles on it acted just like those on the 11/70's UNIBUS (they even used the
same register locations/etc, so programming-wise an 11 with the ENABLE looked
just like an 11/70, as far as the UNIBUS went).

There are code/.h files which give all the register locations, bits in the
CSR, etc so it should be possible to build a replica (so that existing code
for it still works).


If you look at a picture of an ENABLE (there's one in the Product Summary),
it's a hex card which has i) the normal edge connector, ii) a pair of DuPont
headers (which are, I'm pretty sure, the cache connector), and iii) a UNIBUS
connector stuck on the top edge of the card. I think one UNIBUS came in the
edge fingers (but I could be wrong, that's just a guess); the other clearly
used the one of the top of the card.

I don't know if it plugged into a 'normal' Extended UNIBUS system unit, or if
it was a special backplane that Able supplied. I suspect the latter, because
one way or another, that backplane had to have normal UNIBUS on either the
input or output A/B slots, and I can't see how that would work with EUB
memory cards plugged into that backplane. But maybe I'm missing something?

(This is why I'd really like to have the documentation - to see how it was
hooked up. How it worked, I can tell from looking at the software.)

It's possible the cache connector doubled as the memory bus; all memory cycles
would have been sent out that connector to the optional cache card, and if it
hit, cycle done; if not, it went out (over the backplane?) to the EUB
memory. So maybe if there was no cache, there was a different 'null' card
there with a connector for the ribbon cable, and minimal circuitry, to connect
up to the EUB - but that's a pure guess. Another possibility is that only the
cache used the DuPont connectors, and memory cycles went out other 'fingers'
on the edge connectors. (Grr! Wish we had installation instructions!!)


It would really help to know if the ENABLE needed a special backplane. Maybe
someone can look at the one at Update, and see what kind of backplane it's
plugged into? That could also tell us whether the UNIBUS connector on the back
edge was the 'in' or 'out' UNIBUS. (And of course they should make sure their
card looks like the one in the Product Summary brochure!)


    > It's emulating Unibus memory at the same time that it's emulating the
    > Unibus map -- i.e. CPU accesses (which should be relocated through the
    > onboard PARs) are coming over the same bus as DMA (which should be
    > relocated using the Unibus Map).

Nope. Two separate UNIBI.

    > Does it need to tap into each model of CPU somehow (like how a
    > Microverter gets at MMR3)?

AFAIK, it doesn't connect up to the CPU at all.

   > And what if there's a cache, like the KK11A, that doesn't know about
   > the outboard PARs?

Good question! Probably you should pitch the KK11A, and use Able's optional
cache for the ENABLE. Or flush the KK11A whenever you change the mapping
(does the KK11A have a register to do that)?


The one thing I'm still confused about is that I'm pretty sure that on our
11/45, with the ENABLE and its cache, running 'mips' produced 3. But could it
really get that much speed out of the UNIBUS? I had thought that somehow the
one we had plugged into the FastBus on the 11/45, but maybe my memory is
(somehow) playing tricks on me?

	Noel