3 <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
4 <META NAME="Author" CONTENT="Joshua Neal">
5 <META NAME="Description" CONTENT="Pure VGA/SVGA hardware programming (registers, identification, and otherlow-level stuff.)">
6 <META NAME="KeyWords" CONTENT="VGA SVGA hardware video programming">
7 <TITLE>VGA/SVGA Video Programming--DAC Operation</TITLE>
11 <CENTER><A HREF="../home.htm">Home</A> <A HREF="#intro">Intro</A> <A HREF="#DAC">DAC</A>
12 <A HREF="#programming">Programming</A> <A HREF="#precautions">Precautions</A>
13 <A HREF="#flicker">Flicker</A> <A HREF="#state">State</A> <A HREF="vga.htm#general">Back</A>
14 <HR WIDTH="100%"><B>Hardware Level VGA and SVGA Video Programming Information
17 <CENTER>DAC Operation
18 <HR WIDTH="100%"></CENTER>
22 <A HREF="#intro">Introduction</A> -- details the standard VGA DAC capabilities.</LI>
25 <A HREF="#DAC">DAC Subsystem</A> -- gives a description of the DAC hardware.</LI>
28 <A HREF="#programming">Programming the DAC</A> -- details reading and writing
32 <A HREF="#precautions">Programming Precautions</A> -- details potential
33 problems that can be encountered with DAC hardware.</LI>
36 <A HREF="#flicker">Eliminating Flicker</A> -- details on how to manipulate
37 DAC memory without causing visible side-effects.</LI>
40 <A HREF="#state">The DAC State</A> -- details one possible use for an otherwise
43 <A NAME="intro"></A><B>Introduction</B>
44 <BR> One of the improvements
45 the VGA has over the EGA hardware is in the amount of possible colors that
46 can be generated, in addition to an increase in the amount of colors that
47 can be displayed at once. The VGA hardware has provisions for up to 256
48 colors to be displayed at once, selected from a range of 262,144 (256K)
49 possible colors. This capability is provided by the DAC subsystem, which
50 accepts attribute information for each pixel and converts it into an analog
51 signal usable by VGA displays.
53 <P><A NAME="DAC"></A><B>DAC Subsystem</B>
54 <BR> The VGA's DAC subsystem
55 accepts an 8 bit input from the attribute subsystem and outputs an analog
56 signal that is presented to the display circuitry. Internally it contains
57 256 18-bit memory locations that store 6 bits each of red, blue, and green
58 signal levels which have values ranging from 0 (minimum intensity) to 63
59 (maximum intensity.) The DAC hardware takes the 8-bit value from the attribute
60 subsystem and uses it as an index into the 256 memory locations and obtains
61 a red, green, and blue triad and produces the necessary output.
62 <BR> Note -- the DAC subsystem
63 can be implemented in a number of ways, including discrete components,
64 in a DAC chip which may or may not contain internal ram, or even integrated
65 into the main chipset ASIC itself. Many modern DAC chipsets include additional
66 functionality such as hardware cursor support, extended color mapping,
67 video overlay, gamma correction, and other functions. Partly because of
68 this it is difficult to generalize the DAC subsystem's exact behavior.
69 This document focuses on the common functionality of all VGA DACs; functionality
70 specific to a particular chipset are described elsewhere.
72 <P><A NAME="programming"></A><B>Programming the DAC</B>
73 <BR> The DAC's primary host interface
74 (there may be a secondary non-VGA compatible access method) is through
75 a set of four external registers containing the <A HREF="colorreg.htm#3C8">DAC
76 Write Address</A>, the <A HREF="colorreg.htm#3C7W">DAC Read Address</A>,
77 the <A HREF="colorreg.htm#3C9">DAC Data</A>, and the <A HREF="colorreg.htm#3C7R">DAC
78 State</A> fields. The DAC memory is accessed by writing an index value
79 to the <A HREF="colorreg.htm#3C8">DAC Write Address</A> field for write
80 operations, and to the <A HREF="colorreg.htm#3C7W">DAC Read Address</A>
81 field for read operations. Then reading or writing the <A HREF="colorreg.htm#3C9">DAC
82 Data</A> field, depending on the selected operation, three times in succession
83 returns 3 bytes, each containing 6 bits of red, green, and blue intensity
84 values, with red being the first value and blue being the last value read/written.
85 The read or write index then automatically increments such that the next
86 entry can be read without having to reprogramming the address. In this
87 way, the entire DAC memory can be read or written in 768 consecutive I/O
88 cycles to/from the <A HREF="colorreg.htm#3C9">DAC Data</A> field. The <A HREF="colorreg.htm#3C7R">DAC
89 State</A> field reports whether the DAC is setup to accept reads or writes
92 <P><A NAME="precautions"></A><B>Programming Precautions</B>
93 <BR> Due to the variances in
94 the different implementations, programming the DAC takes extra care to
95 ensure proper operation across the range of possible implementations. There
96 are a number of things can cause undesired effects, but the simplest way
97 to avoid problems is to ensure that you program the <A HREF="colorreg.htm#3C7W">DAC
98 Read Address</A> field or the <A HREF="colorreg.htm#3C8">DAC Write Address</A>
99 field before each read operation (note that a read operation may include
100 reads/writes to multiple DAC memory entries.) And always perform writes
101 and reads in groups of 3 color values. The DAC memory may not be updated
102 properly otherwise. Reading the value of the <A HREF="colorreg.htm#3C8">DAC
103 Write Address</A> field may not produce the expected result, as some implementations
104 may return the current index and some may return the next index. This operation
105 may even be dependent on whether a read or write operation is being performed.
106 While it may seem that the DAC implements 2 separate indexes for read and
107 write, this is often not the case, and interleaving read and write operations
108 may not work properly without reprogramming the appropriate index.
111 <B>Read Operation</B></LI>
115 Disable interrupts (this will ensure that a interrupt service routine will
116 not change the DAC's state)</LI>
119 Output beginning DAC memory index to the <A HREF="colorreg.htm#3C7W">DAC
120 Read Address</A> register.</LI>
123 Input red, blue, and green values from the <A HREF="colorreg.htm#3C9">DAC
124 Data</A> register, repeating for the desired number of entries to be read.</LI>
127 Enable interrupts</LI>
131 <B>Write Operation</B></LI>
135 Disable interrupts (this will ensure that a interrupt service routine will
136 not change the DAC's state)</LI>
139 Output beginning DAC memory index to the <A HREF="colorreg.htm#3C8">DAC
140 Write Address</A> register.</LI>
143 Output red, blue, and green values to the <A HREF="colorreg.htm#3C9">DAC
144 Data</A> register, repeating for the desired number of entries to be read.</LI>
147 Enable interrupts</LI>
150 <A NAME="flicker"></A><B>Eliminating Flicker</B>
151 <BR> An important consideration
152 when programming the DAC memory is the possible effects on the display
153 generation. If the DAC memory is accessed by the host CPU at the same time
154 the DAC memory is being used by the DAC hardware, the resulting display
155 output may experience side effects such as flicker or "snow". Note that
156 both reading and writing to the DAC memory has the possibility of causing
157 these effects. The exact effects, if any, are dependent on the specific
158 DAC implementation. Unfortunately, it is not possible to detect when side-effects
159 will occur in all circumstances. The best measure is to only access the
160 DAC memory during periods of horizontal or vertical blanking. However,
161 this puts a needless burden on programs run on chipsets that are not affected.
162 If performance is an issue, then allowing the user to select between flicker-prone
163 and flicker-free access methods could possibly improve performance.
165 <P><A NAME="state"></A><B>The DAC State</B>
166 <BR> The <A HREF="colorreg.htm#3C7R">DAC
167 State</A> field seems to be totally useless, as the DAC state is usually
168 known by the programmer and it does not give enough information (about
169 whether a red, green, or blue value is expected next) for a interrupt routine
170 or such to determine the DAC state. However, I can think of one possible
171 use for it. You can use the DAC state to allow an interrupt driven routine
172 to access the palette (like for palette rotation effects or such) while
173 still allowing the main thread to write to the DAC memory. When the interrupt
174 routine executes it should check the DAC state. If the DAC state is in
175 a write state, it should not access the DAC memory. If it is in a read
176 state, the routine should perform the necessary DAC accesses then return
177 the DAC to a read state. This means that the main thread use the DAC state
178 to control the execution of the ISR. Also it means that it can perform
179 writes to the DAC without having to disable interrupts or otherwise inhibit
183 <P>Notice: All trademarks used or referred to on this page are the property
184 of their respective owners.
185 <BR>All pages are Copyright © 1997, 1998, J. D. Neal, except where
186 noted. Permission for utilization and distribution is subject to the terms
187 of the <A HREF="license.htm">FreeVGA Project Copyright License</A>.
projects / pintos-anon / blob