svgalib.mach32 man page on Peanut

Man page or keyword search:  
man Server   7435 pages
apropos Keyword Search (all sections)
Output format
Peanut logo
[printable version]

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

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

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 what‐
       ever 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, pro‐
       vided that the above copyright notice appear in	all  copies  and  that
       both  that  copyright  notice and this permission notice appear in sup‐
       porting documentation, and that the names of Orest Zborowski and	 David
       Wexelblat not be used in advertising or publicity pertaining to distri‐
       bution 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  dam‐
       ages 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,  pro‐
       vided  that  the	 above	copyright notice appear in all copies and that
       both that copyright notice and this permission notice  appear  in  sup‐
       porting 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 rep‐
       resentations 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 war‐
       ranties 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 what‐
       soever  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 con‐
       sequential 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  automati‐
       cally 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)
       textmodes, the Mach32 driver has to set the included SVGA to a VGA com‐
       patible 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 textmodes.

       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 noticable
       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 configu‐
	      ration 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 videomemory 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
       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 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 linewidth to the default value from  the	 configfile.  Probably
       this will lead to glitches in some 800x600 resolutions. You can inhibit
       these resolutions from the configfile  as  well.	 Apropos  glitches,  I
       found no guidelines as to what clockrates to use due to memory restric‐
       tions. I adjusted the driver, such that I get a stable pic in all reso‐
       lutions.	 However sometimes the screen is disturbed by heavy video mem‐
       ory 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 inter‐
	      nal 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  num‐
	      bers:

	      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 con‐
       figuration file.

7. THE CONFIGURATION EEPROM
       Ah yes, about the EEPROM, I figured out how to read out the Mach32 EEP‐
       ROM.  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 some‐
       thing) 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	check‐
       sums.   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  con‐
       tents.	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 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 com‐
       plete description for this configuration command.

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

	      Unfortunately reading the EEPROM causes annoying screen flicker‐
	      ing  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 memoryaperture given in the
		     EEPROM.

	      usetimings
		     Use videomodes found in the EEPROM of the board.

	      nofile Forget  about any filename that maybe was already config‐
		     ured.  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 subcommand.

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

	      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  EEP‐
		     ROM.

	      The  subcommands	are  intended to be used together and are per‐
	      formed 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 environ‐
	      ment 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 senseable setting for your system, enable a 4MB aper‐
       ture 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 sim‐
       ple  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  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 tol‐
       erance 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 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  perfor‐
       mance  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 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 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>.

Svgalib (>= 1.2.11)		 1 August 1997		     svgalib.mach32(7)
[top]

List of man pages available for Peanut

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net