This is an ISA-specific BIOS option. In motherboards that have ISA slots, the BIOS can be set to reserve part of the upper memory area (UMA), which resides between 640 KB and 1 MB, for use by ISA expansion cards. This is particularly important for older operating systems like MS-DOS because it frees up conventional memory (the first 640 KB) for use by the operating system and applications.
If your ISA expansion card requires an upper memory area of 64 KB in size, select the 64KB option. Similarly, if it requires just 32 KB or 16 KB of upper memory, select the 32KB or 16KB options respectively.
If you are not sure how much memory your ISA expansion card requires, select 64KB. It will work with cards that only require 32 KB or 16 KB of upper memory. The rest of the reserved upper memory area will be left unused.
If you do not have any ISA expansion cards installed, leave it at its default setting of Disabled. This frees up the UMA for use by the operating system (or third-party memory managers) to store TSR (Terminate and Stay Resident) programs.
Details
This is an ISA-specific BIOS option. In motherboards that have ISA slots, the BIOS can be set to reserve part of the upper memory area (UMA), which resides between 640 KB and 1 MB, for use by ISA expansion cards. This is particularly important for older operating systems like MS-DOS because it frees up conventional memory (the first 640 KB) for use by the operating system and applications.
In truly old motherboards with multiple ISA slots, you will have the option to set both the memory address range and the reserved memory size. You may have to set jumpers on your ISA expansion cards to prevent two or more cards using the same memory address range, but this allows you to reserve segments of the upper memory area for your ISA expansion cards.
PCI-based motherboards have no need for so many ISA slots. Most, if not all, only have a single ISA slot for the rare ISA expansion card that had not yet been “ported” to the PCI bus. Therefore, their BIOS only has a single BIOS option, which allows you to set the size of the UMA to be reserved for the single ISA card. There’s no need to set the memory address range because there is only one ISA slot, so you need not worry about conflicts between multiple ISA cards. All you need to do is set the reserved memory size.
[adrotate group=”1″]
To do so, you will have to find out how much memory your ISA expansion card requires. Check the manual that came with the card. It ranges from 16 KB to 64 KB. Once you know how much upper memory your ISA expansion card requires, use this BIOS setting to reserve the memory segment for your card.
If your ISA expansion card requires an upper memory area of 64 KB in size, select the 64KB option. Similarly, if it requires just 32 KB or 16 KB of upper memory, select the 32KB or 16KB options respectively.
If you are not sure how much memory your ISA expansion card requires, select 64KB. It will work with cards that only require 32 KB or 16 KB of upper memory. The rest of the reserved upper memory area will be left unused.
If you do not have any ISA expansion cards installed, leave it at its default setting of Disabled. This frees up the UMA for use by the operating system (or third-party memory managers) to store TSR (Terminate and Stay Resident) programs.
If you like our work, you can help support our work by visiting our sponsors, participating in the Tech ARP Forums, or even donating to our fund. Any help you can render is greatly appreciated!
What this BIOS feature actually does is determine what devices are configured by the BIOS when the computer boots up and what are left to the operating system.
Non-ACPI BIOSes are found in older motherboards that do not support the new ACPI (Advanced Configuration and Power Interface) initiative. With such a BIOS, setting the PNP OS Installed feature to No allows the BIOS to configure all devices under the assumption that the operating system cannot do so. Therefore, all hardware settings are fixed by the BIOS at boot up and will not be changed by the operating system.
On the other hand, if you set the feature to Yes, the BIOS will only configure critical devices that are required to boot up the system. The other devices are then configured by the operating system. This allows the operating system some flexibility in shuffling system resources like IRQs and IO ports to avoid conflicts. It also gives you some degree of freedom when you want to manually assign system resources.
Of course, all current motherboards now ship with the new ACPI BIOS. If you are using an ACPI-compliant operating system (i.e. Windows 98 and above) with an ACPI BIOS, then this PNP OS Installed feature is no longer relevant. This is because the operating system will use the ACPI BIOS interface to configure all devices as well as retrieve system information.
But if your operating system does not support ACPI, then the BIOS will fall back to PNP mode. In this situation, consider the BIOS as you would a Non-ACPI BIOS. If there is no need to configure any hardware manually, it is again recommended that you set this feature to No.
If you are using an old Linux kernel (prior to 2.6.0), Jonathan has the following advice –
Although Linux (prior to kernel 2.6) is not really PnP-compatible, most distributions use a piece of software called ISAPNPTOOLS to setup ISA cards. If you have PnP OS set to No, the BIOS will attempt to configure ISA cards itself. This does not make them work with Linux, though, you still need to use something like ISAPNPTOOLS. However, having both the BIOS and ISAPNPTOOLS attempting to configure ISA cards can lead to problems where the two don’t agree.
The solution? Set PnP OS to Yes, and let ISAPNPTOOLS take care of ISA cards in Linux, as BIOS configuration of ISA cards doesn’t work for Linux anyway (with the current stable and development kernels). Most times, it probably won’t make a difference, but someone somewhere will have problems, and Linux will always work with PnP OS set to Yes.
Britt Turnbull recommends disabling this feature if you are running the OS/2 operating system, especially in a multi-boot system. This is because booting another operating system can update the BIOS which may later cause problems when you boot up OS/2.
To sum it all up, except for certain cases, it is highly recommended that you to set this BIOS feature to No, irrespective of the operating system you actually use. Exceptions to this would be the inability of the BIOS to configure the devices properly in PnP mode and a specific need to manually configure one or more of the devices.
Details
This BIOS feature is quite misleading because its name alludes that you should set it to Yes if you have an operating system that supports Plug and Play (PnP). Unfortunately, it isn’t quite so simple.
What this BIOS feature actually does is determine what devices are configured by the BIOS when the computer boots up and what are left to the operating system. This is rather different from what the name implies, right?
Before you can determine the appropriate setting for this feature, you should first determine the kind of BIOS that came with your motherboard. For the purpose of this discussion, the BIOS can be divided into two types – ACPI BIOS and Non-ACPI BIOS.
You will also need to find out if your operating system supports and is currently running in ACPI mode. Please note that while an operating system may tout ACPI support, it is possible to force the operating system to use the older PnP mode. So, find out if your operating system is actually running in ACPI mode. Of course, this is only possible if your motherboard comes with an ACPI BIOS. With a Non-ACPI BIOS, all ACPI-compliant operating systems automatically revert to PnP mode.
[adrotate banner=”4″]
Non-ACPI BIOSes are found in older motherboards that do not support the new ACPI (Advanced Configuration and Power Interface) initiative. This can be either the ancient non-PnP BIOS (or Legacy BIOS) or the newer PnP BIOS. With such a BIOS, setting the PNP OS Installed feature to No allows the BIOS to configure all devices under the assumption that the operating system cannot do so. Therefore, all hardware settings are fixed by the BIOS at boot up and will not be changed by the operating system.
On the other hand, if you set the feature to Yes, the BIOS will only configure critical devices that are required to boot up the system. For example, the graphics card and the hard disk. The other devices are then configured by the operating system. This allows the operating system some flexibility in shuffling system resources like IRQs and IO ports to avoid conflicts. It also gives you some degree of freedom when you want to manually assign system resources.
While all this flexibility in hardware configuration sounds like a good idea, shuffling resources can sometimes cause problems, especially with a buggy BIOS. Therefore, it is recommended that you set this feature to No, to allow the BIOS to configure all devices. You should only set this feature to Yes if the Non-ACPI BIOS cannot configure the devices properly or if you want to manually reallocate hardware resources in the operating system.
Of course, all current motherboards now ship with the new ACPI BIOS. If you are using an ACPI-compliant operating system (i.e. Windows 98 and above) with an ACPI BIOS, then this PNP OS Installed feature is no longer relevant. It actually does not matter what setting you select. This is because the operating system will use the ACPI BIOS interface to configure all devices as well as retrieve system information. There is no longer a need to specifically split the job up between the BIOS and the operating system.
But if your operating system does not support ACPI, then the BIOS will fall back to PNP mode. In this situation, consider the BIOS as you would a Non-ACPI BIOS. If there is no need to configure any hardware manually, it is again recommended that you set this feature to No.
Please note that bugs in some ACPI BIOS can cause even an ACPI-compliant operating system to disable ACPI. This reverts the BIOS to PnP mode. However, there is an additional catch to it. Certain operating systems (i.e. Windows 98 and above) will only access the buggy BIOS in read-only mode. This means the operating system will rely entirely on the BIOS to configure all devices and provide it with the hardware configuration. As such, you must set the feature to No if you have a buggy ACPI BIOS.
If you are using an old Linux kernel (prior to 2.6.0), Jonathan has the following advice –
Although Linux (prior to kernel 2.6) is not really PnP-compatible, most distributions use a piece of software called ISAPNPTOOLS to setup ISA cards. If you have PnP OS set to No, the BIOS will attempt to configure ISA cards itself. This does not make them work with Linux, though, you still need to use something like ISAPNPTOOLS. However, having both the BIOS and ISAPNPTOOLS attempting to configure ISA cards can lead to problems where the two don’t agree.
The solution? Set PnP OS to Yes, and let ISAPNPTOOLS take care of ISA cards in Linux, as BIOS configuration of ISA cards doesn’t work for Linux anyway (with the current stable and development kernels). Most times, it probably won’t make a difference, but someone somewhere will have problems, and Linux will always work with PnP OS set to Yes.
Britt Turnbull recommends disabling this feature if you are running the OS/2 operating system, especially in a multi-boot system. This is because booting another operating system can update the BIOS which may later cause problems when you boot up OS/2. In addition, if you add or change hardware, you should enable full hardware detection during the initial boot sequence of OS/2 (ALT-F1 at boot screen -> F5) so that the new hardware can be registered correctly.
Thomas McGuire of 3D Spotlight sent me this e-mail from Robert Kirk at IBM :-
“Actually, the setting “PnP OS” is really misnamed. A better thing would be to say “do you want the system to attempt to resolve resource conflicts, or do you want the OS to resolve system conflict?”. Setting the system to PnP OS says that even if the machine determines some kind of resource problem, it should not attempt to handle it… Rather, it should pass it on to the OS to resolve the issue. Unfortunately, the OS can’t resolve some issues…. which sometimes results in a lock or other problems.
For stability reasons, it is better to set EVERY motherboard’s PnP OS option to No, regardless of manufacturer but still allow the BIOS to auto configure PnP devices. Just leave the PnP OS to No. It won’t hurt a thing, you lose nothing, your machine will still autoconfigure PnP devices and it will make your system more stable.”
Thanks, Thomas! That was really useful info.
To sum it all up, except for certain cases, it is highly recommended that you to set this BIOS feature to No, irrespective of the operating system you actually use. Exceptions to this would be the inability of the BIOS to configure the devices properly in PnP mode and a specific need to manually configure one or more of the devices.
Support Tech ARP!
If you like our work, you can help support our work by visiting our sponsors, participate in the Tech ARP Forums, or even donate to our fund. Any help you can render is greatly appreciated!
The AGP ISA Aliasing BIOS feature allows you to determine if the system controller will perform ISA aliasing to prevent conflicts between ISA devices.
The default setting of Enabled forces the system controller to alias ISA addresses using address bits [15:10]. This restricts all 16-bit addressing devices to a maximum contiguous I/O space of 256 bytes.
When disabled, the system controller will not perform any ISA aliasing and all 16 address lines can be used for I/O address space decoding. This gives 16-bit addressing devices access to the full 64KB I/O space.
It is recommended that you disable AGP ISA Aliasing for optimal AGP (and PCI) performance. It will also prevent your AGP or PCI cards from conflicting with your ISA cards. Enableit only if you have ISA devices that are conflicting with each other.
Details
The origin of the AGP ISA Aliasing feature can be traced back all the way to the original IBM PC. When the IBM PC was designed, it only had ten address lines (10-bits) for I/O space allocation. Therefore, the I/O space back in those days was only 1KB or 1024 bytes in size. Out of those 1024 available addresses, the first 256 addresses were reserved exclusively for the motherboard’s use, leaving the last 768 addresses for use by add-in devices. This would become a critical factor later on.
Later, motherboards began to utilize 16 address lines for I/O space allocation. This was supposed to create a contiguous I/O space of 64KB in size. Unfortunately, many ISA devices by then were only capable of doing 10-bit decodes. This was because they were designed for computers based on the original IBM design which only supported 10 address lines.
To circumvent this problem, they fragmented the 64KB I/O space into 1KB chunks. Unfortunately, because the first 256 addresses must be reserved exclusively for the motherboard, this means that only the first (or lower) 256 bytes of each 1KB chunk would be decoded in full 16-bits. All 10-bits-decoding ISA devices are, therefore, restricted to the last (or top) 768 bytes of the 1KB chunk of I/O space.
As a result, such ISA devices only have 768 I/O locations to use. Because there were so many ISA devices back then, this limitation created a lot of compatibility problems because the chances of two ISA cards using the same I/O space were high. When that happened, one or both of the cards would not work. Although they tried to reduce the chance of such conflicts by standardizing the I/O locations used by different classes of ISA devices, it was still not good enough.
Eventually, they came up with a workaround. Instead of giving each ISA device all the I/O space it wants in the 10-bit range, they gave each a much ISA device smaller number of I/O locations and made up for the difference by “borrowing” them from the 16-bit I/O space! Here’s how they did it.
The ISA device would first take up a small number of I/O locations in the 10-bit range. It then extends its I/O space by using 16-bit aliases of the few 10-bit I/O locations taken up earlier. Because each I/O location in the 10-bit decode area has sixty-three16-bit aliases, the total number of I/O locations expands from just 768 locations to a maximum of 49,152 locations!
More importantly, each ISA card will now require very few I/O locations in the 10-bit range. This drastically reduced the chances of two ISA cards conflicting each other in the limited 10-bit I/O space. This workaround naturally became known as ISA Aliasing.
Now, that’s all well and good for ISA devices. Unfortunately, the 10-bit limitation of ISA devices becomes a liability to devices that require 16-bit addressing. AGP and PCI devices come to mind. As noted earlier, only the first 256 addresses of the 1KB chunks support 16-bit addressing. What that really means is all 16-bit addressing devices are thus limited to only 256 bytes of contiguous I/O space!
When a 16-bit addressing device requires a larger contiguous I/O space, it will have to encroach on the 10-bit ISA I/O space. For example, if an AGP card requires 8KB of contiguous I/O space, it will take up eight of the 1KB I/O chunks (which will comprise of eight 16-bit areas and eight 10-bit areas!). Because ISA devices are using ISA Aliasing to extend their I/O space, there’s now a high chance of I/O space conflicts between ISA devices and the AGP card. When that happens, the affected cards will most probably fail to work.
[adrotate banner=”5″]
There are two ways out of this mess. Obviously, you can limit the AGP card to a maximum of 256 bytes of contiguous I/O space. Of course, this is not an acceptable solution.
The second, and the preferred method, would be to throw away the restriction and provide the AGP card with all the contiguous I/O space it wants.
Here’s where the AGP ISA Aliasing BIOS feature comes in.
The default setting of Enabled forces the system controller to alias ISA addresses using address bits [15:10] – the last 6-bits. Only the first 10-bits (address bits 0 to 9) are used for decoding. This restricts all 16-bit addressing devices to a maximum contiguous I/O space of 256 bytes.
When disabled, the system controller will not perform any ISA aliasing and all 16 address lines can be used for I/O address space decoding. This gives 16-bit addressing devices access to the full 64KB I/O space.
It is recommended that you disable AGP ISA Aliasing for optimal AGP (and PCI) performance. It will also prevent your AGP or PCI cards from conflicting with your ISA cards. Enableit only if you have ISA devices that are conflicting with each other.
Support Tech ARP!
If you like our work, you can help support our work by visiting our sponsors, participate in the Tech ARP Forums, or even donate to our fund. Any help you can render is greatly appreciated!
