Provided by: libsvga1_1.4.3-27_i386 bug

NAME

       svgalib.mach32 - Information on the Mach32 chipset driver

TABLE OF CONTENTS

        0. Introduction
        1. Specifying pixel clocks
        2. Copyrights
        3. The mach32info utility
        4. Third party cards
        5. Logical line width
        6. Noisy video signals
        7. The configuration EEPROM
        8. EEPROM woes
        9. The Mach32Eeprom command
       10. Setup of the memory aperture (linear framebuffer)
       11. Accelerator support and other weird features
       12. Ramdacs
       13. Meaning of the detection message from svgalib
       14. Conclusions

0. INTRODUCTION

       The  driver  should allow you to use any of the graph-modes your Mach32
       card supports. Note that there is no support for <8bpp modes and that I
       won’t  ever implement that because I don’t see any reason for doing so.
       All standard VGA-modes are supported, of course (by using the  standard
       VGA driver routines).

       If  you configured your Mach32 for a memory aperture and it is at least
       as big as the memory of your card (that is, not a 1MB  memory  aperture
       for  a  2MB  card) support for linear frame buffer access of svgalib is
       given.

       Auto detection of the Mach32 seems not to work  on  all  cards.  That’s
       really  strange since I got the code from the X people. It should be OK
       regardless of my docs. Well, I fixed that (hopefully). Actually the bug
       was  found  by Daniel Lee Jackson (djackson@ichips.intel.com).  (Thanks
       again.. It was so silly... I would have never found it)  If  you  still
       have problems just put a chipset Mach32 in your config file.

1. SPECIFYING PIXEL CLOCKS

       WARNING!  The Mach32 driver needs to know correct clock frequencies for
       graceful DAC configuration. Wrong clocks may damage your card! However,
       this  version  contains code for automatic clock detection. Since clock
       detection is time critical, please do it on a completely  idle  system.
       Then put the printed out clocks line in your libvga.config(5) file.

       The  driver  tries  to  do  this  for you.  After that, you can restart
       whatever svgalib program you used and you are set. If you already put a
       clocks  line  in your config by hand, comment it out to have the driver
       check your clocks.

       Since clock probing is time critical, values differ from time to  time,
       you  may  try  it  multiple  times and see which values seem to be most
       exact. You can also compare them with  the  standard  clock  chips  for
       Mach32 cards in libvga.config(5)).

       The clock probing relies on the 7th clock being 44.9MHz as this is what
       Xfree does.  If this is not true (and it is  not  always),  probing  is
       hosed.  See  libvga.config(5)  for  a list of the clocks used by common
       svgalib cards.

