home *** CD-ROM | disk | FTP | other *** search
/ Linux Cubed Series 3: Developer Tools / Linux Cubed Series 3 - Developer Tools.iso / utils / console / svgatext.3 / svgatext / SVGATextMode-1.3 / doc / grabmode_pixmux < prev    next >
Encoding:
Text File  |  1995-09-24  |  5.0 KB  |  93 lines
  1.                 grabmode, a text/XWindows mode grabber
  2.                 ======================================
  3.  
  4. (This is not "compulsory reading". Skip it if you want.)
  5.  
  6. extra note: pixel multiplexing, 15/16 bit and 24 bit modes
  7. ----------------------------------------------------------
  8.  
  9. Why doesn't grabmode work correctly on non-256 color graphics modes on most
  10. cards? To understand this, you have to dig a little deeper into the
  11. specifics of VGA cards. If you like tech-talk, read on!
  12.  
  13. Normal, "el cheapo" VGA cards come with a DAC on it that has an 8-bit
  14. interface to the VGA chip. Even most so-called "24-bit" DAC's have just
  15. 8-bit interfaces to the VGA chip. They have a "color palette" lookup table
  16. on board (that makes them a "RAMDAC" instead of just a "DAC") which can
  17. translate an 8-bit value into a 24-bit (or 18-bit on really cheap things)
  18. color value before sending that off to three 8-bit (or six bit) DAC's, and
  19. then to the RGB-outputs of the VGA card.
  20.  
  21. In "normal" 256-color graphics modes, this is an ideal solution: one pixel
  22. just needs one byte, and one byte is sent to the DAC for each pixel. So when
  23. the pixel rate (not necessarily equal to the pixel CLOCK!) is e.g. 75 MHz
  24. for an 1024x768x256 @ 70Hz graphics mode, the data rate through that channel
  25. from the VGA chip to the DAC is also 75 MHz. And in this case this is of
  26. course also the pixel CLOCK. Very simple.
  27.  
  28. BUT. When you want higher-resolution images, like 1280x1024x256 @ 70 Hz, the
  29. pixel rate must increase to 125 or even 135 MHz. And most relatively
  30. low-cost CMOS designs can go up to 110 MHz, but in most cases not much
  31. higher (ET4000, Cirrus Logic, Trident,... all stop at 90 MHz, S3-805 for
  32. example has a max of 110 MHz). Going higher than that would make the VGA
  33. chip cost LOTS more. So what did they do?
  34.  
  35. They used a wider interface, like e.g. 16-bit (eg ET4000W32p), 24-bit (eg
  36. Bt485) or for really high-end stuff: 48, 64, 96, 128, 256-bit (eg IBM,)
  37. interfaces. The DAC then either needs to double (triple, ...) the pixel
  38. clock internally by itself (in the 16-bit case it gets 2 pixels per clock
  39. beat, so it needs to create the double clock to be able to display both
  40. pixels sequentially), or get that clock from the VGA chip.
  41.  
  42. Creating the actual pixel clock only inside the DAC, instead of externally
  43. generating it and trying to feed it to all other chips that would need it
  44. has some major advantages. Price is of course the most important reason:
  45. high-speed digital boards need a very well though-out layout, are more
  46. difficult to get through those stringent US FCC-rules, can create
  47. power-dissipation problems, and use more expensive components. 
  48.  
  49. All this means you can let the VGA chip run at the "cooler" (and cheaper)
  50. clocks of 1/2, 1/3, ... of the pixel clock. But of course both the VGA chip
  51. and the DAC have to "know" about this. 
  52.  
  53. This also explains the limit on many cheap VGA cards on maximum 15/16 and
  54. 24-bit resolutions: since they have only 8-bit interfaces, they need to send
  55. TWO bytes for each 16-bit pixel, and even THREE for 24-bit pixels. And they
  56. have to do that over the same 8-bit bus! Those VGA cards need to be
  57. programmed with the DOUBLE pixel clock for 16-bit modes, and TRIPLE the
  58. pixel clock for 24-bit modes. e.g. an 640x480 mode needs only 25 MHz pixel
  59. clock at 8-bit per pixel. But 50 MHz at 16-bit, and 75 (!) MHz at 24-bit. 
  60.  
  61. My S3-805 card is such an example. I DO have 2MB of video RAM on board, and
  62. that would theoretically allow me to do resolutions OVER 800x600 at 24-bit.
  63. BUT, since 800x600 requires a 50 MHz clock (for 70 Hz refresh) at 8 bit
  64. colors, running it at 24 bit would require 150 MHZ!!! And that would
  65. probably fry it for good...
  66.  
  67. If you would have a DAC with a "wider" interface, you wouldn't need those
  68. double/triple clocks: you can send a pixel in its whole in one clock beat!
  69. So your card probably CAN handle higher resolutions at 24-bit! Of course,
  70. such a card is a bit more expensive.
  71.  
  72. Also, most accelerators cannot work at 24-bit, since that is a rather clumsy
  73. memory organisation, and would be hard to implement in silicon. In most
  74. cases, silicon designers choose for a 32 bit pixel format. This waists a
  75. byte per pixel, but is a lot easier in hardware than 24-bit. You migh have
  76. read in the docs for XFREE3.x that 24-bit modes are NOT supported, but
  77. 32-bit modes are.
  78.  
  79. What is the impact of all this on grabmode?
  80.  
  81. As already mentionned above, grabmode does NOT know about ANY special VGA
  82. chip. It just reads registers, and reports what's in there. So if some chip
  83. needs real values divided by 4 (because it uses pixel multiplexing over a
  84. wider-than-8 bit bus to reduce the external clock rates), then grabmode will
  85. NOT know about this. This is a sad situation, but I didn't want to put all
  86. kinds of chipset-detection code in it. First of all, that's too much work.
  87. Secondly, you're always at least one step behind chip set makers. Thirdly,
  88. grabmode was primarily designed for testing text modes (debugging). I added
  89. graphics modes to it, because that was EASY. At least, for standard chips...
  90. For the moment, I do NOT intend to do anything about that...
  91.  
  92.  
  93.