Can you try 2 < 8 gb cf cards to rule out the on track?

The only thing that comes to mind is that DIR is a built in command so DOS doesn't have to go looking for it.
MEM is a program, so DOS has to look for it, first in the directory you are in, then along your path.

MEM itself shouldn't be accessing you drives, but running it while on the second CF means DOS has to look there
first ... running from the HDD means DOS looks there first (not on the CF)

I can't think of a reason while DIR of a directory on the CF should be fast - obviously it has to access that directory...
Might have something to do with caching?...?

What I'd probably try next is copy a simple command (MEM would do) to a directory on th CF, and put that directory FIRST
in your path - see how fast it runs... also, this will make DOS look on the CF card first for any commad, see if they all get slow!

Hopefully you can characterize it enough more to get a clue what is actually happening!

Hi, how about using FASTOPEN command?
It's ancient, but still smaller than SmartDrive.
If memory serves, it will keep a "copy" of FAT in memory, so DIR is faster.

If you're willing to boot into Linux (eg Slackware 8.0 disc2) and poke at the drives in sequence like that, there may be some IDE errors logged to dmesg that give a hint as to what is wrong.

Pickle wrote on 2025-07-05, 02:18:

Can you try 2 < 8 gb cf cards to rule out the on track?

I was also kinda wondering about this. For the record, it is actually Western Digital DDO version 9.87.

Replacing the 8 GB CF with a larger, 16GB one I had results in no issues. I didn't have a smaller one to use.

That said, Fdisk shows the 16GB CF as having two non-DOS partitions. I don't remember what I have on there or how I was using it.

So I put the 8 GB CF back in the machine as I wasn't really using the 16GB one for anything - I was just switching back and forth from the HDD and the 512MB CF. I figured I would try that same operation with the 512MB now that the 8GB CF was back in the other slot.

Here is how the drive letters are paired:
Hard Drive - C:
8GB CF (2 GB part) - D:
512MB CF - E:
8GB CF (2 GB part) - F:
8GB CF (2 GB part) - G:
8GB CF (2 GB part) - H:

If I switch back and forth from C to E (the 512MB CF), everything seems fast as usual. I copied a directory of files from E: to C:, and all files copied in a few seconds.

But whenever I am performing an operation on C: and then on D: (8GB CF, 2 GB partition) or vice versa, it has that hang for a bit. I decided to try to start bouncing from C and F. Different drive letter, but same physical drive, of course. Same thing.

I kept typing random letters like "sdfsdf" and pressing enter on F:. It would hang each time. So then I thought I should clear the path environmental variable as it pointed to various places on the C: drive (ex: C:\windows\command).

After that, typing asldkjlsdfjlsdjk and pressing enter on F: would produce bad command or file name immediately. Only changing back to C: from an 8GB CF partition and attempting to execute an operation results in the delay. After the delay is over, drive C: is "good" for all operations. I can jump back to CF partitions and perform operations just fine with that path env cleared. Go back to C again... same story.

Each time I return to the C: drive to do something, it is like it has to wake up. (Not literally. For the record, I have power management set to Disabled)

DaveDDS wrote on 2025-07-05, 02:37:

The only thing that comes to mind is that DIR is a built in command so DOS doesn't have to go looking for it.
MEM is a program, so DOS has to look for it, first in the directory you are in, then along your path.

btw - I meant to say thanks for writing this, DaveDDS. It made me look at the big picture in terms of DOS rather than hardware configuration, and that is what led to my clearing of the path environmental variable to prevent commands from touching C: drive each time. Obviously this isn't a fix, but it does help isolate the issue to a degree.

Jo22 wrote on 2025-07-05, 04:55:

Hi, how about using FASTOPEN command?
It's ancient, but still smaller than SmartDrive.
If memory serves, it will keep a "copy" of FAT in memory, so DIR is faster.

While the larger HDD has always had a short delay at the end the first DIR execution after boot because it has to count up the free space, this is a momentary freeze before anything is shown. So you could type DIR or another command or just junk, the cursor drops down a line or two, a long delay (5-10 seconds?) occurs, and then the results appear.

jakethompson1 wrote on 2025-07-05, 05:33:

If you're willing to boot into Linux (eg Slackware 8.0 disc2) and poke at the drives in sequence like that, there may be some IDE errors logged to dmesg that give a hint as to what is wrong.

Hmm. I'd have to rig up the CD-ROM drive with this configuration. Not ruling that out as part of the process, of course. It seems like the DDO is perhaps the culprit rather than mobo controller (huge assumption on my part), but it isn't like DOS can tell me much.

OK. This is an issue that starts from the power button more or less.

Changing the slots the two CFs use (this is a dual-slot reader) may cause the system to not post (as in black screen and no beeps). I can get it to be upset about just about anything, IDE-wise.

I can get it to auto detect the two CFs on the secondary but throw a Primary Master Fail error.

Sometimes it takes pulling the Secondary IDE and going to Primary only just to get the system to come back.
Change an IDE cable here or there... and then I can get it back to booting with all three drives (and having the hanging bug).

It is almost like there is a "conflict" between Primary and Secondary at times.

It doesn't matter if I do manual entry of geometry for all the drives or slide an auto detect in for the CF drives. The board will get really upset about it.

So this is likely a 430FX + 82371FB + BIOS thing

CkRtech wrote on 2025-07-06, 06:10:

So this is likely a 430FX + 82371FB + BIOS thing

I feel like the CF controllers & firmware are likely part of the mix too.

