Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


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

       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

       Auto detection of the Mach32 seems not to work on all cards. That's re-
       ally  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.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 ex-
       act. 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 sv-
       galib 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, 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.  Or-
       est  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 ac-
       tion 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 (
       Modified	for the	Mach-8 by Rickard E. Faith (
       Rewritten for the Mach32	by Kevin E. Martin (

       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:

       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.

       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.

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

	      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 <> re-
       ally 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  as-
	      pects  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  sv-
	      galib 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.


	      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.

       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  re-
       strictions.  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.

       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-

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

	      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.

       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

       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:

       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

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


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


	      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

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

		     Use video modes 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
		     New  style	 form  to specify the filename;	On contrary to
		     the mach32eeprom filename form it can be mixed  with  any
		     other mach32eeprom	subcommand.

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

		     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, configure everything as specified in the EEP-

	      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.

       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 sv-
       galib 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	 aper-
       ture  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 re-
       quested.	 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 af-
       fects 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 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

       This  is	 no hard restriction as	the 16 clocks of the Mach32 can	be di-
       vided 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 in-

       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 can-
       not 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 abil-
       ity 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

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

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

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

       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  en-
	      forced  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.

	      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 ap-
       pended 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 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,


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

       The  Mach32 driver and this documentation was written by	Michael	Weller

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


Want to link to this manual page? Use this URL:

home | help