Ubuntu Manpage: svgalib.mach32 - Information on the Mach32 chipset driver

NAME

       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

0. INTRODUCTION

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

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

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

1. SPECIFYING PIXEL CLOCKS

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

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

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

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

2. COPYRIGHTS

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

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

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

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

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

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

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

And here is my own copyright:

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

Email addresses as of this writing:

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

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

3. THE MACH32INFO UTILITY

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

4. THIRD PARTY CARDS

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

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

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

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

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

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

Often svgaclocks 0 (Dell cards) works.

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

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

The following configuration commands exist to support AST cards:

misc_ctl keep-off
Do not dare to touch MISC_CTL.

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

Finally, for your convenience there exist:

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

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

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

You can enforce correct chipset identification from the configuration file:

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

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

and

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

memory is the amount of video memory in KB.

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

5. LOGICAL LINEWIDTH

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

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

6. NOISY VIDEO SIGNALS

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

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

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

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

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

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

vfifo16 number
vfifo24 number
vfifo32 number

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

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

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

4096 Latch video memory data.

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

16384 Memory full clock pulse enable.

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

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

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

7. THE CONFIGURATION EEPROM

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

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

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

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

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

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

But here are some real problems:

8. EEPROM WOES

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

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

mach32eeprom ignore

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

mach32eeprom ignore usetimings

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

mach32eeprom ignore useaperture

mach32eeprom ignore usetimings useaperture

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

9. THE MACH32EEPROM COMMAND

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

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

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

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

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

Example:

mach32eeprom /etc/vga/mach32.eeprom

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

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

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

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

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

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

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

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

keepfile
Disable all previous updatefile commands.

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

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

mach32eeprom ignore useaperture usetimings

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

mach32eeprom useaperture usetimings ignore

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

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

10. SETUP OF THE MEMORY APERTURE (LINEAR FRAMEBUFFER)

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

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

11. ACCELERATOR SUPPORT AND OTHER WEIRD FEATURES

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

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

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

12. RAMDACS

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

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

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

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

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

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

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

To get rid of the warning message you can use the

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

ramdac dumb
is equivalent to ramdac 3.

ramdac auto
switches back to the default autodetection.

13. MEANING OF THE DETECTION MESSAGE FROM SVGALIB

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

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

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

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

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

adr is the base address of the aperture in MB.

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

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

dactype
is the type of the DAC that was detected.

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

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

14. CONCLUSIONS

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

       I did my very best to code the driver to support the other DAC's by just reading the docs.  But  i  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

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)