Talk:VGA Hardware: Difference between revisions
Jump to navigation
Jump to search
Moved from main page
(→Detection: new section) |
(Moved from main page) |
||
Line 49:
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. [[User:Mystran|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'' - [[User:Combuster|Combuster]] 17:12, 9 December 2007 (CST)
''p.s. would you mind using the talkpage next time''
| |||