X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;ds=sidebyside;f=specs%2Ffreevga%2Fvga%2Fvgadac.htm;fp=specs%2Ffreevga%2Fvga%2Fvgadac.htm;h=4a7c05fd623cd436c7498d293202fcc67d0a0dc3;hb=8af06d1fd50343e17229618ef4d2693193b2b3d9;hp=0000000000000000000000000000000000000000;hpb=d0d14ca50fbac167253e1e1d8d806bfd749a5e8a;p=pintos-anon diff --git a/specs/freevga/vga/vgadac.htm b/specs/freevga/vga/vgadac.htm new file mode 100644 index 0000000..4a7c05f --- /dev/null +++ b/specs/freevga/vga/vgadac.htm @@ -0,0 +1,190 @@ + + + + + + + VGA/SVGA Video Programming--DAC Operation + + + +
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. +
  + +