If you have DOS DEBUG.EXE, you can check the geometry reported by INT 13H very quickly:

1run debug.exe, type following (verify the code first so it does not break anything)
2a
3mov ah,8
4mov dl,80
5int 13
6[blank line, to stop assembly]
7p
8p
9p
10r
11q

If it works as I think, the three "P" letters run the three assembled lines so stop after running the INT 13H.
"r" will show registers.

Somehow those P commands won't work. Nothing gets executed (registers doesn't change states) and the IP register doesn't increment. Is there a bug in the debug (I'm using the debug.exe from https://www.youtube.com/watch?v=wSvE3Uo6_DU )? Or is my emulator breakpoint handling (int 3h and flags TF flag) wrong?

All vanilla DOS versions (prior to 7.0) use int13h for hdd operations.
So - you have the 504 MiB hdd size limit ("Normal" mode, no translation) or the 8064 MiB (7.875 GiB) hdd size limit in "Large" mode with the translation.
Plus the last limit is reduced because of the "256 heads" MS-DOS bug.
You can't use more hdd space in a vanilla DOS. Physically.
P.S. Even 2 TiB hdds still reports the 7.875 GiB CHS for the compatibility. Not sure about 2+ TiB ones.

I've tried auto and LBA mode. Maybe I'll have to select the Large option in xtidecfg?

According to my calculations it uses the maximum CHS count of 16383x16x63, which is the Large limit you've described. MS-DOS still gives errors formatting using Auto&LBA modes. So I'll test using the Large setting.

Edit: I''ve tried the Large option in XTIDECFG which works, but it'll only see the drive as a 4GB drive (instead of 8GB).

I've fixed the Trap flag in the CPU: It was executing before even executing the command. I've made it set a flag before executing the instruction. After the instruction both the Trap flag and the instruction flag are checked and if both are set, interrupt 1 is called. Debug now works as it should.

Using default settings:
AX = 0; BX = 0; CX=253F; DX=0F02; SP=FFEE; BP=0; SI=0; DI=0; DS=ES=SS=CS=19E3; IP=106 (all values are hex). So it gives 38 cylinders, 16 heads and 45 sectors (translated probably). Is this correct?

superfury wrote:

Using default settings:
AX = 0; BX = 0; CX=253F; DX=0F02; SP=FFEE; BP=0; SI=0; DI=0; DS=ES=SS=CS=19E3; IP=106 (all values are hex). So it gives 38 cylinders, 16 heads and 45 sectors (translated probably). Is this correct?

Makes no sense, that's like below 20MB drive? And its 63 sectors (0x3F+0), 16 heads (0x0F+1), and yes, it does say last cylinder is 37 (0x025) so there's 38 cylinders. In what mode was XTIDE in this case, and how big drive there was?

"LARGE" mode only halves cylinders and doubles heads until either cylinder count fits into 0..1023 range or heads go up to 128, so yes, "LARGE" mode is limited to ~4GB (1024*128*63=4032MB) just as you experienced.

I've just thought about something: Your second command (mov dl,80) addresses the first hard disk (in my case the primary master is a 20MB hard disk with Windows 3.0 and MS-DOS 5.0 installed, bootable). I have the big 8GB hard disk mounted as primary slave, so it must be "mov dl,81" not "mov dl,80". It was addressing the wrong harddisk. I'll execute the command again with the primary slave...

Edit: This time I've got different results:

AX=0; BX=0; CX=E1FF; DX=FE02; SP=FFEE; BP=SI=DI=0;
DS=ES=SS=CS=19E3; IP=106.

So the 8GB drive is: 994 cylinders, 255 heads, 63 sectors. So according to the BIOS it's a 7978,32MB harddisk.

CHS translation is set to Automatic mode in XTIDECFG.

With the primary slave set to LBA mode it gives the same results. So it's actually using LBA mode.

So yes Dos can see the 8gb drive, that is not the problem as long the Bios translation isn't interferring. Which it dosen't appear to be. But it needs to be multiple 2gb partitions to eliminate your errors! I don't see why using multiple partions or multiple 2gb images is a problem unless your trying to share the image with another OS or from another OS? If thats the case you can share a 2gb Fat16 hdd img between the two.

This first paragraph pretty much states that Dos can see an 4gb hdd but it needs split into 2gb for read/write. https://support.microsoft.com/en-us/kb/118335

But according to Gamecollector CHS should be limited to 7.875 GiB, not 8GiB. My drive is reporting 7.875 GiB, but MS-DOS/int13h still try to write past it using Auto/LBA Assist mode(in which 8GB should be able to be accessed correctly). It's writing about 0x10000 sectors past the end of the harddisk.

superfury wrote:

But according to Gamecollector CHS should be limited to 7.875 GiB, not 8GiB.

