Computer Science
svgalib.mach32(7) Svgalib User Manual svgalib.mach32(7)
NAME
svgalib.mach32 - Information on the Mach32 chipset driver
TABLE OF CONTENTS
0. Introduction
1. Specifying pixel clocks
2. Copyrights
3. The mach32info utility
4. Third party cards
5. Logical linewidth
6. Noisy video signals
7. The configuration EEPROM
8. EEPROM woes
9. The Mach32Eeprom command
10. Setup of the memory aperture (linear framebuffer)
11. Accelerator support and other weird features
12. Ramdacs
13. Meaning of the detection message from svgalib
14. Conclusions
0. INTRODUCTION
The driver should allow you to use any of the graph-modes
your Mach32 card supports. Note that there is no support
for <8bpp modes and that I won't ever implement that
because I don't see any reason for doing so. All standard
VGA-modes are supported, of course (by using the standard
VGA driver routines).
If you configured your Mach32 for a memory aperture and it
is at least as big as the memory of your card (that is,
not a 1MB memory aperture for a 2MB card) support for lin-
ear 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.con-
fig(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 lib-
vga(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(5) for a
list of the clocks used by common svgalib cards.
2. COPYRIGHTS
Some tiny routines are copied from Xfree86. The clock
detection code is almost just copied. So I repeat the
copyright statements for these parts here:
Copyright 1992 by Orest Zborowski <obz@Kodak.com>
Copyright 1993 by David Wexelblat <dwex@goblin.org>
Permission to use, copy, modify, distribute, and sell this
software and its documentation for any purpose is hereby
granted without fee, 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 spe-
cific, 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 war-
ranties 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, Ger-
many.
Copyright 1993 by Kevin E. Martin, Chapel Hill, North Car-
olina.
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 distribu-
tion of the software without specific, written prior per-
mission. Thomas Roell makes no representations about the
suitability of this software for any purpose. It is pro-
vided "as is" without express or implied warranty.
Thomas Roell, Kevin E. Martin, and Rickard E. Faith dis-
claim all warranties with regard to this software, includ-
ing 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 whatso-
ever 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 (mar-
tin@cs.unc.edu)
Modified for the Mach-8 by Rickard E. Faith
(faith@cs.unc.edu)
Rewritten for the Mach32 by Kevin E. Martin (mar-
tin@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 with-
out 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 mer-
chantability and fitness, in no event shall Michael Weller
be liable for any special, indirect or consequential dam-
ages or any damages whatsoever resulting from loss of use,
data or profits, whether in an action of contract, negli-
gence or other tortious action, arising out of or in con-
nection with the use or performance of this software.
3. THE MACH32INFO UTILITY
The mach32info(6) utility or demo reads out all configura-
tion 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, Ver-
non C. Hoxie <vern@zebra.alphacdc.com> found a work around
after years (really!) of investigating. AST Mach32 seems
to work now. The work around was also submitted to Xfree
and will be incorporated to allow running it on the AST
hardware too in recent versions. Please read on the
misc_ctl command below.
Dell users should have a look at the vendor, ramdac, and
svgaclocks commands below (if they have problems with the
default settings).
Commands to support third party cards
I had to learn that those cards seem to use not only non
standard clocks for the Mach32, but also for the included
SVGA. However, since people often like to use proprietary,
non standard VGA (read 80x25) textmodes, the Mach32 driver
has to set the included SVGA to a VGA compatible clock
frequency. Otherwise svgalib has problems using plain VGA
modes. This screws VGA modes up if these clocks have dif-
ferent 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 appli-
cation is started, that is, you must use 80x25
(maybe 80x50) console textmodes.
As I mentioned already, Vernon C. Hoxie
<vern@zebra.alphacdc.com> really seems to have located the
reason for the Mach32 AST problems. Any access to MISC_CTL
locks up the card & system. Fortunately MISC_CTL is only
used for some DAC fine tuning (actually the setting you
can fine tune with the blank command) which is only of
barely noticable effect to the screen.
The following configuration commands exist to support AST
cards:
misc_ctl keep-off
Do not dare to touch MISC_CTL.
misc_ctl use
Use it for fine tuning of the Ramdac setup
(default).
Finally, for your convenience there exist:
vendor ati
vendor dell
vendor ast
These are macros that expand to settings for svga-
clocks, 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 com-
mand.
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 distri-
bution 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 automat-
ically.
and
16 Ramdac is of type 0 (ATI68830)
17 Ramdac is of type 1 (IMS-G173, SC11486)
18 Ramdac is of type 2 (ATI68875, TLC34075)
19 Ramdac is of type 3 (INMOS176, INMOS178)
20 Ramdac is of type 4 (Bt481, Bt482)
21 Ramdac is of type 5 (ATI68860)
0 Ramdac type is queried from Mach32 chip.
memory is the amount of videomemory in KB.
Note that the type of the ramdac can be set more conve-
niently with the ramdac command.
5. LOGICAL LINEWIDTH
At least my VRAM card seems to be very peculiar about log-
ical 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 dif-
ferent value. Include the name and model number of the
card and what the correct numbers should be. This is so
that I can correct the auto configuration of the driver.
If some svgalib application has problems, note that you
can force the logical linewidth to the default value from
the configfile. Probably this will lead to glitches in
some 800x600 resolutions. You can inhibit these resolu-
tions from the configfile as well. Apropos glitches, I
found no guidelines as to what clockrates 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 max-
clock16 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 pre-
set 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 cor-
rectly 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 fol-
lowing 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 rou-
tine 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 videomodes that are defined in the EEPROM (if
no better modes are known by the driver). This is usually
safe, because the driver knows which modes are safe for
your hardware (if clocks, monitor and ramdac are config-
ured correctly). You can also allow the driver to use the
configuration for the linear frame buffer in the EEPROM:
mach32eeprom ignore useaperture
or
mach32eeprom ignore usetimings useaperture
However I discourage this because the driver will just
enable what the EEPROM says about the aperture. Use
mach32info(6) to check the address it will choose is safe.
It might be better to use setuplinear to set up a 4MB
aperture at a free address range.
9. THE MACH32EEPROM COMMAND
The mach32eeprom allows to work around these problems.
Here is the 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 cre-
ates 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 subcom-
mands are:
ignore Don't complain about checksum and don't use
any EEPROM contents.
useaperture
Use the configuration for the memoryaperture
given in the EEPROM.
usetimings
Use videomodes found in the EEPROM of the
board.
nofile Forget about any filename that maybe was
already configured. Don't read a file,
don't create one.
file filename
Newstyle form to specify the filename; On
contrary to the mach32eeprom filename form
it can be mixed with any other mach32eeprom
subcommand.
updatefile
Don't read the file, always read the EEPROM
(except when ignore is given) and create an
uptodate image of the 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, config-
ure everything as specified in the EEPROM.
The subcommands are intended to be used together
and are performed in the order specified. For exam-
ple:
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 under-
stood 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 senseable
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 speci-
fies how to set up the ramdac. A list of actual hardware
chips used for each type exists, but is not of much use.
The Mach32 will return a type and the ramdac will be com-
pletely hardware compatible to one of the given type.
Type 1 and 4 Dacs need different clock frequencies for
high colormodes. For 32K/64K colormodes the frequencies
have to be doubled and for 16M colors (type 4 only) they
have to be tripled. I followed the ATI scheme and did this
internally. However this means that for 32K/64K you can
use only clocks for which the doubled frequencies can be
generated as well.
This is no hard restriction as the 16 clocks of the Mach32
can be divided by 2. Thus if you setup some mode yourself
try to use one of the divided clocks in your timings and I
can use the undivided clocks internally.
It is a real restriction for 16M colors. ATI themself only
supports 25MHz (640x480) here by use of a 75MHz clock.
Depending on your clock chip other values may be usable as
well. Even the doubled/tripled clocks have to be less than
the magic 80 MHz. However the driver does all this itself.
It may just happen that some of the predefined or one of
your handmade mode-timings can't be used because the clock
that is used cannot be doubled/tripled. Even though there
is already some tolerance in the driver you may fix that
by slighty changing the clock values that you set with the
clocks command. But note that this will as well affect the
ability of the driver to calculate video timings and thus
it ability to check the monitor and DAC safety restric-
tions.
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 com-
pletely 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 repro-
duce 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 appli-
cations 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 aper-
ture 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_setchipsetand-
features(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 dif-
ferent DAC, making patches to support your card will be
much more helpful instead of just complaining. If you
have a different DAC that works well tell me as well such
that I can remove the need for SVGALIB_MACH32 in the next
release. Still, even now, after years, I got no reports of
a Mach32 card with a type 1 or 5 ramdac. Go figure.
Thank you for your audience and wishes you will enjoy this
driver,
Michael.
FILES
/etc/vga/libvga.config
/etc/vga/mach32.eeprom
SEE ALSO
svgalib(7), libvga(5), mach32info(6).
AUTHOR
The Mach32 driver and this documentation was written by
Michael Weller <eowmob@exp-math.uni-essen.de>.
Svgalib (>= 1.2.11) 1 August 1997 1
Back to the index
