Alas, in this day of Windows, video adapter manufacturers do not have much incentive to support DOS video modes. Fractint can support any video modes included in your board's VESA video bios. Many otherwise good boards do not include the higher resolution modes in their bios even though those modes are supported in the manufacturer's Windows driver.
Fractint users are particularly fond of the 1600x1200 mode. If you want to use this mode, make sure your video board supports it. Some boards that have given good results are boards from STB, various versions of Matrox Millennium, and boards from several manufacturers using Nvidia Riva chip sets.
Using high resolution video modes poses a second challenge for fractint users. That is that the VESA standard does not have standard settings for this mode, so you will have to edit the fractint.cfg file to support your board. You can run the program makefcfg.exe that comes with fractint to generate entries for your fractint.cfg file.
Finally, even if your video board VESA Bios supports high resolution video modes, it probably doesn't come with a utility that allows you to set the vertical refresh. If the vertical refresh is set for 60 Hz or less, you may see flicker and be subject to headaches. Fortunately, there is a wonderful freeware utility by Rob Muller that allows you to control the vertical refresh for any VESA video mode. Of course your monitor still needs to be able to support higher rates -- software can't help that. To get Rob's unirefresh program, email Rob at email@example.com or check out:
True to the spirit of public-domain programming, Fractint makes only a limited attempt to verify that your video adapter can run in the mode you specify, or even that an adapter is present, before writing to it. So if you use the "video=" command line parameter, check it before using a new version of Fractint - the old key combo may now call an ultraviolet holographic mode.
Fractint assumes that every EGA adapter has a full 256K of memory (and can therefore display 640 x 350 x 16 colors), but does nothing to verify that fact before slinging pixels.
The IBM VGA adapter is a highly programmable device, and can be set up to display many video-mode combinations beyond those "officially" supported by the IBM BIOS. E.g. 320x400x256 and 360x480x256 (the latter is one of our favorites). These video modes are perfectly legal, but temporarily reprogram the adapter (IBM or fully register-compatible) in a non-standard manner that the BIOS does not recognize.
Fractint also contains code that sets up the IBM (or any truly register- compatible) VGA adapter for several extended modes such as 704x528, 736x552, 768x576, and 800x600. It does this by programming the VGA controller to use the fastest dot-clock on the IBM adapter (28.322 MHz), throwing more pixels, and reducing the refresh rate to make up for it.
These modes push many monitors beyond their rated specs, in terms of both resolution and refresh rate. Signs that your monitor is having problems with a particular "tweaked" mode include:
We have successfully tested the modes up to 768x576 on an IBM PS/2 Model 80 connected to IBM 8513, IBM 8514, NEC Multisync II, and Zenith 1490 monitors (all of which exhibit some overscan and flicker at the highest rates), and have tested 800x600 mode on the NEC Multisync II (although it took some twiddling of the vertical-size control).
Since version 12.0, we've used both John Bridges' SuperVGA Autodetecting logic *and* VESA adapter detection, so that many brand-specific SuperVGA modes have been combined into single video mode selection entries. There is now exactly one entry for SuperVGA 640x480x256 mode, for instance.
If Fractint's automatic SuperVGA/VESA detection logic guesses wrong, and you know which SuperVGA chipset your video adapter uses, you can use the "adapter=" command-line option to force Fractint to assume the presence of a specific SuperVGA Chipset - see Video Parameters for details.
The IBM 8514/A modes (640x480 and 1024x768) default to using the hardware registers. If an error occurs when trying to open the adapter, an attempt will be made to use IBM's software interface, and requires the preloading of IBM's HDILOAD TSR utility.
The Adex 1280x1024 modes were written for and tested on an Adex Corporation 8514/A using a Brooktree DAC. The ATI GU 800x600x256 and 1280x1024x16 modes require a ROM bios version of 1.3 or higher for 800x600 and 1.4 or higher for 1280x1024.
There are two sets of 8514/A modes: full sets (640x480, 800x600, 1024x768, 1280x1024) which cover the entire screen and do NOT have a border color (so that you cannot tell when you are "paused" in a color- cycling mode), and partial sets (632x474, 792x594, 1016x762, 1272x1018) with small border areas which do turn white when you are paused in color-cycling mode. Also, while these modes are declared to be 256- color, if you do not have your 8514/A adapter loaded with its full complement of memory you will actually be in 16-color mode. The hardware register 16-color modes have not been tested.
If your 8514/A adapter is not truly register compatible and Fractint does not detect this, use of the adapter interface can be forced by using afi=y or afi=8514 in your SSTOOLS.INI file.
Finally, because IBM's adapter interface does not handle drawing single pixels very well (we have to draw a 1x1 pixel "box"), generating the zoom box when using the interface is excruciatingly slow. Still, it works!
The XGA adapter is supported using the VESA/SuperVGA Autodetect modes - the XGA looks like just another SuperVGA adapter to Fractint. The supported XGA modes are 640x480x256, 1024x768x16, 1024x768x256, 800x600x16, and 800x600x256. Note that the 1024x768x256 mode requires a full 1MB of adapter memory, the 1024x768 modes require a high-rez monitor, and the 800x600 modes require a multisynching monitor such as the NEC 2A.
TARGA support for Fractint is provided courtesy of Joe McLain and has been enhanced with the help of Bruce Goren and Richard Biddle. To use a TARGA board with Fractint, you must define two DOS environment variables, "TARGA" and "TARGASET". The definition of these variables is standardized by Truevision; if you have a TARGA board you probably already have added "SET" statements for these variables to your AUTOEXEC.BAT file. Be aware that there are a LOT of possible TARGA configurations, and a LOT of opportunities for a TARGA board and a VGA or EGA board to interfere with each other, and we may not have all of them smoothed away yet. Also, the TARGA boards have an entirely different color-map scheme than the VGA cards, and at the moment they cannot be run through the color-cycling menu. The "MAP=" argument (see Color Parameters ), however, works with both TARGA and VGA boards and enables you to redefine the default color maps with either board.
To use the special modes supported for TARGA+ adapters, the TARGAP.SYS device driver has to be loaded, and the TPLUS.DAT file (included with Fractint) must be in the same directory as Fractint. The video modes with names containing "True Color Autodetect" can be used with the Targa+. You might want to use the command line parameters "tplus=", "noninterlaced=", "maxcolorres=", and "pixelzoom=" (see Video Parameters ) in your SSTOOLS.INI file to modify Fractint's use of the adapter.
These "video modes" do not involve a video adapter at all. They use (in order or preference) your expanded memory, your extended memory, or your disk drive (as file FRACTINT.$$$) to store the fractal image. These modes are useful for creating images beyond the capacity of your video adapter right up to the current internal limit of 32767 x 32767 x 256, e.g. for subsequent printing. They're also useful for background processing under multi-tasking DOS managers - create an image in a disk- video mode, save it, then restore it in a real video mode.
While you are using a disk-video mode, your screen will display text information indicating whether memory or your disk drive is being used, and what portion of the "screen" is being read from or written to. A "Cache size" figure is also displayed. 64K is the maximum cache size. If you see a number less than this, it means that you don't have a lot of memory free, and that performance will be less than optimum. With a very low cache size such as 4 or 6k, performance gets considerably worse in cases using solid guessing, boundary tracing, plasma, or anything else which paints the screen non-linearly. If you have this problem, all we can suggest is having fewer TSR utilities loaded before starting Fractint, or changing in your config.sys file, such as reducing a very high BUFFERS value.
The zoom box is disabled during disk-video modes (you couldn't see where it is anyway). So is the orbit display feature.
Color Cycling can be used during disk-video modes, but only to load or save a color palette.
When using real disk for your disk-video, Fractint previously would not generate some "attractor" types (e.g. Lorenz) nor "IFS" images. These stress disk drives with intensive reads and writes, but with the caching algorithm performance may be acceptable. Currently Fractint gives you a warning message but lets you proceed. You can end the calculation with [Esc] if you think your hard disk is getting too strenuous a workout.
When using a real disk, and you are not directing the file to a RAM disk, and you aren't using a disk caching program on your machine, specifying BUFFERS=10 (or more) in your config.sys file is best for performance. BUFFERS=10,2 or even BUFFERS=10,4 is also good. It is also best to keep your disk relatively "compressed" (or "defragmented") if you have a utility to do this.
In order to use extended memory, you must have HIMEM.SYS or an equivalent that supports the XMS 2.0 standard or higher. Also, you can't have a VDISK installed in extended memory. Himem.sys is distributed with Microsoft Windows 286/386 and 3.0. If you have problems using the extended memory, try rebooting with just himem.sys loaded and see if that clears up the problem.
If you are running background disk-video fractals under Windows 3, and you don't have a lot of real memory (over 2Mb), you might find it best to force Fractint to use real disk for disk-video modes. (Force this by using a .pif file with extended memory and expanded memory set to zero.) Try this if your disk goes crazy when generating background images, which are supposedly using extended or expanded memory. This problem can occur because, to multi-task, sometimes Windows must page an application's expanded or extended memory to disk, in big chunks. Fractint's own cached disk access may be faster in such cases.
If you have a favorite adapter/video mode that you would like to add to Fractint... if you want some new sizes of disk-video modes... if you want to remove table entries that do not apply to your system... if you want to specify different "textsafe=" options for different video modes... relief is here, and without even learning "C"!
You can do these things by modifying the FRACTINT.CFG file with your text editor. Saving a backup copy of FRACTINT.CFG first is of course highly recommended!
Fractint uses a video adapter table for most of what it needs to know about any particular adapter/mode combination. The table is loaded from FRACTINT.CFG each time Fractint is run. It can contain information for up to 300 adapter/mode combinations. The table entries, and the function keys they are tied to, are displayed in the "select video mode" screen.
This table makes adding support for various third-party video cards and their modes much easier, at least for the ones that pretend to be standard with extra dots and/or colors. There is even a special "roll- your-own" video mode (mode 19) enabling those of you with "C" compilers and a copy of the Fractint source to generate video modes supporting whatever adapter you may have.
The table as currently distributed begins with nine standard and several non-standard IBM video modes that have been exercised successfully with a PS/2 model 80. These entries, coupled with the descriptive comments in the table definition and the information supplied (or that should have been supplied!) with your video adapter, should be all you need to add your own entries.
After the IBM and quasi-pseudo-demi-IBM modes, the table contains an ever-increasing number of entries for other adapters. Almost all of these entries have been added because someone like you sent us spec sheets, or modified Fractint to support them and then informed us about it.
Lines in FRACTINT.CFG which begin with a semi-colon are treated as comments. The rest of the lines must have eleven fields separated by commas. The fields are defined as:
NOTE that the AX, BX, CX, and DX fields use hexadecimal notation (fifteen ==> 'f', sixteen ==> '10'), because that's the way most adapter documentation describes it. The other fields use standard decimal notation.
If you look closely at the default entries, you will notice that the IBM VGA entries labeled "tweaked" and "non standard" have entries in the table with AX = BX = CX = 0, and DX = some other number. Those are special flags that we used to tell the program to custom-program the VGA adapter, and are NOT undocumented BIOS calls. Maybe they should be, but they aren't.
If you have a fancy adapter and a new video mode that works on it, and it is not currently supported, PLEASE GET THAT INFORMATION TO US! We will add the video mode to the list on our next release, and give you credit for it. Which brings up another point: If you can confirm that a particular video adapter/mode works (or that it doesn't), and the program says it is UNTESTED, please get that information to us also. Thanks in advance!