Improved Atari TOS FAT16 filesystem details
 
  
   This will be little technical, but I try to make it understandable for average computer user. Only little sense for simple mathematic is required :-)
So, what is FAT16 ?  It as abbrev. of 16 bit file allocation table.  Every file, DIR on hard disk partition is divided in segments, here called clusters, and they must be not in order on disk - that allows adding new data (new bytes) to existing file, while space right after it is occupied. That 16 means that each record in FAT is 16 bit (2 bytes) long, and that means 2 POW 16 = 65536 possible records, in practice little less, and that depends from partition size too.
In case of small, now barely used 32 MB or smaller partitions 1 FAT record can be exactly 1 sector on disk (512 bytes).
With larger partitions sizes count of bytes per cluster grows, but it is always POW of 2. So 2, 4, 8, 16, 32 ...
And that means also that minimal space what some short file occupies on disk is for instance 16 sectors, or 8 KB .
We can easily calculate partition size with such cluster size: 8KB x 65536 = 512 MB . Or better said: is is with 257-512 MB size.
And that's actually max partition size what TOS 1.04-3.06 support (TOS 1.00 and 1.02 max 256 MB) . Unfortunately, TOS or AHDI FAT16 is not really regular FAT16. I call it rather FAT15 . Because it can handle max 2 POW 15 clusters. And that means that in case of 512 MB partition (down to 257 MB) cluster size is not 8, but 16 KB . And that means more wasted space. See test results at page bottom.
And there is more bad: since TOS (AHDI) uses 16-bit sector addressing instead 32-bit (on 32 bit CPU !) count of logical sectors is limited too - 65536 . So, there are so called large logical sectors used. Depending on partition size. In case of 512 MB it is 8 KB . And that's minimal size with which hard disk driver operates. And yes, not good, especially not with short files. See speed test results at bottom.

What I did is correctiong TOS FAT16 filesystem code at several places - so it has now full 32-bit sector addressing. Full 16-bit FAT.  And 32 logical drives possible - that means 30 hard disk partitions, since A and B are reserved for floppy drives.

30 partitions of max size of 1 GB, with less buffer need, faster work, less wasted space. Yes, that's what you get, and it is tested a lot.

Now can fully utilize 32 GB SD card - even with 30 or 29 partitions. Because real capacity is usually some 10% less than nominal. I was able to create 28x 1023 MB + 1x 870 MB partitions on 32 GB micro SD (via adapter) with UltraSatan.


 


Here is speed test I made some months ago:

Done on Mega STE, with same UltraSatan, with 2 SD cards with practically same speed.
Test is just copying SUBDIR with 80 very short files to some other SUBDIR on partition.

Regular TOS 2.06 :

Note: it needs min 32 KB for buffers for 500 MB partition.
Almost empty 500 MB partition:
At 8 MHz: 39 sec , at 16 MHz 27 sec


Regular TOS 1.04, 8 MHz for same as above: 38 sec - marginally faster.

Improved TOS 1.04i (without large sectors), DOS FAT16 partition of 1000 MB, almost empty:
No added buffers, only base 2 KB, what TOS creates after boot.

At 8 MHz: 26 sec , at 16 MHz: 17 sec
With 32 KB added buffers:
8 MHz - 25 sec, 16 MHz - 17 sec - marginal improvement, or just in range of test error.


Wasted space on hard disk/Flash card :

Here are concrete test results:
Regular TOS, 512 MB AHDI compatible partition. Free space before adding files is 535609344 bytes. Adding DIR with 80 very short files, all below 100 bytes. After that free space is 534282240 bytes. So 1327104 bytes less. And that's exactly 81x16384 .
81 because DIR takes 1 cluster too.

Improved TOS, 512 MB real FAT16 partition (DOS type):  Free space before adding files is 535519232 bytes. After adding 80 short files with DIR containing them free space is 534855680 bytes. 663552 bytes less - or 2 times less as above.
Cluster size is 8 KB instead 16 KB in case of same partition size. And that means better space usage. Less wasted space.
It may be pretty much in case of many short files.


PP, Sept. 2019