Try a different version of dos or freedos
or make the partition slightly larger

Have you seen http://www.dewassoc.com/kbase/hard_drives/dri … mitations_2.htm ?

http://www.vintage-computer.com/vcforum/showt … imit-in-MSDOS-5 suggests MS-DOS 5 can go up to 9.8 GB with appropriate partitioning; http://www.msfn.org/board/topic/159631-testin … os-limitations/ suggests 8 GB.

Ps: I think if Dos had a hard drive bug it would be well known

After format completes, it reports that 0x5A28000(hex) bytes are in bad sectors (2146467840 bytes total disk space). 32KB in each allocation unit, 62620 allocation units available on disk.

This is formatting a disk image (of exactly 8GB in size). It's compressed, but when converted to an IMG file it should be exactly 8000x1024768 bytes in size.

But how is the IDE drive represented to DOS? Is the INT13H code coming from XT bios, or XT-IDE add-on BIOS, or where, and how do they translate the ATA geometry to INT13H?

The point is, ATA drives always seem to specify their hardware geometry with 16 heads and 63 sectors, for example 40GB drive says 16 heads, 63 sectors and 16383 cylinders. (I thought ATA specs could say 64k cylinders and 255 heads, but it seems not).

Anyway, BIOS standard interface is limited to 63 heads also, and 1024 cylinders. Heads theoretically go up to 256.

Early bioses used LARGE translation mode, where they just double heads and halve cylinders.

But actually, there is a DOS bug with 256 heads, so therefore many BIOSes limit the head to 255.

So, 1024*255*63 sectors is maximum you can safely allow DOS to use, 8032.5 MiB (7.844 GiB), through standard INT 13H.
And why would a 8086 need a 8GB hard drive, the standard 1024*64*16 limits for 504 MiB should be enough 😀

The disk is 8GB(as createn) with 15873 cylinders, 16 heads, 63 sectors per track, as detected in my ATA-1 emulation (16000000 sectors of 512 bytes each). FDisk reports the disk as 7797MB, with partition at maximum size as 2047MBytes.

I've also tried creating and formatting a 2GB disk drive, which works without problems (both partitioning and formatting).

When trying to format the partition on the 8GB disk's primary partition, it startes checking @1% for cluster number 981 (which it shouldn't do) and onwards.

Have you also seen the OS/2 museum article on How to please WDCTRL? Of course, WDCTRL is not MS-DOS 5.0's format utility, but perhaps some of the same reasoning applies.

(Apologies if that isn't terribly helpful, but there doesn't seem to be much else to go on at this point.)

Also, does a 4 GB disk work? That would suggest the 4.2 GB Barrier mentioned in my earlier link is at fault.

superfury wrote:

The disk is 8GB(as createn) with 15873 cylinders, 16 heads, 63 sectors per track, as detected in my ATA-1 emulation (16000000 sectors of 512 bytes each). FDisk reports the disk as 7797MB, with partition at maximum size as 2047MBytes.

Yes, but as I said, who does the geometry translation for INT 13H? Because clearly it is translated to 994*255*63=7797MiB.
Note that it is 255 heads, not 256, because the head translation list goes 16,32,64,128,255, because 256 needs to be avoided for compatibility reasons. What I also don't understand why it it 994 cylinders, as it could also be 995.

superfury wrote:

I've also tried creating and formatting a 2GB disk drive, which works without problems (both partitioning and formatting).

You don't say the disk size in this case, but disk with 2GB (2*10^9) bytes is 3906250 sectors, so your ATA emulation could say it is 3875*16*63 disk. It is then translated to maybe 968*64*63=1905MiB. The situation is completely different, as the 16 heads is translated only to 64, not to 255.

superfury wrote:

When trying to format the partition on the 8GB disk's primary partition, it startes checking @1% for cluster number 981 (which it shouldn't do) and onwards.

Maybe geometry translation issue? For example, every time you increase cylinders, you skip sectors and leave them unused in image file, and thus accessing the last sectors on disk, it tries to seek past end of file.

Can you check what the BIOS translated geometry for the disk is?

