svgalib.mach32(7)      Svgalib User Manual      svgalib.mach32(7)

       svgalib.mach32 - Information on the Mach32 chipset driver

        0. Introduction
        1. Specifying pixel clocks
        2. Copyrights
        3. The mach32info utility
        4. Third party cards
        5. Logical linewidth
        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

       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 lin-
       ear 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 (  (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.

       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.con-
       fig(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  lib-

       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(5) for a
       list of the clocks used by common svgalib cards.

       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 <>
       Copyright 1993 by David Wexelblat <>

       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 spe-
       cific, 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 war-
       ranties  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, Ger-
       Copyright 1993 by Kevin E. Martin, Chapel Hill, North Car-

       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 distribu-
       tion of the software without specific, written prior  per-
       mission.  Thomas  Roell makes no representations about the
       suitability of this software for any purpose. It  is  pro-
       vided "as is" without express or implied warranty.

       Thomas  Roell,  Kevin E. Martin, and Rickard E. Faith dis-
       claim all warranties with regard to this software, includ-
       ing 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 whatso-
       ever 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,

       Rewritten   for  the  8514/A  by  Kevin  E.  Martin  (mar-
       Modified   for   the   Mach-8   by   Rickard   E.    Faith
       Rewritten   for  the  Mach32  by  Kevin  E.  Martin  (mar-

       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  with-
       out any warranty.

       Copyright 1994 by Michael Weller

       Email addresses as of this writing:

       Michael Weller disclaims all  warranties  with  regard  to
       this  software,  including  all implied warranties of mer-
       chantability and fitness, in no event shall Michael Weller
       be  liable for any special, indirect or consequential dam-
       ages or any damages whatsoever resulting from loss of use,
       data  or profits, whether in an action of contract, negli-
       gence or other tortious action, arising out of or in  con-
       nection with the use or performance of this software.

       The mach32info(6) utility or demo reads out all configura-
       tion 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.

       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,  Ver-
       non C. Hoxie <> 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) textmodes, 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  dif-
       ferent 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 appli-
              cation is started, that  is,  you  must  use  80x25
              (maybe 80x50) console textmodes.

       As     I    mentioned    already,    Vernon    C.    Hoxie
       <> 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 noticable effect to the screen.

       The  following configuration commands exist to support AST

       misc_ctl keep-off
              Do not dare to touch MISC_CTL.

       misc_ctl use
              Use  it  for  fine  tuning  of  the  Ramdac   setup

       Finally, for your convenience there exist:

       vendor ati
       vendor dell
       vendor ast
              These  are macros that expand to settings for svga-
              clocks, 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 com-

              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 distri-
              bution contains recommendations for modes from ATI.

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

              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 automat-


              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 videomemory in KB.

       Note  that  the  type of the ramdac can be set more conve-
       niently with the ramdac command.

       At least my VRAM card seems to be very peculiar about log-
       ical  linewidths. 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 dif-
       ferent 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 linewidth to the default value from
       the configfile. Probably this will  lead  to  glitches  in
       some  800x600  resolutions.  You can inhibit these resolu-
       tions from the configfile as  well.  Apropos  glitches,  I
       found  no  guidelines  as to what clockrates 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 max-
       clock16 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.

       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

       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  pre-
              set  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  cor-
              rectly  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 fol-
              lowing 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.

       Ah  yes,  about  the EEPROM, I figured out how to read out
       the Mach32 EEPROM. I did it by disassembling the BIOS rou-
       tine  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

       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

       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:

       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 videomodes 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 config-
       ured correctly). You can also allow the driver to use  the
       configuration for the linear frame buffer in the EEPROM:

       mach32eeprom ignore useaperture


       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.

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

       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 cre-
              ates the file).


              mach32eeprom /etc/vga/mach32.eeprom

       Due to problems with some boards this command got  heavily

       mach32eeprom subcommand1 [subcommand2...]
              At  least  one  subcommand is needed. Valid subcom-
              mands are:

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

                     Use the configuration for the memoryaperture
                     given in the EEPROM.

                     Use videomodes found in the  EEPROM  of  the

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

              file filename
                     Newstyle  form  to  specify the filename; On
                     contrary to the mach32eeprom  filename  form
                     it  can be mixed with any other mach32eeprom

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

                     Disable all previous updatefile commands.

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

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

              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  under-
              stood  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.

       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 senseable
       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.

       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.

       Mach32 Ramdacs are specified by a type in range  1  ..  5.
       This  type  can be queried from the Mach32 and then speci-
       fies 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  com-
       pletely 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 themself 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 slighty 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  restric-

       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  com-
       pletely  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 repro-
       duce 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.

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

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

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

              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  appli-
              cations 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  aper-
              ture was detected, but parameters to set it up were
              found in the EEPROM.

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

              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_setchipsetand-
       features(3) a forced will be appended to the line.

       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  can't  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 dif-
       ferent 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


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

       The Mach32 driver and this documentation  was  written  by
       Michael Weller <>.

Svgalib (>= 1.2.11)       1 August 1997                         1