2. COPYRIGHTS

       Some tiny routines are copied from Xfree86. The clock detection code is
       almost  just  copied.  So  I  repeat the copyright statements for these
       parts here:

       Copyright 1992 by Orest Zborowski <obz@Kodak.com>
       Copyright 1993 by David Wexelblat <dwex@goblin.org>

       Permission to use, copy, modify, distribute, and sell this software and
       its  documentation  for  any  purpose  is  hereby  granted without fee,
       provided that the above copyright notice appear in all copies and  that
       both  that  copyright  notice  and  this  permission  notice  appear in
       supporting documentation, and that the names  of  Orest  Zborowski  and
       David  Wexelblat  not be used in advertising or publicity pertaining to
       distribution  of  the  software   without   specific,   written   prior
       permission. Orest Zborowski and David Wexelblat make no representations
       about the suitability of this software for any purpose. It is  provided
       "as is" without express or implied warranty.

       Orest Zborowski and David Wexelblat disclaim all warranties with regard
       to this software, including all implied warranties  of  merchantability
       and  fitness,  in  no event shall Orest Zborowski or David Wexelblat be
       liable for any  special,  indirect  or  consequential  damages  or  any
       damages whatsoever resulting from loss of use, data or profits, whether
       in an action of contract, negligence or other tortious action,  arising
       out of or in connection with the use or performance of this software.

       Copyright 1990,91 by Thomas Roell, Dinkelscherben, Germany.
       Copyright 1993 by Kevin E. Martin, Chapel Hill, North Carolina.

       Permission to use, copy, modify, distribute, and sell this software and
       its documentation for  any  purpose  is  hereby  granted  without  fee,
       provided  that the above copyright notice appear in all copies and that
       both that  copyright  notice  and  this  permission  notice  appear  in
       supporting documentation, and that the name of Thomas Roell not be used
       in advertising or publicity pertaining to distribution of the  software
       without  specific,  written  prior  permission.  Thomas  Roell makes no
       representations about the suitability of this software for any purpose.
       It is provided "as is" without express or implied warranty.

       Thomas  Roell,  Kevin  E.  Martin,  and  Rickard  E. Faith disclaim all
       warranties  with  regard  to  this  software,  including  all   implied
       warranties  of  merchantability  and  fitness,  in  no  event shall the
       authors be liable for any special, indirect or consequential damages or
       any  damages  whatsoever  resulting  from loss of use, data or profits,
       whether in an action of contract, negligence or other tortious  action,
       arising  out  of  or  in connection with the use or performance of this
       software.

       Author:  Thomas Roell, roell@informatik.tu-muenchen.de

       Rewritten for the 8514/A by Kevin E. Martin (martin@cs.unc.edu)
       Modified for the Mach-8 by Rickard E. Faith (faith@cs.unc.edu)
       Rewritten for the Mach32 by Kevin E. Martin (martin@cs.unc.edu)

       And here is my own copyright:

       This driver is free software; you can redistribute it and/or modify  it
       without  any restrictions. This library is distributed in the hope that
       it will be useful, but without any warranty.

       Copyright 1994 by Michael Weller

       Email addresses as of this writing:

       eowmob@exp-math.uni-essen.de mat42b@spi.power.uni-essen.de

       Michael Weller disclaims all warranties with regard to  this  software,
       including  all implied warranties of merchantability and fitness, in no
       event shall Michael Weller be  liable  for  any  special,  indirect  or
       consequential  damages or any damages whatsoever resulting from loss of
       use, data or profits, whether in an action of contract,  negligence  or
       other  tortious action, arising out of or in connection with the use or
       performance of this software.

3. THE MACH32INFO UTILITY

       The mach32info(6) utility or demo reads out all configuration registers
       and the configuration EEPROM of your Mach32 card. If there is a problem
       with the particular card you have, compile and run the utility  in  the
       mach32/  directory  of the svgalib distribution and send it’s stdout to
       me This might also be useful if you need a lot of options (e.g.  clocks
       on  new  models?)  to  get  it  to  work  so  that  this  can  be  done
       automatically in future versions.