Oh well, I think your LBA2CHS and CHS2LBA have errors. You give it the amount of heads but add 1 to them in the equations. If it has 16 heads, it has 16 heads ranging 0..15, not 16+1 heads.

So in each of the three occurence of (nheads+1) in lba.c, change them to (nheads), and verify operation.

For instance I always use 1.44MB floppy disk as basis in a spreadsheet (LibreOffice for me, maybe Excel for you) because it has only 2880 sectors 0..2879 and so it has only 2 heads ranging from 0 to 1 and 18 sectors ranging from 1 to 18 and 80 tracks ranging from 0 to 79. Also for any random number, convert it from LBA to CHS and back to LBA and see if you have same LBA number.

My latest version has a fix in the maximum cylinder count (0x3FFF). Also identify word 57-58 (total current addressable sectors) isn't set nor updated (by set drive parameters command). Is this causing problems?

Btw it isn't using LBA.c: ATA_CHS2LBA/ATA_LBA2CHS is used instead.

Edit: Added word 57/58.

Fdisk now gives me a parition size of 2047MB(maximum partition size). It tells me the total disk space is 7797Mbytes (1 byte = 1048576 bytes). Usage 26%.

Format tells me it's formatting a 2047.31M harddisk. The "Trying to recover allocation unit X" message still shows with such a large disk.

Up to 4GB formats fine. 4.23GB gives errors already (somewhere at allocation unit 5XX). Could this be the 4.22GB barrier at work?

The 256 heads one? Maybe.
The fix is known - replace translation factor 16 to 15.
By the way, why do you need 8 GiB for MS-DOS? It's still the FAT16 with the 2 GiB limit per volume.

I simply want the harddisk to work 100% (no errors), so I need to fix what bugs may occur.

I've tested with a 4.22GB harddisk (4220MB generated harddisk). It also gives the errors. So the problem is somewhere between 4097MB(works) and 4220MB(error) sized harddisks.

Also, could this be a bug in the XT-IDE BIOS I'm using?

superfury wrote:

I've tested with a 4.22GB harddisk (4220MB generated harddisk). It also gives the errors. So the problem is somewhere between 4097MB(works) and 4220MB(error) sized harddisks.

Also, could this be a bug in the XT-IDE BIOS I'm using?

OK, so finally I got an answer, the MSDOS <-> IDE geometry translation is done by XT-IDE. It may have a problem, but it would not work in a real machine with real disks over 8GB then either.
Next question, what is the geometry seen by MSDOS throuh INT13H? Specifically, does it have 255 or 256 heads?
Also, what XT-IDE BIOS version you are using?

Because you can run your own software, you can make reads to certain sectors in DOS and see what kind of reads end up to your IDE emulation.

I don't know by what geometry MSDOS calls the int13h handler. I do know that during those invalid accesses, LBA addressing mode is used.

I'm using the latest XT-IDE BIOS version (XTIDE Universal BIOS v2.0.0 beta3).

I could make a simple program in turbo pascal and query the INT13 disk geometry and display it. Or is there already something to use out there?

You can also use DOS DEBUG.EXE to read FAT info sector and peek some values from there. At least it has number of sectors per track, and number of heads, but does not include cylinder count. Still, it is not the same thing as asking the parameters from INT 13H.

I was going to say the get_cylinder returned always one too big number, but it appears you fixed that in commit f7608e5, did it fix the issue?

Also, how have you configured the XT-IDE settings, is it using LARGE/AUTO/LBA modes and have you forced LBA/CHS parameters there?

I've installed DOS 6.22 I belive it was on a drive over 8GB prior formatted in fat16 using Linux. I kept getting drive errors mostly saying the drive was full but things would still install. Because it can't fully read or create a partition past 2gb not nativly. Might be a work around I'm not sure. You probably could easily partion the 8GB into 4x2GB partions, would run without errors but would see 4 hdd's.

I've configured XT-IDE using the default settings: Auto mode and no forced LBA/CHS parameters.

Edit: I've just tested using the slave drive(the 8GB drive) using translation set to LBA Assisted. It still gives the same problems during formatting.