this needs to be as ubiquitous(sp) as possible -- it can be suboptimal
as long as there are very few separate kinds of media.  a small MOP
image that in turn can do a tftp load of the real loader and thence
the real kernel, would cover the vast majority of systems likely to
be candidates for netbsd -- that is, machines with delqa's, deqna's,
and deuna's.  note that deuna machines other than the 730/750 (that
is, the 8600 and 780/785) all need floppies even to get as far as MOP,
since the system board doesn't have MOP in rom like the newer unibus
machines and virtually all qbus machines have.  but that floppy is
already provided by dec, so MOP is still the best overall option.

should we ever get BI support working (torek did a BSD port long ago
but i don't know how much of it was in the non-32V portion), all of
the BI machines have either MOP in ROM or can get MOP via their 
console processors.

for machines that just don't have ethernet, we will need a small selection
of console media.  what we put on them ought to be terribly small and
simple -- just enough to load a bigger image from the distribution media.
that is, since we won't be able to fit a BSD distribution on a TU58, it
makes no sense to put any more intelligence onto a TU58 boot tape than
it takes to load a real kernel or miniroot from a TS11 or other 9-track.
likewise the RX01.

i think we have problems to solve between now and then.  i know of a C
implementation of MOP service and i will work on that part while the 
rest of you fix the VM stuff that's got us stopped.  we can't make any
progress on qbus until the 750 port is not crashing any more.