• Please review our updated Terms and Rules here

Rev. A Microsolutions CompatiCard I Errors - Not working or just not compatible?

O

olePigeon

Veteran Member
Joined
Aug 14, 2009
Messages
1,266
Location
Silicon Valley
I have a Revision A Microsolutions CompatiCard I card, but I can't seem to get it to work. However, I don't have an older computer to know if it's a compatibility issue, or if my card is broken.

When used as a secondary controller, I always get a "DIVIDE OVERFLOW" when I attempt to access the floppy drive, forcing me to restart. I then get a "FLOPPY CONTROLLER FAILURE" on reboot.

If I use it as a primary controller, I always get "DRIVE NOT READY" error, and nothing happens.

I'm using an Intel DX4-100 Overdrive with DOS 6.22 and 32MBs of memory. I pulled all other cards out when testing, just incase it's a hardware conflict. I also tried it as secondary and tertiary controller as suggested by the manual, but no go.

Looks like this card was originally intended for 286 and 386 machines, neither of which I have to test if it's a compatibility issue.

Any suggestions?

Thanks,

oP
 
The CC I and CC II (same animal, just difference between 2 and 4 drive capability) require their own drivers, as they're not strictly compatible with legacy PC FDC conventions. The Sydex utilities have a special flag in the configuration to signify CC I and II. Don't know if any other utilities do.

Shorter: They're very different animals than the CC IV.
 
I've recently gone through this same exercise - trying to install a CompatiCard I in a PC with a first generation Pentium.

The CompatiCard I does not have an on-board ROM BIOS, therefore you need to have:

- the CompatiCard driver CCDRIVER.SYS on your boot drive. Make sure you are using CCDRIVER.SYS, and not the CC4DRV.SYS driver intended for the CompatiCard IV

- the CONFIG.SYS file contains the line DEVICE=CCDRIVER.SYS followed by the configuration parameters describing (a) the CompatiCard hardware address (primary, secondary, ... controller) and the connector your drives are attached to on the CompatiCard, and (b)the type of drive(s) connected to the CompatiCard. Both parameters must be included correctly, else you will get the "drive not ready" error.

If you want to use the CompatiCard as the primary drive controller, your motherboard BIOS configuration must allow for its built-in controller to be completely disabled. If that is not possible, the CompatiCard will need to be configured as a secondary drive controller. The CCDRIVER.SYS driver is always required, irrespective of whether the CompatiCard is the primary controller (motherboard controller disabled) or the secondary controller.

Make sure you have the drives cabled properly to the CompatiCard, and you don't have the cable connected backwards on the card or the drives. If you have only one drive connected, make sure it is on the connector at the end of the cable (after the twist).

