I only have an idea 😀

A fixed disk is an IDE hard disk in this case, not a floppy drive.

You are right in that fixed disk 0 is the working hard disk.

Somehow it has a primary slave configured too, which it does not seem to find.

Perhaps clearing cmos confoguration data or reloading bios defaults might clear that.

Sounds to me like you need to replace the CMOS battery inside the machine (assuming there is one).

8bitbubsy wrote on 2025-03-12, 11:38:

Sounds to me like you need to replace the CMOS battery inside the machine (assuming there is one).

Most BIOS will issue an error if the CMOS is corrupted (checksum fails usually = bad battery)...
But I don't see anything like that. (still worth trying if reset doesn't work)

I agree that it seems to think there is a slave HD. Normally you would see this in the system
configuration ... but that fact that it shows "INT HD" suggests to me that this BIOS has been
adjusted specifically for a laptop, and might be doing the user a favor by not showing information
about a slave if there "would never be one" or "the slave caddy is not detected"

Restoring BIOS defaults would be the first thing I'd try!

Hm yeah, maybe it isn't related to the CMOS battery after all. It probably needs replacing anyway!
I also agree that resetting the CMOS/BIOS settings is worth trying. If you can't do it from the BIOS setup screen itself, you could maybe try different CMOS resetting tools for DOS.

This is interesting. I'll need to take a closer look at it this evening. I'm currently using a CR2023 battery with a Schottky diode as the CMOS battery, but I suspect the original was actually a 3.7V battery. I'll use my lab bench power supply as a stand-in for the CMOS battery so I can simulate a 3.7V battery, and I'll report back this evening.

Resetting the BIOS to its default settings didn't help—I tried it several times. As I mentioned, I also tried a second BIOS chip.

Another thing I noticed is that in 'fdisk,' there's an option under menu item 5 to switch to a second hard drive (if one were present). However, when I try to switch, it says that the drive wasn't found. I've never seen that before, and I'll post a picture of it later.

The notebook has several DIP switches located behind a service panel. Maybe one of them is set incorrectly, causing the notebook to think there's a second hard drive. That might explain why I'm seeing the same behavior even after resetting the BIOS settings and replacing the entire BIOS chip.

Here you can see the switches (some are behind another cover):

(Of course, I don’t have any documentation for these switches… 😒)

Ah, the pleasure of mystery switches!

If various combinations of them dont make a difference, and resetting bios in various different ways dont make a difference, mayyybe a bit in the cmos ram could be bad? Quite a long shot, not as if it is escd flash that we have some cases on here that went bad.

My Test Results:

The DIP switches did not change anything except for the FSB and the inversion of the pixels:

A fully charged CMOS battery was not the solution either. I also had a new 3.6V Ni-MH battery (with a modest 700mAh), but even this CMOS battery made no difference.

Still the same issue:

It is highly unlikely that a bit in the CMOS chip has flipped, as I get the exact same error when using the chip from the other notebook.

(In the meantime, I switched to a Seagate ST9655AG with a 524 MB HDD, but of course, that made no difference either.)

User5518 wrote on 2025-03-12, 20:06:

...It is highly unlikely that a bit in the CMOS chip has flipped, as I get the exact same error when using the chip from the other notebook.

I agree, unlikely - and a bad bit would be caught by the CMOS checksum.

But to confirm:
Change some odd-but-identifiable setting in BIOS. (depends on your
BIOS) something that won't kill BIOS entry, but also isn't normally set.

Power off/on - verify that your "odd" setting is still there.
(to confirm that you didn't pick something BIOS would reset)

With the CMOS battery in place, verify there is voltage on the CMOS ram chip.
(while the system is powered off - this is mainly to confirm that you know the
right pins to test)

Then remove the battery - confirm that the CMOS is NOT getting power
(due to capacitance in the circuit it may take a few seconds to drop - You can
help it with a 10k or so resistor: VCC->Gnd. Leave the CMOS
unpowered for 10 mins - this should be long enough for it's internal
capacitance to discharge - reconnect battery and power up.

See if you get a "configuration bad" error message of some sort from BIOS.

If so, your CMOS is good.

If not, go into BIOS and see if you "odd" setting is still set.
- if it is, then maybe you have the wrong CMOS RAM chip, or there
is some other power source for it. (Repeat above but let sit unpowered for
a couple days)

- If it is not, looks like your BIOS detects the checksum fail and
resets to defaut without telling you!

The CMOS configuration of the primary two hard drives is quite universal, as many vendors just copied the IBM layout of CMOS memory. Try some generic AT setup utility like GSETUP and check whether it reports a configured slave drive. If yes, try setting the slave drive type to "not installed" with that tool and hope that the mainboard BIOS picks up the change without resetting the whole BIOS settings.

The BIOS is behaving as expected:

I set the HDD to "manual" and entered "0" for each field. Additionally, I assigned a drive to the external FDD port, even though no such drive exists:

Both settings were displayed as expected after a short power-off:

Here is the FDISK view with the 5th option that I mentioned earlier:

When I try to create a partition on this "second" harddrive, FDISK freezes.

@mkarcher I will try this and will report back, thank you.

Was this HDD working properly in this machine before, or did you add it yourself? In the latter case did you set the master/slave jumpers properly? Some older IDE drives have a separate master and master with slave settings, and wrong setting can lead to bad PDIAG behaviour, which in turn can sometimes fool the BIOS/HDC that there is a second drive connected. So make sure you got the jumpers right.

@mkarcher THANK YOU!!!

gsetup solved my issue, it is working!

I was able to disable the second HDD using this handy tool:

My BIOS accepted the change, so I no longer receive that annoying message. Additionally, FDISK no longer detects the "second" HDD. 😀

Now, I just need to 3D-print a small cover for this, and then the notebook will be complete!

Deunan wrote on 2025-03-12, 21:45:

Was this HDD working properly in this machine before, or did you add it yourself? In the latter case did you set the master/slave jumpers properly? Some older IDE drives have a separate master and master with slave settings, and wrong setting can lead to bad PDIAG behaviour, which in turn can sometimes fool the BIOS/HDC that there is a second drive connected. So make sure you got the jumpers right.

I bought the notebook second-hand a few years ago, and it had been sitting unused in the closet for quite some time. I'm not sure if this issue has always existed. I only know that the problem did not occur with the black notebook when it was still working. Additionally, the HDD from the black notebook shows the same error.

I don't really have a way to set a jumper. But as I mentioned before, with GSETUP, I was able to disable the "second" hard drive, which the system had mistakenly detected. As long as my BIOS battery has power, the GSETUP setting will remain in place, so I won’t see this message—at least until the BIOS battery eventually runs out. With 700mAh, I hope that will take a while, even if I don’t use the notebook for an extended period.

I wonder how it got there. Garbage and corruption from being powered down for long? Does this bios even checksum the cmos memory? Or only some part of it? I doubt it ever had a 6 gigabyte hard drive installed.

Loading bios defaults probably only loads and overwrites chipset settings, it looks as if it does not touch the configured drives.

It seems as if this bios setup program has no way of setting those fields, but being a modified bios of something prior, it actually still has all the slave drive stuff still built in, just hidden from sight.

st31276a wrote on 2025-03-14, 06:40:

I wonder how it got there. Garbage and corruption from being powered down for long? Does this bios even checksum the cmos memory? ...

Most do .. The method I outlined a few posts back (remove battery - insure chip voltage go to 0)
would confirm that it does ... but since it's been solved now - I don't suggest messing with it!