@Multibooter: The Medium ID Byte occurs in three places, at offsets 0x15 (BPB), 0x200 (1st FAT) and 0x1400 (2nd FAT). In the image attached to this post I've changed them all to F8 (a hard disk), instead of F0 (a 1.2, 1.44, 2.88 floppy or a superfloppy). Let's see how GRDuw likes this new image.
jaclaz, on 14 July 2011 - 01:04 PM, said:
Having only 9 sectors per FAT should mean that as soon as you fill the image with files there may be a problem, even with 32 Kb clusters.
@jaclaz: While you've got the numbers from the BPB all right, what is relevant here is:
Total sectors: 196608 and Sectors per cluster: 64
So 196608 / 64 = 3072 clusters
Now, each cluster uses 1.5 bytes per cluster in a FAT-12 so this means
3072 * 1.5 = 4608 to which you may add 3 bytes which is the "FAT start signature"
So we have 4611 and 4611 / 512 = 9.006 sectors per FAT-12
Now, the question is, what do we do with the 0.006 sector? It means 3 bytes in the FAT-12 or 2 clusters.
So, to be on the safe side there should be 10 sectors per FAT-12, which is what mkdosfs
would create, if used. I decided it was too much, and used just 9, because, in my reasoning, 196608 is the total sector count, but we should subtract from them the boot sector, 18 sectors for two FATs and the root directory. So, since we have 512 root entries and each entry takes 32 bytes, that means 32 sectors are used for the root directory! Now 1 +18 +32 = 51, and so, the available sectors are just 196608 - 51 = 196557 and 196557 / 64 = 3071.2031 clusters or 4606.8047 + 3 bytes per FAT-12 or 9.004 sectors per FAT-12. Since my really precious data wouldn't ever be in all in this image, anyway, I decided to round that to 9 sectors per FAT-12. And that means you're right: when the last cluster happen to be filled, the second FAT might be trashed. Then again, I suspect DOS simply would never use the last cluster, because it *knows* there are just 9 sectors per FAT, so this image has 32 kiB of unusable space, which I find quite acceptable. On the other hand, if I had used 10 sector per FAT-12, that would change the numbers again and 1 +20 +32 = 53 --> 196608 - 53 = 196555 --> 196555 / 64 = 3071.1719 --> 9.003 sectors per FAT-12, so two more sectors are used, of which not more than 3, and, in fact, probably only 1.5 byte would ever be used... If you transfer the image to a real Zip100 and fill it to the brim, let's see whether DOS destroys the start of the second FAT, thus corrupting the disk or if, as I presume, it'll just consider the disk filled when there's no more free space in the FAT. You've got me curious.
And, just to keep related things together, I think it proper that I should quote this older post here:
rloew, on 03 March 2010 - 11:54 PM, said:
dencorso, on 03 March 2010 - 10:40 PM, said:
BTW, the FAT article in the Wikipedia (link
) gives 4078 clusters as the maximum for FAT12, and their reasoning seems correct to me.
4078 is based on the standards.
DOS and Windows computes the number of available Clusters then tests it against a threshold. If below, assume FAT12. If above, assume FAT16.
To complicate things further, DOS and Windows do not even use the same threshold. DOS uses 4086 and Windows uses 4085. A partition could be interpreted as FAT12 by DOS and FAT16 by Windows.
FAT16/FAT32 discrimination is even worse. DOS uses 65526 as a threeshold, Windows tests the 16-Bit # of Sectors per FAT field.
Still according to the above cited Wikipedia page, under Linux, FAT12 is limited to 4084 clusters, adding to the confusion.