Try 512,63,32,1023

DosFreak wrote on 2025-04-23, 20:57:

Try 512,63,32,1023

Tried that, and got DOS to recognize it as a 32MB disk.
With 64, I got a 128MB disk, but more than that, the disk is not even recognized...

The DOSBOX Wiki says that it's 512,63,32,X, where X depends on the size (it's the number of cylinders) and the others shouldn't be changed.

Maybe DosBOX is really limited to 512MB images?

I have 512,63,128,519 and a resulting (almost) 2GB disk size

vanfanel wrote on 2025-04-24, 10:28:

Maybe DosBOX is really limited to 512MB images?

It's not.
In theory it can support up to 8GB by using 512,63,255,1023 but depending on the build, the filesystem functions used by the linked C library will probably only handle image files up to 2GB.
In either case the wiki is wrong.

What are you trying to archieve? Can you not create a disk drive using VirtualBox?

Ringding wrote on 2025-04-24, 11:16:

I have 512,63,128,519 and a resulting (almost) 2GB disk size

Is that stable? I mean.. no corruption down the line?

Forgive me my above post I am still new here and do not know how to edit posts (what do I click?)

I really do not know what you are trying to achieve and why.

You can change freesize visible in DOSBOX upon mounting your game directory

[solved] How to change amount of reported free disk space?

Then mount *.img file of a ms-dos boot floppy
You can then boot it from DOSBOX command line

Also try https://www.dosbox.com/wiki/IMGMOUNT

I was also thinking - create a raw vritualbox disk and then change it into .img file using vboxmanage tools?

oh I think I know what it is you created 1GB hdd.img file. If you want to create 2GB you need to go

dd if=/dev/zero of=hdd.img bs=1M count=2048

I think

Ideally, you would properly calc out the size in 512 byte sector chunks using your desired chs geometry, so it's the exact correct filesize.

So, more along the lines of

dd if=/dev/zero of=./hdd.img bs=512 count=[C * H * S]

Where the math between the [] is calc'ed out as a number.

Eg, for [63 * 128 * 519] suggested for 'nearly 2gb' size, the dd line would be:

dd if=/dev/zero of=./hdd.img bs=512 count=4185216

This will give a zero-filled file of the EXACTLY CORRECT size.

wierd_w wrote on 2025-04-24, 15:08:

Ideally, you would properly calc out the size in 512 byte sector chunks using your desired chs geometry, so it's the exact corre […]
Show full quote

Ideally, you would properly calc out the size in 512 byte sector chunks using your desired chs geometry, so it's the exact correct filesize.

So, more along the lines of

dd if=/dev/zero of=./hdd.img bs=512 count=[C * H * S]

Where the math between the [] is calc'ed out as a number.

Eg, for [63 * 128 * 519] suggested for 'nearly 2gb' size, the dd line would be:

dd if=/dev/zero of=./hdd.img bs=512 count=4185216

This will give a zero-filled file of the EXACTLY CORRECT size.

Now ... where do you get the 519 from? I take you rise the header number from classic 16 to 128 to compensate for the cylinder limit of 1024, but where do you get that 519 from??

vanfanel wrote on 2025-04-24, 18:31:

wierd_w wrote on 2025-04-24, 15:08:

Ideally, you would properly calc out the size in 512 byte sector chunks using your desired chs geometry, so it's the exact corre […]
Show full quote

Ideally, you would properly calc out the size in 512 byte sector chunks using your desired chs geometry, so it's the exact correct filesize.

So, more along the lines of

dd if=/dev/zero of=./hdd.img bs=512 count=[C * H * S]

Where the math between the [] is calc'ed out as a number.

Eg, for [63 * 128 * 519] suggested for 'nearly 2gb' size, the dd line would be:

dd if=/dev/zero of=./hdd.img bs=512 count=4185216

This will give a zero-filled file of the EXACTLY CORRECT size.

Now ... where do you get the 519 from? I take you rise the header number from classic 16 to 128 to compensate for the cylinder limit of 1024, but where do you get that 519 from??

It was mentioned here.

Re: DOSBOX partition size limit: 512MB? Or I am doing something wrong?

I did not invent this example, I just gave the dd invocation to satisfy it.

Edit:

The confusion is likely from the parameters being in the wrong order, since Dosbox's geometry statement is wonkadoodles, in that it expects input in the form of

[Size of sector],[Sectors per Track],[Heads],[Cylinders]

Instead of [Size of sector],[Cylinders],[Heads],[Sectors per track] like every drive geometry table on the planet records drive info in.

Conveniently for us, the math still works out for the dd example, regardless, because multiplication is commutative; the factors can be in any order, the result is the same: the number of 512 byte sectors to wtite into a file.

