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 @@ + +
+ + + + +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.
+
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.
+
+
+