>    I know this. You have to take a chunk of the Q22-bus address space and
> map it to a chuck of the VAX address space (typically the main RAM). There
> are special registers to put these mappings into.
>    
>    I wonder, how do UNIBUS/Q22-bus bridges from Able and others handle
> this? Do they also have special map registers?

Yes, they have models with the map.  They also have models without, if you're
willing to program around the limitations.

> I have always been thinking
> about the following scenario: taking some UNIBUS device like a UDA50,
> plugging it into a UNIBUS backplane, and attaching it to a Q22-bus MicroVAX
> via a Quniverter.

You may have been thinking about it, but I've been doing it for well over
a decade.

> I have been thinking that the OS running on the MicroVAX
> CPU would see it as an equivalent Q-bus device, e.g., a KDA50, without
> knowing in any way that it's actually a UDA50 on a UNIBUS.

It's very easy for the OS to tell whether it's talking to a KDA50 or
a UDA50; it just looks at the "controller ID byte" reported during
initializiation of the MSCP controller.  See, for example, my DUSTAT utility
for a list of MSCP controller ID's, at:

http://sunsite.unc.edu/pub/academic/computer-science/history/pdp-11/rt/dustat/

For other controllers that exist on bot the Q-bus (22-bit DMA addresses)
and Unibus (18-bit DMA addresses) there are tests you can do to the device
registers that similarly let you determine 18-bitness or 22-bitness.

> However, if as
> you say the UNIBUS is mapped into the Q22-bus in the same way as it's
> mapped into the VAX address space on 780 and 750, this won't work. Would
> you please clarify this issue for me?

Sorry if I confused you - the details of the mapping registers are clearly
different, but the concept is the same.  Just check any of the processor
manuals for the real dirt.  Things get quite complicated at the mapping
level, but these services are usually provided by the OS (at least they are
in VMS and most Unices) so that device-driver-writers don't have to
worry about all the different hardware configurations.  (Life gets really
interesting when you hook an Alpha running VMS to a Unibus via a PCI-to-
Unibus bridge!)

> > > And what
> > > about Q18 vs. Q22? How compatible are these two?
> >
> > Depends on the hardware you're talking about.  Some Q18 peripherals (like
> > the RXV21) are "well-behaved" and the driver just has to be careful
> > to keep them DMA to/from them in the lower 256 kByte space they can
> > address.
>    
>    I take this to mean that there is no need to mess with any mapping
> registers in this case. Is this right?

Right.  Again, all this is clearly explained in the Micronote that I
referenced as well as the DEC controller manuals.

>    P.S. I wonder, how do UNIBUS and Q-bus compare performance-wise? Being
> multiplexed, Q-bus should be slower, right? Or did they shorten all the
> timings to make it faster?

Q-bus peripherals can use "burst-mode" DMA, where they don't have to send
the entire address for each read-write cycle.  In burst-mode, the Q-bus
and Unibus aren't too different in capacity.  (Things are made quite
complicated on the Unibus because it is potentially several hundred feet
long, if you insert enough repeaters, etc.  This can slow it down
significantly, but it's your choice whether you want length or speed.)

Tim.