VOGONS


Strange Floppy Disk behaviour 486

Topic actions

Reply 20 of 29, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 21 of 29, by Disruptor

User metadata
Rank Member
Rank
Member

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.

Reply 22 of 29, by maxtherabbit

User metadata
Rank Oldbie
Rank
Oldbie
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

Reply 23 of 29, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 24 of 29, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 25 of 29, by snufkin

User metadata
Rank Member
Rank
Member

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?

Reply 26 of 29, by maxtherabbit

User metadata
Rank Oldbie
Rank
Oldbie
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

Reply 27 of 29, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 28 of 29, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 29 of 29, by CoffeeOne

User metadata
Rank Member
Rank
Member
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.