[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: To snoop or not to snoop...



Dave New <den@aisinc.com> writes..
> 
> Now that the subject of VGA palette snooping has been brought up,
> there has been a question floating around my organization for some
> time, that is, "Why VGA palette snoop at all?"
> 
> I mean, it would appear in some situations to be non-useful or perhaps
> even counter-productive.  The examples discussed in the PCI
> specification appear to address only a very narrow application range,
> that is, of a secondary non-VGA compatible graphics board displaying
> data on a VGA adapter via the VGA feature connector.  

Very narrow. The original VGA feature connector was only useable on VGAs with 8
bit ramdacs, a fairly narrow slice of todays market.

The standard VGA 'feature' connector is BEFORE the ramdac, i.e. its the digital
8 bit stream before the color lookup tables and DACs...  The snooping was
designed so another board (presumably a TV-in-a-window type thing) could take
the feature connector OUTPUT and run it thru its own copy of the RAMDAC, while
inserting its own video (probably a live video feed in a window).
 
> This is not our
> application, or at least it doesn't appear to be that way.
> Our application would have a graphics engine (of sorts, it really
> doesn't matter for the purposes of this discussion *how* it produces
> its graphics data, just that it does) that wants to display pixels
> in a window on a (DCI or DirectDraw -compatible?) VGA adapter via
> PCI bus transactions, not through the VGA feature connector (this may
> be splitting hairs, and may have nothing to do with the question, or
> it may be the whole crux of it).

I suspect this may be problematic on some graphics adapters, if you write to
their frame buffer while their internal graphics engine is working, there may
be pixel corruption.  The DCI or DirectDraw API was designed for host access...
you make a BeginAccess call, you draw your frame, you make a EndAccess call. 
This takes care of cursor exclusion, and waits for the VGA's graphics engine to
be free.  Microsoft makes no provision for a asynchronous bus master.  Sure, it
should work on many cards.

> Anyway, the feature we *do* have on our "graphics engine" is a color
> lookup table that can be read/written by the host processor, so that
> we can map our 256-gray scale output into the closest matching color
> space that is currently loaded on the VGA board.  Note that the
> color information we are trying to match is the 8-bit palette index
> which is written by the host to the VGA board for normal display
> operations.


> Now, here's the kicker.  I don't believe that we can get the information
> that we really need to live in a 256-color-palatte world by snooping
> writes to the VGA palatte.  Rather, being in a reasonably palette-aware
> environment that supports logical color palettes and color matching
> (Microsoft Windows NT), I would prefer to update my board's LUT
> with the logical color table that Windows NT returns from a
> palette realization call, which my application or driver would
> make in response to a Palette Manager message that the window
> focus and/or color map has changed.  This is the same software
> LUT that the Windows GDI uses when an application wishes to write
> 8-bit palettized information to a display device.

You are right, the snooping feature has nothing to do with what you want.  

One catch, the 'translation' table built by the GDI and used to translate
between a background app's palette and the current foreground palette is only
available to the display driver as far as I know.  You'll probably have to
create your own best-fit palette based on the current RGB palettes that you can
query from the GDI.

....

> Thoughts, brickbats?  I've already told our organization that I
> don't believe VGA palette snooping is necessary (or desirable)
> for our product, so I hope I get some validation, here.  I've
> spent some time with the Microsoft white papers and sample code
> on the Developer Network CD's, and convinced myself that hardware
> palette snooping is not required in our case, but an 8-bit to
> 8-bit hardware lookup table (note that for the moment, I'm ignoring
> 16-bit and 24-bit color modes just to simplify the issues), updated by
> software, is the proper answer.

Hopefully, you'll have some sort of simplistic hardware dithering capability
for 8bpp modes.  But on the other hand, more and more folks are running in 16
and 24bpp modes these days (I'm at 16M colors here right now).

-jrp
(x	f