4. THIRD PARTY CARDS

       I got a few reports about AST systems with  onboard  Mach32.   They  do
       feature  an  incompatible  EEPROM setup, but I think I got around that.
       Nevertheless the Mach32 chipset driver doesn’t work out of the  box  on
       any AST system I heard of.

       Since  original  ATI Mach32 demos and tools don’t work as well, I’ve to
       claim that the Mach32 on these AST systems does not  conform  to  ATI’s
       Mach32  docs.   Fortunately,  Vernon C. Hoxie <vern@zebra.alphacdc.com>
       found a work around after years (really!) of investigating. AST  Mach32
       seems to work now. The work around was also submitted to Xfree and will
       be incorporated to allow running it on the AST hardware too  in  recent
       versions. Please read on the misc_ctl command below.

       Dell  users  should  have  a look at the vendor, ramdac, and svgaclocks
       commands below (if they have problems with the default settings).

   Commands to support third party cards
       I had to learn that those cards seem  to  use  not  only  non  standard
       clocks  for  the Mach32, but also for the included SVGA. However, since
       people often like to use proprietary, non  standard  VGA  (read  80x25)
       text  modes,  the  Mach32  driver has to set the included SVGA to a VGA
       compatible clock frequency. Otherwise svgalib has problems using  plain
       VGA  modes.  This  screws  VGA  modes up if these clocks have different
       values on third party Mach32 cards.

       svgaclocks n
              with n a number between 0 and 31 to select the svga clocks to be
              used  in vga modes. The bits of n refer to specific ATI register
              bits to complicated to explain here. Even if I  would,  I  can’t
              tell  which  clocks  they  would select on your third party card
              (which is the actual problem)

              svgaclocks 9 is the default setting and correct for original ATI
              cards.

              Often svgaclocks 0 (Dell cards) works.

       svgaclocks keep
              is  special  in that the driver will not touch any SVGA timings.
              This requires the Mach32 SVGA part to be  in  a  VGA  compatible
              mode  when the svgalib application is started, that is, you must
              use 80x25 (maybe 80x50) console text modes.

       As I  mentioned  already,  Vernon  C.  Hoxie  <vern@zebra.alphacdc.com>
       really  seems  to  have located the reason for the Mach32 AST problems.
       Any access to MISC_CTL locks up the card & system. Fortunately MISC_CTL
       is  only  used  for  some DAC fine tuning (actually the setting you can
       fine tune with the blank command) which is only  of  barely  noticeable
       effect to the screen.

       The following configuration commands exist to support AST cards:

       misc_ctl keep-off
              Do not dare to touch MISC_CTL.

       misc_ctl use
              Use it for fine tuning of the Ramdac setup (default).

       Finally, for your convenience there exist:

       vendor ati
       vendor dell
       vendor ast
              These are macros that expand to settings for svgaclocks, ramdac,
              misc_ctl, and mach32eeprom that are  usually  correct  for  ATI,
              Dell,  AST  cards.  Be  aware that they really work like macros.
              That is,  they  override  any  setting  of  svgaclocks,  ramdac,
              misc_ctl,  and  mach32eeprom  made  before  them  and individual
              aspects will be  changed  by  a  following  svgaclocks,  ramdac,
              misc_ctl, and mach32eeprom command.

              Note  that  the mach32eeprom ignore required for some Dell cards
              requires you to include explicit timings for Mach32 modes  other
              than  640x480x256.   The  mach32/mach32.std-modes  file  in  the
              svgalib distribution contains  recommendations  for  modes  from
              ATI.

              I  heard about a bug in some ATI chipsets returning wrong memory
              amounts configs. (But cannot confirm that)

              You  can  enforce  correct  chipset  identification   from   the
              configuration file:

       chipset Mach32 chiptype memory
              where  chiptype  is the sum of at exactly one value from each of
              the following two groups

              128    use no memory aperture.
              160    use a 1MB memory aperture.
              192    use a 4MB memory aperture.
              0      choose size for the memory aperture automatically.

              and

              16     Ramdac is of type 0 (ATI68830)
              17     Ramdac is of type 1 (IMS-G173, SC11486)
              18     Ramdac is of type 2 (ATI68875, TLC34075)
              19     Ramdac is of type 3 (INMOS176, INMOS178)
              20     Ramdac is of type 4 (Bt481, Bt482)
              21     Ramdac is of type 5 (ATI68860)
              0      Ramdac type is queried from Mach32 chip.

              memory is the amount of video memory in KB.

       Note that the type of the ramdac can be set more conveniently with  the
       ramdac command.

5. LOGICAL LINEWIDTH

       At  least  my  VRAM  card  seems to be very peculiar about logical line
       widths. From my experience a multiple  of  64  pels  is  needed.   Your
       mileage  may vary. Use the config file options to adjust it and tell me
       if your card needs a different value. Include the name and model number
       of  the  card and what the correct numbers should be. This is so that I
       can correct the auto configuration of the driver.

       If some svgalib application has problems, note that you can  force  the
       logical  line width to the default value from the config file. Probably
       this will lead to glitches in some 800x600 resolutions. You can inhibit
       these  resolutions  from  the  config file as well. Apropos glitches, I
       found no guidelines as to  what  clock  rates  to  use  due  to  memory
       restrictions.  I  adjusted  the driver, such that I get a stable pic in
       all resolutions. However sometimes the screen  is  disturbed  by  heavy
       video  memory  accesses. If you don’t like that, reduce the clocks used
       with the maxclock16 or maxclock24 command, resp.  This  may  of  course
       lead  to  none of the predefined modes being used.  Then you can try to
       define your own mode via the define command.

