• Please review our updated Terms and Rules here

CompatiCard IV causes A20 issue in a Pentium-MMX 233 system..

geneb

geneb

Veteran Member
Joined
Aug 19, 2003
Messages
525
Location
Graham, WA USA
I'm building an imaging workstation around a Pentium-MMX motherboard and the addition of a CompatiCard IV has got it throwing an error when himem.sys kicks off:

ERROR: Unable to control A20 line.
XMS Driver not installed.

I previously had a different 8 bit, 4 drive controller in the system, but it wouldn't pass the single density tests that Dave Dunfield's TESTFDC perform.

The CompatiCard IV is configured with the defaults shown in the "quick start" section of the manual.

There's no explict A20 control options in the bios configuration (Award BIOS v4.51PG).

Without the card, there's no issues.

Help! :)

thanks.

g.
 
The CCIV will run in an 8088 system, so it's not A20 per se. There's something very fishy going on with your card. What about the on-board FDC? Did you disable it, or do you have the CCIV configured for alternate DMA/Port/IRQ?
 
Onboard FDC is disabled and the CCIV is configured using the "default" settings.
The BIOS ROM address is set via SW1 (1-off, 2-on, 3-off - CE00)
DMA channel 2
IRQ 6
It's configured to /not/ "auto boot".

The card itself operates without issue. I've got three drives connected to it and it recognizes and can access them all.

g.
 
If your onboard BIOS allows for specification of drive types with the onboard FDC set to "disabled", try that, while disabling the CC IV BIOS ROM. That is, try the CCIV as a "naked" controller. There often are nasty interactions between the "native" BIOS/Chipset and the add-on stuff. You could also keep the onboard BIOS and drives and configure the CC as a secondary (there are DOS drivers for that).
 
I've got the driver disk for the card, so that's not a problem. I'll try disabling the ROM and see how that goes. Thanks.

g.
 
The ROM disable didn't have any effect. however, adding "/M:2" to the HIMEM.SYS command line did fix the issue.

g.
 
Doesn't make much sense. Why would that card cause HIMEM.SYS to no longer detect the system type correctly? And why would "2" work, which is for the IBM PS/2 series of computers, which his 233 MMX certainly isn't?
 
We don't know what the original installation detected. Perhaps Gene can re-run his example without the /M switch but include the /VERBOSE switch to see what the original setup thought the machine type was.

My (probably incomplete) understanding of what the function of the /M switch was largely to indicate to HIMEM what the mechanism for A20 line manipulation was. That's not a function of the CPU type, but of the chipset being used.

I also seem to recall that going into the BIOS setup and disabling A20 functionality was another way around a host of HIMEM.SYS problems.
 
HIMEM.SYS in PS/2 mode skips the use of keyboard controller to set the A20 line which can be done with some non-PS/2 hardware. I have no idea what is causing the card HIMEM interaction.
 
I seem to recall that back in the day, if you had problems with extended memory, one of the bits of advice was "try /M:n, where n=1 to 16" or some such.

It really seems strange that by the time of the P1 we were still wrestling with XT memory space compatibility. The gripe by an Intel applications engineer back around 1990 was "Here we give you a 32 bit CPU capable of virtual memory and what do you do? You run real-mode DOS on it".

Was there ever a PC that immediately switched (via BIOS) to protected mode before loading the OS?
 
You must log in or register to reply here.
Back
Top