UNFORTUNATELY for input on the .conf line, INT13 allocates different sized integers for each factor, which prevents you just putting them down in an arbitrary order.

Understanding the limits of these integer types is at the heart of this thread's subject.

vanfanel wrote on 2025-04-24, 14:32:

Ringding wrote on 2025-04-24, 11:16:

I have 512,63,128,519 and a resulting (almost) 2GB disk size

Is that stable? I mean.. no corruption down the line?

AFAICT, yes. I have not been using it extensively, but I have also never encountered adverse events.

Well, I understand the simple equation where all this is derived from:

Disk Size = Cylinders * Headers * Sectors * Bytes per Sector

But then, if we set that:
Headers = 128
Sectors = 63
Bytes per Sector = 512

...We still have "Disk Size" and "Cylinders".
Is Cylinders derived from "Disk Size", or is it the other way around???

Ringding wrote on 2025-04-25, 06:53:

vanfanel wrote on 2025-04-24, 14:32:

Ringding wrote on 2025-04-24, 11:16:

I have 512,63,128,519 and a resulting (almost) 2GB disk size

Is that stable? I mean.. no corruption down the line?

AFAICT, yes. I have not been using it extensively, but I have also never encountered adverse events.

Where did you get the Headers=128 and Cylinders=519 values from, please?

The geometry used by DOSBox is defined at INT13 BIOS level, not IDE level, so the following limits must be respected:

• C <= 1024
• H <= 256 (255 for DOS compatibility)
• S <= 63
• BPS = 512

You can use any geometry you want, as long as these limits are respected, it will work. For generating the image with the exact size (but it will also work fine if the image is bigger), use the following: "dd if=/dev/zero of=hdd.img bs=512 count=C*H*S".

The maximum hdd you can get is 1024*255*63*512 = 8422686720 bytes = 8032.5 MB. Keep in mind that MS-DOS 6.22 only supports FAT16, so that imposes another limitation of only 2GB per partition.

PS: I tested it on DOSBox Staging, but I assume regular DOSBox or other forks as DOSBox-X will behave the same.

vanfanel wrote on 2025-04-25, 13:53:

Well, I understand the simple equation where all this is derived from: […]
Show full quote

Well, I understand the simple equation where all this is derived from:

Disk Size = Cylinders * Headers * Sectors * Bytes per Sector

But then, if we set that:
Headers = 128
Sectors = 63
Bytes per Sector = 512

...We still have "Disk Size" and "Cylinders".
Is Cylinders derived from "Disk Size", or is it the other way around???

It's more a process of 'I want a geometry I can actually get DosBox to accept without errors or corruption, and it enforces the old 'large int13 restriction, and lacks an lba mode' issue.

This means your jumpoff point is the limitations imposed by large int13.

http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html

The maximum values for each, is at most 1024 cylinders (numbered 0-1023), 256 heads (numbered 0-255), 63 sectors/track (numbered 1-63) .

So, you want a 2gb volume, or there abouts.

So, you do the naive starting point of wanting exactly 2GiB, (2048MiB), which is exactly 2147483648 bytes.

We take this number, and divide it by 512, to get the number of sectors, which comes out to
4194304

Next, we divide by the max sectors per track, 63, to get the number of tracks... but it does not divide equally!

66576.2539

Well, let's ignore the remainder, and go for 'best fit'. Trying to get sectors to align will make heads and cyls balloon like crazy.

Next, we go for heads. the max is 255, but that clearly wont divide equally (look at the last number, it's a six!), and we dont really want MORE rounding error, and 128 might just divide equally, so we try it... and are disappointed..

520.125

But the remainder is rather small, so we eat it.

This gives us a 'Best Fit' ECHS for a 'It's almost 2gb' volume of:

520 cyl, 128 heads, 63 sectors per track, 512 byte per sector

Which is VERY close to his suggested 519 cyl.

He might have backed off on the cyl count for other reasons.

If we want to be slavish on this...

The largest 'equally divisible' value for sectors per track is 32, which gives us 131072 tracks. This IS equally divisible by 128 heads, and gives us EXACTLY 1024 cyls.

So, 'an actually 2GiB volume' has an ECHS geometry of

512, 32,128,1024

There are very valid reasons for not wanting to have exactly the max cyl count.

The 'good enough' modulo division method prior gets you in the ballpark with safer numbers.

wierd_w wrote on 2025-04-25, 15:01:

So, 'an actually 2GiB volume' has an ECHS geometry of

512, 32,128,1024

There are very valid reasons for not wanting to have exactly the max cyl count.

The most valid reason is that 1024 doesn't fit in 10 bits, making it an invalid value.

EXACTLY. 😀