The definition of IBM PC standard Int13h

1CH[7:0] = Cylinder[7:0]
2CL[5:0] = Sector, CL[7:6] = Cylinder[9:8]
3DH[7:0] = Head[7:0]

There are 24-bit addressing for blocks, 0x000000 for the 1st block and 0xFFFFFF for the last block. This is how DOSBox internal Int13h handler manages the translation, sort of a simplified linear LBA scheme. Since the patch was meant for DOSBox, there isn't any compatibility concerns.

BTW, parted can work on image file, too, IIRC, and should be able to create the MBR partition and FAT filesystem that DOSBox can boot. Just remember that the FAT partition type should be non-LBA. Parted supports toggling off the LBA flag. And, fdisk gives you precisely the partition type to set. If toggling LBA flag in parted did not work, then you just use fdisk to create the MBR partition and set type. Then use parted to create the FAT filesystem. I guess this is the part that you missed, both parted and fdisk set LBA flag by default. Then you just need to boot DOSBox with floppy image and SYS C: to make it bootable.

I wasn't 100% sure as I haven't gone through the workflow. I maybe able to do that shortly and get back to you. I knew I was able to use QEMU to prepare the disk image, then all I need is to remove the LBA flag and DOSBox can boot the image. So I think it is possible to do the same with parted/fdisk/mkfs without QEMU.

Serious Callers Only wrote on 2020-04-29, 02:45:

Also why limit the first value to 1023 - is this just a cosmetic off by one because of 0 addressing ?

MSDOS has a habit of hanging if you use 1024, so pretty much everything else pretends the limit is 1023.

kjliew wrote on 2020-04-29, 07:30:

And, fdisk gives you precisely the partition type to set. If toggling LBA flag in parted did not work, then you just use fdisk to create the MBR partition and set type.

man sfdisk gives the impression that it was completely removed with:

Since version 2.26 sfdisk supports MBR (DOS), GPT, SUN and SGI disk labels, but no longer pro‐
vides any functionality for CHS (Cylinder-Head-Sector) addressing. CHS has never been important
for Linux, and this addressing concept does not make any sense for new devices.

but man fdisk says it's "CHS (Cylinder-Head-Sector) addressing is deprecated and not used by default."

