>> We'll need to know that so we
>> can figure out what type of DEC controller it emulates, which in turn
>> will determine how we'll try to boot the machine.
As far as I recall, the boot firmware only knew about MSCP, so nothing
else could be booted. (ie. Anything else had to boot off floppy or tape
to get it going.) There wasn't much to the boot command:
>>> b/N duXY	(X - controller letter, Y - drive digit)
	N - a number passed to the secondary bootstrap. 3 - indicated
	    single user with prompt for boot file on BSD
for example
>>> b/3 dua0	- interactive boot from first drive on first MSCP controller

Others have described the slots. My recollection is the order only affects
bus priority (closest to the cpu wins). Usually the DEQNA (one of DEC's
less stellar hardware achievemnets, by any standard) came first and the
disk controller last. (Some disk controllers had to be last, because they
didn't pass on bus signals properly.)

I tossed my last MicroVAXII in the recycle a few weeks ago. Strangely
enough, a lot of the NFS code still in the various BSDen was written
for the old beast. Someone recently wondered why I didn't use in line
functions. Because the Portable C compiler for the VAX didn't support
them. I used lots of macros (that I've taken lots of heat for over the
years) because a VAX CALL instruction was so darn slow on the MicroVAXII.
(It's much slower than the slowest PC anyone can imagine. Oh, how times
have changed.)

Have fun with it. Just don't expect it to do anything useful:-) rick