<!doctype linuxdoc system>

<article>
<title> Information for S3 Chipset Users
<author>The XFree86 Project Inc.
<date>15 January 1995
<toc>

<sect> Supported hardware
<p>
The current S3 Server supports the following S3 chipsets: 911, 924,
801/805, 928, 732 (Trio32), 764 (Trio64), 864, and 964.  The S3 server
will also recognise the 866, 868 and 968, but it has not been tested
these chipsets.  If you have any problems or success with these, please
report it to us.

Nevertheless, this is not enough to support every board using one of these
chipsets. The following list contains some data points on boards that are
known to work.  If your card is similar to one of the described ones,
chances are good it might work for you, too.

<descrip>
<tag>S3 801/805, AT&amp;T 20C490 (or similar) RAMDAC</tag>
	<itemize>
        <item> Orchid Fahrenheit 1280+ VLB
        <item> Actix GE32
	</itemize>

        8 and 15/16 bpp

        Note: the AT&amp;T20C490 RAMDAC is not automatically detected by
        the server.  You need to provide a `<tt/Ramdac "att20c490"/'
        entry in your <tt/XF86Config/.

	Real AT&amp;T 20C490 or 20C491 RAMDACs work with the
        <tt/"dac_8_bit"/ option.  Some clones (like the Winbond
        82C490) do not.


<tag>S3 805 VLB, S3 GENDAC (RAMDAC + clock synthesizer)</tag>
	<itemize>
	<item> MIRO 10SD (available for VLB and PCI)
                       It is not known whether all 10SDs use the S3 GENDAC.
	</itemize>

	8 and 15/16 bpp
			
 <tscreen><verb>
 ClockChip "s3gendac"
 RamDac    "s3gendac"
 </verb></tscreen>


<tag>S3 801/805, AT&amp;T 20C490 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
	<item> STB PowerGraph X.24 S3 (ISA)
	</itemize>

	8 and 15/16 bpp

        Note: the AT&amp;T20C490 RAMDAC is not automatically detected by
        the server.  You need to provide a `<tt/Ramdac "att20c490"/'
        entry in your <tt/XF86Config/.

 <tscreen><verb>
 ClockChip "icd2061a"
 RamDac    "att20c490"
 Option    "dac_8_bit
 </verb></tscreen>


<tag>S3 805, Diamond SS2410 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> Diamond Stealth 24 VLB
	</itemize> 

	8 bpp only.

	requires `<tt/Option "nolinear"/'


<tag>S3 928, AT&amp;T 20C490 RAMDAC </tag>
      	<itemize> 
	<item> Actix Ultra
	</itemize>

 	8 and 15/16 bpp

 	Note: the AT&amp;T20C490 RAMDAC is not automatically detected by
	the server.  You need to provide a `<tt/Ramdac "att20c490"/'
	entry in your <tt/XF86Config/.  Also, the server's RAMDAC probe
	reportedly causes problems with some of these boards, and a
	RamDac entry should be used to avoid the probe.

 	Real AT&amp;T 20C490 or 20C491 RAMDACs work with the
 	<tt/"dac_8_bit"/ option.  Some clones (like the Winbond
 	82C490) do not.


<tag>S3 928, Sierra SC15025 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> ELSA Winner 1000 ISA/EISA (``TwinBus'', not Winner1000ISA!!)
        <item> ELSA Winner 1000 VL
	</itemize>

 	8, 15/16 and 24(32) bpp

 	Supports 8bit/pixel RGB in 8bpp and gamma correction for 15/16
 	and 24bpp modes

 	24 bpp might get ``snowy'' if the clock is near the limit of
 	30MHz. This is not considered dangerous, but limits the
 	usability of 24 bpp.

 	D-step (or below) chips cannot be used with a line width of
 	1152; hence the most effective mode for a 1 MB board is about
 	1088x800x8 (similar to 2 MB, 1088x800x16).


