ux-3 wrote on 2024-05-25, 19:23:

I have had a similar problem on one controller and could solve it by changing master and slave on the IDE port.

You mean, the cable connector?

popcalent wrote on 2024-05-25, 20:26:

ux-3 wrote on 2024-05-25, 19:23:

I have had a similar problem on one controller and could solve it by changing master and slave on the IDE port.

You mean, the cable connector?

In my case, I changed the jumpering on the CF card adapter and the DVD-ROM. Made the DVD master, the card slave and voilá...

popcalent wrote on 2024-05-25, 10:53:

I even booted again from floppy and did a "fdisk /mbr" on C:, but still, it doesn't work...

I know, This tip is often being recommended.
Though FDISK /MBR as an universal cure is being a bit overrated, I think. It's not reliable, I think. It also doesn't work as expected.

There's a difference between MS-DOS 6.22 and 7.x behavior, among other things.

See https://thestarman.pcministry.com/asm/mbr/FDISK.htm

The MBR switch won't re-write the boot record under all circumstances, for example.

Clearing Track 0 is a safer way of making sure that the MBR and PBR are being gone.

If Track Zero is cleared, FDISK and other setup programs will think the HDD is fresh from factory and are being forced to start over from scratch.

https://en.wikipedia.org/wiki/Track0

The German S0Kill utility does this, for example (Spur 0 Kill=Track 0 Kill).

DD on Linux could be used, too, I guess, but *nix tools are deadly often. No safety measures built-in.

GParted or the Gnome Disk Utility can safely erase an existing partition, by contrast.

Good luck. 🙂🤞

ux-3 wrote:

In my case, I changed the jumpering on the CF card adapter and the DVD-ROM. Made the DVD master, the card slave and voilá...

I only have one IDE device which is the CF adapter. It's set to master through a jumper. Not sure if changing the jumper makes that much of a difference when there's only one IDE device. If it keeps annoying me I'll end up buying an XTIDE card...

Have you got a network card that supports a boot rom? You may stick a rom in thats loaded with xt-ide and set the hard disk to none in your bios. Xt-ide should be able to auto detect the dom/cf on your regular ide port. In fact, I've used it to boot windows 98 from a 2GB drive on a 486 that has the 504MB limit in the bios... From a sound card ide port (thirtiary ide reported).

^I second this. From. My experience, it's not the electronics but the software that causes trouble.
XTIDE Universal BIOS (aka XUB) often saved my day in the past.
It's just important to either run the official DOS utility (IDECFG or XTIDECFG) or use a pre-configured image (set to auto-detection).
My old, personal ones for testing purposes can be found here.

Edit: When using XUB, it might be necessary to buy a new CF card, not sure.
LBA addressing usually is being used on media past 512MB.

So I'm not sure if XUB supports small cards that use CHS typical values (max 1024 cyl, 16 hds, 63 sec). Might be that XUB expects to see bigger values, rather.

Personally, I once had trouble using a smaller CF card (below 512MB).
Plugging in a 2GB CF card and then partitioning/formatting it via MS-DOS 6.22 boot floppy did work when XUB was loaded.
The CF had also booted afterwards into MS-DOS.

I have always been unlucky with these modern solutions for HDD replacement. I know about DDO, but I want the system to work natively without them.
What I found so far is that every piece in the puzzle can be a failing point: BIOS, CF/SD Card itself, adapter, anything else connected on the same IDE channel.

I have a bunch of adapters and CF/SD cards ranging from 256MB to 128GB, and a number of adapters: CF2IDE, SD2IDE, SD2CF all of different brands and manufacturers.
For every mobo I newely get, I start with with an old skool HDD of 128MB, validating that it boots to DOS and all. Then the combinatorial experimentation starts... Surprisingly, sometimes a smaller size SD card will fail and a larger one succeeds. It's crazy. Of course each storage unit is pre-identified with correct CHS values.

Bottom line: grab a bunch of options and try them all until you get lucky...

Good luck!

I ended up ordering an XTIDE card. Right now the CF card doesn't boot all of the time and I have to keep resetting until it decides to boot. It's pretty annoying. Also, I couldn't use the DOM. Hopefully the XTIDE will solve these issues.

popcalent wrote on 2024-05-26, 06:00:

I ended up ordering an XTIDE card. Right now the CF card doesn't boot all of the time and I have to keep resetting until it decides to boot. It's pretty annoying. Also, I couldn't use the DOM. Hopefully the XTIDE will solve these issues.

That would be a fine solution 😀
If the bios file in that card is set to auto detect, it should also detect your existing ide port.
In that case you still may want to connect the dom/cf to the 16 bit port, rather than the card (which translates ide to an 8 bit signal for compatibility reasons). The translation makes the xt-ide card rather slow compared to the 16 bit native port.
Luckily the access time to a dom or cf is next to nothing compared to a regular hdd. So the 8bit translation won't set you all the way to zero.

waterbeesje wrote on 2024-05-26, 16:48:

If the bios file in that card is set to auto detect, it should also detect your existing ide port.
In that case you still may want to connect the dom/cf to the 16 bit port, rather than the card (which translates ide to an 8 bit signal for compatibility reasons).

So, in the computer BIOS, I leave HDD1 and HDD2 to none, and I connect the CF/DOM to my current HDD controller card (not the XTIDE). Then, I don't connect anything to the XTIDE. Then, when booting the ROM in the XTIDE will find the DOM/CF that is/are connected to the old HDD controller, correct?

Yes. The card performs its own autodetection on startup with its ROM routine, assuming that ROM is properly configured, as others pointed out prior.

wierd_w wrote on 2024-05-26, 17:04:

Yes. The card performs its own autodetection on startup with its ROM routine, assuming that ROM is properly configured, as others pointed out prior.

I ordered it from texElec (https://texelec.com/product/isa-compactflash-adapter/). I imagine it will be properly configured...

If the BIOS (with the right parameters) and a simple program like whatIDE are having intermittent troubles using the IDE interface, I don't see how XTIDE is going to have better luck.
It sounds like you're going to be downgrading to 8-bit IDE just to workaround a bad I/O card.

jmarsh wrote on 2024-05-27, 01:01:

If the BIOS (with the right parameters) and a simple program like whatIDE are having intermittent troubles using the IDE interface, I don't see how XTIDE is going to have better luck.
It sounds like you're going to be downgrading to 8-bit IDE just to workaround a bad I/O card.

If I connect the CF to the IDE connector on the 16-bit card, but use the XTIDE to detect the card, wouldn't it work at a 16-bit speed?