>>The Turbo SCSI code needs to get moved into the SCSI driver at some point :)
> 
> i'm not entirely sure i agree with that, because it just makes the
> situation uglier.  however, regardless, we can blame apple for this one.

How so? The Turbo SCSI registers living in the same space as the video
conroller is coincidental. My prototype code simply maps two bus spaces so
that other code (like the SCSI driver) can map those five or six registers
elsewhere. It boils down to "What the heck is SCSI code doing in the
video driver?" :) Besides, those registers actually control certain delays
in the way the SCSI chip services things. The SCSI driver might eventually
manage those registers more intelligently than simply turning the delays
down to their lowest setting. Thus, we need this code moved out of the
video driver.

> this is accurate, and unpleasant.  the offset in intvid_info[] could be
> used as a base address, by the way, and offset later on.  (this could be
> especially important if we actually start supporting powermacs with nubus
> slots, by the way.  bus_space access in the nubus drivers will become very
> important.)

I like the tabilzation idea for storing intvid base addresses but the problem
comes back to not knowing what the console is. I think I've been
miscommunicating this.

This is the problem:
A user has a two monitor setup. One monitor is on a NuBus card the other is
on internal video. He sets the "default" screen (i.e, the one with the
menu bar and happy mac) to the NuBus card.

When the user boots NetBSD, the *card's* base address is loaded into
mac68k_vidlog/phys. When the grf_iv stuff comes around to initialization
it tries to pick up it's values from mac68k_vidlog/phys and what it really
is getting is some address in NuBus space.

The way I think about mac68k_vidlog/phys is just variables we use that contain
the frame buffer address of the console at boot so that the console can
output to the screen until the video subsystem has been initialized.
mac68k_vidlog/phys should *never* appear in a video driver because it's
impossible to tell if the address is destined for the driver.

> actually, the ultimate plan was to use the information to actually map the
> video RAM.   that it currently doesn't do this is something that i'd like
> to correct.

Agreed! You can map the absolute base address through the size of the VRAM
to whatever you'd like. The range obviously has to be continuous. To avoid
confusion it may be simpler for the driver to deal with a physical address
when calculating the current frame buffer base and then convert it to a
logical address when it's done. Otherwise it we will need some kind of
array or call or something that's going to have to manage all the current
logical video addresses floating around in the system. Ugh!

> one thing you should note:  your patch wreaks havoc with the old
> GRFIOCGINFO ioctl, because mac68k_vidlog is set incorrectly.  it is true
> that this interface should (must) go away, but at the moment, we haven't
> officially deprecated it.  (yes, i realize i'll also have to modify
> setmachdep() to set the proper KVA, as well; it may be easier to just rip
> that code out.)

Well, grfiocginfo has to go but supporting it under my vid architecture is
easy if you still want it. It simply has to go, though. :)

> this is wrong for two reasons; not only shouldn't we depend on the booter
> for anything like this, you're assuming that Mac OS is being used to boot
> the system.  i've been working on native boot blocks as a side project.
> this would complicate my job quite a bit.

I've contemplated writing native booters in the past. You can get the current
video base from a low-mem global which should be initialized by the ROMs
by the time your booter comes up. As far as I can tell, this is how MacOS
does it. Again, this gives you the "happy mac screen" frame buffer base
address. This could be a NuBus card, internal video, or whatever.

BTW, you may want to consider writing a "fake" system file rather than boot
blocks. Writing a fake system should easier to do and can be done with
normal tools. Also, a fake system can be installed to HFS via the htools
based installer other folks are working on. Installing boot blocks can be
a pain and may cause certain virus software to go nuts.

> the correct thing to do is have the kernel determine this information at
> console initialization time (which happens well before autoconfiguration
> starts).  your drivers should have a function that helps us figure this
> out, somehow.  i'm not attached to any particular method of doing this, at
> least not yet.

Yes, autoconfig is simply too late to intialize video. The trouble is,
without autoconfiging how do we know what driver to use? If we do some
primitive matching and it's intvid then it's easy but the trouble comes
in with cards. Short of doing a full match/attach how can I decide if
I want to use the TFB, Radius, SuperMac, etc. drivers?

If we can work this out, then I'd like to have an initialization function
that reads the PRAM to find out what mode the user wants the video in or
default to one if the card was just installed. The init function can then
put the hardware into a known state.

I've found that trying to determine the state of a video controller can be
somewhat of a pain. :)

In any case, I'm still kind of fuzzy on how the console becomes automagically
initialized before autoconfig. Can you explain this a little? 

> fbbase = 0xf9000000 | (vbase1 << 9) | (vbase2 << 5);
> if (intvid_info[i].fbbase <= fbbase &&
>     fbbase <= (intvid_info[i].fbbase + intvid_info[i].fblen))
>         mac68k_vidphys = fbbase;
> 
> basically, `if the PA of the framebuffer is in the range we expect, let's
> set it to where it really should be.'  this avoids moving the console from
> a nubus-based card to on-board video.

I don't quite see why you're doing this. If you want to determine which
screen is the console then the better way to do it is to check the PRAM.
If you want to figure out the location of the video so we can re-map it
we can get the PA and length out of a table and remap it.

> booter, above.  i don't want to rely on the booter any more than is
> absolutely necessary.

Well, I believe that the booter should at least pass in the base address,
rowbytes, and size of the console. It should be able to grok these from
low mem globals. Otherwise, how can the console find this stuff out before
autoconfig unless we do a separate video autoconfig up front?

> no trouble.  thanks for bearing with me.  i think we're fundamentally
> agreed on the goal, really.  it's just a matter of working out some of the
> details. :-)

Cool!