<tag>S3 928, Bt9485 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> STB Pegasus VL 
	</itemize>
                        
 	8, 15/16 and 24(32) bpp

 	Supports RGB with sync-on-green if <tt/"sync_on_green"/
	option is provided and board jumper is set for BNC outputs.

	VLB linear addressing now occurs at 0x7FCxxxxx so that 64MB
	or more main memory can be supported without losing linear
	frame buffer access.

 	Option <tt/"stb_pegasus"/

 	The <tt/"dac_8_bit"/ option is always selected on this board.


<tag>S3 928, Bt485 RAMDAC, SC11412 Clockchip</tag>
	<itemize>
        <item> SPEA Mercury 2MB VL
	</itemize>
                        
 	8, 15/16 and 24(32) bpp   

 	Option <tt/"SPEA_Mercury"/<newline>
 	ClockChip <tt/"SC11412"/

 	The <tt/"dac_8_bit"/ option is recommended.


<tag>S3 928, Bt485 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> &num;9 GXE Level 10, 11, 12
	</itemize>	

 	8, 15/16 and 24(32) bpp

 	Option <tt/"number_nine"/

 	The <tt/"dac_8_bit"/ option is recommended.


<tag>S3 928, Ti3020 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> &num;9 GXE Level 14, 16
	</itemize>
                        
	8, 15/16 and 24(32) bpp

 	Supports RGB with sync-on-green

 	Option <tt/"number_nine"/

 	The <tt/"dac_8_bit"/ option is recommended.


<tag>S3 864, AT&amp;T20c498, ICS2494 Clockchip</tag>
	<itemize>
        <item> MIRO 20SD (BIOS 1.xx)
	</itemize>

 	The ICS2494 is a fixed frequency clockchip, you have to use
	X -probeonly (without a Clocks line in XF86Config) to get the 
	correct clock values.

	8, 15/16 and 24(32) bpp


<tag>S3 864, AT&amp;T20c498 or STG1700 RAMDAC, ICD2061A or ICS9161 Clockchip</tag>
	<itemize>
        <item> Elsa Winner1000PRO VLB
        <item> Elsa Winner1000PRO PCI
        <item> MIRO 20SD (BIOS 2.xx)
	</itemize>

 	8, 15/16 and 24(32) bpp


<tag>S3 864, STG1700 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> Actix GraphicsENGINE 64 VLB/2MB
	</itemize>

 	8, 15/16 (and probably 24(32)) bpp


<tag>S3 864, 20C498 or 21C498 RAMDAC, ICS2595 Clockchip</tag>
	<itemize>
        <item> SPEA MirageP64 2MB DRAM  (BIOS 3.xx)
	</itemize>

 	8 and 15/16 bpp

 	ClockChip <TT/"ICS2595"/

 	Clockchip support is only preliminary and on some machines
 	problems with the first mode after startup of XF86_S3 or after
 	switching back from VT have been seen; switching to next mode
 	with CTRL+ALT+``KP+'' and back seems to solve this problem

        Mirage P64 with BIOS 4.xx uses the S3 SDAC.  


<tag>S3 864, S3 86C716 SDAC RAMDAC and Clockchip</tag>
	<itemize>
        <item> Elsa Winner1000PRO
        <item> MIRO 20SD (BIOS 3.xx)
        <item> SPEA MirageP64 2MB DRAM  (BIOS 4.xx)
        <item> Diamond Stealth 64 DRAM
	</itemize>

 	8, 15/16 and 24 bpp

 	ClockChip <TT/"s3_sdac"/  (should be detected automatically)


<tag>S3 864, ICS5342 RAMDAC and Clockchip</tag>
	<itemize>
        <item> Diamond Stealth 64 DRAM (only some cards)
	</itemize>

 	8, 15/16 and 24 bpp

 	ClockChip <TT/"ics5342"/
 	RAMDAC    <TT/"ics5342"/


<tag>S3 864, AT&amp;T21C498-13 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> &num;9 GXE64 - PCI
	</itemize>
                        
 	8, 15/16, 24(32) bpp

 	Option <tt/"number_nine"/<newline>
 	Option <tt/"dac_8_bit"/ (recommended)
 