6. NOISY VIDEO SIGNALS

       If you get some flicker or heavy noise on your screen, some fine tuning
       may  be  needed.  My docs didn’t give me hints as to what each card can
       stand.  Especially DRAM cards may give problems (I’ve  VRAM).  In  that
       case,  use  the  fine  tuning  config commands and send me your results
       along with the output of mach32info(6).  Then I can include them in  my
       next release.

   Fine-tuning configuration commands
       First  you  should  think about the maxclock* configuration commands to
       reduce pixel clocks used for each color depth.

       Especially important for DRAM cards is the video  FIFO  depth  used  to
       queue memory values for writing to the screen. Here is a command to set
       this value for the 8bpp modes:

       vfifo8 number
              where number is in range 0 - 15.  The default is now 6.

              Since vfifo is of some impact to the speed of the card, tell  me
              the lowest setting that satisfies your card.

              For  16/24/32  modes,  there  are  non-zero  values  preset from
              internal tables and the EEPROM, however you can enforce  minimal
              vfifo values with:

       vfifo16 number
       vfifo24 number
       vfifo32 number

       blank number
              where number is 4 * pixel_delay + blank_adjust where pixel_delay
              and blank_adjust are in range 0 .. 3.  pixel_delay delays pixels
              before  they  are  sent  to the DAC and blank_adjust adjusts the
              blank pulse for type 2 DAC’s.  blank should be set correctly for
              each DAC type automatically.  So use it only as a last resort.

       latch number
              where  number  is  the  sum  of  zero  or  more of the following
              numbers:

              128    VRAM serial delay latch enable, DRAM latch bits  63  -  0
                     enable.

              4096   Latch video memory data.

              8192   Memory data delay latch enable for data bits 63 - 0.

              16384  Memory full clock pulse enable.

              Default  is to switch all settings on (they are on on my card by
              default anyway).

       Note that these commands may vanish  again  once  they  are  no  longer
       needed for debugging purposes.

       There  is no 320x200 mode in the EEPROM of the Mach32 at all, however I
       defined one in the default configuration file for you. This is the best
       thing I could get up on my card/screen. Note that it will probably have
       big borders on your screen, and black lines in between the pixel lines.
       This is because of the lack of low clocks < 16MHz on the Mach32 and the
       lack of a line doubling mode as VGA has. The Mach32 is not intended for
       such low resolutions. If you find a better mode or have an idea, please
       let me know. You can also just  remove  my  timings  from  the  default
       configuration file.

7. THE CONFIGURATION EEPROM

       Ah  yes,  about  the  EEPROM,  I figured out how to read out the Mach32
       EEPROM. I did it by disassembling the BIOS  routine  mentioned  in  the
       docs.  I  then  redid  it in C. The driver will use everything it finds
       there.

       Use the Mach32 install tools (they should  have  reached  you  together
       with  your Mach32 VGA card) to setup your card/monitor combo correctly.
       The monitors setting from the config  file  (or  default  of  35kHz  or
       something) will be obeyed by the driver nevertheless (for safety!).

       As  you  probably know already, accessing the EEPROM causes some screen
       flickering. If this annoys you (or even worse your monitor) have a look
       at the mach32eeprom command described below. This allows you to put the
       data from the EEPROM into a file and which can be read whenever  it  is
       required.

       Don’t  even think about changing the contents of the file. (There is an
       easily faked checksum in it.). Anyway the  driver  ensures  (hopefully)
       that no damage can be caused.

       Also, if some mode is not well aligned on your screen or you don’t like
       it’s sync frequency, consider using the Mach32 install  utility  (setup
       for  custom monitor) and set one up interactively. If there is no valid
       faster (higher VSYNC) standard mode given in the EEPROM the driver will
       use that mode. You will find that this is fun compared with calculating
       video timings for /etc/XF86Config or /etc/vga/libvga.config.

       However the install utility does restrict the maximum pixel  depth  for
       custom modes sometimes unneeded hard and the driver obeys that.  (Hmm..
       actually it should be smart enough to decide itself which  pixel  depth
       it  can  use  in that mode.)  Since the standard modes are usually only
       slightly shifted to one side a file  with  the  configuration  commands
       representing  the standard modes is given in mach32/mach32.std-modes in
       the svgalib distribution. You can use these as a starting point.

       But here are some real problems:

