Congratulations, your computer does support LBA, in both meanings 😀

1- an implementation of translated CHS (ie "LBA" as in not "Large" or "Normal") - most any OS can use this using the classic Int13 functions

2- "Int13 extensions" (Int13X) allowing OSes that specifically know about these then-new functions to actually do LBA access - in MS land this started with Win95 OSR2 and used to ba called "large disk support", although the same term ALSO means FAT32

So, "without drivers", or more correctly using BIOS-or-equivalent-builtin drivers, DOS 6.22 is limited to CHS addressing which even with all bells and whistles is limited* to little more than 8 GB, while W98 has anything needed to beat (with a compatible firmware) that limit, at least up to 137 GB of LBA28 😀

* most HDDs understand this and declare that size as maximum, some CF cards go further and not all BIOSes like that!

Also note that, while historically (2) implies (1), they could be totally independent - and often the disk configuration part only really deals with (1), while (2) has at best an on/off setting…

How rare is that the BIOS setup program is not using int13x (even if the BIOS actually provides them)?
Why does the win9x boot disk fdisk also show 8GB ? (it should be DOS 7 disk, and therefore capable of using int13x....).

Btw if I find it bizarre that this subforum has a pinned thread for "the most memory efficient CD-ROM driver" but not for storage size limits which is practically a daily question (or even hourly question, like today 8GB CF Card Reporting as a 504MB Partition in DOS 6.22 (StarTech Adapter) ).

Maybe if someone knows of a good newcomer tutorial it could be linked? https://www.vogonswiki.com/index.php/Storage# … age_Limitations is correct but likely too technical.

That wiki entry is already simplifying it enough as it is. Storage limits are a very complex subject.

Essentially in this case, DOS will only ever see the amount of space that the BIOS tells it about. The system BIOS is the device driver for DOS. When Windows95 loads, it takes over with it's own driver.

akimmet wrote on 2024-07-24, 18:50:

Essentially in this case, DOS will only ever see the amount of space that the BIOS tells it about. The system BIOS is the device driver for DOS. When Windows95 loads, it takes over with it's own driver.

Now you are contradicting the previous message by assuming that this BIOS doesn't have int13x. That was also my first hypothesis, but then I remembered that Win9x will not enable LBA if the BIOS does not have int13x.
It is a bit difficult for me to test this at the moment, but if 9x didn't do that, you would have the strange situation that only the first 8GB of a partition would be accessible during boot, and only after ESDI_506.PDR was loaded would the rest of the disk be accessible, resulting in potentially catastrophic results if your partition was >8GiB and you were to e.g. defragment some Windows system files.

Hm, that also rings a bell.... so maybe 9x did use LBA without int13x.

I'm thinking that the BIOS is claiming int13x support but it is broken. This was a similar situation with some 486 motherboards and lba.

Int 13h is available and used by all legacy BIOS. The 8GB limit (8033 MB in your case, not sure if it's the same on all old DOS systems, but it's very close) is a combination of the limits of int 13h and DOS. You'll never get DOS to see more without third party drivers.

Dos from Windows95 OSR2 should work with drives and Fat32 partitions up to 32Gb. Any thing else earlier will be limited to 2Gb Fat16 partitions and 8.4Gb drive size.

From what I make of it, I should be able to see something larger than 8GB in DOS or my BIOS. I'm definitely using OSR2, as well as a Windows 98 boot disk with FDISK on it, which are DOS 7.1. This isn't that big of a deal because I have other systems to format the drive on and put it back into my machine, but I'd rather get to the bottom of this to satisfy my curiosity.

I'm looking in my BIOS and the drive was set under 'auto'. If I begin filling in some of the geometry manually I can get the drive to go over 8GB, but I believe that it should be 16383/16/63 for any drive larger than 8GB. My drive is a Western Digital WD200BB-75DEA0. The BIOS has an LBA mode to enable, but seems to still report to DOS that the size is 8GB no matter what. The Auto setting sets it to 16383/16/63 but sets the size as 8GB, and that's what it tells DOS.

debs3759 wrote on 2024-07-24, 22:10:

Int 13h is available and used by all legacy BIOS. The 8GB limit (8033 MB in your case, not sure if it's the same on all old DOS systems, but it's very close) is a combination of the limits of int 13h and DOS. You'll never get DOS to see more without third party drivers.

There's the regular int13 functions, then there are extended int13 functions which use 64-bit LBA addressing to support drives larger than 8GB. DOS from Win95 OSR2 onwards knows how to use the extended functions.
It sounds like this board either doesn't support or implement the extended int13 functions correctly. If it's an AT board (OP seems to have typo'd the model name, google can't find it but does find AOpen AP5VM) I would assume the former.
The easy way around this is to install drive overlay software, that uses a small bit of conventional memory to implement the extended int13 functions.

javispedro1 wrote on 2024-07-24, 17:31:

