Ok, I've gotten a few bits of info. I suppose I didn't explain the Advanced
section well enough. Here's a new version of the survey:

Machine:
Driver:
Slot:
Virtual Controller Base:
Virtual Controller Range:
Physical Controller Base:
Physical Controller Range:
Other Info:

Ok, the first 3 you can get from your own knowlege and the Slots program.
The last 5 are a little more tricky. They're optional since I can do some
of the more advanced leg-work on my own once I know what machine goes with
what driver and what slot it's expecting.

*WARNING*
This requires that you can grok raw assembly and have too much time on your
hands! Here's what to do if you're feeling gutsy today:

- Figuring out the Virtual Base-Address
Once you know the driver name from Slots, load a copy of your system into
Res-Edit with CODE Editor. Look for the video driver your machine uses and
open it. Look through the code and try and look for a constant that stands
out that usually ends up gettting moved into an address register. The best
way to do this is to look for a MOVEA.L with a wacky constant. From the two
drivers I have examined so far, these seem to run in and around the 0x0C00
to 0x0F00 area. Kind of low in memory.

- Figuring out the Virtual Controller Range
Ok, knowing the base address look around the code and see if you can guess
where the code is actually doing things like loading the CLUT, switching
resolutions, etc. Usually, they just take the virual base address and
add a small amount to it before moving it into an Address register. Look out!
Sometimes the base address is moved into an address register before calling
and you have to parse through it to figure it out. Luckily, most of the
operations get thrown into a single routine (i.e. one of the CODE Editor
Anons) Find the highest add and you're close.

Second, look at the memory around the base address in MacsBug. Then switch
resolutions and see what changes. This gave me a great deal of insight.

Basically, these two are the most important pieces of data. If all internal
videos map the physical control registers in roughly the same space that space
can be preserved at boot up and we can just load the drivers in from ROM and
call them just like NuBus video. Cool, huh :)

Oh, if the address ranges for the DAC and the video controller seem different
(two constants) like the PPC video, then please feel free to indicate it.

- Figuring out the physical base and range
This is really tricky stuff and it's something I can't do without the actual
machine. This requires that you know the virtual controller addresses and
that you walk the MMU registers looking for a mapping from a physical address
to those virtual addresses. I have no idea how to even do this on the MacOS
side. I suspect that the Virtual addresses will be enough to get the ROM
drivers to work. However, if all the internal videos use similar physical
addresses I can do likewise but it will be a little more precise. Better
yet, if I can get both the physical and virtual addresses I can map them
for each machine.

- Other info
Spout off any of your own findings here :)

I have a feeling that the video types will come in "clusters". That is, some
internal videos will be very similar to each other. For instance, I bet that
the IIsi and IIci videos will react very similarly. Centris video will probably
be very similar, etc.

Let's hope for a pattern folks and good hunting!

_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________