Bancho wrote on 2021-04-24, 16:05:

What would cause this behaviour? If it can boot directly.. that would suggest the BIOS is correct? After installing DOS (from floppies on the same drive) it point blank refuses. As i say, this was a brand new DOS install. No changes to anything.

It's a wild guess, but you might have a virus (or a disk overlay) installed in your MBR of the hard drive. When you boot DOS from floppy, that code does not get loaded, but when you boot from your hard drive, that code get executed. You might want to try running "FDISK /MBR" after booting from the DOS installation floppy. This should clean any unwanted code from the MBR of your (first) hard drive.

After FDISK /MBR do nothing else but turn your computer off. No Ctrl-Alt-Delete or anything. Just power off and then try to boot from your hard disk. I recommend to write protect that floppy.

Bancho wrote on 2021-04-24, 16:05:

maxtherabbit wrote on 2021-04-24, 15:35:

Well in that case I suggest you add a line reading:

DRIVPARM=/D:0 /F:7

To your config.sys. This will force DOS to treat the drive as a 1.44MB regardless of what it thinks the BIOS equipment list says.

maxtherabbit.. your suggestion worked! I've never had to do this before on a system, floppy drives have normally worked without question! I'm now able to read from the disk!

What would cause this behaviour? If it can boot directly.. that would suggest the BIOS is correct? After installing DOS (from floppies on the same drive) it point blank refuses. As i say, this was a brand new DOS install. No changes to anything.

I honestly have no idea. I held off on suggesting it until you exhausted every other option because, as you say, you should normally never have to do this. I have zero familiarity with EISA systems so my gut feeling would be it's something to do with the EISA platform, but I have no real evidence to substantiate that

I just encountered the same behaviour described in this thread on an ASUS PCI/I-486SP3G board with the most recent beta BIOS (0306): The floppy drive is set as 1.44MB in the CMOS setup, but DOS 6.22 booted from a hard disk (in this case, a 128MB DOM) insists of the drive being 360KB. There is no boot sector virus or disk overlay software active, or it is hiding extremely well. I'm going to troubleshoot the real cause right now, but as this board is not an EISA board, I guess pecularities of "the EISA platform" are ruled out.

OK, so this one is evil.

The BIOS provides a function "get floppy drive type" (INT 13, AH=8). This function is called by the MS-DOS initialization code to determine what kind of floppy drives are installed. This function retrieves the floppy drive settings from the CMOS RAM (on EISA systems: The primary CMOS RAM, not the EISA extended configuration storage). At least on certain Award BIOSes, this function is "gated" by the "CMOS power lost" bit, and returns invalid values (0 Tracks, 0 sectors/track, 0 heads) if the CMOS battery is flat. Dallas chips with integrated battery provide the status of the internal battery in their "valid RAM and time (VRT)" bit (bit 7 of control register D), no matter whether they currently get proper supply from the mainboard +5V. If this bit is found indicating "internal battery flat" by the POST, it sets the "CMOS power lost" bit (bit 7 of CMOS RAM, index 0E). The BIOS also prints the message "CMOS battery failed" error message, but doesn't wait for any key and clears the screen directly afterwards, so you don't get to see it.

If I enter a second hard drive (D:) in the BIOS setup without connecting a secondary drive to the IDE port, I get to see both "Hard disk(s) fail (20)" and "CMOS battery failed". This proves my point that the message is indeed printed, and you can see it if the BIOS waits for F1 due to a different error.

I think it is quite unfortunate, that the BIOS mostly works with a flat CMOS battery, but stubbornly refuses to report valid drive types to DOS (or any other caller of INT13), and doesn't indicate this condition in any user-visible way.

Thanks for the work and the explanation about what's happening. And it would be better if the BIOS could print a message and wait for a key press like other errors. I suppose in theory that if the battery has failed the BIOS ought to make sure it passes at least some sane defaults to the OS, rather than whatever random data would be in the CMOS. But just passing zeros for drive settings doesn't sound like a good default. Better to force entering CMOS setup maybe?

Do you know how the computer manages to boot from the floppy correctly if the settings are wrong (Bancho could boot from a DOS 6.22 floppy and then read disks fine)? Does the BIOS "get floppy drive type" provide correct settings if it's been able to start booting from one?

Also, with the Dallas RTCs, do you know if the VRT get reset if they're modded to fit a new CR2032 on their back?

mkarcher wrote on 2021-05-30, 15:33:

OK, so this one is evil. […]
Show full quote

OK, so this one is evil.

The BIOS provides a function "get floppy drive type" (INT 13, AH=8). This function is called by the MS-DOS initialization code to determine what kind of floppy drives are installed. This function retrieves the floppy drive settings from the CMOS RAM (on EISA systems: The primary CMOS RAM, not the EISA extended configuration storage). At least on certain Award BIOSes, this function is "gated" by the "CMOS power lost" bit, and returns invalid values (0 Tracks, 0 sectors/track, 0 heads) if the CMOS battery is flat. Dallas chips with integrated battery provide the status of the internal battery in their "valid RAM and time (VRT)" bit (bit 7 of control register D), no matter whether they currently get proper supply from the mainboard +5V. If this bit is found indicating "internal battery flat" by the POST, it sets the "CMOS power lost" bit (bit 7 of CMOS RAM, index 0E). The BIOS also prints the message "CMOS battery failed" error message, but doesn't wait for any key and clears the screen directly afterwards, so you don't get to see it.

If I enter a second hard drive (D:) in the BIOS setup without connecting a secondary drive to the IDE port, I get to see both "Hard disk(s) fail (20)" and "CMOS battery failed". This proves my point that the message is indeed printed, and you can see it if the BIOS waits for F1 due to a different error.