How rare is that the BIOS setup program is not using int13x (even if the BIOS actually provides them)?
Why does the win9x boot disk fdisk also show 8GB ? (it should be DOS 7 disk, and therefore capable of using int13x....).

So the term "BIOS" refers to three different things here when we are talking about storage:

• There is the setup UI that you get into during boot by pressing DEL or whatever
• There is the drive table that keeps the Cylinders, Heads, Sectors configuration
• There is the INT 13h handler that gets real mode requests for data and pulls it from storage

There can be issues along any of these parts.

One example is Phoenix BIOS 4.03 & 4.04. There is a bug in the BIOS setup UI that let you attempt to enter values that are larger than the size of the memory that it allocated to hold your input. Enter a drive larger than 3277 MB and the setup UI immediately locks hard. Boom. At the time that these came out in 1994, 3GB seemed pretty unrealistic for a desktop. I guess it didn't make it into the dev's test cases.

Many BIOS before 1998 won't accept Cylinder values larger than 65535 in the cylinder field of the drive table. They were effectively capped at ~30GB. If they autodetect a drive with Cylinders > 65535, the POST behavior can be "undefined". Depends on what memory was overwritten in the overflow.

There are many examples of cases where the Setup and the Drive table can configure and hold the values, but the INT13h handler in the BIOS doesn't work with the large values. Immediate failure isn't the worst case here. It can be more unpleasant if the INT13h handler just discards the unexpected bits and effectively maps multiple Cylinder values to the same place on the drive.

You get the same issues when you try to bring in 3rd party drivers for DOS or Windows that are older than your storage. It's not uncommon to find storage drivers that have the same issues as a BIOS at 512MB (<1994), 8GB (<1996), and 128GB (<2001). Some DOS drivers think they know best and overwrite the active copy of bios drive table with values that they like when the driver loads. If you are unlucky enough to do a lot of write operations before your computer crashes, your data gets shredded.

Then these trickle down to the OS limitations, DOS <= 3.3 @ 32MB, DOS <= 7.0 w@ 8GB, Windows < XP @ 128GB etc.

jmarsh wrote on 2024-07-25, 12:08:

OP seems to have typo'd the model name, google can't find it but does find AOpen AP5VM) I would assume the former.

Yep, typo. Here it is: https://theretroweb.com/motherboards/s/aopen-ap5vm-2

I really doubt that board supports int13 extensions, if you have debug handy try the code from this page: https://donaldkenney.x10.mx/GLOSSARY/EXTENDED.HTM

Syntho wrote on 2024-07-24, 14:32:

My motherboard is an AOpen APV5M-2.

Can't find any info about this motherboard model; I assume it's a typo of AP5VM-2 Saw that you've corrected the typo. Its newest BIOS R2.70 on TRW dated 1997/10/29.

Javispedro1 already mentioned my reply in that "8GB CF Card" thread. In short, BIOS earlier than 1998/01 has a big chance not supporting HDD larger than 8.4 GB.

How the number "8033" came from: 1024 cylinders × 255 heads × 63 sectors/track × 512 bytes/sector = 8,422,686,720 bytes ≈ 8,423 MB ≈ 8.4 GB
8,422,686,720 ÷ 1,048,576 = 8,032.5 MiB ≈ 7.8 GiB

Good article: History of BIOS and IDE limits by Andries Brouwer

javispedro1 wrote on 2024-07-24, 17:31:

How rare is that the BIOS setup program is not using int13x (even if the BIOS actually provides them)?

What I meant, relative to my (1) and (2)'s, is that in most every BIOS I've used - ones old enough to have a manual disk configuration (so Pentium 1/2/3/4 age)*, that is - you can enter most any CHS values but that will have negligible to no effect on the accessible capacity (exactly because real LBA "(2)" access is pretty much just a passthrough, and CHS to LBA conversion "(1)" uses a simulated geometry in the first place) 😀

(off topic)

* and writing that reminded me of my GA-C847N, possibly one of the last motherboards with IDE, where the only related option is to enable the controller or not... and no, it doesn't mean that if you plug into it a mid 2000s IDE disk or optical drive it's guaranteed to Just Work 😁

douglar wrote on 2024-07-25, 13:38:

Many BIOS before 1998 won't accept Cylinder values larger than 65535 in the cylinder field of the drive table. They were effectively capped at ~30GB. If they autodetect a drive with Cylinders > 65535, the POST behavior can be "undefined". Depends on what memory was overwritten in the overflow.

It's impossible for a drive to report more than 65535 cylinders since it's only a 16-bit field. The ATA spec even says it can't be larger than 16383 for >32GB drives (not sure why up to 65535 was allowed for drives smaller than that).

