Boot RXS

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.) 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