Talk:VGA Hardware

Things that still need to be done:

• I need to reverse engineer more documentation for the sequencer.
• I need to test some additional GC bits for effects.
• Read Modes 0 and 1, Write modes 1,2,3 (this is easy as this documentation is rather complete. I Have not tested all details of this stuff)
• DAC Mask Register (the latest spec doesnt document it)
• Color Logic (There's more to this than the eye meets. I can write this from info out of Abrash's book, but i should still test it anyway. (It partially depends on the Sequencer)
• Sequencer: byte word doubleword mode, doublescanning, why 256-color modes have halved horizontal resolutions. Some of this depends on the sequencer operation...

- Combuster 17:15, 3 January 2007 (CST)

What you can do:

• Proof-read it, check for sanity.
• Comment on n00b-friendliness
• check registers and timings
• probably a lot more :)

- Combuster 16:55, 27 December 2006 (CST)

I'm proof-reading it :-)
Let me know if you'd rather me use British English instead of American English.
- Jack 17:23, 14 October 2011 (UTC)

Detection

You mention checking for VGA compatability before use, but you make no mention of how to check for VGA compatability. I have never programmed for VGA so could not write this myself. --Tyler 18:28, 1 February 2007 (CST)

Well, I don't have any detection code either, because I know of no standard way existing of doing probes. You can deduce an probing method from the info listed, however, but it is not guaranteed to leave non-vga machines intact (see forum thread on ATI Mobile cards). You may want to google for it and contribute whatever you find - Combuster 03:38, 2 February 2007 (CST)

Well i have had a good search. Unfortunately it really is all so device independent that it is impossible to tell. I do recall once reading some kernel source code that verified a colour system was being used in it's initialisation routine. Unfortunately i have misplaced the code so if anyone comes across it, i think it may be used as such. I will keep searching. --Tyler 10:08, 2 February 2007 (CST)

For PCI cards you can probe the class and subclass; if the device class is 0x03 and the subclass is 0x01, then it is VGA compatible; there are no guarantees for any other subclasees (i.e. it might be VGA compatible or it might not).Clearer 08:46, 16 December 2011 (UTC)

Memory layout stuff

Should we turn this section into a link to Bochs_VBE_extensions#Memory_layout_of_video_modes and copy the fleshed-out tidbits to the aforementioned article? Or the other way around? --Troy Martin 00:06, 27 December 2008 (UTC)

"Memory Layout in 4-bit modes"

Surely the memory layout in 4-bit modes would be exactly the same as the memory layout in 16-colour modes? :-)

I assume this title was meant to be "Memory Layout in 4-colour (2-bit) modes". In this case AFAIK it's very similar to 4-bit/16-colour modes, except that only 2 planes are used (instead of 4 planes). The same applies to monochrome (1-bit, 2-colour) modes, where only one plane is used.

Detection

There's at least 3 different "hints" that could be used to help VGA detection.

The first hint is the class code in the device's PCI configuration space. If the class code is 0x03 (display device), the sub-class code is 0x00 and the interface code is 0x00, then (according to PCI standards) the device is: "VGA-compatible controller. Memory addresses 0A0000h through 0BFFFFh. I/O addresses 3B0h to 3BBh and 3C0h to 3DFh and all aliases of these addresses.".

Other class codes define other types of display devices. Example, 0x030000 is VGA, 0x030001 is "8514-compatible controller", 0x030100 is "XGA controller", 0x030200 is "3D controller" and 0x038000 is "Other display controller". Also, class code 0x00???? means that "Device was built before Class Code definitions were finalized".

The second hint is VBE. For "Function 00h - Return VBE Controller Information", Bit 1 in the Capabilities field will be either set (Controller is not VGA compatible) or clear (Controller is VGA compatible).

The third hint is BIOS function Int 0x10, ax = 0x1A00 ("GET DISPLAY COMBINATION CODE (PS,VGA/MCGA)"). I'll let Ralph Brown describe it (see http://www.ctyme.com/intr/rb-0219.htm). I'm assuming that if this function is supported and returns 0x07 or 0x08 then it's VGA compatible (however, if this function is supported and returns 0xFF then the controller may or may not be VGA compatible).

Of course I call these "hints" because I don't think any of them are necessarily definitive. A better idea might be to get the PCI vendor and device IDs and implement a "compatible enough to work" white list and a "not compatible enough" black list (and then rely on the hints above for video cards that aren't in either list).

Old Chain-4 discussion

Been testing the effect of Chain 4 on memory writes and output, and the results aren't consistent with one another. Chain 4 is located in the Sequencer which would mean setting/clearing it would have effect on video output. Furthermore I have been testing whether plane enable has effect in chain 4 writes. - Combuster

This section needs a rewrite. Chain4 mode is perfectly normal function of VGA that standard BIOS 0x13 mode relies on for it's "linear" addressing. Basicly, when chain4 is set, lowest 2 bits of memory access address select the plane, and the address is shifted 2 bits down. The memory organization (as far as display goes) is always planar (like Mode-X) but the special mapping that is chain4 mode makes it appear linear. As such, I find it highly unlikely that the data about chain4 support below is correct. Mystran 09:25, 9 December 2007 (CST)

Here's the catch: all systems emulate mode 0x13 and mode-x up to the extent most programmers do expect. When in mode 0x13, video memory seems linear due to the chain 4 bit. On the other end, selecting the corresponding byte-mode, word-mode and dword-mode make the display come up as appropriate, i.e. dword mode for 0x13 and byte mode for mode-x. It means that when you use only one mode there's nothing wrong. However, bochs does not support the b/w/d-mode bits and instead uses the chain-4 bit to determine the selection. QEmu doesn't support these bits either, but always uses byte mode and redirects the writes in chain-4 enabled mode to the location needed to have byte word work as expected. All the tested emulators have their quirks in this area, assuming that the real cards are the most VGA compatible. (MSVPC being the closest to a real card).

The process to verify the behaviour:

• Enter mode-x, clear screen (I added rulers but they won't interfere with the actual process.)
• Enable chain-4 bit (but leave the BWD bits in their mode-x state) - this should not change the screen (it does however on bochs)
• write a test pattern to the screen
• Visually check the output. On real hardware you'll notice 4 coloured pixels followed by 12 blank ones, 4 pixels, 12 blanks etc.

(you could also clear chain-4 and read out the actual planes to detect qemu writing pixels without blanks)

I have just verified it again. The write address is not shifted as you state, it is ANDed. The 12-pixel gaps appear supporting the stated hypothesis. If you have evidence of the opposite I would gladly see it. The purpose is after all to provide information.

If you look at existing mode-X code you will see that it will change the two Byte/Word/Doubleword bits besides just the chain4 bit.

I have in the meantime learned that the chip ordering isn't as logically distinct as you expect. Chain-4 is located at the GC end of the sequencer and should not affect the output at the CRTC/AC end. I added a stub instead of the comment above to at least make some effort regarding the rewrite - Combuster 17:12, 9 December 2007 (CST)

p.s. would you mind using the talkpage next time