> Maybe...  This doesn't always work for real RAM--unless I was imagining
> things a while ago on the II, memory wraps around in wierd ways so that
> there are few memory locations that actually return a bus error with
> translation disabled (MMU off).  It's been a while and I don't remember
> the details, but that's why the memory size is passed in from the booter.

I was envisioning this being used before the kernel really messed with MMU
too much. I wouldn't recommend it for general RAM but for things like ROM
and VRAM where you have blocks that are likely to be contiguously mapped or
in increments of some size.

Other than the booter passing in the VRAM size there is no other real way
to know exactly how big VRAM is. Right now the booter only passes in the
current rowbytes and the screen dimentions. I noticed that pmap_bootstrap
thinks that a good way to calculate VRAM size is to use
rowbytes * screen_height. This isn't a valid technique on a Quadra where
the screen resolution changes. You've got to probe for this stuff :)
Future video drivers need to know the exact size of video ram so that they
can make determinations as to the maximum mode the machine is capable of
handling.

> There is actually already a routine for this--bad_baddr(), I think--in
> machdep.c.  It encapsulates the setjmp for you and returns 0 if the
> address is mapped and non-zero if it's not.

Great! Then it's really, more or less, a for loop!