A few comments about the Mach32 driver. [HH: If is there is a problem with the particular card you have, compile and run the utility in the Mach32/ directory that reports all information stored in the EEPROM of the card. Send the output to Michael. This is also 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.] 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. The driver can do this for you too. After that you can restart whatever svgalib program you used and you are set. If you put already 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 README.config Some statements are copied from Xfree86. The clock detection code is almost just copied. So I repeat here the copyright statements for these parts: Copyright 1992 by Orest Zborowski Copyright 1993 by David Wexelblat Permission to use, copy, modify, distribute, and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the names of Orest Zborowski and David Wexelblat not be used in advertising or publicity pertaining to distribution of the software without 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 DISCLAIMS 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@vm.hrz.uni-essen.de eowmob@pollux.exp-math.uni-essen.de mat42b@de0hrz1a.bitnet MICHAEL WELLER DISCLAIMS 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. This is an intermediate pre-ALPHA release of the Mach32-driver. Pre means that I did not implement the accelerated functions for Mach32 yet. I'm doing that while you are reading this message. However I don't think I'll need long for this.. compared to the rest of the driver I think they are fairly trivial. Anyway 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 of course supported.. (by using of the standard VGA driver routines). If you configured your Mach32 for an memory aperture and it is at least as big as the memory of your card (that is, not an 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 I got code from the X people, and it should be OK regarding to my docs. Well, I fixed that (hopefully). Actually the bug was found by Daniel Lee Jackson (djackson@ichips.intel.com). (Thanks again.. oh my good it was that silly... I would have never found it) If you still have problems just put a chipset Mach32 in your config file. Note that at least my VRAM card seems to be 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. (and what for a card it exactly is, s.t. I may autoconfig the driver correctly). 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 what clockrates to use due to memory restrictions. I adjusted the driver, s.t. 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 used clocks with the maxclk16 or maxclk24 command, resp. This may of course lead to none of the predefined modes being used. Then you can try/have to define your own mode via the define command. If you get some flicker/heavy noise on your screen some fine tuning may be needed. My docs didn't give me hints what each card can stand. Esp. DRAM cards may give problems (I've VRAM). In that case use the fine tuning config commands and send me your results and output of Mach32info that I'm able to make my next release auto detect such configurations. Fine-tuning commands: First you should think about the maxclock commands to reduce pixel clocks used for each mode depth. Esp. 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 0-15. The default is 6 now. May happen that I set it back to 0 if a VRAM card is detected as it was default once. 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 out of 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 0..3. Pixel-delay delays pixel b4 they are sent to the DAC and blank_adjust adjust the blank pulse for type 2 DAC's. blank should be set correctly for each DAC type automatically. So use it only as last resort. latch number where number is the sum of one or more of: 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 setting on. (they are on my card 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 config 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 lines. This is because of the lack of low clocks <16 on the Mach32 and the lack of a line doubling mode as a 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. Ah yes, and apropos EEPROM, I figured out how to read out the Mach32 EEPROM. (Not from the docs but from disassembling the BIOS routine the docs mention and re doing it (much better and compacter of course) in C). The driver will use everything it finds there. Use the Mach32 install tools to setup your card monitor combo correctly. The monitor setting from the config file (or default of 35kHz or something) will be obeyed by the driver anyway (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. This allows you to give a filename where the EEPROM contents are once saved and then just read out. Since this is also true for clock probing (in fact at a much higher impact) probed clocks are also saved in the EEPROM file. Don't even think about changing the contents of the file. (There is an easy 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 Xconfig / svgalib.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 usually the standard modes are only slightly shifted to the site a file with the config commands representing the standard modes is given in mach32 mach32.std-modes. I heard about a bug in some ATI chipsets returning wrong memory configs. Note that you can enforce correct identification from the config file. Have a look at mach32.h for correct values. Some programs (that set the correct flag) will show a Using Mach32 (#1M at #2M (#3), #4K mem, DAC #5) line (vgatest, testlinear.. etc.. (will probably scroll away when you use vgatest). In this line #1 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) #1 can also be no if no aperture is setup at all. #2 is the base address of the aperture in MB. #3 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 config command. It is "EEPROM" when no aperture was detected but parameters to set it up were found in the EEPROM. #4 is the amount of memory the card reported to have. #5 is the type of the DAC (0-5 are known yet) that was detected. If #4, #5 and/or the chipset were enforced with "chipset" from the config-file or the appropriate application function call a "forced" will be appended to the line. A final word: I have an ATI ULTRA PRO/2MB/EISA with a Type 2 DAC. My monitor is an EIZO F550i-M. Everything I tried worked 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 DEFINITELY GIVE ANY 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 or 2. (Will of course change if no one with DAC!=0 2 has serious problems). Since I have Dac type 2, if you have a different DAC, Patches to make it work instead of just complaining are probably much more helpful to support your card. Thank you for your audience and wishes you will enjoy this driver, Michael Weller eowmob@exp-math.uni-essen.de