> From: David Bridgham
> Our plan is to produce a Unibus board as well, we just chose the QBUS
> first.
For no particularly strong reasons; I had working QBUS machines, and
prototyping cards, etc, etc.
> (actually, this should work with Q18 QBUS systems as well)
Goodness, never thought of that. Hmmm.. it's probably enough hassle to mod
the software (who ever heard of a 'QBUS map' on a QBUS -11 - but you'd need
it to give DMA devices access to high memory) that it's probably just easier
to go out and get Q22 hardware. Does anyone even have a Q18 /23? I think that
was only the A model, right? I've never seen one.
> we plan to also implement the Able ENABLE+ functionality
In other words, a 'USIC' with Able ENABLE functionality added in.
> This will, of course, require you to modify your OS to support this
> non-standard memory.
We should be programming compatible with the ENABLE, so for OS's where
ENABLE support already exists, it should be a compile-and-go.
> Noel has already done so for v6 Unix.
Back in the day, with a real hardware ENABLE. PWB1, actually (pretty much
V6).
It wasn't too much work; one just changes the address definitions for the
User and Kernel PARs from the DEC addresses to the Able ones, and recompiles
all the kernel modules that touch them. One then has to set up the DEC User
and Kernel PARs (which I did in the assembler startup, which was the only
source module that took any serious changes).
(If your OS uses Supervisor mode, well, err... :-)
There are some other minor tweaks needed, e.g. this comment:
/ these routines are used to access /dev/kmem and look at possible
/ NXM locations in the system. The reason it uses this mechanism
/ is that some locations to be examined are on the bus before the
/ ABLE map, and thus cannot be examined by playing with the ABLE
/ map regs, e.g. using the standard u access routines
.globl _fkbyte, _skbyte
.globl _fkword, _skword
Noel