<tag>S3 964, AT&amp;T 20C505 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
        <item> Miro Crystal 20SV
	</itemize>

 	8, 15/16, 24(32) bpp


<tag>S3 964, Bt485 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
 	<item> Diamond Stealth 64
	</itemize>

 	8, 15/16, 24(32) bpp


<tag>S3 964, Bt9485 RAMDAC, ICS9161a Clockchip</tag>
	<itemize>
 	<item> SPEA Mercury 64
	</itemize>

 	8, 15/16, 24(32) bpp

 	Option <tt/"SPEA_Mercury"/


<tag>S3 964, Ti3020 RAMDAC, ICD2061A Clockchip</tag>
	<itemize>
 	<item> Elsa Winner2000PRO PCI
	</itemize>

 	8 bpp only


<tag>S3 964, Ti3025 RAMDAC, Ti3025 Clockchip</tag>
	<itemize>
        <item> Miro Crystal 40SV
	<item> &num;9 GXE64 Pro VLB
        <item> &num;9 GXE64 Pro PCI
	</itemize>

 	8 bpp, 15, 16 and 24(32) bpp

 	Option <tt/"number_nine"/

 	There are some known problems with the GXE64 Pro support,
 	including some image shifting/wrapping at 15/16/24 bpp.

 	We have found that &num;9 no longer support the GXE64 Pro
 	at 1600x1200.  They do however have a new (and more expensive)
 	board called the GXE64Pro-1600 which uses a 220MHz RAMDAC
 	instead of 135MHz part used on the other boards.  It is not
 	known at this stage whether the GXE64Pro-1600 will work with
 	XFree86 3.1.

<tag>S3 764 (Trio64)</tag>
	<itemize>
        <item> SPEA Mirage P64 (BIOS 5.xx)
        <item> Diamond Stealth 64 DRAM
        <item> &num;9 GXE64 Trio64
	</itemize>

 	8/15/16/24 bpp

	Note: there are some display wrapping problems with the Trio64 at
	8bpp which have not yet been fixed.

</descrip>

<sect> 16bpp and 32bpp
<p>

On 801/805 + AT&amp;T490 Cards (like the Fahrenheit 1280+ VLB) only 15 and
16bpp are supported. 32bpp isn't available on this type of
chips. (There is a 24 bit mode under MS Windows, but it's not a 32bpp
sparse mode but a real 3 bytes/pixel mode -- implementing this in
XFree86 isn't easy).

<sect>List of Supported Clock Chips
<p>

<tscreen><verb>
ICD2061A                                ==> ClockChip "icd2061a"
ICS9161A (ICD2061A compatible)          ==> ClockChip "ics9161a"
DCS2824-0 (Diamond, ICD2061A comp.)     ==> ClockChip "dcs2824"
 
S3 86c708 GENDAC                        ==> ClockChip "s3gendac"
ICS5300 GENDAC (86c708 compatible)      ==> ClockChip "ics5300"

S3 86c716 SDAC                          ==> ClockChip "s3_sdac"
ICS5342 GENDAC                          ==> ClockChip "ics5342"
 
Sierra SC11412                          ==> ClockChip "sc11412"
ICS2595                                 ==> ClockChip "ics2595"
TI3025                                  ==> ClockChip "ti3025"
</verb></tscreen>

<sect> Additional Notes
<p>
If you have a RAMDAC that is not listed here, be VERY careful not to
overdrive it using XF86_S3. Better contact the XFree86 team first to
verify that running XF86_S3 will not damage your board.

If you feel adventurous you could also open up your computer and have
a peek at your RAMDAC. The RAMDAC is usually one the larger chips
(second or third largest chip that is NOT an EPROM) on the board.  The
markings on it are usually

<tscreen><verb>
  <Company logo>

      <company identifier><part number>-<speed grade>
      <manufacturing week><manufacturing year>  
      <lot number><other funny numbers>
</verb></tscreen>

For example:

<tscreen><verb>
          @@
          @@ AT&amp;T

        ATT20C490-11
         9339S ES
          9869874
</verb></tscreen>

This is a AT&amp;T 490 with a speed grade of 110 MHz. This would then mean
that you put a `<tt/DacSpeed 110/' line in your <tt/XF86Config/ file.  Be
advised that some RAMDACs have different modes that have different
limits. The manufacturer will always mark the chip naming the higher
limits, so you should be careful.  The S3 server knows how to handle
the limits for most of the RAMDACs it supports providing the DacSpeed
is specified correctly.


chips labeled <bf/-80/ or <bf/-8/  should use `<tt/DacSpeed 80/' in
the device section
<tscreen><verb>
S3716-ME SDAC  ==>  DacSpeed 110
SC15025-8      ==>  DacSpeed  80
ATT20C490-80   ==>  DacSpeed  80
</verb></tscreen>

Some RAMDACs (like the Ti3025) require some mode timing consideration
for their hardware cursor to work correctly.  The Ti3025 requires that
the mode have a back porch of at least 80 pixel-clock cycles.  A
symptom of this not being correct is the HW cursor being chopped off
when positioned close to the right edge of the screen.

<sect> How to to avoid "snowing" display while graphics operations
<p>

For cards with S3 Vision864 chip there is a automatic correction which
depends on the pixel clock and the memory clock MCLK at which the S3 chip
operates. For most clock chips this value can't be read (only the S3 SDAC
allows reading the MCLK value so far), so this value has to be estimated 
and specified by the user (the default is 60 [MHz]).