I think it is quite unfortunate, that the BIOS mostly works with a flat CMOS battery, but stubbornly refuses to report valid drive types to DOS (or any other caller of INT13), and doesn't indicate this condition in any user-visible way.

Interesting. I have actually seen something similar with a dead Dallas module vis a vis the system time. Even if you enter setup and manually set the time, then reboot, DOS will get a garbage value for date and time when it queries the RTC via BIOS call. This was on an AMI BIOS

snufkin wrote on 2021-05-30, 16:28:

Do you know how the computer manages to boot from the floppy correctly if the settings are wrong (Bancho could boot from a DOS 6.22 floppy and then read disks fine)? Does the BIOS "get floppy drive type" provide correct settings if it's been able to start booting from one?

I didn't work out that one yet, but maybe DOS uses the boot sector specified geometry for the boot drive instead of asking the BIOS in that case. When you boot from HD, you don't have the floppy boot sector at hand.

snufkin wrote on 2021-05-30, 16:28:

Also, with the Dallas RTCs, do you know if the VRT get reset if they're modded to fit a new CR2032 on their back?

I just modded the Dallas module on this very mainboard, and the problem is fixed: The BIOS no longer prints "CMOS battery failed" together with other error messages, and DOS is correctly able to format 1.44MB floppies.

snufkin wrote on 2021-05-30, 16:28:

I suppose in theory that if the battery has failed the BIOS ought to make sure it passes at least some sane defaults to the OS, rather than whatever random data would be in the CMOS. But just passing zeros for drive settings doesn't sound like a good default. Better to force entering CMOS setup maybe?

The BIOS has multiple indicators that the settings are corrupted / invalid. One of them is a bad checksum, and the other one is the "Valid RAM and time" bit. If the checksum is wrong, things happen just as you described: You get a CMOS checksum error, the BIOS loads the defaults, and you get the message "Press F1 to continue or DEL to enter setup". It seems like there was an attempt to make the system usable with a flat battery as long as the AT supply is permanently powered on; they just forgot to adjust the "get floppy type" function.

Bancho wrote on 2021-04-24, 15:59:

majestyk wrote on 2021-04-24, 15:36:

Have you done the initial EISA setup for this mainboard using the EISA utility, installed the .cfg / .ovl files for this mainboard? Maybe there is some old configuration still stored in the DALLAS NVRAM. Some mainbords demand even regular ISA cards to be configured with the EISA utility. After changing or reseating EISA cards, this utility needs to be run everytime.
Just to make sure, the mainboard setup is clean.

This is the only thing I haven't done yet. I did buy the motherboard and eisa card from the same seller. I have the config disk but its bad and I'm not sure where to retrieve the exact utility and files from. This is my first experience with EISA! The system actually works. So I can install DOS from the floppy disks, I've got the cd rom working off a SB16 card and its got a CL VL vga card which is detected correctly. the IDE Controller works fine and detects the HD and boots fine.

As I say, what I can't understand is, if I boot from a floppy, it acts normal. I was able to load the Turtle Beach Maui Utility from the floppy disk and play Descent on the system, by booting from the floppy disk and the accessing the C drive.

Running an EISA mainboard without configuring it via ECU (eisa configuration utility) is barbaric.

mkarcher wrote on 2021-05-30, 15:33:

OK, so this one is evil.

The BIOS provides a function "get floppy drive type" (INT 13, AH=8). This function is called by the MS-DOS initialization code to determine what kind of floppy drives are installed. This function retrieves the floppy drive settings from the CMOS RAM (on EISA systems: The primary CMOS RAM, not the EISA extended configuration storage). At least on certain Award BIOSes, this function is "gated" by the "CMOS power lost" bit, and returns invalid values (0 Tracks, 0 sectors/track, 0 heads) if the CMOS battery is flat. Dallas chips with integrated battery provide the status of the internal battery in their "valid RAM and time (VRT)" bit (bit 7 of control register D), no matter whether they currently get proper supply from the mainboard +5V. If this bit is found indicating "internal battery flat" by the POST, it sets the "CMOS power lost" bit (bit 7 of CMOS RAM, index 0E). The BIOS also prints the message "CMOS battery failed" error message, but doesn't wait for any key and clears the screen directly afterwards, so you don't get to see it.

Thanks a lot for this information. I know at least one workaround (by installing 2m-abios.exe from 2M v 3.0 from config.sys) but it doesn't enable booting from a system disk. Until my replacement NiMH batteries arrive, I'm planning to work it around by modifying a bootable MS-DOS boot sector to go resident and answer to that "get floppy drive type" request with a proper answer.

By the way, sorry for resurrecting this thread.

Trevize wrote on 2021-10-10, 21:07:

By the way, sorry for resurrecting this thread.

Since you have... I'd like to point to Necroware's hardware solution Re: Solution for dead RTC modules Dallas DS1287 / DS1387, Benchmarq BQ3287 / BQ4287 and others unfortunately someone like me, who only has one 386 computer that uses it, ordering up PCBs and putting it all together seems like a lot of work and money. I'd support a kickstarter and be willing to spend $20-30, rather than buy a dubious "new-old stock".
I also will point out Necroware's previous video on the subject https://www.youtube.com/watch?v=xBvw1TLHyqM Revised: Repairing Real-Time Clock Battery (Dallas DS1287 / Odin OEC12C887) where he explains only one hole is necessary!!! Pin 12 on the opposite side is also GND, so it can be connected to that ground, instead of making the second hole!!! There have been many other YouTube videos posted after that that haven't picked up on this simple update to the procedure. For beginners especially, who don't plan on doing any other soldering on their vintage PCs ever, this little tip deserves more exposure.