VOGONS


First post, by realnc

User metadata
Rank Member
Rank
Member

(This is with current SVN.)

It is currently impossible to mount HDD images. A 10MB image for example created with bximage from Bochs using defaults and formatted with DOS 6.22 fails the sanity check in drive_fat.cpp:

/* Sanity checks */
if ((bootbuffer.sectorsperfat == 0) || // FAT32 not implemented yet
(bootbuffer.bytespersector != 512) || // non-standard sector sizes not implemented
(bootbuffer.sectorspercluster == 0) ||
(bootbuffer.rootdirentries == 0) ||
(bootbuffer.fatcopies == 0) ||
(bootbuffer.headcount == 0) ||
(bootbuffer.headcount > headscyl) ||
(bootbuffer.sectorspertrack == 0) ||
(bootbuffer.sectorspertrack > cylsector)) {
created_successfully = false;
return;
}

In particular:

bootbuffer.headcount > headscyl

bootbuffer.headcount is 32 and headscyl is 16. Commenting this line out allows the image to be mounted and it appears to be working correctly.

Didn't this use to work in the past?

I'm attaching a FAT-formatted example 10MB image for testing. (It's empty so bzip2 compresses it to almost nothing.)

Attachments

  • Filename
    c.img.bz2
    File size
    872 Bytes
    Downloads
    9 downloads
    File comment
    10MB FAT-formatted HDD image
    File license
    Public domain

Reply 1 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 3 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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:

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

Reply 4 of 15, by realnc

User metadata
Rank Member
Rank
Member

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.

Reply 5 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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. 😉

Reply 7 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 8 of 15, by realnc

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

xeqWoB9.png

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:

ErV6Vo7.png

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

Reply 9 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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:

imgmount a dos622_1.img -t floppy
imgmount 2 c.img -t hdd -size 512,63,16,20 -fs none
boot -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:

imgmount c c.img -t hdd

Reply 10 of 15, by realnc

User metadata
Rank Member
Rank
Member

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?

Reply 11 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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. 😀

Reply 12 of 15, by realnc

User metadata
Rank Member
Rank
Member

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.

Reply 13 of 15, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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.

Reply 14 of 15, by Serious Callers Only

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

Reply 15 of 15, by _Rob

User metadata
Rank Member
Rank
Member

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.

command_002.png
Filename
command_002.png
File size
12.59 KiB
Views
222 views
File license
Public domain