FAT Troubles

[mark3094]

Hi,

I'm working on my FAT driver (FAT 16 to start with). I can read entries from the root directory without any problems.
When I get the cluster address for any of the files, I have difficulty.

I have found that this formula works:
LBA = Start of partition + 417 + (sectors per cluster * address)

I found this through trial and error, but I don't know why this works. This seems to be different to what's in the Wiki.
The start of partition comes from the MBR (=63), and the address is the address of the cluster in the RD entry (an example is another directory, whose address is 16). Sectors per cluster = 64.

I'm really not sure where the 417 comes from. Can anyone suggest how to untangle my mess?

[turdus]

lba = start of partition + number of reserved sectors + (number of fats * sectors per fat) + (sectors per cluster * (cluster number - 2))
You seem to lack some key variables in BPB (reserved sectors and fat table sizes), and it's also important that cluster numbers starts at 2, not 0.
Cluster numbers 0,1 and FFF8+ are invalid or special (bad cluster, end of file markers etc.).

If you take an advice, don't bother with FAT16, use FAT32 instead, it's not harder to implement, and still in use today. Here's a comprehensive description, that seems legit: http://www.pjrc.com/tech/8051/ide/fat32.html

[mark3094]

Thanks for the advice. Sounds like a good idea.
I'll see how I go

[egos]

turdus, for FAT1x add rootsize (rootdirentries/16, rootdirentries value should be multiple of 16) too. Cluster numbers xFF6h, xFF7h are invalid too.

[turdus]

turdus, for FAT1x add rootsize (rootdirentries/16, rootdirentries value should be multiple of 16) too. Cluster numbers xFF6h, xFF7h are invalid too.

Why is it so? Root directory resides in a cluster too, isn't it? Besides, rootdirentries*16 probably does not make up a whole cluster, so the resulting lba will not be on cluster boundary. Just curious, I haven't code any FAT1x code in decades.

[egos]

Root directory is not hold in data area in FAT1x. There is a special area for this purpose (between last FAT and data area).

[turdus]

Root directory is not hold in data area in FAT1x. There is a special area for this purpose.

Oh, I see. We love you M$... That's definitely a contra to FAT1x and pro for FAT32. It's clearer to put root directory in a cluster too.

[mark3094]

for FAT1x add rootsize (rootdirentries/16, rootdirentries value should be multiple of 16) too. Cluster numbers xFF6h, xFF7h are invalid too.

I was just about to reply to say that I was out by 32, then I saw your post. Thank you.

Combining all the posts here, I now have it working.

So I guess this means that for FAT32, rootsize is not required for this calculation?

[qw]

You'd best search for fatgen103.doc on Microsoft's website.

[egos]

So I guess this means that for FAT32, rootsize is not required for this calculation?

Yes. Before writing the driver download FAT32 FS Spec. as Hobbes said.

[mark3094]

All working now. Thanks.

Just want to check, is this the same formula that I should use when I get the next cluster in the chain from the FAT?

One more question which is related to this.
As a test, I am printing out a text file to the screen (the old MS DOS autoexec.bat file). I read the entire cluster, then print it one character at a time. As expected, it gets to the end of the file, then starts printing gibberish.
What's the best way to determine the end of the file? I found one website that says the ASCII 26 is the EOF marker, but that doesn't seem to work.

I have thought about checking for the end of file by excluding any character over 128, but the problem with this is that the text file might deliberately need to print these characters, or the gibberish afterwards might include normal characters.

What's the best way to check for EOF?

[gerryg400]

From the file size in the directory entry.

[bluemoon]

EOF is not reliable since it can be inserted anywhere with binary write.
You should check the file length field in Directory Entry.

[mark3094]

Seems so simple now

Small files work just fine. The only problem I'm having now is when I check the FAT to get the next cluster. I read the FAT and get the next address, which looks fine (single cluster files return 0xFFFF, multi cluster files return a value such as 0x18).

Is this formula still relevant? I couldn't find it in the Wiki.

lba = start of partition + number of reserved sectors + (number of fats * sectors per fat) + (sectors per cluster * (cluster number - 2))

for FAT1x add rootsize

Thank you

[bluemoon]

Is this formula still relevant? I couldn't find it in the Wiki.

lba = start of partition + number of reserved sectors + (number of fats * sectors per fat) + (sectors per cluster * (cluster number - 2))

The formula should be fairly easy to be deduced with the very well documented FAT layout.
http://en.wikipedia.org/wiki/File_Allocation_Table