8. EEPROM WOES

       I got 2  reports  of  people  having  problems  with  incorrect  EEPROM
       checksums.  Both had motherboards with onboard Mach32 VGA’s from AST. I
       guessed a checksum algorithm from those reports and  put  this  in  the
       code  in  addition  to  the standard ATI style. Still I got a report of
       someone whose EEPROM was completely empty. If you  have  problems  with
       checksums  send  me the output of mach32info(6) and I’ll see what I can
       do.

       By default  svgalib  writes  a  complaining  message  and  ignores  the
       contents.   You  can have svgalib ignore the checksum and contents with
       the configuration command

       mach32eeprom ignore

       Then you can decide to use the partial info that is still in it. Use

       mach32eeprom ignore usetimings

       to use the video modes that are defined in the  EEPROM  (if  no  better
       modes  are  known  by  the  driver).  This is usually safe, because the
       driver knows which modes are safe for your hardware (if clocks, monitor
       and  ramdac are configured correctly). You can also allow the driver to
       use the configuration for the linear frame buffer in the EEPROM:

       mach32eeprom ignore useaperture

       or

       mach32eeprom ignore usetimings useaperture

       However I discourage this because the driver will just enable what  the
       EEPROM  says about the aperture. Use mach32info(6) to check the address
       it will choose is safe. It might be better to use setuplinear to set up
       a 4MB aperture at a free address range.

9. THE MACH32EEPROM COMMAND

       The  mach32eeprom  allows  to  work  around these problems. Here is the
       complete description for this configuration command.

       mach32eeprom filename
              The filename has to begin with a "/".

              Unfortunately  reading  the  EEPROM   causes   annoying   screen
              flickering  and is slow.  To avoid this, specify a filename from
              which to read the contents of the EEPROM.

              If the file cannot be read, the EEPROM is read out and the  file
              is  created. There is a very simple checksum put into this file.
              Although it can easily be fooled, don’t change the  file  except
              you know very, very well what you are doing.

              Also, as long as the file exists, changes in the Mach32’s EEPROM
              are ignored. Delete the file to recreate an updated  version  on
              next  use  of svgalib. You should ensure that the permissions of
              the file don’t allow normal users to change it. (This may happen
              if umask has a bad value when svgalib creates the file).

              Example:

              mach32eeprom /etc/vga/mach32.eeprom

       Due to problems with some boards this command got heavily expanded:

       mach32eeprom subcommand1 [subcommand2...]
              At least one subcommand is needed. Valid subcommands are:

              ignore Don’t  complain  about  checksum and don’t use any EEPROM
                     contents.

              useaperture
                     Use the configuration for the memory  aperture  given  in
                     the EEPROM.

              usetimings
                     Use video modes found in the EEPROM of the board.

              nofile Forget   about   any  filename  that  maybe  was  already
                     configured.  Don’t read a file, don’t create one.

              file filename
                     New style form to specify the filename;  On  contrary  to
                     the  mach32eeprom  filename form it can be mixed with any
                     other mach32eeprom subcommand.

              updatefile
                     Don’t read the file, always read the EEPROM (except  when
                     ignore  is  given)  and  create  an uptodate image of the
                     EEPROM.

              keepfile
                     Disable all previous updatefile commands.

              compatible
                     Fall back to default behavior: If checksum on the  EEPROM
                     data is not ok, use nothing of the configuration data. If
                     it is  ok,  configure  everything  as  specified  in  the
                     EEPROM.

              The  subcommands  are  intended  to  be  used  together  and are
              performed in the order specified. For example:

              mach32eeprom ignore useaperture usetimings

              will ignore the checksum of your EEPROM, but use  its  contents.
              Order is vital! So:

              mach32eeprom useaperture usetimings ignore

              won’t  use  any  configuration from your EEPROM. Be careful with
              the useaperture subcommand. Please see the EEPROM WOES  section.
              Note  that  any  non  understood  subcommand  will terminate the
              mach32eeprom command  silently!  Use  only  one  subcommand  per
              mach32eeprom command to avoid this.

              The   mach32eeprom   command  is  usually  not  allowed  in  the
              environment variable SVGALIB_CONFIG.

