Dear Tim,
   
   You wrote:
> Yes, they have models with the map.  They also have models without, if
> you're willing to program around the limitations.
   
   Which one should I use if I want things to work the obvious way? Here is
what I mean by that. Take 4.3BSD for instance. (Yes, I know that this is a
NetBSD list, but we are discussing hardware and I have chosen an example
that I know better. I am also pretty sure that this works in exactly the
same way in NetBSD and Ultrix, but I won't make a statement unless I'm sure
about it.) You have got the "uba" portion of the code which deals with both
UNIBUS and Q-bus. During the autoconfiguration stage all UNIBUSes and Q-
buses in the system are found and added to the configuration tables. Then
they are presented to the higher layers, i.e., the drivers for specific
devices and controllers. These drivers see the thing as an abstract uba
device, regardless of whether it's a UNIBUS or a Q-bus. The uda driver
doesn't care whether it's a UDA50 or a KDA50, the tmscp driver doesn't care
whether it's a TUK50 or a TQK50, the dz driver doesn't care whether it's a
DZ11 or a DZV11/DZQ11, etc. (The only exception is in the case of DEUNA vs.
DEQNA, which look different to the software and are supported by different
drivers.) If a driver doesn't differentiate between the UNIBUS and the Q-
bus versions of the card, it should work with a card across the bridge just
as fine, right? What kind of bridge should I use to accomplish this? Assume
that the OS doesn't have any special knowledge about the bridge.
   
   Actually in my particular case the SC-21 to my knowledge has never had a
Q-bus twin. The driver for it was probably written before Q-bus has come
into existence. Is there any way to make such a driver work unmodified with
an SC-21 across the bridge from a Q22-bus MicroVAX CPU?
   
> 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.
   
   Yes, 4.3BSD definitely centralizes the code that worries about the
mappings. (I'm sure that NetBSD and Ultrix do too.) However, if the path
from the CPU to the device goes through a Quniverter, the OS won't know
what to do with it, will it? I haven't looked at the code myself yet, but
I'm assuming that the driver asks some central routine "I want to DMA to
this VAX memory address", the routine maps it to a UNIBUS or Q-bus address,
and returns the latter. When running on a Q22-bus CPU, this routine will
assume that all 4 MB of the Q22-bus address space are available, won't it?
The address returned to the driver may have some of its 4 high bits set,
right? The driver will try to stick it in the device's registers, but they
have only 18 bits. Does this mean that an ordinary VAX OS cannot work
unmodified with a Quniverter?
   
> > > 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.
   
   Hmm, a Q18 card like an RXV21 should be no different from a UNIBUS card
across a Quniverter, right? The same OS considerations as I have described
above apply here too, don't they? Also Micronotes 5 lists all the cards
that work in Q22 systems, and I see lots of non-DMA ones in there, like
DZV11/DZQ11. I also don't see any such cards in the incompatible section.
This suggests to me that all these Q22-compatible non-DMA cards should work
in Q18 systems, right? They have to decode their CSR addresses, right? How
can the same card work in both if Q22 compatibility requires decoding
BDAL18-21 while in a Q18 backplane these fingers may be dangling or
connected to something odd? Or is the I/O page where all the CSRs are
treated specially in that the devices don't have to decode the high bits?
But even if that is the case, there are cards like RXV11 and RLV12. They
certainly do DMA, and they are listed as fully Q22-compatible. OTOH, RXV21
and RLV11 are certainly for Q18. Since it's very unlikely that an RX01
controller is newer than an RX02 one, it seems that RXV11 should work in a
Q18 system too. What does it put out on BDAL18-21 during DMA to make both
systems happy?
   
   Sincerely,
   Michael Sokolov
   Phone: 440-449-0299
   ARPA Internet SMTP mail: sokolov@alpha.ces.cwru.edu