The ATA IDENTIFY response has the C/H/S values but also a raw "number of sectors" field for LBA purposes. The BIOS has to let go of the CHS stuff to handle drives over 32GB since it's simply impossible to represent a larger drive in terms of 16-bit cylinders, 8-bit heads, and 6-bit sector fields. Really they should have done that at 8.4GB. I suspect Award may have maintained the C/H/S fiction for >8.4GB drives since it cut down on special cases in their code, only to be burned by it once it became impossible to turn the "total number of sectors" field into CHS values.

Syntho wrote on 2024-07-24, 14:32:

MY 20GB HD reads as 8033MB in the BIOS. When it boots and the system info is being displayed, it says the size is 8064. When I go to Fdisk in DOS it says 8033MB and it won't allow me to make a partition larger than that. However, in Win95/98 it reads correctly at about 18.6GB. I tried playing with the settings in the BIOS and it won't budge.

Is it possible you have moved this drive between machines and/or partitioned it with something smarter than Win95?

The reason I mention it is that when you create a FAT32 partition, at partitioning time Win95/98 will check your BIOS for Int13h extensions at that time and "lock in" whether you have them or not.

If you lack them, it uses partition code 0B, and if you have them, it uses partition code 0C. If it needs to do a 0B code it enforces the 8.4GB limit. The reason for this is so that you don't boot into DOS mode and lose access to the portion of your drive beyond 8.4GB (imagine if something important like a driver needed to boot into Win95 is located there).

As an experiment, on a drive lacking Int13h extensions, I first installed Win95 on an 8.4FB FAT32 partition. I booted into Linux and manually created an LBA extended partition and logical drive and formatted it as a FAT32 partition covering the rest of the drive (I think it was a 40GB drive). That actually works--you get a D: drive that you can access when you're booted in the Win95 GUI, but it disappears when you drop into DOS mode. (Of course you want to manually pass /L:E to mscdex in DOS mode to preserve your sanity so that the drive letter doesn't shuffle around).

jakethompson1 wrote on 2024-07-25, 18:43:

douglar wrote on 2024-07-25, 13:38:

Many BIOS before 1998 won't accept Cylinder values larger than 65535 in the cylinder field of the drive table. They were effectively capped at ~30GB. If they autodetect a drive with Cylinders > 65535, the POST behavior can be "undefined". Depends on what memory was overwritten in the overflow.

It's impossible for a drive to report more than 65535 cylinders since it's only a 16-bit field. The ATA spec even says it can't be larger than 16383 for >32GB drives (not sure why up to 65535 was allowed for drives smaller than that).

The ATA IDENTIFY response has the C/H/S values but also a raw "number of sectors" field for LBA purposes. The BIOS has to let go of the CHS stuff to handle drives over 32GB since it's simply impossible to represent a larger drive in terms of 16-bit cylinders, 8-bit heads, and 6-bit sector fields. Really they should have done that at 8.4GB. I suspect Award may have maintained the C/H/S fiction for >8.4GB drives since it cut down on special cases in their code, only to be burned by it once it became impossible to turn the "total number of sectors" field into CHS values.

Here's where I got that info : https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html
The 33.8 GB limit (August 1999)
The next hurdle comes with a size over 33.8 GB. The problem is that with the default 16 heads and 63 sectors/track this corresponds to a number of cylinders of more than 65535, which does not fit into a short. Many BIOSes couldn't handle such disks. (See, e.g., Asus upgrades for new flash images that work.) Linux kernels older than 2.2.14 / 2.3.21 need a patch.

That description matched my recollection of the issue that I ran into back in the 1999-2000 period.

douglar wrote on 2024-07-25, 19:51:

Here's where I got that info : https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html The 33.8 GB limit (August 1999) The next hurdle […]
Show full quote

Here's where I got that info : https://tldp.org/HOWTO/Large-Disk-HOWTO-4.html
The 33.8 GB limit (August 1999)
The next hurdle comes with a size over 33.8 GB. The problem is that with the default 16 heads and 63 sectors/track this corresponds to a number of cylinders of more than 65535, which does not fit into a short. Many BIOSes couldn't handle such disks. (See, e.g., Asus upgrades for new flash images that work.) Linux kernels older than 2.2.14 / 2.3.21 need a patch.

That description matched my recollection of the issue that I ran into back in the 1999-2000 period.

I agree, I'm just saying it was Award's decision to continue attempting to represent drive sizes in terms of CHS even when it no longer made any sense, that needlessly introduced this bug. Because no translation scheme could ever could make a larger-than-8.4 GB accessible to non-extended Int 13h anyway.

I see a lot of people are "experts" in this bios hdd limitation. But those explanations are just confusing.
From experience on one of my retro pc:
I had a hdd that in bios is detected 8 gb but, like the OP said, if I made the partition with full size on other pc, windows 95/98 will see all size, BUT it cant write more then 8 gb and even scandisk dos/win gives reading errors when it reaches the 8 gb limit, even though in windows 95/98 it apears the full drive size.