This article is from the comp.sys.ibm.pc.hardware.video Frequently Asked Questions, by Michael Scott with numerous contributions by others. (v1.0).
[From: Michael Scott (scott@bme.ri.ccf.org)]
Overclocking VLB to >40 MHz
If your motherboard operates at 50 MHz, it's quite possible that you will have trouble with VLB video cards. The VESA specification states that, at best, one card can operate at 40 MHz, or two can operate at up to 33 MHz. Some manufacturers don't even guarantee that their cards will run at 40 MHz, preferring to support bus speeds of 33 MHz or less. I am unaware of _any_ vendor who will guarantee that their VLB video card will work at >40 MHz. So, if your VLB video card, running at >40 MHz, is causing problems, your best bet is to step your bus speed down. As an alternative, try another model or brand of card.
[From: Dylan Rhodes (Formerly of Hercules) ]
Version 2.0 of the VESA VL-Bus specification added support for a 50MHz bus speed. However, VESA VL-Bus 2.0 is one of a few VESA specs which went largely unimplemented by manufacturers. Just because the VL-Bus 2.0 spec exists does not mean that all VL-Bus motherboards manufactured since day one are now compatible with this new spec.
[From: Michael Scott (scott@bme.ri.ccf.org) ]
IBM SLC Motherboards
Some VLB video cards will not operate properly in some 486slc motherboards. Implementation of the 32 bit VLB with the 16 bit external data path of this CPU was problematic on early incarnations. For the most part, this was because of poor implementations of VLB on the motherboards, not a video card problem. Later versions of these motherboards overcame these problems, but if you have an older one you may not be able to run some VESA video cards on it.
VLB and Memory Aperture
If you have a VLB system and your video card uses a memory aperture, ensure that your system has adequate address space. Memory aperture works by reserving linearly mapped address space, usually at high addresses (120Meg+) which corresponds to the memory on the video card. As a result, large linear memory transfers can be done without resorting to regular VGA memory address segmentation. As a result, your system has to have more memory address space than physical memory, or there will be conflicts between the memory aperture and physical RAM.
i.e. system RAM + video RAM <= maximum addressable RAM
For example, a system with 16 Meg of RAM that can address 128 Meg can have a memory aperture at 120 Meg, for up to 8 continuous megabytes. However, if your system is a 486slc which has only 24 bit addressing, it can only address 16 Meg of RAM. In this case, the memory aperture must be located at <16 Meg (usually 12 Meg) so your total system RAM can't exceed 12 Meg if you wish to take advantage of the speed increases of using a memory aperture.
IBM's 8514/a and COM4
[From: Michael Scott (scott@bme.ri.ccf.org) and Dylan Rhodes (Formerly of Hercules) and Jim at Hercules]
The 8514/a was designed to coexist with a VGA adapter, and for this reason it uses a different range of addresses. Some of these are 16-bit addresses which are located at h42E8, h82E8, h92E8, hA2E8 & hE2E8. Unfortunately, many cheapo serial controllers only decode the first 12 bits of the I/O port addresses, and assume that calls to x2E8 (like all of those listed above) are intended for the serial port rather than the video card. This means that COM4 cannot be used on a machine with an 8514/a compatible video card _unless_ the address of COM4 can be changed (usually via jumpers) on the serial card, or the serial controller decodes all 16 bits of the I/O port addresses. There is no other way to get COM4 and any 8514/a compatible display adapter to coexist.
Note that this is _not_ a shortcoming of 8514/a, but is rather a limitation of most serial controllers.
ATI Mach and S3 Vision/Trio cards and COM4 [From: Michael Scott (scott@bme.ri.ccf.org)]
ATI's Mach and S3's current chipsets were based on IBM's 8514/a standard and have the same problems as the 8514/a. See 'IBM 8514/a and COM4".
see: http://www.hercules.com/knowbase/ : Do a search on COM4 and Terminator. You are looking for item 575 in the knowledge base.
ATI Mach64 cards + Quicktime for Windows 3.1 = GPF
GPF (General Protection Faults) are all too common in Windows 3.1. In this case, the fix is easy. Simply edit your system.ini file, and under the [macx] heading, add the following line: DeviceBitmaps=off. Games (like Myst) or other programs that use Quicktime for Windows 1.1 will require this fix.
If editing your system.ini file makes you nervous, try the following: [Roger Squires (rsquires@cyclops.eece.unm.edu)]
Go into the ATI FlexDesk, type " OPT" (brings up hidden window) and uncheck DeviceBitmap
If you have any other tips or fixes for other boards or chipsets, please submit them to Michael Scott (scott@bme.ri.ccf.org).
Video Circuitry Integral with the Motherboard [Michael Scott (scott@bme.ri.ccf.org)]
If you're installing a new video card into an existing system that has video circuitry integral with the motherboard, you will have to disable the built-in video. Otherwise you will have conflicts between the new video card and existing circuitry - they will try to both use the same VGA address space.
If none of the above apply to you, then either talk to a professional, or if you're a bit knowledgeable, you might try the following.
There are some general things to consider when you suspect that there may be a hardware conflict between your video card and another part of your system. The odds are that the conflict is due to either another add-in card or a TSR (Terminate and Stay Resident) program. To be able to determine this yourself, you have to know a little bit about pc hardware and software configuration. In general, the following procedure should help you to isolate the cause of your frustrations:
First, make sure it isn't a software conflict. This example is for DOS users. Start by creating a boot floppy by getting to a command prompt, putting a blank floppy into floppy drive A: and typing:
format /s a:
This will transfer the basic system files to the floppy. After this, copy the absolute minimum TSR's onto the floppy, and put a bare-bones config.sys and autoexec.bat on it. Take out sound card drivers, cdrom drivers, RAM disks and anything else superfluous. Reboot the computer with the floppy in, and see if the problem persists.
If not, incrementally add your TSR's back in until the problem appears. At this point you know what is causing the conflict, and can go about trying to get a new driver or configuring the existing one properly.
If the problem is still there, then the problem is in hardware. The same basic approach works here. After your computer is shut off, take the case off the back. You should ground yourself to the computer's chassis (if metal) or power supply to avoid blasting any of your add-in cards with static electricity. Remove all but the most necessary cards - usually this means the video adapter and i/o adapter are the only cards remaining. Reboot the system with the minimal TSR's loaded and check for the problem. If it still persists, and you have determined that a software conflict does _not_ exist, then your video card may be incompatible with your motherboard.
If the problem disappears, incrementally add your other cards back into the machine until you find the offending card. Once you find it, check the configuration of that card. Ensure that it isn't using the same memory address space or interrupts that the video card uses.
 
Continue to: