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>FreeVGA - VGA Sequencer Operation</TITLE>
11 <CENTER><A HREF="../home.htm">Home</A> <A HREF="vga.htm#general">Back</A>
12 <HR><B>Hardware Level VGA and SVGA Video Programming Information Page</B></CENTER>
14 <CENTER>VGA Sequencer Operation
17 <BR> The sequencer portion of
18 the VGA hardware reads the display memory and converts it into data that
19 is sent to the attribute controller. This would normally be a simple
20 part of the video hardware, but the VGA hardware was designed to provide
21 a degree of software compatibility with monochrome, CGA, EGA, and MCGA
22 adapters. For this reason, the sequencer has quite a few different
23 modes of operation. Further complicating programming, the sequencer
24 has been poorly documented, resulting in many variances between various
25 VGA/SVGA implementations.
27 <BR><B>Sequencer Memory Addressing</B>
28 <BR> The sequencer operates by
29 loading a display address into memory, then shifting it out pixel by pixel.
30 The memory is organized internally as 64K addresses, 32 bits wide.
31 The seqencer maintains an internal 16-bit counter that is used to calculate
32 the actual index of the 32-bit location to be loaded and shifted out.
33 There are several different mappings from this counter to actual memory
34 addressing, some of which use other bits from other counters, as required
35 to provide compatibility with older hardware that uses those addressing
38 <P><More to be added here>
40 <BR><B>Graphics Shifting Modes</B>
41 <BR> When the <A HREF="graphreg.htm#06">Alphanumeric
42 Mode Disable</A> field is set to 1, the sequencer operates in graphics
43 mode where data in memory references pixel values, as opposed to the character
44 map based operation used for alphanumeric mode.
45 <BR> The sequencer has three
46 methods of taking the 32-bit memory location loaded and shifting it into
47 4-bit pixel values suitable for graphics modes, one of which combines 2
48 pixel values to form 8-bit pixel values. The first method is the
49 one used for the VGA's 16 color modes. This mode is selected when
50 both the <A HREF="graphreg.htm#05">256-Color Shift Mode</A> and <A HREF="graphreg.htm#05">Shift
51 Register Interleave Mode</A> fields are set to 0. In this mode, one
52 bit from each of the four 8-bit planes in the 32-bit memory is used to
53 form a 16 color value. This is shown in the diagram below, where the most
54 significant bit of each of the four planes is shifted out into a pixel
55 value, which is then sent to the attribute controller to be converted into
56 an index into the DAC palette. Following this, the remaining bits
57 will be shifted out one bit at a time, from most to least significant bit,
58 with the bits from planes 0-3 going to pixel bits 0-3.
61 <CENTER><A HREF="seqplanr.txt"><IMG SRC="seqplanr.gif" ALT="Click here for Textified Planar Shift Mode Diagram" HEIGHT=256 WIDTH=376></A></CENTER>
64 <P> The second shift mode is
65 the packed shift mode, which is selected when both the <A HREF="graphreg.htm#05">256-Color
66 Shift Mode</A> field is set to 0 and the <A HREF="graphreg.htm#05">Shift
67 Register Interleave Mode</A> field is set to 1.This is used by the VGA
68 bios to support video modes compatible with CGA video modes. However,
69 the CGA only uses planes 0 and 1 providing for a 4 color packed mode; however,
70 the VGA hardware actually uses bits from two different bit planes, providing
71 for 16 color modes. The bits for the first four pixels shifted out
72 for a given address are stored in planes 0 and 2. The second four
73 are stored in planes 1 and 3. For each pixel, bits 3-2 are shifted
74 out of the higher numbered plane and bits 1-0 are shifted out of the lower
75 numbered plane. For example, bits 3-2 of the first pixel shifted
76 out are located in bits 7-6 of plane 2; likewise, bits 1-0 of the same
77 pixel are located in bits 7-6 of plane 0.
80 <CENTER><A HREF="seqpack.txt"><IMG SRC="seqpack.gif" ALT="Click for Textified Packed Shift Mode Diagram" HEIGHT=256 WIDTH=376></A></CENTER>
83 <P> The third shift mode is used for
84 256-color modes, which is selected when the <A HREF="graphreg.htm#05">256-Color
85 Shift Mode</A> field is set to 1 (this field takes precedence over the
86 <A HREF="graphreg.htm#05">Shift Register Interleave Mode</A> field.)
87 This behavior of this shift mode varies among VGA implementations, due
88 to it normally being used in combination with the <A HREF="attrreg.htm#10">8-bit
89 Color Enable</A> field of the attribute controller. Thus certain
90 variances in the sequencing operations can be masked by similar variances
91 in the attribute controller. However, the implementations I have
92 experimented with seem to fall into one of two similar behaviors, and thus
93 it is possible to describe both here. Note that one is essentially
94 a mirror image of the other, leading me to believe that the designers knew
95 how it should work to be 100% IBM VGA compatible, but managed to get it
96 backwards in the actual implementation. Due to being very poorly documented
97 and understood, it is very possible that there are other implementations
98 that vary significantly from these two cases. I do, however, feel
99 that attempting to specify each field's function as accurately possible
100 can allow more powerful utilization of the hardware.
101 <BR> When this shift mode is
102 enabled, the VGA hardware shifts 4 bit pixel values out of the 32-bit memory
103 location each dot clock. This 4-bit value is processed by the attribute
104 controller, and the lower 4 bits of the resulting DAC index is combined
105 with the lower 4 bits of the previous attribute lookup to produce an 8-bit
106 index into the DAC palette. This is why, for example, a 320 pixel
107 wide 256 color mode needs to be programmed with timing values for a 640
108 pixel wide normal mode. In 256-color mode, each plane holds a 8-bit
109 value which is intended to be the DAC palette index for that pixel.
110 Every second 8-bit index generated should correspond to the values in planes
111 0-3, appearing left to right on the display. This is masked by the
112 attribute controller, which in 256 color mode latches every second 8-bit
113 value as well. This means that the intermediate 8-bit values are
114 not normally seen, and is where implementations can vary. Another
115 variance is whether the even or odd pixel values generated are the intended
116 data bytes. This also is masked by the attribute controller, which
117 latches the appropriate even or odd pixel values.
118 <BR> The first case is where
119 the 8-bit values are formed by shifting the 4 8-bit planes left.
120 This is shown in the diagram below. The first pixel value generated
121 will be the value held in bits 7-4 of plane 0, which is then followed by
122 bits 3-0 of plane 0. This continues, shifting out the upper four
123 bits of each plane in sequence before the lower four bits, ending up with
124 bits 3-0 of plane 3. Each pixel value is fed to the attribute controller,
125 where a lookup operation is performed using the attribute table.
126 The previous 8-bit DAC index is shifted left by four, moving from the lower
127 four bits to the upper four bits of the DAC index, and the lower 4 bits
128 of the attribute table entry for the current pixel is shifted into the
129 lower 4 bits of the 8-bit value, producing a new 8-bit DAC index.
130 Note how one 4-bit result carries over into the next display memory location
132 <BR> For example, assume planes
133 0-3 hold 01h, 23h, 45h, and 67h respectively, and the lower 4 bits of the
134 the attribute table entries hold the value of the index itself, essentially
135 using the index value as the result, and the last 8-bit DAC index generated
136 was FEh. The first cycle, the pixel value generated is 0h, which is fed
137 to the attribute controller and looked up, producing the table entry 0h
138 (surprise!) The previous DAC index, FEh, is shifted left by four bits,
139 while the new value, 0h is shifted into the lower four bits. Thus,
140 the new DAC index output for this pixel is E0h. The next pixel is
141 1h, which produces 1h at the other end of the attribute controller.
142 The previous DAC index, E0h is shifted again producing 01h. This
143 process continues, producing the DAC indexes, in order, 12h, 23h, 34h,
144 45h, 56h, and 67h. Note that every second DAC index is the appropriate
145 8-bit value for a 256-color mode, while the values in between contain four
146 bits of the previous and four bits of the next DAC index.
149 <CENTER><A HREF="256left.txt"><IMG SRC="256left.gif" ALT="Click for Textified 256-Color Shift Mode Diagram (Left)" HEIGHT=256 WIDTH=376></A></CENTER>
152 <P> The second case is where the 8-bit
153 values are formed by shifting the 8-bit values right, as depicted in the
154 diagram below. The first pixel value generated is the lower four
155 bits of plane 0, followed by the upper four bits. This continues
156 for planes 1-3 until the last pixel value produced, which is the upper
157 four bits of Plane 3. These pixel values are fed to the attribute
158 controller, where the corresponding entry in the attribute table is looked
159 up. The previous 8-bit DAC index is shifted right 4 places. and the
160 lower four bits of the attribute table entry generated is used as the upper
161 four bits of the new DAC index.
162 <BR> For example, assume planes
163 0-3 hold 01h, 23h, 45h, and 67h respectively, and the lower 4 bits of the
164 the attribute table entries hold the value of the index itself, essentially
165 using the index value as the result, and the last 8-bit DAC index generated
166 was FEh. The first cycle, the pixel value generated is 1h, which is fed
167 to the attribute controller and looked up, producing the table entry 1h.
168 The previous DAC index, FEh, is shifted right by four bits, while the new
169 value, 1h is shifted into the upper four bits. Thus, the new DAC
170 index output for this pixel is 1Fh. The next pixel is 0h, which produces
171 0h at the other end of the attribute controller. The previous DAC
172 index, 1Fh is shifted again producing 01h. This process continues,
173 producing the DAC indexes, in order, 30h, 23h, 52h, 45h, 74h, and 67h.
174 Again, note that every second DAC index is the appropriate 8-bit value
175 for a 256-color mode, while the values in between contain four bits of
176 the previous and four bits of the next DAC index.
179 <CENTER><A HREF="256right.txt"><IMG SRC="256right.gif" ALT="Click for Textified 256-Color Shift Mode Diagram (Right)" HEIGHT=256 WIDTH=376></A></CENTER>
182 <BR> Another variance that can
183 exist is whether the first or second DAC index generated at the beginning
184 of a scan line is the appropriate 8-bit value. If it is the second,
185 the first DAC index contains 4 bits from the contents of the DAC index
186 prior to the start of the scan line. This could conceivably contain
187 any value, as it is normally masked by the attribute controller when in
188 256-color mode whcih would latch the odd pixel values. Likely this
189 value will be either 00h or whatever the contents were at the end of the
190 previous scan line. A similar circumstance arises where the last
191 pixel value generated falls on a boundary between memory addresses.
192 In this circumstance, however, the value generated is produced by sequencing
193 the next display memory address as if the line continued, and is thus more
197 <P>Notice: All trademarks used or referred to on this page are the property
198 of their respective owners.
199 <BR>All pages are Copyright © 1997, 1998, J. D. Neal, except where
200 noted. Permission for utilization and distribution is subject to the terms
201 of the <A HREF="license.htm">FreeVGA Project Copyright License</A>.
projects / pintos-anon / blob