Boot RXS

[Noel Chiappa]

    > From: Jim Stephens

    > I had a meeting with Ken Omohundro on 12/7 and will be having dinner
    > with him again soon. I'll ask him about it. I know he doesn't have any
    > records left, but I could take him your notes and see what he recalls.

Thanks very much for that offer; we do think we know more or less how it
works (software-wise we always knew, since I wrote the code for it on the MIT
system, and that, and some other code to run it, still survive; the hardware
details had faded from my memory, but the documentation that Clem Cole found
cleared the high-level details of that up, mostly); however, there are two
areas in which he might be able to help.

The first is some very low-level details of how it worked, in terms of the
UNIBUS interaction; we can surmise, from the way it's installed, how it more
or less has to work (details below), but it would be nice to have it
confirmed. The second is some details of how some of the optional stuff for
using existing memory, non-DMA devices, etc worked. (I honestly forget the
details of what I couldn't work out there; I'll have to go study it again.)


The first is that unlike my initial recollections, both the CPU and DMA
devices are on a single UNIBUS segment which feeds into the ENABLE. There are
two different 18->22 maps in the ENABLE, one for CPU cycles, one for DMA (the
latter perfectly emulates the UNIBUS map on the -11/70 and /44). So, more or
less by definition, it has to be able to distinguish CPU bus cycles from DMA
device bus cycles on the incoming UNIBUS segment.

But how, exactly? I can _theorize_ how it did it, but this is a topic not
covered in the still-extant documentation. I _surmise_ that it was something
like it watches NPR/SACK for a DMA cycle (it won't see the NPG, of course),
then waits for BBSY to cycle, at which point it knows it's a DMA cycle; if
not, the current cycle must be from the CPU. He may or may not remember the
details, but if he can, that would be great.

(For software emulation, we don't need to know this, but it would be good,
for completeness' sake, to know. Also, I have a fantasy that the UNIBUS
version of the QSIC will also include ENABLE-type functionality, and although
we could probably work it out on our own, it would be good to have the
benefit of anything he can recall - any not-so-obvious gotcha's, etc.)

It would also be interesting to know why he just didn't use a 3-bus design:
i) UNIBUS in from the CPU, ii) UNIBUS in from DMA devices, and iii) EUB to
the memory. I suspect that the answer is that they way they did it, they
could use a stock MUD backplane (being used in EUB mode), and only one
over-the-back connector into the ENABLE.


On the second, I'll have to go re-read the documentation, and get back.
(Although now that I think about it, I may have just figured out, not only
the question, but also the answer.)


    > I hope to get a biography and history of his companies including Able,
    > and figure somewhere to get it stored.

The Computer History wiki would seem an ideal place for this sort of content?
(Depending on how long the bio is; but the company info would _definitely_ be
very much on target for there.)

	Noel