The Sierra Hicolor DAC

 Journal:   Dr. Dobb's Journal  Oct 1991 v16 n10 p155(6)
 Title:     The virtues of affordable technology: the Sierra Hicolor DAC.
            (Sierra Semiconductor Corp.'s Hicolor digital-to-analog converter)
            (Hardware Review) (evaluation)
 Author:    Abrash, Michael.
 AttFile:    Program:  GP-OCT91.ASC  Source code listing.

 Summary:   Sierra Semiconductor Corp's Hicolor digital-to-analog converter
            (DAC) is easy to program and supports an 800x600, 32,768-color
            mode.  The difference between the cost of the Hicolor DAC compared
            to a standard VGA DAC is less than $10 and some HiColor-based
            SuperVGA's are priced at less than $200.  On the downside, the
            Hicolor DAC has some disadvantages.  It needs twice as much memory
            for a given resolution as an equivalent CEG/DAC and graphics
            operations can take longer.  The Hicolor DAC also does not perform
            gamma correction in hardware.  It also does not include a built-in
            lookup table for correction of programmable gamma.  However, the
            Hicolor DAC makes it possible for the first time in the VGA market
            to perform general antialiasing.
 Company:   Sierra Semiconductor Corp. (Products).
 Ticker:    SERA.
 Product:   Sierra Semiconductor HiColor (Digital-to-analog converter)
 Topic:     Digital to Analog Converters
 Feature:   illustration
 Caption:   Mappings of sets of four double-resolution pixels to single screen
            pixels. (chart)
            Mappings from double-resolution buffer pixels. (chart)
            Listing one. (program)

 Full Text:

 My, how quickly the PC world changes!  Six months ago, I described the Edsun
 CEG/DAC as a triumph of inexpensive approximation.  That chip was and is an
 ingenious bridge between SuperVGA and true color that requires no
 modifications to VGA chips or additional memory, yet achieves often-stunning
 results.  Six months ago, the CEG/DAC was the only affordable path beyond

 Time and technology march on, and, in this case, technology has marched much
 the faster.  I have on my desk a SuperVGA card, built around the Tseng Labs
 ET4000 VGA chip, 1 Mbyte of RAM, and the Sierra Semiconductor Hicolor DAC
 (digital-to-analog converter, the chip that converts pixel values from the
 VGA into analog signals for the monitor), that supports an 800x600,
 32,768-color mode.  The added cost of the Hicolor DAC over a standard VGA DAC
 (of which the Hi-color DAC is a fully compatible superset) to the board
 manufacturer is less than $10; I have already seen a Hicolor-based SuperVGA
 listed in Computer Shopper for under $200.

 To those of us who remember buying IBM EGAs for $1000, there's a certain
 degree of unreality to the though of an 800x600 32K-color VGA for less than

 Understand, now, that I'm not talking about clever bitmap encoding or other
 tricky ways of boosting colore here.  This is the real, 15-bpp, almost
 true-color McCoy, beautifully suited to imaging, antialiasing, and virtually
 any sort of high-color graphics you might imagine.  The Hicolor DAC supports
 normal bitmaps that are just like 256-color bitmaps, except that each pixel
 is composed of 15 bits spread across 2 bytes.  If you know how to program
 800x600 256-color mode, you should have no trouble at all programming 800x600
 32K-color mode; for the most part, just double the horizontal byte counts.
 (Lower-resolution 32K-color modes, such as 640x480, are available.  No
 1024x768 32K-color mode is supported, not due to any limitation of the
 Hicolor DAC, but because no VGA chip currently supports the 1.5 Mbyte of
 memory that mode requires.  Expect that to change soon.)  The 32K-color
 banking schemes are the same as in 256-color modes, except that there are
 half as many pixels in each bank.  Even the complexities of the DAC's
 programmable palette go away in 32K-color mode, because there is no
 programmable palette.

 And therein lies the strength of the Hicolor DAC: It's easy to program.
 Theoretically, the CEG/DAC can produce higher-color and more precise images
 using less display memory than the Hicolor DAC, because CEG color resolutions
 of 24-bpp and even higher are possible.  Practically speaking, it's hard to
 write software -- especially real-time software -- that takes full advantage
 of the CEG/DAC's capabilities.  On the other hand, it's very easy to extend
 existing 256-color SuperVGA code to support the Hicolor DAC, and although 32K
 colors is not the same as true color (24-bpp), it's close enough for most
 purposes, and astonishingly better than 256 colors.  Digitized and rendered
 images look terrific on the Hicolor DAC, just as they do on the CEG/DAC --
 and it's a lot easier and much faster to generate such images for the Hicolor

 The Hicolor DAC has three disadvantages.  First, it requires twice as much
 memory at a given resolution as does an equivalent 256-color or CEG/DAC mode.
 This is no longer a significant problem (apart from temporarily precluding a
 1024x768 32K-color mode, as explained earlier); memory is cheap, and 1 Mbyte
 is becoming standard on SuperVGAs.  Secondly, graphics operations can take
 considerably longer, simply because there are twice as many bytes of display
 memory to be dealt with; however, the latest generation of SuperVGAs provides
 for such fast memory access that 32K-color software will probably run faster
 than 256-color software did on the first generation of SuperVGAs.  Finally,
 the Hicolor DAC neither performs gamma correction in hardware nor provides a
 built-in look-up tables to allow programmable gamma correction.

 To refresh your memory, gamma correction is the process of compensating for
 the nonlinear response of pixel brightness to input voltage.  A pixel with a
 green value of 60 is much more than twice as bright as a pixel of value 30.
 The Hicolor DAC's lack of built-in gamma correction puts the burden on
 software to perform the correction so that antialising will work properly,
 and images such as digitized photographs will display with the proper
 brightness.  Software gamma correction is possible, but it's a time-consuming
 nuisance; it also decreases the effective color resolution of the Hicolor DAC
 for bright colors, because the bright colors supported by the Hicolor DAC are
 spaced relatively farther apart than the dim colors.

 The lack of gamma correction is, however, a manageable annoyance.  On
 balance, the Hicolor DAC is true to its heritage; a logical, inexpensive, and
 painless extension of SuperVGA.  The obvious next steps are 1024x768 in 32K
 colors, and 800x600 with 24 bpp; heck, 4 Mbytes of display memory (eight
 4-Mbit RAMs) would be enough for 1024x768 24-bpp with room to spare.  In
 short, the Hicolor DAC appears to be squarely in the mainstream of VGA
 evolution.  (Note that although most of the first generation of Hicolor
 boards are built around the ET4000, which has quietly and for good reason
 became the preeminent SuperVGA chip, the Hicolor DAC works with other VGA
 chips and will surely appear on SuperVGAs of all sorts in the near future.)

 Does that mean that the Hicolor DAC will become a standard?  Beats me.  I'm
 out of the forecasting business; the world changes too fast.  The CEG/DAC has
 a head start and is showing up in a number of systems, and who knows what
 else is in the pipeline?  Still, programmers love the Hicolor DAC, and I
 would be astonished if there were not an installed base of at least 100,000
 by the end of the year.  Draw your own conclusions; but me, I can't wait to
 do some antialiased drawing on the Hicolor DAC (and I will, in this column,
 next month).

 If the CEG/DAC is a triumph of inexpensive approxumation, the Hicolor DAC is
 a masterpiece of affordable technology.  I'd have to call a 1-Mbyte Hicolor
 SuperVGA for around $200 the ultimate in graphics cost effectiveness at this
 moment -- but don't expect it to hold that title for more than six months.
 Things change fast in this industry; $200 true-color in a year, anyone?

 Polygon Antialiasing

 To my mind, the best thing about the Hicolor DAC is that, for the first time
 in the VGA market, it makes fast, general antialiasing possible -- and the
 readers of this column will soon see the fruits of that.  You see, what I've
 been working toward in this column is real-time 3-D, perspective drawing on a
 standard PC, without the assistance of any expensive hardware.  The object
 model I'll be using is polygon-based; hence the fast polygon fill code I've
 presented.  With mode X (320x240, 256 colors, undocumented by IBM), we now
 have a fast, square-pixel, page-flipped, 256 colors, undocumented by IBM), we
 now have a fast, square-pixel, page-flipped, 256-color mode, the best that
 standard VGA has to offer.  In this mode, it's possible to do not only
 real-time, polygon-based perspective drawing and animation, but also
 relatively sophisticated effects such as lighting sources, smooth shading,
 and hidden surface removal.  That's everything we need for real-time e-d --
 but things could still be better.

 Pixel are so large in mode X that polygons have very visibly jagged edges.
 These jaggies are the results of the aliasing of which I spoke back in April
 and May; that is, distortion of the true image that results from
 undersampling at the low pixel rate of the screen.  Jaggies are a serious
 problem; the whole point of real-time 3-D is to create the illusion of
 reality, but jaggies quickly destroy that illusion, particularly when they're
 crawling along the edges of moving objects.  More frequent sampling (higher
 resolution) helps, but not as much as you'd think.  What's really needed is
 the ability to blend colors arbitrarily within a single pixel, the better to
 reflect the nature of the true image in the neighborhood of that pixel --
 that is, antialiasing.  The pixels are still as large as ever, but with the
 colors blended properly, the eye processes the screen as a continuous image,
 rather than as a collection of discrete pixels, and perceives the image at
 much higher resolution than the display actually supports.

 There are many ways to antialias, some of them fast enough for real-time
 processing, and they can work wonders in improving image appearance -- but
 they all require a high degree of freedom in choosing colors.  For many sorts
 of graphics, 256 simultaneous colors is fine, but it's not enough for
 generally useful antialiasing (although we will shortly see an interesting
 sort of special-case antialiasing with 256 colors).  Therefore, the one
 element lacking in my quest for affordable real-time 3-D has been good

 No longer.  The Hicolor DAC provides plenty of colors (although I sure do
 with the software didn't have to do gamma correction!), and makes them
 available in a way that allows for efficient programming.  In a couple of
 months, I'm going to start presenting 3-D code; initially, this code will be
 for mode X, but you can expect to see some antialiasing code for the Hicolor
 DAC soon.

 256 Color Antialiasing

 Next month, I'll explain how the Hicolor DAC works -- how to detect it, how
 to initialize it, the pixel format, banking, and so on -- and then I'll
 demonstrate Hicolor antialiasing.  This month, I'm going to demonstrate
 antialiasing on a standard VGA, partly to introduce the uncomplicated but
 effective antialiasing technique that I'll use the next month, partly so you
 can see the improvement that even quick and dirty antialiasing produces, and
 partly to show the sorts of interesting things that can be done with the
 palette in 256-color mode.

 I'm going to draw a cube in perspective.  For reference, Listing One (page
 173) draws the cube in mode 13h (320x200, 256 colors) using the standard
 polygon fill routine that I developed back in February and March.  No, the
 perspective calculations aren't performed in Listing One; I just got the
 polygon vertices out of 3-D software that I'm developing and hardwired them
 into Listing One.  Never fear, though; we'll get to true 3-D soon enough.

 Listing One draws a serviceable cube, but the edges of the cube are very
 jagged.  Imagine the cube spinning, and the jaggies rippling along its edges,
 and you'll see the full dimensions of the problem.

 Listing Two (page 173) and Three (page 173) together draw the same cube, but
 with simple, unweighted antialiasing.  The results are much better than
 Listing One; there's no question in my mind as to which cube I'd rather see
 in my graphics software.

 The antialiasing technique used in Listing Two is straightforward.  Each
 polygon is scanned out in the usual way, but at twice the screen's resolution
 both horizontally and vertically (which I'll call "double-resolution,"
 although it produces four times as many pixels), with the double-resolution
 pixels drawn to a memory buffer, rather than directly to the screen.  Then,
 after all the polygons have been drawn to the memory buffer, a second pass is
 performed; this pass looks at the colors stored in each set of four
 double-resolution pixels, and draws to the screen a single pixel that
 reflects the colors and intensities of the four double-resolution pixels that
 make it up, as shown in Figure 1.  In other words, Listing Two temporarily
 draws the polygons at double resolution, then uses the extra information from
 the double-resolution bitmap to generate an image with an effective
 resolution considerably higher than the screen's actual 320x200 capabilities.

 Two interesting tricks are employed in Listing Two.  First, it would be best
 from the standpoint of speed, if the entire screen could be drawn to the
 double-resolution intermediate buffer in a single pass.  Unfortunately, a
 buffer capable of holding one full 640x400 screen would be 64,000 or more
 bytes in size -- too much memory for most programs to spare.  Consequently,
 Listing Two instead scans out the image just two double-resolution scan lines
 (corresponding to one screen scan line) at a time.  That is, the entire image
 is scanned once for every two double-resolution scan lines, and all
 information not concerning the two lines of current interest is thrown away.
 This banding is implemented in Listing Three, which accepts a full list of
 scan lines to draw, but actually draws only those lines within the current
 scan line band.  Listing Three also draws to the intermediate buffer, rather
 than to the screen.

 The polygon-scanning code from February was hard-wired to call the function
 DrawHorizontalLineList, which drew to the display; this is the
 polygon-drawing code called by Listing One.  That was fine so long as there
 was only one possible drawing target, but now we have two possible targets --
 the display (for nonantialiased drawing), and the intermediate buffer (for
 antialiased drawing).  It's desirable to be able to mix the two, even within
 a single screen, because antialiased drawing looks better but nonantialiased
 is faster.  Consequently, I have modified Listing One from February -- the
 function FillConvexPolygon -- to create FillCnvxPolyDrvr, which is the same
 as FillConvexPolygon, except that it accepts as a parameter the name of the
 function to be used to draw the scanned-out polygon.  FillCnvxPolyDrvr is so
 similar to FillConvexPolygon that it's not worth taking up printed space to
 show it in its entirety; Listing Four (page 174) shows the differences
 between the two; and the new module will be available in its entirety as part
 of the code from this issue, under the name FILCNVXD.C.

 The second interesting trick in Listing Two is the way in which the palette
 is stacked to allow unweighted antialiasing.  Listing Two arranges the
 palette so that rather than 256 independent colors, we'll work with four-way
 combinations within each pixel of three independent colors (red, green, and
 blue), with each pixel accurately reflecting the intensities of each of the
 four color components that it contains.  This allows fast and easy mapping
 from four double-resolution pixels to the single screen pixel to which they
 correspond.  Figure 2 illustrates the mapping of subpixels (double-resolution
 pixels) through the palette to screen pixels.  This palette organization
 converts mode 13h from a 256-color mode to a four-color antialiasing mode.

 It's worth noting that many palette registers are set to identical values by
 Listin Two, because the values of sub-pixels matter, arrangements of these
 values do not.  For example, the pixel values 0x01, 0x04, 0x10, and 0x40 all
 map to 25 percent blue.  By using a table look-up to map sets of four
 double-resolution pixels to screen pixel values, more than half the palette
 could be freed up for drawing with other colors.

 Unweighted Antialiasing: How Good?

 Is the antialiasing used in Listing Two the finest possible antialiasing
 technique?  It is not.  It is an unweighted antialiasing technique, meaning
 that no accounting is made for how close to the center of a pixel a polygon
 edge might be.  The edges are also biased a half-pixel or so in some cases,
 so registration with the underlying image isn't perfect.  Nonetheless, the
 technique used in Listing Two produces attractive results, which is what
 really matters; all screen displays are approximations, and unweighted
 antialiasing is certainly good enough for PC animation applications.
 Unweighted antialiasing can also support good performance, although this is
 not the case in Listing Two and Three, where I have opted for clarity rather
 than performance.  Increasing the number of lines drawn on each pass, or
 reducing the area processed to the smallest possible bounding rectangle would
 help improve performance, as, of course, would the use of assembly language.
 If there's room, I'll demonstrate some of these techniques next month.

 For further information on antialiasing, you might check out the standard
 reference: Computer Graphics, by Foley and van Dam.  Michael Covington's
 "Smooth Views," in the May, 1990 Byte, provides a short but meaty discussion
 of unweighted line antialiasing.

 As relatively good as it looks, Listing Two is still watered-down
 antialiasing, even of the unweighted variety.  For all our clever palette
 stacking, we have only five levels of each color component available; that's
 a far cry from the 32 levels of the Hicolor DAC, or the 256 levels of true
 color.  The limiations of 256-color modes, even with the palette, are showing

 Nexth month, 15-bpp antialiasing.

 The Mode X Mode Set Bug, Revisited

 Two months back, I added a last-minute note to this column describing a fix
 to the mode X mode set code that I presented in the July column.  I'd like to
 describe how this bug slipped past me, as an illustration of why it's so
 difficult to write flawless software nowadays.  The key is this: The PC world
 is so huge and diverse that it's a sure thing that someone, somewhere, will
 eventually get clobbered by even the most innocuous bug -- a bug that you
 might well not have found if you had spent the rest of your life doing
 nothing but beta testing.  It's like the thought that 100 monkeys, typing
 endlessly, would eventually write the complete works of Shakespeare; there
 are 50,000,000 monkeys out there banging on keyboards and mousing around, and
 they will inevitably find any holes you leave in your software.

 In writing the mode X mode set code, I started by modifying known-good code.
 I tried the final version of the code on both of my computers with five
 different VGAs, and I had other people test it out on their systems.  In
 short, I put the code through all the hoops I had available, and then I sent
 it out to be beaten on by 100,000 DDJ readers.  It took all of one day for
 someone to find a bug.

 The code I started with used the VGA's 28-MHz clock.  Mode X should have used
 the 25-MHz clock, a simple matter of setting bit 2 of the Miscellaneous
 Output register (3C2h) to 0 instead of 1.

 Alas, I neglected to change that single bit, so frames were drawn at a faster
 rate than they should have been; however, both of my monitors are
 multifrequency types, and they automatically compensated for the faster frame
 rate.  Consequently, my clock-selection bug was invisible and innocuous --
 until all those monkeys started banging on it.

 IBM makes only fixed-frequency VGA monitors, which require very specific
 frame rates; if they don't get what you've told them to expect, the image
 rolls -- and that's what the July mode X mode set code did on fixed-frequency
 monitors.  The corrected version, shown in Listing Five (page 174), selects
 the 25-MHz clock, and works just fine on fixed-frequency monitors.

 Why didn't I catch this bug?  Neither I nor a single one of my testers had a
 fixed-frequency monitor!  This nicely illustrates how difficult it is these
 days to test code in all the PC-compatible environments in which it might
 run.  The problem is particularly severe for small developers, who can't
 afford to buy every model from every manufacturer; just imagine trying to
 test network-aware software in all possible configurations.

 When people ask why software isn't bulletproof; why it crashes or doesn't
 coexist with certain programs; why PC clones aren't always compatible; why,
 in short, the myriad of irritations of using a PC exist -- this is a big part
 of the reason.  That's just the price we pay for unfettered creativity and
 vast choice in the PC market.

 Unfettered for the moment; but consider AT&T's patent on backing store, the
 "esoteric" idea of storing an obscured area of a window in a buffer so as to
 be able to redraw it quickly.  It took me all of ten minutes to independently
 invent that one five years ago.  Better yet, check out the letters to the
 editor in the July Programmer's Journal, about which I will say no more
 because it sets my teeth on edge.  We'd better hope that no one patents
 "patterned tactile-pressure information input," that is, typing.  Trust
 50,000,000 monkeys to come up with a system as ridiculous as this.

 [BACK] Back

Discuss this article in the forums

Date this article was posted to 7/16/1999
(Note that this date does not necessarily correspond to the date the article was written)

See Also:
Michael Abrash's Articles

© 1999-2011 All rights reserved. Terms of Use Privacy Policy
Comments? Questions? Feedback? Click here!