Clustersize (and other things) ignored by MSDOS?

[TheMechanist]

Hi folks,

I created an empty hdd image (one primary partition) which is mounted as Drive D (different machines from i286 to 486). The machines use MS DOS 5.0 (the image creation process is part of a tool I'm coding atm).

The hdd image is derived from CHS 733, 7, 17 specification and (even automatically) correctly recognized by the different BIOSes (MBR is valid) and pre-formated as FAT16 and correctly recongized by MS DOS & different tools (valid VBR).

But no matter if I change the cluster size (VBR offset 0xD) or the number of FATs (VBR offset 0x10) - MS DOS just ignores the entries.

Chkdsk & sysinfo tell a cluster size of 2048 (4 sectors) and 2 FATs (vanilla style, but not mandatory) no matter what is stored in VBR. But Invalid entries (like 3 at 0xD are recognized, so MS DOS obviously reads the entry).

I'm running out of ideas ... is the cluster size hard coded in MS DOS 5.0 FAT driver depending on disk size (in this special case a cluster size of 1024 (2) would be enough, but 4096 (8) or 8192 (16) are ignored as well) ? Or is it related to PCEm's disk manager & some not obvious cache (v17, Linux)?

Greetz and happy easter!

[Zup]

I don't think that changing parameters on a filesystem is a wise move, it would lead to a heavily corrupt filesystem (did you try to execute chkdsk after that?).

If you change those parameters and then format the filesystem again, MS-DOS will do with their default parameters... so everything will be reset. If you really need to change cluster size, you should do the format using a third-party utility. I don't know about pure DOS format utilities, but mkfs.fat (linux) allows you to change every parameter. Maybe some old linux bootable distro (DSL?) can help you do that.

[JohnElliott]

What is the OEM ID? MS-DOS is inclined to ignore bits of the BPB if the OEM ID doesn't measure up. See, for example, http://seasip.info/Misc/oemid.html

[TheMechanist]

I don't think that changing parameters on a filesystem is a wise move, it would lead to a heavily corrupt filesystem (did you try to execute chkdsk after that?).

Of course, kids, don't try this at home ... but not in my case, since it's my own tool that creates the image and pre-formats it

What is the OEM ID? MS-DOS is inclined to ignore bits of the BPB if the OEM ID doesn't measure up. See, for example, http://seasip.info/Misc/oemid.html

Awesome! Thanks for the advice! The guys from Redmond Yes, that was the problem, I've chosen a fantasy OEM for my tool (in most VBR documentations there is no word left about the problems that may result just from choosing another ID ). When I change it to "MSDOS5.0" cluster size is correctly read from VBR by MSDOS (... but it still ignores number of FATs, still assumes 2 FATs even if I choose just 1). Interestingly enough MSDOS calculates disk size wrong (number of sectors per partition in VBR at offeset 0x20 doesn't change), when cluster size is set to 1024 (2 sectors) (chkdsk tells just half of size) .. but not, if cluster size is equal or above 2048 ... maybe you have another hint

[TheMechanist]

Interestingly enough MSDOS calculates disk size wrong (number of sectors per partition in VBR at offeset 0x20 doesn't change), when cluster size is set to 1024 (2 sectors) (chkdsk tells just half of size) .. but not, if cluster size is equal or above 2048 ... maybe you have another hint

It was my fault, forgot to calculate the necessary amount of needed clusters for FAT size (VBR offset 0x16) ... now it works even with a cluster size of 1024 ...