  Information for W32 and ET6000 Chipset Users
  Glenn G. Lai <glenn@cs.utexas.edu>, Dirk H. Hohndel <hohn-
  del@XFree86.Org>, Koen Gadeyne <koen.gadeyne@barco.com>
  November 13, 1995

  1.  Information for W32 Chipset Users

  XF86_W32 is basically XF86_SVGA with the drawing code completely
  replaced with one based on X11R6's mi/cfb code and modified for the
  ET4000/W32 series.  Even though it accepts the same keywords as
  XF86_SVGA, those not applicable to the ET4000/W32 series are silently
  ignored; e.g., the keyword "SpeedUp" is a no-op.  The server currently
  supports the w32, w32i, and w32p chips.  For a complete list, see the
  sign-on message printed by XF86_W32.  The server only supports 256
  colors.

  Just as with XF86_SVGA, you can specify a virtual world that has a
  width that is a multiple of four.  The size of the virtual world is
  constrained by the amount of the available video RAM.  XF86_W32 can
  use more than 1 M of video RAM, but it reserves 1 K for internal use.
  If you have 1 M, XF86_W32 claims you have 1023 K; you get to specify
  the virtual world as 1152x900, but not 1152x910.

  For most cards the maximum clock is set to 86 MHz according to the
  Tseng databooks.  For a non-interlaced 1280x1024x(256 colors) at say
  135-MHz, you need a w32p (with its 16-bit RAMDAC bus) with a
  multiplexing RAMDAC so that the w32p sees only (135/2 = 67.5) MHz, not
  135 MHz.  This requires special code only provided for cards using the
  ICS5341 GENDAC or the STG1703. This code seems to work fine for most
  people, except, with the ICS5341, for a small band of frequencies
  around 90MHz.

  If you have problems with the server.  Try the following:

     o  Put Option "pci_burst_off" in the Device Section.

     o  Put Option "w32_interleave_off" in the Device Section.

     o  Take out the Hercules monochrome adapter, if you have one.  Many
        configurations of the ET4000/W32 series do not allow one in the
        system.

     o  Get a motherboard with its local bus running at 33 MHz.  Many,
        if not all, ET4000/W32 boards will surely behave in a funny way
        on a 50-MHz bus.  You may have to use a wait state or two, but
        first try without any.

     o  Cold-boot your machine.  Do not run anything that messes with
        the video hardware, including other X servers, before running
        XF86_W32.

     o  Try XF86_SVGA.  If it works, put the following in your
        XF86Config:



          Ramdac "generic"





  Note that the built-in power saver (for a "green" monitor) has not
  been tested.  Also do not expect it to work on a board without a
  w32p_rev_c or later chip.

  2.  Using XF86_W32 on a board with an ICS5341 GENDAC

  Even though the GENDAC provides a set of standard clocks that can be
  found with the normal clock probing procedure, it is mandatory to put
  a


       ClockChip  "ics5341"




  line into the Device Section to be able to use the programmable clocks
  that the ICS5341 can produce. You can also add a


       Ramdac     "ics5341"




  line, but the RAMDAC should be auto-probed correctly.  Even though the
  server currently accepts any dot clock up to 135MHz with the ICS5341
  GENDAC, most boards show a small band of clock values in the area
  between 86MHz and about 100MHz that don't work. This are usually is
  just a few MHz wide, higher clocks as well as lower clocks work just
  fine. I'm working on it. (DHH)

  3.  Using XF86_W32 on a board with an STG1703 GENDAC

  Even though the STG1703 provides a set of standard clocks that can be
  found with the normal clock probing procedure, it is mandatory to put
  a


       ClockChip  "stg1703"




  line into the Device Section to be able to use the programmable clocks
  that the STG1703 can produce. You can also add a


       Ramdac     "stg1703"




  line, but the RAMDAC should be auto-probed correctly.

  4.  Using XF86_W32 on an ET6000-based board

  The ET6000 driver code was developed on top of the existing ET4000/W32
  code, because of the many similarities between both devices. As with
  the other W32 (external) clockchip/RAMDAC devices, the ET6000's built-
  in clockchip/RAMDAC provides a set of 8 standard clocks, which could
  be probed with the normal XFree clock probing procedure.  In spite of
  that, XF86_W32 will always use the built-in programmable clockchip and
  RAMDAC. So there is no need for a


        ClockChip "et6000"



  or a


        Ramdac "et6000"



  line in the Device Section of the XF86Config file. Once it knows it's
  dealing with an ET6000, XF86_W32 will find its own way.  At this
  moment, accelerated support is very sketchy, and only uses those
  things the ET4000/W32 code already provided, with some changes due to
  incompatibilities between the two devices. Major speed improvements
  should be possible.  Tseng Labs specifies a maximum pixel clock of 135
  MHz for the ET6000 chips (with higher clocks to come).

  5.  Acknowledgments

  Jerry J. Shekhel (jerry@msi.com) gave me (GGL) the 1-M Mirage
  ET4000/W32 VLB board on which the initial development (X_W32) was
  done.

  X11R6 and The XFree86 Project provide the base code for XF86_W32.

  Hercules Computer Technology Inc. lent me (GGL) a 2-M Hercules
  Dynamite Pro VLB board for the development that led to XF86_W32.
  They donated a Dynamite Power PCI to The XFree86 Project, that was
  used by DHH to extend the server.

  Koen Gadeyne (koen.gadeyne@barco.com) wrote a patchkit for
  XFree86-3.1.1 that was partly integrated in this server and he
  continues to help develop it.

  Tseng Labs Europe kindly donated (KMG) an ET6000-based board (a Jazz
  Multimedia G-Force 128), which spurred the development of the ET6000
  code.

  Numerous testers have given me feedback for X_W32 and later XF86_W32.
  I apologize for my failure to keep track of the people who tested
  X_W32, but the names of the people involved with the XF86_W32 testing
  are listed below:

     Linux:
        bf11620@coewl.cen.uiuc.edu (Byron Thomas Faber)

        dlj0@chern.math.lehigh.edu (David Johnson)

        peterc@a3.ph.man.ac.uk (Peter Chang)

        dmm0t@rincewind.mech.virginia.edu (David Meyer)

        nrh@philabs.Philips.COM (Nikolaus R. Haus)

        jdooley@dbp.caltech.edu (James Dooley)

        thumper@hitchcock.eng.uiowa.edu (Timothy Paul Schlie)

        klatta@pkdla5.syntex.com (Ken Latta)

        robinson@cnj.digex.net (Andrew Robinson)

        reggie@phys.washington.edu (Reginald S. Perry)

        sjm@cs.tut.fi (M{kinen Sami J)

        engel@yacc.central.de (C. Engelmann) use cengelm@gwdg.de

        postgate@cafe.net (Richard Postgate)

        are1@cec.wustl.edu (Andy Ellsworth)

        bill@celtech.com (Bill Foster)

      FreeBSD:
        ljo@ljo-slip.DIALIN.CWRU.Edu (L Jonas Olsson)


  Generated from XFree86: xc/programs/Xserver/hw/xfree86/doc/sgml/W32.sgml,v 3.11 1996/08/13 11:30:58 dawes Exp $





  $XConsortium: W32.sgml /main/9 1996/01/07 18:54:35 kaleb $


















































$XFree86: xc/programs/Xserver/hw/xfree86/doc/README.W32,v 3.20 1996/08/13 11:42:18 dawes Exp $