10. SETUP OF THE MEMORY APERTURE (LINEAR FRAMEBUFFER)

       Due to poor design, Xfree86 insists on setting up the aperture  itself.
       It doesn’t reset the original settings at a VC switch once it runs. You
       should not start X for the first time  after  a  boot  as  long  as  an
       svgalib  application is running. This will result in pre X values being
       restored at a VC switch by svgalib. If you use svgalib and  XF86_Mach32
       together,  run  X  first  or at least do not start it while any svgalib
       appl. is still running. After X was started once you  can  use  svgalib
       and X in all combinations w/o any problems. Xfree uses whatever address
       is given in the MEM_CFG Mach32 register for a 4MB aperture, even if the
       aperture  is  not  already  enabled  and  the value in this register is
       pointless garbage. This is IMHO a dangerous bug  as  some  systems  may
       work only with a 1MB aperture.

       However,  usage  of  a correct EEPROM circumvents any such problems. If
       you cannot use that, use mach32info (6) to find the address in MEM_CFG.
       Then,  if  it  is  a  sensible  setting  for  your system, enable a 4MB
       aperture at that address with setuplinear.  Ensure that no  other  card
       or memory uses the address range you choose.

11. ACCELERATOR SUPPORT AND OTHER WEIRD FEATURES

       This  version now has support for all accelerator functions of svgalib.
       However they were intended for use with the cirrus chips. It may happen
       that  at  runtime  they  find they cannot emulate the function actually
       requested. Then you should disable the corresponding blit function  (at
       least for that application) with the blit config command.

       Data transfer between the host and the Mach32 is normally via I/O. This
       proved to be pretty slow. If a big  enough  aperture  is  available,  a
       simple  memory  copy  is used instead. This is usually much faster. You
       can change which method is used with the blit command. This I/O  option
       affects only vga_imageblt(3).  The other functions are incredible fast.

       For type 2 DACS, there is support for 8 bit per color (instead  of  the
       normal  6) in the RGB triple in the color lookup table of the 256 color
       modes. This can be enabled by an application, if it  supports  it.  The
       testaccel(6)  demo  uses it if supported by your hardware.  You can use
       vga_ext_set(3) to use it from your programs.

12. RAMDACS

       Mach32 Ramdacs are specified by a type in range 1 .. 5. This  type  can
       be queried from the Mach32 and then specifies how to set up the ramdac.
       A list of actual hardware chips used for each type exists, but  is  not
       of  much  use.  The  Mach32  will  return a type and the ramdac will be
       completely hardware compatible to one of the given type.

       Type 1 and 4 Dacs need different clock frequencies for high colormodes.
       For  32K/64K  colormodes the frequencies have to be doubled and for 16M
       colors (type 4 only) they have to be tripled. I followed the ATI scheme
       and  did  this  internally. However this means that for 32K/64K you can
       use only clocks for which the doubled frequencies can be  generated  as
       well.

       This  is  no  hard  restriction  as  the 16 clocks of the Mach32 can be
       divided by 2.  Thus if you setup some mode yourself try to use  one  of
       the  divided  clocks in your timings and I can use the undivided clocks
       internally.

       It is a real restriction for 16M colors. ATI itself only supports 25MHz
       (640x480)  here  by  use of a 75MHz clock. Depending on your clock chip
       other values may be usable as well.  Even  the  doubled/tripled  clocks
       have to be less than the magic 80 MHz. However the driver does all this
       itself. It may just happen that some of the predefined or one  of  your
       handmade  mode-timings  can’t  be  used  because the clock that is used
       cannot be doubled/tripled.  Even though there is already some tolerance
       in  the  driver  you may fix that by slightly changing the clock values
       that you set with the clocks command. But note that this will  as  well
       affect the ability of the driver to calculate video timings and thus it
       ability to check the monitor and DAC safety restrictions.

       In addition (in complete contrast to my original  ATI  docs)  RAMDAC  4
       does not support RGB with blue byte first but only with red first. This
       required special handling and me adding a bunch  of  functions  to  all
       modules  of  svgalib  and  vgagl.  The  added  functions  are  of lower
       performance than the usual functions.  However  most  data  has  to  be
       completely  mangled, so I doubt that it can be done much faster. Sorry.

       Of course, I might have forgotten to port some parts or  even  confused
       things.  About  bugs  in the gl and drawing libs, please ask Harm.  But
       then, I’m able to emulate a BGR ramdac on my card, so I should even  be
       able to reproduce your problems.

       Recently  I  hear  often  about type 6 ramdacs in non ATI Mach32 cards.
       There exists no info about these dacs, thus I cannot support them.  The
       driver  assumes  unknown  DACs  can stand up to 80MHz in 256 color clut
       modes and does not touch the ramdac (that is, assumes it is in the  256
       color mode already)

       To get rid of the warning message you can use the

       ramdac n
              configuration  command.  It allows to explicitly set the type of
              the dac to n (in range 0 to 5).  Ramdac 3 is  the  most  dumbest
              ramdac  possible,  s.t. you can use it without any fear for your
              hardware.

       ramdac dumb
              is equivalent to ramdac 3.

       ramdac auto
              switches back to the default autodetection.