So i guess this is indeed still possible (in fdisk) but i have to create the file first (that is calculate what number of cylinders i need to allocate to fill 1 full sized partition + MBR for the the size the user gives, fallocate the file, then use fdisk -b 512 -C $CYLINDERS -H 255 -S 63 on the file and not a device somehow....

I have no idea how fdisk interacts with the MBR, maybe i should use $CYLINDERS-1 and skip 63 bytes, maybe not. Linux is too damn proud of being modular, it's ridiculous there is not one main tool to create fat images that allows using CHS without hoops of calculating the 'ideal' size for a file first - mkfs.fat comes close but gives 0 control to the CHS (and you say i have to use parted to switch it from LBA to CHS too). You'd expect a project like qemu would already have this as a installable utility.

The dd that i copied from a forgotten post here on Vogons to create the file given cylinders :

dd if=/dev/zero of=dsk.img bs=512 count=`echo $[(( (C+1) *255)+1)*63]`

this is user unfriendly since the user wants to give mb or similar - could even use the gnu library for MB, GB, MiB prefixes (and besides i want a sparse file so i have to use fallocate).

Then after i have the file, i have to turn that into CHS, to find the 'C' since the HS is fixed to max (or maybe 240 heads if i want total compatibility with ECHS for other emulators), then fdisk the found CHS (in a image file, and preferably without mounting it or sudo) and finally then use mkfs.fat on the file?

This is super user-unfriendly, no wonder most instructions just tell you to mount it raw and use windows fdisk.

Each C works out to be roughly 8256KiB when HS is fixed to max. You can use this to round up for inputs in human readable forms. If toggling off LBA flags work in parted, then you can pipe text script into parted. Last I can remember, parted does include "mkpart" and "mkfs" command. The "mkfs" command may not work well for advanced filesystems such as ext4/ntfs, but FAT should be fine.

You could write more exotic scripts/tools to permute CHS for the best geometry for a given size. BTW, upstream DOSBox (without patch) locks CHS to C/16/63 and rounding with C, too, for the max image size of 504MiB.

kjliew wrote on 2020-04-29, 10:59:

BTW, upstream DOSBox (without patch) locks CHS to C/16/63 and rounding with C, too, for the max image size of 504MiB.

No it doesn't. DOSBox SVN supports up to 255 heads.

I'm willing to waste a bit to only vary cylinders and have less size available to have compatibility with other 'low level emulators' for the images that use real bios.

For input in human readable form i'm using the gnu numfmt. Since this is for a package and not a 'portable' utility i decided to use what's available.

I've got the input validation 'appearing' to work by limiting FAT16 to a [35mb-2.1gb (2GiB)] range and FAT32 to a [35mb-7.9gb (7.4GiB)] range with MIN and MAX as more exact aliases, and the idea is to limit it to [0*-1023]/240/64 CHS ranges (for if i ever want to use the game images in another emulator that is not dosbox, assuming a old bios with ECHS).

*actually this 0 is actually 4 because of the lower limit of 35mb and the fixed size of HS.

Anyway with the bytes and with a fixed sector size of 512 bytes, it's easy to calculate the cylinders: BYTES/63/240/512. As for the max size of FAT32 it's from: 1023*63*240*512

Does this make sense at all? Or am i limiting the heads unnecessarily because even this geometry wouldn't work on a LLEmulator or the 1023/255/63 would work anyway?

Now i 'only' have to figure out the magic combination of commands that allows me to fallocate (easy), write the filesystem to a file with parted with that CHS and format it with FAT32 or FAT16.

I'm also thinking of setting the boot flag here or not. It's not worth it right? Because to install a windows OS from a boot disk or cd, the process will set the boot flag by itself right? And without access to the OS files there is no point because it wouldn't boot without going into dosbox to install anyway.

jmarsh wrote on 2020-04-29, 14:31:

kjliew wrote on 2020-04-29, 10:59:

BTW, upstream DOSBox (without patch) locks CHS to C/16/63 and rounding with C, too, for the max image size of 504MiB.

No it doesn't. DOSBox SVN supports up to 255 heads.

Yeah, I meant to say the DOSBox built-in IMGMOUNT auto-sized detection for mounting FAT16 image. That limits the image size to 504MiB. I have patched it to be able to use the full extent of FAT16 image up to 2GB by locking CHS at C/255/63.

I'm very suspicious of the autodetection these days. Why couldn't dosbox support one of the formats where autodetection is not needed anyway? Do these problems exist with qcow2?

Serious Callers Only wrote on 2020-04-30, 03:53:

I'm very suspicious of the autodetection these days. Why couldn't dosbox support one of the formats where autodetection is not needed anyway? Do these problems exist with qcow2?

It could if the devs wanted to. There is nothing magic about autodetection and it does not have to tie with image format. QEMU supports autodetection with the same raw image that DOSBox can use. It is just making efforts to find the best geometry, sacrifice some slacks if required. If the devs do not believe the feature is worth spending efforts, then it could be done with the least efforts. Taking inputs from user without validating is one good example.

Even for real PC before LBA addressing was available. CHS translation scheme was never universal. Real HDD formatted on one machine's BIOS may not work on another machine's until it was re-formatted. Some just being lucky with the same BIOS vendors or the disk just not larger enough to use CHS translation. The only universal CHS scheme is C/16/63 before the size of HDD broke the 1024-cylinder barrier because that info was available directly from the ATA drive detection.

Ugh. The only easy non-root way to make a dos filesystem in linux appears to be mkdosfs, and it uses the C/255/63 addressing scheme (well, it uses blocks, but i can do the calculation easily by dividing and fdisk -lu=cylinders gives those values). I'm going to give up on C/240/63 and test things out to see if images created like this work mounted after a already booting windows drive.

mkdosfs not saying in the man page how 'BLOCKS' are calculated didn't help either (it's the kernel concept of #blocks, filesize/1024).

I've got something almost working. I' saying 'almost' because i'd like to install (or rather to copy over) the OS into another bootable drive from linux and start it up. I tried ms-sys but it didn't really help, and i tried the native tools (without formatting) with a bootdisk and a fdisk /mbr and a sys c: from the boot disk booting the new drive with the old windows as c but it always says that the 'operating system is missing' in the windows 95b boot without the bootdisk.

It's annoying.

https://gist.github.com/i30817/f9705d8e2977a7 … 4ce17530732c8f8

Any ideas? edit : it may be the win95 image i'm using that's incomplete or corrupt.

ruthan wrote on 2018-08-05, 03:04:

BTW how much work would be make proper FAT32 support for Dosbox?

Gulikoza: Im still using you Dosbox glide build from 2011, thanks for it, could you recommend some successor with same topmenu options and Glide support?

FAT32 disk images are already fully supported by DOSBox-X. All other DOSBox forks do not support this yet.

He probably meant fat32 'transparency' usually wanted for windows 95 booting. And the answer is 'functionally impossible without replacing windows 95/98/whatever, because dosbox doesn't emulate windows and thus the windows drivers take precedence and passthrough is impossible'.

The reason wine is able to do transparency is because it replaces APIs and doesn't use the original io.

In dont know what transparency means, but yeah i want to use bigger disk images because Win9x usage.. and there there is 2GB disk too small to reasonable collection of games, even in this age some games had 500-1000 MBs, when wanted to used it without contant cd readings and virtual cds switching.

ruthan wrote on 2020-07-08, 14:59:

In dont know what transparency means, but yeah i want to use bigger disk images because Win9x usage.. and there there is 2GB disk too small to reasonable collection of games, even in this age some games had 500-1000 MBs, when wanted to used it without contant cd readings and virtual cds switching.

DOSBox-X will let you make and mount FAT32 disk images just like FAT12/16 images, directly from the DOSBox-X shell (without having to specify "-fs none" and booting into guest OS). So it does support very large disk images, much greater than 2GB. It also supports long filenames as in Win9x. The all-in-one Windows installer for DOSBox-X 0.83.3 is available from:

DOSBox-X-0.83.3-setup.exe

Just remember to select "7.10" as the reported DOS version during installation.

Ok thanks, what is now best way to boot Win9x with Dosbox?

In old Dosbox i used these in *.bat from booted Dosbox with this:
imgmount X D:\Games\!DosboxWin9XDisk\win98.img
boot -l c

But its only one disk image, now i would need boot Windows 9x with 2 disk images, one old FAT16 and one FAT32 ad driver D for more games. Convert old FAT16 disk to FAT32 and resize it would be nice too.

ruthan wrote on 2020-07-08, 17:48:

Ok thanks, what is now best way to boot Win9x with Dosbox? […]
Show full quote

Ok thanks, what is now best way to boot Win9x with Dosbox?

In old Dosbox i used these in *.bat from booted Dosbox with this:
imgmount X D:\Games\!DosboxWin9XDisk\win98.img
boot -l c

But its only one disk image, now i would need boot Windows 9x with 2 disk images, one old FAT16 and one FAT32 ad driver D for more games. Convert old FAT16 disk to FAT32 and resize it would be nice too.

Right now you cannot boot into the Win9x graphical interface directly from the DOSBox-X shell, but some efforts have already been made towards this direction and it may work in future versions. So for now just boot into the image files for starting Win9x itself. Hopefully you will find the following Wiki guides (both targeted at DOSBox-X 0.83.3) useful for doing this:

Guide: Installing Windows 98 in DOSBox-X

Guide: Managing image files in DOSBox-X

Can we keep the DOSBox-X talk in the DOSBox-X thread?

ruthan wrote on 2020-07-08, 17:48:

Ok thanks, what is now best way to boot Win9x with Dosbox? […]
Show full quote

Ok thanks, what is now best way to boot Win9x with Dosbox?

In old Dosbox i used these in *.bat from booted Dosbox with this:
imgmount X D:\Games\!DosboxWin9XDisk\win98.img
boot -l c

But its only one disk image, now i would need boot Windows 9x with 2 disk images, one old FAT16 and one FAT32 ad driver D for more games. Convert old FAT16 disk to FAT32 and resize it would be nice too.

Something like this would do the trick. Replace the filenames and paths with your real filenames and paths.

imgmount c disk-c.img
imgmount d disk-d.img
boot C:

disk-d.img in this case can be a fat32 volume up to 128GB for Win98, or up to 32GB for Win95. You could also create a new fat32 C: volume, and transfer your existing installation to it, but I'm not going to write out the step by step instructions for that.

Note that only Win95 OSR2 or later has FAT32 support, older Win95 releases simply do not support FAT32.

ruthan: If you have further questions about FAT32 support and booting Win9x in DOSBox-X, you may want to ask in the DOSBox-X thread or DOSBox-X’s issue tracker.