Which leads me to the biggest problem, the "DIVIDE OVERFLOW" error. I have used the CompatiCard on an original IBMPC, where the card and its CCDRIVER.SYS driver work perfectly fine. However, when I installed it on my "newer" PC the CCDRIVER.SYS driver would generate a "DIVIDE OVERFLOW" error and fails to load - and it sounds like you are encountering the same problem on your PC. I don't think the error is specific to the DOS version, since I was using MSDOS 6.22 on both PCs. In the end I gave up trying. However, my main purpose for installing the Compaticard was to use ImageDisk, Uniform, and 22Disk, and I no longer use the PC's internal drives to access MSDOS floppy disks. Fortunately all three of those applications bypass the BIOS (ie don't require CCDRIVER.SYS to be loaded) and allow you to specify within the application (a) whether the CompatiCard has been installed as the primary or secondary controller and (b) the type of floppy drive(s) attached to the CompatiCard.

Note: These comments do not apply to a CompatiCard IV. The CC4DRV.SYS driver for that card suffers from the same "divide error" but fortunately this can be avoided by using the CompatiCard IV's built-in ROM BIOS.
 
Last edited:
Yep, I followed the manual pretty closely. It says it only needs the driver when used as a secondary (or more) controller. I tried it both ways. My card is complete-in-box, so I have everything. I set the jumpers as secondary controller. I installed the software. I set CONFIG.SYS correctly (I think) according to the manual. I had my 360k drive on the card edge connector on JP 1/2 using a single-device non-twisted cable, and my Floppy Emulator on the JP 3/4 using a single-device non-twisted cable. In CONFIG.SYS I have the device driver set, with the correct codes for each floppy to indicate type, location, and step.

When I run the ccdrives app, it detects and shows the floppy drives correctly. However, when I try to access them, I get the "DIVIDE OVERFLOW" error. :(

I tried it as primary controller as well, and it won't even boot as indicated above.

My main purpose is similar to yours, @hmb. I have 4 floppy drives: 360k, 1.2MB, 1.4MB, and a flashed/modded Gotek.

I went through my BIOS options. My motherboard does not have floppy connectors, so any controller cards installed would be the primary controller. So no option to disable.
 
SUCCESS!

I decided to set my BIOS settings to default, and it's working now! I hope it's not a conflict with my extended memory. I need it to play Darklands. :eek:

Plus, my computer's Turbo isn't working, so it's only running at 1/2 speed now.
 
Are you using the CC I drivers?

If not, have you tried reading/writing disks of both densities?

I've owned both CCI and CC II boards, but never used them as primaries.
 
Yeah, it's currently being used a secondary controller card. Since my primary one is a combo hard disk / floppy controller, I can't really use it as a primary unless I get a stand-alone hard disk controller.

So I've made progress. Since it works with default BIOS settings, I've been turning on the features one by one. I've narrowed it down (so far) to "Internal Cache Memory." With "Internal Cache Memory" enabled, I get the "DIVIDE OVERFLOW" error. When I disable it, it works fine. :)

My motherboard has the cache memory maxed out. So I'm going to go ahead and test the other features for incompatibilities, and then I'm going to go back and see if it's actually the Cache Memory feature, or if I have a bad DRAM chip in my cache. I hope it's a bad chip and not the cache feature itself. The cache speeds up things significantly.
 
olePigeon said:
Yeah, it's currently being used a secondary controller card. Since my primary one is a combo hard disk / floppy controller, I can't really use it as a primary unless I get a stand-alone hard disk controller.

So I've made progress. Since it works with default BIOS settings, I've been turning on the features one by one. I've narrowed it down (so far) to "Internal Cache Memory." With "Internal Cache Memory" enabled, I get the "DIVIDE OVERFLOW" error. When I disable it, it works fine. :)

My motherboard has the cache memory maxed out. So I'm going to go ahead and test the other features for incompatibilities, and then I'm going to go back and see if it's actually the Cache Memory feature, or if I have a bad DRAM chip in my cache. I hope it's a bad chip and not the cache feature itself. The cache speeds up things significantly.
Click to expand...

As I mentioned above I get the same "Divide Overflow Error" as you do, with my mid-90s era AST Bravo. Therefore, my bet is that the problem is related to the cache memory feature on "newer" PCs. It is unlikely both of us have a hardware problem with the cache memory on our PCs.
 
For whatever it's worth, calling the interrupt a "Divide by zero" is a bit of a misnomer at times. What's really happening is that the DBZ interrupt vector is at 0000:0000, so the interrupt can reflect a myriad of hardware or software issues not related to division. It's possible to add a small TSR that grabs that vector and reports the contents of the registers (and interrupt information on the stack).
 
Chuck(G) said:
For whatever it's worth, calling the interrupt a "Divide by zero" is a bit of a misnomer at times. What's really happening is that the DBZ interrupt vector is at 0000:0000, so the interrupt can reflect a myriad of hardware or software issues not related to division. It's possible to add a small TSR that grabs that vector and reports the contents of the registers (and interrupt information on the stack).
Click to expand...

That would be beyond my capabilities, but I wouldn't mind lending the card out if someone could make a patch for the driver. It seems like it would benefit quite a few people.

hmb said:
As I mentioned above I get the same "Divide Overflow Error" as you do, with my mid-90s era AST Bravo. Therefore, my bet is that the problem is related to the cache memory feature on "newer" PCs. It is unlikely both of us have a hardware problem with the cache memory on our PCs.
Click to expand...

Have you tried disabling your Internal Cache and see if it fixes it? Assuming the cache can be disabled.
 
olePigeon said:
Have you tried disabling your Internal Cache and see if it fixes it? Assuming the cache can be disabled.
Click to expand...

That's the first thing I checked when I saw your message suggesting a "partial fix" for the problem. Unfortunately, there is no system configuration option on my AST Bravo to disable the motherboard cache memory.

Creating a patch to the CompatiCard 1 driver is is also well beyond my capabilities :(
 
Shucks.

Well, when I disable Internal Cache Memory, my machine slows to a crawl, even with a DX4-100. I didn't realize how much of a difference it makes.

External Cache Memory makes it faster, but not nearly as fast. However, at least I know the issue. So it's not a terrible inconvenience to disable the cache memory before imaging 360k disks or installing from my Gotek.

I'm gonna go post over at Vogons. Maybe someone there has run into this issue and found a fix. I tried looking on Google, and I can't find anything even remotely related except for a CompatiCard IV being incompatible with version 4.0 of SMRTDRV, and to disable caching for the floppy drives.

Out of curiosity, I disabled SMRTDRV, but it didn't make any difference for my CompatiCard I. It's definitely the BIOS cache option.
 
It was not uncommon practice at the time to use CPU loops for timing delays. The D765 controller in the CC I/II definitely requires delays between certain operations. Fast hardware renders these CPU loops worthless. There are better ways to do short delays.
 
I think my best option would be to trade it for a card that's compatible with faster computers. I think there are even new homebrew cards on the market now, but there is something to be said about sticking with vintage tech. However, I already have a Gotek installed, so, it'd be a bit hypocritical. :p
 
You mentioned you also had a combo hard drive and floppy controller card installed - what make/model is it?
 
hmb said:
You mentioned you also had a combo hard drive and floppy controller card installed - what make/model is it?
Click to expand...

I have no idea. There don't seem to be any marks on it. There's a TS (or ST?) with a circle around it, only logo I can find. And it says "KE P00-F040-000" on the front. Other side doesn't say anything.

I did a search for the "KE P00-F040-000," which comes up with several different VLB cards, but none of which look like mine.
 
You must log in or register to reply here.
Back
Top