Home Intro DAC Programming Precautions Flicker State Back 
Hardware Level VGA and SVGA Video Programming Information Page
DAC Operation 
Introduction
        One of the improvements the VGA has over the EGA hardware is in the amount of possible colors that can be generated, in addition to an increase in the amount of colors that can be displayed at once. The VGA hardware has provisions for up to 256 colors to be displayed at once, selected from a range of 262,144 (256K) possible colors. This capability is provided by the DAC subsystem, which accepts attribute information for each pixel and converts it into an analog signal usable by VGA displays.

DAC Subsystem
        The VGA's DAC subsystem accepts an 8 bit input from the attribute subsystem and outputs an analog signal that is presented to the display circuitry. Internally it contains 256 18-bit memory locations that store 6 bits each of red, blue, and green signal levels which have values ranging from 0 (minimum intensity) to 63 (maximum intensity.) The DAC hardware takes the 8-bit value from the attribute subsystem and uses it as an index into the 256 memory locations and obtains a red, green, and blue triad and produces the necessary output.
        Note -- the DAC subsystem can be implemented in a number of ways, including discrete components, in a DAC chip which may or may not contain internal ram, or even integrated into the main chipset ASIC itself. Many modern DAC chipsets include additional functionality such as hardware cursor support, extended color mapping, video overlay, gamma correction, and other functions. Partly because of this it is difficult to generalize the DAC subsystem's exact behavior. This document focuses on the common functionality of all VGA DACs; functionality specific to a particular chipset are described elsewhere.

Programming the DAC
        The DAC's primary host interface (there may be a secondary non-VGA compatible access method) is through a set of four external registers containing the DAC Write Address, the DAC Read Address, the DAC Data, and the DAC State fields. The DAC memory is accessed by writing an index value to the DAC Write Address field for write operations, and to the DAC Read Address field for read operations. Then reading or writing the DAC Data field, depending on the selected operation, three times in succession returns 3 bytes, each containing 6 bits of red, green, and blue intensity values, with red being the first value and blue being the last value read/written. The read or write index then automatically increments such that the next entry can be read without having to reprogramming the address. In this way, the entire DAC memory can be read or written in 768 consecutive I/O cycles to/from the DAC Data field. The DAC State field reports whether the DAC is setup to accept reads or writes next.

Programming Precautions
        Due to the variances in the different implementations, programming the DAC takes extra care to ensure proper operation across the range of possible implementations. There are a number of things can cause undesired effects, but the simplest way to avoid problems is to ensure that you program the DAC Read Address field or the DAC Write Address field before each read operation (note that a read operation may include reads/writes to multiple DAC memory entries.) And always perform writes and reads in groups of 3 color values. The DAC memory may not be updated properly otherwise. Reading the value of the DAC Write Address field may not produce the expected result, as some implementations may return the current index and some may return the next index. This operation may even be dependent on whether a read or write operation is being performed. While it may seem that the DAC implements 2 separate indexes for read and write, this is often not the case, and interleaving read and write operations may not work properly without reprogramming the appropriate index.

Eliminating Flicker
        An important consideration when programming the DAC memory is the possible effects on the display generation. If the DAC memory is accessed by the host CPU at the same time the DAC memory is being used by the DAC hardware, the resulting display output may experience side effects such as flicker or "snow". Note that both reading and writing to the DAC memory has the possibility of causing these effects. The exact effects, if any, are dependent on the specific DAC implementation. Unfortunately, it is not possible to detect when side-effects will occur in all circumstances. The best measure is to only access the DAC memory during periods of horizontal or vertical blanking. However, this puts a needless burden on programs run on chipsets that are not affected. If performance is an issue, then allowing the user to select between flicker-prone and flicker-free access methods could possibly improve performance.

The DAC State
        The DAC State field seems to be totally useless, as the DAC state is usually known by the programmer and it does not give enough information (about whether a red, green, or blue value is expected next) for a interrupt routine or such to determine the DAC state. However, I can think of one possible use for it. You can use the DAC state to allow an interrupt driven routine to access the palette (like for palette rotation effects or such) while still allowing the main thread to write to the DAC memory. When the interrupt routine executes it should check the DAC state. If the DAC state is in a write state, it should not access the DAC memory. If it is in a read state, the routine should perform the necessary DAC accesses then return the DAC to a read state. This means that the main thread use the DAC state to control the execution of the ISR. Also it means that it can perform writes to the DAC without having to disable interrupts or otherwise inhibit the ISR.
 

Notice: All trademarks used or referred to on this page are the property of their respective owners.
All pages are Copyright © 1997, 1998, J. D. Neal, except where noted. Permission for utilization and distribution is subject to the terms of the FreeVGA Project Copyright License.