Sure, the sanity checks weren't there before, now they are. You simply need to specify the actual geometry with the -size parameters when mounting.

Edit: FYI, auto-detection of hdd geometry is based on 63 sectors per track and 16 heads, with track count calculated to image size. This is not new, but if an image doesn't have the assumed SPT and head count then the auto-sizing will be incorrect and the sanity checks point it out.

Well, it's 16 heads:

1Creating hard disk image 'c.img' with CHS=20/16/63 (sector size = 512)

But it only works if I lie and say that it's 32 heads using "-size" 😒

But FDISK (or maybe the image tool) wrote 32 heads into the BPB...

Actually, I think the sector addressing still works okay when DOS is using a head count that is a multiple of the BIOS head count, so I suppose the check could be made more lenient for that case:

1(bootbuffer.headcount > headscyl && bootbuffer.headcount % headscyl != 0)

Yeah. The common image creation tools (like bochs or PCem) create images with that BPB, but they report to the user 16 heads. If I didn't look at the dosbox code, I wouldn't even know what the correct value is supposed to be.

realnc wrote on 2020-04-24, 01:39:

The common image creation tools (like bochs or PCem) create images with that BPB, but they report to the user 16 heads.

This didn't fit with my recollection of what BXIMAGE does, so I just checked, and indeed the file created by that program is completely empty. So, please describe the exact process you used to partition and format the image (e.g. boot real DOS and use FDISK/FORMAT, or externally use MTOOLS, etc). I don't want to go barking up the wrong tree here. 😉

I used MS-DOS 6.22 running in PCem to partition and format the image. So "fdisk" and "format d:". PCem itself detected the image as 16 heads when adding it to the emulated PC's IDE adapter.

Well, some kind of revision occurred when 32 heads was written into the BPB instead of 16. Of course it can work just fine: twice as many heads with half as many cylinders... it's just not the head count you expected (or that auto-detection works with).

I'm not sure what the auto-detection you describe in PCem amounts to, but what I'm more interested in is what the BIOS says. You typically have to use BIOS to assign drive geometry parameters from a table or a "USER_TYPE" with manually entered parameters -- what are THOSE parameters? That's what gets communicated from BIOS to FDISK and FORMAT.

ripsaw8080 wrote on 2020-04-27, 14:23:

I'm not sure what the auto-detection you describe in PCem amounts to

Oops, it's just file size based. It says so right on the label:

bximage itself tells me that the CHS of the image it creates is: CHS=20/16/63. So I guess that's either a bug, or it's expected that things work out fine anyway even if in reality it's 32 heads?

but what I'm more interested in is what the BIOS says. You typically have to use BIOS to assign drive geometry parameters from a table or a "USER_TYPE" with manually entered parameters -- what are THOSE parameters? That's what gets communicated from BIOS to FDISK and FORMAT.

Right. The BIOS is set to "AUTO". It reports "LBA, Mode 2". If I go into the BIOS setup to see what exactly that means, it detects 32 heads:

(The auto-detected values that are used are those on the first line.)

It's basically what I expected. No fault of BXIMAGE, the flat image file it creates is of a size that is perfectly suitable for the parameters it reports, but it's also suitable for twice as many heads with half as many cylinders. It's the BIOS of the system you are using that decided to auto-select 32 heads with 10 cylinders, instead of the 16 heads with 20 cylinders that you expected, and 16 heads that DOSBox needs in order to auto-select the geometry.

Here is a method using DOSBox SVN that I have used and know works without trouble:

1) Create the blank image with BXIMAGE (just press enter on its defaults for 10MB)
2) Mount a DOS disk and the blank image with:

1imgmount a dos622_1.img -t floppy
2imgmount 2 c.img -t hdd -size 512,63,16,20 -fs none
3boot -l a

3) FDISK (create a primary DOS partition using the entire disk)
4) DOSBox will close for the reboot, so restart DOSBox with the same commands as above
5) FORMAT C: (/S if desired)
6) Close DOSBox
7) Now you can mount the hdd image with:

1imgmount c c.img -t hdd

Hm. So for existing images that were not created that way, what problems would arise if dosbox used the head count from the BPB without having to verify it with -size? In other words, what if the sanity check would check if the BPB head count results in a cylinder count that works out fine compared to 16 heads? Right now it assumes 16 heads by default and aborts if the BPB has a higher value. What if it instead used the BPB head count, decreased the cylinder count as appropriate for a 16 heads to 32 heads (in this case) increase, and then checked if that works out OK?

DOS can use a head count or SPT *less* than what BIOS is using, in which case not all of the image is being used by the filesystem and DOSBox switches from absolute sector addressing to CHS addressing, but *more* can cause corruption of the image with any software that performs BIOS access (such as booting real DOS).

0.74 always uses absolute sector addressing for the FAT drive backend, so it doesn't really care what the geometry is, but it can corrupt the image when booting real DOS. Because it is not known in advance if the user intends to boot the image, the sanity checks in question were added.

That said, I will add a better error message with a suggestion of what -size parameters to use based on what is in the BPB and the length of the image file, instead of just rejecting the image with no explanation. 😀

Right. I was hoping there could be some safe autodetection for this so that when running dosbox in Retroarch the user can just select an image to mount in the GUI. It's not possible to specify a geometry by hand there, you just select the image file.

I guess I could kludge this by having the user encode the geometry in the image file name (like "disk_16h.img") and then calculate the correct values to pass to the fatDrive constructor.

Well, what you were describing was more like a reworking of the auto-sizing; it sounds doable... feel free to submit a patch. 😉 If you do work on it then you might look in the MBR fields for the geometry rather than the BPB, but I haven't researched the details.

realnc wrote on 2020-04-27, 21:12:

Right. I was hoping there could be some safe autodetection for this so that when running dosbox in Retroarch the user can just select an image to mount in the GUI. It's not possible to specify a geometry by hand there, you just select the image file.

I guess I could kludge this by having the user encode the geometry in the image file name (like "disk_16h.img") and then calculate the correct values to pass to the fatDrive constructor.

People should be encouraged to always use the -size switch on conf files and not rely on autodetection.

BTW i'm trying to use mkfs.fat to create a large image already formatted for windows 95 with those patches for large CHS to make it more user friendly to create those images, and i'm failing miserably. Not sure if it's because dosbox large 'CHS' and associated windows 95 support (i think it's called vfat or something) is supposed to only be 'FAT16+extensions', or because mkfs.fat refuses to increase (or show) the number of cylinders to the values of the patch (max 1023). Meh.

I'd love if there was a imgmake patch apart from the others that could support this larger number of cylinders and could spit out something already formatted to windows 95 or 98 or DOS. Those patches for 8gb imgs with large number of cylinders *appear* to work in windows 95 boots.

There is a "imgmake" patch for DOSBox, which at least dosbox-x has included. It allows to easily create diskette or hdd images, partitioned and formatted from within dosbox-x. DOSBox-X also has some geometry autodetect logic for mounting HDD images, which tends to work fine for most typical use cases.

None typical cases where I know the geometry autodetect fails in DOSBox-X is with DOS versions prior to v3.3 as the MBR partitioning scheme that was used until fairly recently was introduced then. DOS 2.0-3.2 used a different partitioning system.