VOGONS

Common searches


Large HD images (DOSBOX)

Topic actions

Reply 60 of 70, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

The definition of IBM PC standard Int13h

CH[7:0] = Cylinder[7:0]
CL[5:0] = Sector, CL[7:6] = Cylinder[9:8]
DH[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.

Reply 61 of 70, by jmarsh

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

Reply 62 of 70, by Serious Callers Only

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

Reply 63 of 70, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 64 of 70, by jmarsh

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

Reply 65 of 70, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.

Reply 66 of 70, by kjliew

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

Reply 67 of 70, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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?

Reply 68 of 70, by kjliew

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

Reply 69 of 70, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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

Reply 70 of 70, by Serious Callers Only

User metadata
Rank Member
Rank
Member

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.