To snoop or not to snoop...

[Dave New <den@aisinc.com>]

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.  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).

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.

I guess the essence is that I wish to match the color stream
(palatte-wise) of pixel data that is flowing across the PCI bus
to the VGA adapter, so that I pick the appropriate 8-bit value
that come closest to (or matching) the grey scale "color" that I want
on the screen.  Aside from attempting to do color matching on my
adapter board (which the OS will do for me), I don't see what
information I get from snooping VGA palette writes .vs. using the
operating system's palette matching facilities to keep my palette
updated.

Perhaps the original intent of VGA palette snooping was to support
only the situations where a graphics card was painting a VGA display
via the feature connector, where you must color match the pixel
stream, since (I believe) it is after the VGA RAMDAC lookup.  Any
other use doesn't seem to make sense, except in the situation
where the operating system doesn't have any palette management
(MS-DOS comes to mind).  Since we intend to market only to folks
that have decent operating systems running on their platforms, perhaps
this is a non-issue for new designs.

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.

At the worst, it's not too late to change our mind...

Thanks,

DaveN

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Dave New, den@aisinc.com    | Machine vision?
Applied Intelligent Systems |      I'm glad *they* can see the future...
3980 Ranchero Drive         | 
Ann Arbor, MI  48108        |        Opinions expressed are mine.    |
PGP 2.6
(313) 332-7010              | 08 12 9F AF 5B 3E B2 9B  6F DC 66 5A 41 0B
AB 29
(313) 332-7077 FAX
$Œz