The 430FX + 82371FB combo should want to try MWDMA2 yes? Most CF’s report that they can do MWDMA but not all CF’s successfully implemented MWDMA modes as well as they do UDMA modes. Curiously, my experience is that CF’s with firmware newer than 2013 seems to be more likely to have issues with MWDMA than older firmware. Perhaps some firmware developers stopped caring as much about the old modes at that point. Or maybe there was a significant change in the flash controllers at that time and the firmware date changes were coincidental. Or maybe I am jumping to conclusions from a small sample size.

You could try forcing PIO modes in the BIOS or you could get a PCI controller that supports UDMA and see if either of those things helps.

douglar wrote on 2025-07-06, 13:44:

I feel like the CF controllers & firmware are likely part of the mix too. […]
Show full quote

CkRtech wrote on 2025-07-06, 06:10:

So this is likely a 430FX + 82371FB + BIOS thing

I feel like the CF controllers & firmware are likely part of the mix too.

The 430FX + 82371FB combo should want to try MWDMA2 yes? Most CF’s report that they can do MWDMA but not all CF’s successfully implemented MWDMA modes as well as they do UDMA modes. Curiously, my experience is that CF’s with firmware newer than 2013 seems to be more likely to have issues with MWDMA than older firmware. Perhaps some firmware developers stopped caring as much about the old modes at that point. Or maybe there was a significant change in the flash controllers at that time and the firmware date changes were coincidental. Or maybe I am jumping to conclusions from a small sample size.

You could try forcing PIO modes in the BIOS or you could get a PCI controller that supports UDMA and see if either of those things helps.

I knocked the suspect CF down to PIO 2 and then PIO 0 with the same results. I then knocked all drives down to PIO 0, and the delay is still there.

I want to say that even the 512MB card that seems to be working just fine nowadays had some issues with the previous reader I paired with this motherboard back in 2010. Cold boot would hang during POST after it detected the card. One press of reset would make it all work. I ended up ditching it just because I thought it was annoying. So this motherboard/chipset combo has always been picky with CF in one way or another.

I'm leaning toward moving to a UDMA controller card solution and get out of my mobo's BIOS for this particular system.

Follow-up -

I acquired a Promise UltraATA100 TX2.

It can read the 8GB CF just fine but does not detect the 512MB. How interesting.

It also detects the physical HDD, but that drive is using the Dynamic Drive Overlay. DDO disables itself when drive is connected to the Promise controller. So it will be a bit of a project to undo the DDO and migrate the HDD to the controller.

At the moment -
1: HDD connected to Primary IDE on motherboard. Mobo Secondary IDE disabled.
2: CF adapter connected to Promise controller Secondary IDE. Now using the original 8GB (Master) + a second 16GB (Slave) card I also had.

System boots to the HDD using DDO and can access the CF partitions without slowdown. Did an HDD to CF multi-directory copy, and things moved at lightspeed. Not even using an 80 wire cable on CF adapter yet.

I assume the Promise controller must know what to do with the Primary IDE still enabled on the motherboard. Sure is slow detecting the CF drives. Perhaps because of the would-be Primary IDE conflict.

Energy star screen of the BIOS takes a solid few seconds before finally starting to fade out and fire-up the Promise BIOS and its slow drive detection. Sadly, this means boots and reboots take an eternity now.

At least I am in a state where I can backup files quickly, clear off the HDD, and move away from DDO. I am curious as to whether that DDO was causing the delay problems.

Glad the performance feels better

The promise detection takes a second or two, but it shouldn't be that long.

Do you know what DDO was installed?

I am not sure exactly where this came from, tbh. Perhaps it was an included DDO with a version of data lifeguard.

CkRtech wrote on 2025-07-10, 00:18:

I am not sure exactly where this came from, tbh. Perhaps it was an included DDO with a version of data lifeguard.

OK. You have an OEM version of OnTrack. Disks configured with an Ontrack version < 10.0 usually appear to have a proprietary partition type when you run fdisk without the overlay loaded. It's the main reason why drive overlay software got a bad name, imho.

I have now migrated off the motherboard IDE controller and the DDO. I am no longer experiencing delays during operations when moving back and forth between the compact flash cards and the HDD. I suppose the original problem led to the fortune of speeding up this Pentium MMX system as all drives are now running off the newly acquired Promise Ultra100 TX2 card.

A note on DDO migration: Even though I seemed to have an OEM version, I ended up using EZ Drive 9.09W from a bootable floppy to remove it. This did require repartitioning and reformatting the drive after DDO removal.

If anyone happens upon this and has a random DDO, EZ Drive 9.09W did not recognize that I had a version present and active for the drive. What I did was tell it to install EZ-Drive (probably overwriting the WD OEM version), immediately disabled it in the options menu, rebooted, entered EZ once again, and then removed EZ-Drive. This got the job done as the computer reported "no operating system" instead of loading an overlay when attempting to boot from the drive

Another benefit of having DDO removed was that drive detection with the Promise controller is a LOT faster now.

Copying the existing Windows 98SE installation to the CF and back to the newly formatted drive was easy with LFN tools.

Congrats! Removing an unwanted DDO can be a real challenge. Usually fdisk /mbr will clear them off but sometimes it doesn’t and I’m not sure why.

douglar wrote on 2025-07-12, 13:21:

Congrats! Removing an unwanted DDO can be a real challenge. Usually fdisk /mbr will clear them off but sometimes it doesn’t and I’m not sure why.

If I were implementing a DDO, it would make a lot of sense to have both a "real MBR" that invokes the DDO at boot and a "pseudo-MBR" with the partition table in it, and redirect MBR writes to the latter, to prevent the DDO from being removed accidentally. Remember that Windows 95 setup (IIRC) will overwrite the MBR without asking. It's interesting how similar a DDO and boot sector virus are in implementation.