With the new `<tt/s3MCLK/' entry for your <tt/XF86Config/ file now you can 
specify e.g.

 <tscreen><verb>
 s3MCLK 55
 </verb></tscreen>

for a 55 MHz MCLK which will reduce snowing. Smaller MCLK values will reduce 
performance a bit so you shouldn't use a too low value (55 or 50 should be a 
good guess in most cases).

Below is a small shell script which might be useful to determine the
approximate value for MCLK (about +/- 1-2 MHz error). Before running
this script you have to add the line

 <tscreen><verb>
 s3MNadjust -31 255
 </verb></tscreen>

to the device section in your <tt/XF86Config/ file and restart X Windows.
With this option (which is for testing and debugging only) you'll get
lots of disastrous display flickering and snowing, so it should be removed
again immediately after running the test script below.

Running this script will use xbench and/or x11perf to run a test to determine
the MLCK value, which is printed in MHz. Up to 4 tests are run, so you'll
get up to 4 estimates (where the first might be the most accurate one).

<code>
#!/bin/sh

exec 2> /dev/null

scale=2

calc() {
  m=`awk 'BEGIN{printf "%.'$scale'f\n",'"( $1 + $2 ) / $3; exit}" `
  [ -z "$m" ] && m=` echo "scale=$scale; ( $1 + $2 ) / $3" | bc `
  [ -z "$m" ] && m=` echo "$scale $1 $2 + $3 / pq" | dc `
  echo $m
}

run_xbench() { 
  r=` ( echo 1; echo 2; echo 3; echo 4 ) | xbench -only $1 | grep rate `
  [ -z "$r" ] && return
  cp="$2 $3"
  set $r
  calc $3 $cp
}  

run_x11perf() {
  r=` x11perf $1 | grep trep | tr '(/)' '   ' `
  [ -z "$r" ] && return
  cp="$2 $3"
  set $r
  calc `calc 1000 0 $4` $cp    
}

run_x11perf "-rect500 -rop GXxor"     3.86  5.53  #  0 1  #    4.11    5.52  #
run_xbench invrects500                4.63  5.48  #  0 1  #    4.69    5.48  #

run_x11perf "-rect500 -rop GXcopy"  -16.42 13.90  #  0 1  #  -14.99   13.88  #
run_xbench fillrects500              -7.81 13.57  #  0 1  #   -8.53   13.58  #

exit
</code>

<verb>
$XConsortium: S3.sgml,v 1.6 95/01/27 16:14:30 kaleb Exp $
$XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/S3.sgml,v 3.11 1995/01/26 02:19:15 dawes Exp $
</verb>

</article>
