1svgalib.mach32(7) Svgalib User Manual svgalib.mach32(7)
2
6 svgalib.mach32 - Information on the Mach32 chipset driver
7
10 0. Introduction
11 1. Specifying pixel clocks
12 2. Copyrights
13 3. The mach32info utility
14 4. Third party cards
15 5. Logical linewidth
16 6. Noisy video signals
17 7. The configuration EEPROM
18 8. EEPROM woes
19 9. The Mach32Eeprom command
20 10. Setup of the memory aperture (linear framebuffer)
21 11. Accelerator support and other weird features
22 12. Ramdacs
23 13. Meaning of the detection message from svgalib
24 14. Conclusions
25
28 The driver should allow you to use any of the graph-modes your Mach32
29 card supports. Note that there is no support for <8bpp modes and that I
30 won't ever implement that because I don't see any reason for doing so.
31 All standard VGA-modes are supported, of course (by using the standard
32 VGA driver routines).
33 If you configured your Mach32 for a memory aperture and it is at least
35 as big as the memory of your card (that is, not a 1MB memory aperture
36 for a 2MB card) support for linear frame buffer access of svgalib is
37 given.
38 Auto detection of the Mach32 seems not to work on all cards. That's
40 really strange since I got the code from the X people. It should be OK
41 regardless of my docs. Well, I fixed that (hopefully). Actually the bug
42 was found by Daniel Lee Jackson (djackson@ichips.intel.com). (Thanks
43 again.. It was so silly... I would have never found it) If you still
44 have problems just put a chipset Mach32 in your config file.
45
48 WARNING! The Mach32 driver needs to know correct clock frequencies for
49 graceful DAC configuration. Wrong clocks may damage your card! However,
50 this version contains code for automatic clock detection. Since clock
51 detection is time critical, please do it on a completely idle system.
52 Then put the printed out clocks line in your libvga.config(5) file.
53 The driver tries to do this for you. After that, you can restart what‐
55 ever svgalib program you used and you are set. If you already put a
56 clocks line in your config by hand, comment it out to have the driver
57 check your clocks.
58 Since clock probing is time critical, values differ from time to time,
60 you may try it multiple times and see which values seem to be most
61 exact. You can also compare them with the standard clock chips for
62 Mach32 cards in libvga.config(5)).
63 The clock probing relies on the 7th clock being 44.9MHz as this is what
65 Xfree does. If this is not true (and it is not always), probing is
66 hosed. See libvga.config(5) for a list of the clocks used by common
67 svgalib cards.
68
71 Some tiny routines are copied from Xfree86. The clock detection code is
72 almost just copied. So I repeat the copyright statements for these
73 parts here:
74 Copyright 1992 by Orest Zborowski <obz@Kodak.com>
76 Copyright 1993 by David Wexelblat <dwex@goblin.org>
77 Permission to use, copy, modify, distribute, and sell this software and
79 its documentation for any purpose is hereby granted without fee, pro‐
80 vided that the above copyright notice appear in all copies and that
81 both that copyright notice and this permission notice appear in sup‐
82 porting documentation, and that the names of Orest Zborowski and David
83 Wexelblat not be used in advertising or publicity pertaining to distri‐
84 bution of the software without specific, written prior permission.
85 Orest Zborowski and David Wexelblat make no representations about the
86 suitability of this software for any purpose. It is provided "as is"
87 without express or implied warranty.
88 Orest Zborowski and David Wexelblat disclaim all warranties with regard
90 to this software, including all implied warranties of merchantability
91 and fitness, in no event shall Orest Zborowski or David Wexelblat be
92 liable for any special, indirect or consequential damages or any dam‐
93 ages whatsoever resulting from loss of use, data or profits, whether in
94 an action of contract, negligence or other tortious action, arising out
95 of or in connection with the use or performance of this software.
96 Copyright 1990,91 by Thomas Roell, Dinkelscherben, Germany.
98 Copyright 1993 by Kevin E. Martin, Chapel Hill, North Carolina.
99 Permission to use, copy, modify, distribute, and sell this software and
101 its documentation for any purpose is hereby granted without fee, pro‐
102 vided that the above copyright notice appear in all copies and that
103 both that copyright notice and this permission notice appear in sup‐
104 porting documentation, and that the name of Thomas Roell not be used in
105 advertising or publicity pertaining to distribution of the software
106 without specific, written prior permission. Thomas Roell makes no rep‐
107 resentations about the suitability of this software for any purpose. It
108 is provided "as is" without express or implied warranty.
109 Thomas Roell, Kevin E. Martin, and Rickard E. Faith disclaim all war‐
111 ranties with regard to this software, including all implied warranties
112 of merchantability and fitness, in no event shall the authors be liable
113 for any special, indirect or consequential damages or any damages what‐
114 soever resulting from loss of use, data or profits, whether in an
115 action of contract, negligence or other tortious action, arising out of
116 or in connection with the use or performance of this software.
117 Author: Thomas Roell, roell@informatik.tu-muenchen.de
119 Rewritten for the 8514/A by Kevin E. Martin (martin@cs.unc.edu)
121 Modified for the Mach-8 by Rickard E. Faith (faith@cs.unc.edu)
122 Rewritten for the Mach32 by Kevin E. Martin (martin@cs.unc.edu)
123 And here is my own copyright:
125 This driver is free software; you can redistribute it and/or modify it
127 without any restrictions. This library is distributed in the hope that
128 it will be useful, but without any warranty.
129 Copyright 1994 by Michael Weller
131 Email addresses as of this writing:
133 eowmob@exp-math.uni-essen.de mat42b@spi.power.uni-essen.de
135 Michael Weller disclaims all warranties with regard to this software,
137 including all implied warranties of merchantability and fitness, in no
138 event shall Michael Weller be liable for any special, indirect or con‐
139 sequential damages or any damages whatsoever resulting from loss of
140 use, data or profits, whether in an action of contract, negligence or
141 other tortious action, arising out of or in connection with the use or
142 performance of this software.
143
146 The mach32info(6) utility or demo reads out all configuration registers
147 and the configuration EEPROM of your Mach32 card. If there is a problem
148 with the particular card you have, compile and run the utility in the
149 mach32/ directory of the svgalib distribution and send it's stdout to
150 me This might also be useful if you need a lot of options (e.g. clocks
151 on new models?) to get it to work so that this can be done automati‐
152 cally in future versions.
153
156 I got a few reports about AST systems with onboard Mach32. They do
157 feature an incompatible EEPROM setup, but I think I got around that.
158 Nevertheless the Mach32 chipset driver doesn't work out of the box on
159 any AST system I heard of.
160 Since original ATI Mach32 demos and tools don't work as well, I've to
162 claim that the Mach32 on these AST systems does not conform to ATI's
163 Mach32 docs. Fortunately, Vernon C. Hoxie <vern@zebra.alphacdc.com>
164 found a work around after years (really!) of investigating. AST Mach32
165 seems to work now. The work around was also submitted to Xfree and will
166 be incorporated to allow running it on the AST hardware too in recent
167 versions. Please read on the misc_ctl command below.
168 Dell users should have a look at the vendor, ramdac, and svgaclocks
170 commands below (if they have problems with the default settings).
171 Commands to support third party cards
174 I had to learn that those cards seem to use not only non standard
175 clocks for the Mach32, but also for the included SVGA. However, since
176 people often like to use proprietary, non standard VGA (read 80x25)
177 textmodes, the Mach32 driver has to set the included SVGA to a VGA com‐
178 patible clock frequency. Otherwise svgalib has problems using plain VGA
179 modes. This screws VGA modes up if these clocks have different values
180 on third party Mach32 cards.
181 svgaclocks n
184 with n a number between 0 and 31 to select the svga clocks to be
185 used in vga modes. The bits of n refer to specific ATI register
186 bits to complicated to explain here. Even if I would, I can't
187 tell which clocks they would select on your third party card
188 (which is the actual problem)
189 svgaclocks 9 is the default setting and correct for original ATI
191 cards.
192 Often svgaclocks 0 (Dell cards) works.
194 svgaclocks keep
196 is special in that the driver will not touch any SVGA timings.
197 This requires the Mach32 SVGA part to be in a VGA compatible
198 mode when the svgalib application is started, that is, you must
199 use 80x25 (maybe 80x50) console textmodes.
200 As I mentioned already, Vernon C. Hoxie <vern@zebra.alphacdc.com>
202 really seems to have located the reason for the Mach32 AST problems.
203 Any access to MISC_CTL locks up the card & system. Fortunately MISC_CTL
204 is only used for some DAC fine tuning (actually the setting you can
205 fine tune with the blank command) which is only of barely noticable
206 effect to the screen.
207 The following configuration commands exist to support AST cards:
209 misc_ctl keep-off
212 Do not dare to touch MISC_CTL.
213 misc_ctl use
215 Use it for fine tuning of the Ramdac setup (default).
216 Finally, for your convenience there exist:
218 vendor ati
220 vendor dell
221 vendor ast
222 These are macros that expand to settings for svgaclocks, ramdac,
223 misc_ctl, and mach32eeprom that are usually correct for ATI,
224 Dell, AST cards. Be aware that they really work like macros.
225 That is, they override any setting of svgaclocks, ramdac,
226 misc_ctl, and mach32eeprom made before them and individual
227 aspects will be changed by a following svgaclocks, ramdac,
228 misc_ctl, and mach32eeprom command.
229 Note that the mach32eeprom ignore required for some Dell cards
231 requires you to include explicit timings for Mach32 modes other
232 than 640x480x256. The mach32/mach32.std-modes file in the
233 svgalib distribution contains recommendations for modes from
234 ATI.
235 I heard about a bug in some ATI chipsets returning wrong memory
237 amounts configs. (But cannot confirm that)
238 You can enforce correct chipset identification from the configu‐
240 ration file:
241 chipset Mach32 chiptype memory
244 where chiptype is the sum of at exactly one value from each of
245 the following two groups
246 128 use no memory aperture.
248 160 use a 1MB memory aperture.
249 192 use a 4MB memory aperture.
250 0 choose size for the memory aperture automatically.
251 and
253 16 Ramdac is of type 0 (ATI68830)
255 17 Ramdac is of type 1 (IMS-G173, SC11486)
256 18 Ramdac is of type 2 (ATI68875, TLC34075)
257 19 Ramdac is of type 3 (INMOS176, INMOS178)
258 20 Ramdac is of type 4 (Bt481, Bt482)
259 21 Ramdac is of type 5 (ATI68860)
260 0 Ramdac type is queried from Mach32 chip.
261 memory is the amount of videomemory in KB.
264 Note that the type of the ramdac can be set more conveniently with the
266 ramdac command.
267
270 At least my VRAM card seems to be very peculiar about logical
271 linewidths. From my experience a multiple of 64 pels is needed. Your
272 mileage may vary. Use the config file options to adjust it and tell me
273 if your card needs a different value. Include the name and model number
274 of the card and what the correct numbers should be. This is so that I
275 can correct the auto configuration of the driver.
276 If some svgalib application has problems, note that you can force the
278 logical linewidth to the default value from the configfile. Probably
279 this will lead to glitches in some 800x600 resolutions. You can inhibit
280 these resolutions from the configfile as well. Apropos glitches, I
281 found no guidelines as to what clockrates to use due to memory restric‐
282 tions. I adjusted the driver, such that I get a stable pic in all reso‐
283 lutions. However sometimes the screen is disturbed by heavy video mem‐
284 ory accesses. If you don't like that, reduce the clocks used with the
285 maxclock16 or maxclock24 command, resp. This may of course lead to
286 none of the predefined modes being used. Then you can try to define
287 your own mode via the define command.
288
291 If you get some flicker or heavy noise on your screen, some fine tuning
292 may be needed. My docs didn't give me hints as to what each card can
293 stand. Especially DRAM cards may give problems (I've VRAM). In that
294 case, use the fine tuning config commands and send me your results
295 along with the output of mach32info(6). Then I can include them in my
296 next release.
297 Fine-tuning configuration commands
300 First you should think about the maxclock* configuration commands to
301 reduce pixel clocks used for each color depth.
302 Especially important for DRAM cards is the video FIFO depth used to
304 queue memory values for writing to the screen. Here is a command to set
305 this value for the 8bpp modes:
306 vfifo8 number
309 where number is in range 0 - 15. The default is now 6.
310 Since vfifo is of some impact to the speed of the card, tell me
312 the lowest setting that satisfies your card.
313 For 16/24/32 modes, there are non-zero values preset from inter‐
315 nal tables and the EEPROM, however you can enforce minimal vfifo
316 values with:
317 vfifo16 number
319 vfifo24 number
320 vfifo32 number
321 blank number
324 where number is 4 * pixel_delay + blank_adjust where pixel_delay
325 and blank_adjust are in range 0 .. 3. pixel_delay delays pixels
326 before they are sent to the DAC and blank_adjust adjusts the
327 blank pulse for type 2 DAC's. blank should be set correctly for
328 each DAC type automatically. So use it only as a last resort.
329 latch number
332 where number is the sum of zero or more of the following num‐
333 bers:
334 128 VRAM serial delay latch enable, DRAM latch bits 63 - 0
336 enable.
337 4096 Latch video memory data.
339 8192 Memory data delay latch enable for data bits 63 - 0.
341 16384 Memory full clock pulse enable.
343 Default is to switch all settings on (they are on on my card by
345 default anyway).
346 Note that these commands may vanish again once they are no longer
348 needed for debugging purposes.
349 There is no 320x200 mode in the EEPROM of the Mach32 at all, however I
351 defined one in the default configuration file for you. This is the best
352 thing I could get up on my card/screen. Note that it will probably have
353 big borders on your screen, and black lines in between the pixel lines.
354 This is because of the lack of low clocks < 16MHz on the Mach32 and the
355 lack of a line doubling mode as VGA has. The Mach32 is not intended for
356 such low resolutions. If you find a better mode or have an idea, please
357 let me know. You can also just remove my timings from the default con‐
358 figuration file.
359
362 Ah yes, about the EEPROM, I figured out how to read out the Mach32 EEP‐
363 ROM. I did it by disassembling the BIOS routine mentioned in the docs.
364 I then redid it in C. The driver will use everything it finds there.
365 Use the Mach32 install tools (they should have reached you together
367 with your Mach32 VGA card) to setup your card/monitor combo correctly.
368 The monitors setting from the config file (or default of 35kHz or some‐
369 thing) will be obeyed by the driver nevertheless (for safety!).
370 As you probably know already, accessing the EEPROM causes some screen
372 flickering. If this annoys you (or even worse your monitor) have a look
373 at the mach32eeprom command described below. This allows you to put the
374 data from the EEPROM into a file and which can be read whenever it is
375 required.
376 Don't even think about changing the contents of the file. (There is an
378 easily faked checksum in it.). Anyway the driver ensures (hopefully)
379 that no damage can be caused.
380 Also, if some mode is not well aligned on your screen or you don't like
382 it's sync frequency, consider using the Mach32 install utility (setup
383 for custom monitor) and set one up interactively. If there is no valid
384 faster (higher VSYNC) standard mode given in the EEPROM the driver will
385 use that mode. You will find that this is fun compared with calculating
386 video timings for /etc/XF86Config or /etc/vga/libvga.config.
387 However the install utility does restrict the maximum pixel depth for
389 custom modes sometimes unneeded hard and the driver obeys that. (Hmm..
390 actually it should be smart enough to decide itself which pixel depth
391 it can use in that mode.) Since the standard modes are usually only
392 slightly shifted to one side a file with the configuration commands
393 representing the standard modes is given in mach32/mach32.std-modes in
394 the svgalib distribution. You can use these as a starting point.
395 But here are some real problems:
397
400 I got 2 reports of people having problems with incorrect EEPROM check‐
401 sums. Both had motherboards with onboard Mach32 VGA's from AST. I
402 guessed a checksum algorithm from those reports and put this in the
403 code in addition to the standard ATI style. Still I got a report of
404 someone whose EEPROM was completely empty. If you have problems with
405 checksums send me the output of mach32info(6) and I'll see what I can
406 do.
407 By default svgalib writes a complaining message and ignores the con‐
409 tents. You can have svgalib ignore the checksum and contents with the
410 configuration command
411 mach32eeprom ignore
413 Then you can decide to use the partial info that is still in it. Use
415 mach32eeprom ignore usetimings
417 to use the videomodes that are defined in the EEPROM (if no better
419 modes are known by the driver). This is usually safe, because the
420 driver knows which modes are safe for your hardware (if clocks, monitor
421 and ramdac are configured correctly). You can also allow the driver to
422 use the configuration for the linear frame buffer in the EEPROM:
423 mach32eeprom ignore useaperture
425 or
427 mach32eeprom ignore usetimings useaperture
429 However I discourage this because the driver will just enable what the
431 EEPROM says about the aperture. Use mach32info(6) to check the address
432 it will choose is safe. It might be better to use setuplinear to set up
433 a 4MB aperture at a free address range.
434
437 The mach32eeprom allows to work around these problems. Here is the com‐
438 plete description for this configuration command.
439 mach32eeprom filename
442 The filename has to begin with a "/".
443 Unfortunately reading the EEPROM causes annoying screen flicker‐
445 ing and is slow. To avoid this, specify a filename from which
446 to read the contents of the EEPROM.
447 If the file cannot be read, the EEPROM is read out and the file
449 is created. There is a very simple checksum put into this file.
450 Although it can easily be fooled, don't change the file except
451 you know very, very well what you are doing.
452 Also, as long as the file exists, changes in the Mach32's EEPROM
454 are ignored. Delete the file to recreate an updated version on
455 next use of svgalib. You should ensure that the permissions of
456 the file don't allow normal users to change it. (This may happen
457 if umask has a bad value when svgalib creates the file).
458 Example:
460 mach32eeprom /etc/vga/mach32.eeprom
462 Due to problems with some boards this command got heavily expanded:
465 mach32eeprom subcommand1 [subcommand2...]
468 At least one subcommand is needed. Valid subcommands are:
469 ignore Don't complain about checksum and don't use any EEPROM
472 contents.
473 useaperture
475 Use the configuration for the memoryaperture given in the
476 EEPROM.
477 usetimings
479 Use videomodes found in the EEPROM of the board.
480 nofile Forget about any filename that maybe was already config‐
482 ured. Don't read a file, don't create one.
483 file filename
485 Newstyle form to specify the filename; On contrary to the
486 mach32eeprom filename form it can be mixed with any other
487 mach32eeprom subcommand.
488 updatefile
490 Don't read the file, always read the EEPROM (except when
491 ignore is given) and create an uptodate image of the EEP‐
492 ROM.
493 keepfile
495 Disable all previous updatefile commands.
496 compatible
498 Fall back to default behavior: If checksum on the EEPROM
499 data is not ok, use nothing of the configuration data. If
500 it is ok, configure everything as specified in the EEP‐
501 ROM.
502 The subcommands are intended to be used together and are per‐
504 formed in the order specified. For example:
505 mach32eeprom ignore useaperture usetimings
507 will ignore the checksum of your EEPROM, but use its contents.
509 Order is vital! So:
510 mach32eeprom useaperture usetimings ignore
512 won't use any configuration from your EEPROM. Be careful with
514 the useaperture subcommand. Please see the EEPROM WOES section.
515 Note that any non understood subcommand will terminate the
516 mach32eeprom command silently! Use only one subcommand per
517 mach32eeprom command to avoid this.
518 The mach32eeprom command is usually not allowed in the environ‐
520 ment variable SVGALIB_CONFIG.
521
524 Due to poor design, Xfree86 insists on setting up the aperture itself.
525 It doesn't reset the original settings at a VC switch once it runs. You
526 should not start X for the first time after a boot as long as an
527 svgalib application is running. This will result in pre X values being
528 restored at a VC switch by svgalib. If you use svgalib and XF86_Mach32
529 together, run X first or at least do not start it while any svgalib
530 appl. is still running. After X was started once you can use svgalib
531 and X in all combinations w/o any problems. Xfree uses whatever address
532 is given in the MEM_CFG Mach32 register for a 4MB aperture, even if the
533 aperture is not already enabled and the value in this register is
534 pointless garbage. This is IMHO a dangerous bug as some systems may
535 work only with a 1MB aperture.
536 However, usage of a correct EEPROM circumvents any such problems. If
538 you cannot use that, use mach32info (6) to find the address in MEM_CFG.
539 Then, if it is a senseable setting for your system, enable a 4MB aper‐
540 ture at that address with setuplinear. Ensure that no other card or
541 memory uses the address range you choose.
542
545 This version now has support for all accelerator functions of svgalib.
546 However they were intended for use with the cirrus chips. It may happen
547 that at runtime they find they cannot emulate the function actually
548 requested. Then you should disable the corresponding blit function (at
549 least for that application) with the blit config command.
550 Data transfer between the host and the Mach32 is normally via I/O. This
552 proved to be pretty slow. If a big enough aperture is available, a sim‐
553 ple memory copy is used instead. This is usually much faster. You can
554 change which method is used with the blit command. This I/O option
555 affects only vga_imageblt(3). The other functions are incredible fast.
556 For type 2 DACS, there is support for 8 bit per color (instead of the
558 normal 6) in the RGB triple in the color lookup table of the 256 color
559 modes. This can be enabled by an application, if it supports it. The
560 testaccel(6) demo uses it if supported by your hardware. You can use
561 vga_ext_set(3) to use it from your programs.
562
565 Mach32 Ramdacs are specified by a type in range 1 .. 5. This type can
566 be queried from the Mach32 and then specifies how to set up the ramdac.
567 A list of actual hardware chips used for each type exists, but is not
568 of much use. The Mach32 will return a type and the ramdac will be com‐
569 pletely hardware compatible to one of the given type.
570 Type 1 and 4 Dacs need different clock frequencies for high colormodes.
572 For 32K/64K colormodes the frequencies have to be doubled and for 16M
573 colors (type 4 only) they have to be tripled. I followed the ATI scheme
574 and did this internally. However this means that for 32K/64K you can
575 use only clocks for which the doubled frequencies can be generated as
576 well.
577 This is no hard restriction as the 16 clocks of the Mach32 can be
579 divided by 2. Thus if you setup some mode yourself try to use one of
580 the divided clocks in your timings and I can use the undivided clocks
581 internally.
582 It is a real restriction for 16M colors. ATI themself only supports
584 25MHz (640x480) here by use of a 75MHz clock. Depending on your clock
585 chip other values may be usable as well. Even the doubled/tripled
586 clocks have to be less than the magic 80 MHz. However the driver does
587 all this itself. It may just happen that some of the predefined or one
588 of your handmade mode-timings can't be used because the clock that is
589 used cannot be doubled/tripled. Even though there is already some tol‐
590 erance in the driver you may fix that by slighty changing the clock
591 values that you set with the clocks command. But note that this will as
592 well affect the ability of the driver to calculate video timings and
593 thus it ability to check the monitor and DAC safety restrictions.
594 In addition (in complete contrast to my original ATI docs) RAMDAC 4
596 does not support RGB with blue byte first but only with red first. This
597 required special handling and me adding a bunch of functions to all
598 modules of svgalib and vgagl. The added functions are of lower perfor‐
599 mance than the usual functions. However most data has to be completely
600 mangled, so I doubt that it can be done much faster. Sorry.
601 Of course, I might have forgotten to port some parts or even confused
603 things. About bugs in the gl and drawing libs, please ask Harm. But
604 then, I'm able to emulate a BGR ramdac on my card, so I should even be
605 able to reproduce your problems.
606 Recently I hear often about type 6 ramdacs in non ATI Mach32 cards.
608 There exists no info about these dacs, thus I cannot support them. The
609 driver assumes unknown DACs can stand up to 80MHz in 256 color clut
610 modes and does not touch the ramdac (that is, assumes it is in the 256
611 color mode already)
612 To get rid of the warning message you can use the
614 ramdac n
617 configuration command. It allows to explicitly set the type of
618 the dac to n (in range 0 to 5). Ramdac 3 is the most dumbest
619 ramdac possible, s.t. you can use it without any fear for your
620 hardware.
621 ramdac dumb
623 is equivalent to ramdac 3.
624 ramdac auto
626 switches back to the default autodetection.
627
629 Some programs (which do not switch it off) will show a
630 Using Mach32 version (sizeM at adrM (how), memK mem, DAC dactype)
632 line. This will show up in testlinear(6) etc but will probably scroll
634 away when you use vgatest(6). In this line:
635 version
638 is the version of the driver (as of my counting, not the svgalib
639 version).
640 size is the size of the memory aperture. It can be 1 or 4 (1 will
642 lead to not using the linear aperture if your card has more than
643 1MB memory, however applications can still use the 1MB aperture
644 and page the video memory through it in 1MB steps). size can
645 also be no if no aperture is setup at all.
646 adr is the base address of the aperture in MB.
648 how is autodetect if the aperture was setup this way already when
650 the program started. It is setup when the the setting was
651 enforced with a setuplinear configuration command. It is EEPROM
652 when no aperture was detected, but parameters to set it up were
653 found in the EEPROM.
654 mem is the amount of memory the card reported to have.
656 dactype
658 is the type of the DAC that was detected.
659 If a special ramdac type was set with the ramdac command a (set)
661 will be displayed after dactype.
662 If mem, dactype and/or the chipset were enforced with chipset from the
664 configuration file or vga_setchipsetandfeatures(3) a forced will be
665 appended to the line.
666
669 A final word: I have an ATI ULTRA PRO/2MB/EISA with a Type 2 DAC. My
670 monitor is an EIZO F550i-M. Everything I tried works on it like a
671 charm. However, I couldn't try it with other machines myself and esp.
672 other DAC's. Fortunately the Type 2 DAC is the worst to code. So I will
673 probably have gotten the other DAC's right. But please be warned!
674 I did my very best to code the driver to support the other DAC's by
676 just reading the docs. But i can't give any definitive guarantee for
677 it to work or even not damaging your hardware. So please be careful!
678 Note that you will have to set the environment variable SVGALIB_MACH32
680 to ILLTRYIT if your DAC is not type 0, 2, 3 or 4. This will of course
681 change if no one with a DAC equal to 1 or 5 has serious problems. If
682 you have a different DAC, making patches to support your card will be
683 much more helpful instead of just complaining. If you have a different
684 DAC that works well tell me as well such that I can remove the need for
685 SVGALIB_MACH32 in the next release. Still, even now, after years, I got
686 no reports of a Mach32 card with a type 1 or 5 ramdac. Go figure.
687 Thank you for your audience and wishes you will enjoy this driver,
689 Michael.
690
692 /etc/vga/libvga.config
693 /etc/vga/mach32.eeprom
694
697 svgalib(7), libvga.config(5), mach32info(6).
698
701 The Mach32 driver and this documentation was written by Michael Weller
702 <eowmob@exp-math.uni-essen.de>.
703Svgalib (>= 1.2.11) 1 August 1997 svgalib.mach32(7)