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.
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.
Copyright 1992 by Orest Zborowski <obz@Kodak.com>
Copyright 1993 by David Wexelblat <dwex@goblin.org>
Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Orest Zborowski and David Wexelblat not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Orest Zborowski and David Wexelblat make no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
Orest Zborowski and David Wexelblat disclaim all warranties with regard to this software, including all implied warranties of merchantability and fitness, in no event shall Orest Zborowski or David Wexelblat be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software.
Copyright 1990,91 by Thomas Roell, Dinkelscherben, Germany.
Copyright 1993 by Kevin E. Martin, Chapel Hill, North Carolina.
Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of Thomas Roell not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. Thomas Roell makes no representations about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty.
Thomas Roell, Kevin E. Martin, and Rickard E. Faith disclaim all warranties with regard to this software, including all implied warranties of merchantability and fitness, in no event shall the authors be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software.
Author: Thomas Roell, roell@informatik.tu-muenchen.de
Rewritten for the 8514/A by Kevin E. Martin (martin@cs.unc.edu)
Modified for the Mach-8 by Rickard E. Faith (faith@cs.unc.edu)
Rewritten for the Mach32 by Kevin E. Martin (martin@cs.unc.edu)
And here is my own copyright:
This driver is free software; you can redistribute it and/or modify it without any restrictions. This library is distributed in the hope that it will be useful, but without any warranty.
Copyright 1994 by Michael Weller
Email addresses as of this writing:
eowmob@exp-math.uni-essen.de mat42b@spi.power.uni-essen.de
Michael Weller disclaims all warranties with regard to this software, including all implied warranties of merchantability and fitness, in no event shall Michael Weller be liable for any special, indirect or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with the use or performance of this software.
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).
svgaclocks 9 is the default setting and correct for original ATI cards.
Often svgaclocks 0 (Dell cards) works.
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:
Finally, for your convenience there exist:
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:
and
Note that the type of the ramdac can be set more conveniently with the ramdac command.
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.
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:
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
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.
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:
By default svgalib writes a complaining message and ignores the contents. You can have svgalib ignore the checksum and contents with the configuration command
mach32eeprom ignore
Then you can decide to use the partial info that is still in it. Use
mach32eeprom ignore usetimings
to use the video modes that are defined in the EEPROM (if no better modes are known by the driver). This is usually safe, because the driver knows which modes are safe for your hardware (if clocks, monitor and ramdac are configured correctly). You can also allow the driver to use the configuration for the linear frame buffer in the EEPROM:
mach32eeprom ignore useaperture
or
mach32eeprom ignore usetimings useaperture
However I discourage this because the driver will just enable what the EEPROM says about the aperture. Use mach32info(6) to check the address it will choose is safe. It might be better to use setuplinear to set up a 4MB aperture at a free address range.
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 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.
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.
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.
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
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:
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.
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.