It's GiB, not GB. Gibibytes. Binary multipliers. 7.875 GiB = 8064 MiB = 8257536 KiB = 8455716864 B.
HDD sizes traditionally uses binary-decimal method. Thousands/millions of MiBs.

superfury wrote:

So the 8GB drive is: 994 cylinders, 255 heads, 63 sectors. So according to the BIOS it's a 7978,32MB harddisk.

The geometry looks correct, but as 994*255*63*512=8175928320 and no matter what I try, I don't get 7978MB.

Let's see the whole again, exactly 8192 million bytes is the disk_size.
Disk size gets shifted by 9 so it is total LBA sectors again, exactly 16 million.
You divide that by (16*63) to get 15873 cylinders so CHS geometry is 15873*16*63=15999984 CHS sectors, all must be addressable.
You set the calculated physical CHS geometry OK, but decrease LBA sector count by 1 before setting IDENTIFY LBA count. Well, it's one less, but it should not matter, as LBA count is still larger than CHS count.

The rest depends on XTIDE then. We know XTIDE uses LBA mode to access drive, so this is not about IDE emulation translation error. We know XTIDE calculates logical geometry OK, because 994*255*63=15968610 CHS sectors and it is less than physical LBA/CHS. We don't know if XTIDE uses initialize drive parameters to set custom translations, but if it does, you don't recalculate cylinders based on drive size in sectors, you keep the previous cylinder values and update the drive size with that, and new head/sector values. So it could be IDE emulation bug. Otherwise, if there is some weird bug in XTIDE, it manifests on drives larger than 8257536 sectors (~4gb) and it addresses hard drive wrong, but if large enough drive than 8GB is used maybe it just works (but disks unreadable on other machines).

The, do you see the issue on both dynamic and static images, maybe one of them has a bug?

The problem happens before the disk image is accessed, during readsector/writesector. It detects the LBA is past the value at IDENTIFY offset 60/61 and aborts. When valid, the values are read/written from/to disk using the io.c interface, which passes the information to static/dynamicimage_read/writesector. They both work with 32-bit sector indexes and 64-bits file offsets(using my emufopen etc. wrapper). That part should be working correctly afaik.

Edit: I've made the wrong division (1024(x)768 instead of 1048576.... Whoops).. It's supposed to be (8175928320/1048576)=7797MB. I seem to have made this mistake in displaying generation of disk images, EMS memory and memory detection. This has now been fixed.

I've fixed the hard disk partitioning and formatting. When creating the disk images, it was creating a disk image where:
4096 bytes = 4KB (up/down increases/decreases)
1024000 bytes = 1MB(left/right increases/decreases).
1024000000 bytes = 1GB (LTrigger/RTrigger increases/decreases),

Of course, the disk creation process divides the bytes with 512 to get the amount of sectors to create in the image.

I've changed this to:
4096 bytes = 4KB(unchanged).
1048576 bytes(1024^2) = 1MB.
1024^3 = 1GB.

It now partitions and formats the created 8GB harddisk without errors. Anyone knows if the BIOS has problems with hard disks with an odd amount of sectors (CHS geometry doesn't match actual size or strange amount of LBA sectors)?

I've tried testing it with a different size (substracting 1MB and 4KB from the hard disk size). It now goes wrong at the final partition (drives D to G have been created. Formatting drive G gives errors at 96-99%). The format summary says 8781824 bytes in bad sectors (so around 17151 sectors of 512 bytes). The disk is 1981972480 bytes large (3871040 sectors in the partition). FDisk says 8033Mbytes. The image is created as 8190MB and 1020KB (both powers of 1024).

So the emulated harddisk is 8.588.881.920 bytes large.

Anyone knows if MS-DOS has problems with odd numbered sector sized harddisks?

Edit: Just tested with a 8GiB harddisk. 8GiB harddisks format without errors (even the G partition), but substract 1MB and 4KB from the size and it gives the bad sectors during formatting (see above).

You seem to be using Visual Studio, right? Doesn't it come with a debugger so you could debug your code? Put some breakpoints to parts where it seems that somebody is accessing drives past the end of the size.

superfury wrote:

So the emulated harddisk is 8.588.881.920 bytes large.

Again it makes no sense.
That is 16775160 LBA sectors, and ATA physical CHS geometry will be limited to 16383*16*63=16514064 sectors, so the disk needs LBA access to go beyond that. Well XTIDE uses LBA. Now the BIOS logical CHS geometry will be anyway limited to 63*255*1024=16450560 sectors, so DOS and BIOS are not able to access beyond your drive size, no matter how much you grow the disk size. Unless there's a bug somewhere.

Now, 8 GiB disk would be exactly 16777216 sectors, even larger. Even if you subtract 1MiB ( 2048 sectors) and/or 4KiB (8 sectors), drive size is still over what DOS and BIOS can see and access. At least it should be.

So either XTIDE has issues or your IDE emulation or image accessing. Debug your code to see what's wrong.