13. MEANING OF THE DETECTION MESSAGE FROM SVGALIB

       Some programs (which do not switch it off) will show a

       Using Mach32 version (sizeM at adrM (how), memK mem, DAC dactype)

       line. This will show up in testlinear(6) etc but will  probably  scroll
       away when you use vgatest(6).  In this line:

       version
              is the version of the driver (as of my counting, not the svgalib
              version).

       size   is the size of the memory aperture. It can be 1  or  4  (1  will
              lead to not using the linear aperture if your card has more than
              1MB memory, however applications can still use the 1MB  aperture
              and  page  the  video memory through it in 1MB steps).  size can
              also be no if no aperture is setup at all.

       adr    is the base address of the aperture in MB.

       how    is autodetect if the aperture was setup this  way  already  when
              the  program  started.  It  is  setup  when  the the setting was
              enforced with a setuplinear configuration command. It is  EEPROM
              when  no aperture was detected, but parameters to set it up were
              found in the EEPROM.

       mem    is the amount of memory the card reported to have.

       dactype
              is the type of the DAC that was detected.

              If a special ramdac type was set with the ramdac command a (set)
              will be displayed after dactype.

       If  mem, dactype and/or the chipset were enforced with chipset from the
       configuration file or vga_setchipsetandfeatures(3)  a  forced  will  be
       appended to the line.

14. CONCLUSIONS

       A  final  word: I have an ATI ULTRA PRO/2MB/EISA with a Type 2 DAC.  My
       monitor is an EIZO F550i-M. Everything I  tried  works  on  it  like  a
       charm.  However,  I couldn’t try it with other machines myself and esp.
       other DAC’s. Fortunately the Type 2 DAC is the worst to code. So I will
       probably have gotten the other DAC’s right. But please be warned!

       I  did  my  very  best to code the driver to support the other DAC’s by
       just reading the docs.  But i cant give any definitive  guarantee  for
       it to work or even not damaging your hardware. So please be careful!

       Note  that you will have to set the environment variable SVGALIB_MACH32
       to ILLTRYIT if your DAC is not type 0, 2, 3 or 4. This will  of  course
       change  if  no  one with a DAC equal to 1 or 5 has serious problems. If
       you have a different DAC, making patches to support your card  will  be
       much more helpful instead of just complaining.  If you have a different
       DAC that works well tell me as well such that I can remove the need for
       SVGALIB_MACH32 in the next release. Still, even now, after years, I got
       no reports of a Mach32 card with a type 1 or 5 ramdac. Go figure.

       Thank you for your audience and wishes you will enjoy this driver,
       Michael.

FILES

       /etc/vga/libvga.config
       /etc/vga/mach32.eeprom

SEE ALSO

       svgalib(7), libvga.config(5), mach32info(6).

AUTHOR

       The Mach32 driver and this documentation was written by Michael  Weller
       <eowmob@exp-math.uni-essen.de>.