Ok, I'm still not happy with the explanation of the microsoft pdf [1].

What do you understand from this paragraph:

{--exerpt--}
RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec - 1)) /
BPB_BytsPerSec;
Note that on a FAT32 volume the BPB_RootEntCnt value is always 0, so on a
FAT32 volume
RootDirSectors IS ALWAYS 0. The 32 in the above is the size of one FAT
directory entry in bytes.
Note also that this computation rounds up.
{--exerpt--}

This seems so wrong... where it says that on a FAT32 volume RootDirSectors
is always 0 don't match with the calculation:

if BPB_RootEntCnt = 0
then
RoodDirSectors = ((0*32)+(512-1))/512 = (0+511)/512 = 0.9980468

So, if you round it UP, as the text says, you have 1, not 0...

Jeeesh...


.--. .- -.. ..-
----- Original Message -----
From: "Robert Rolf" <Robert.Rolf@ualberta.ca>
To: "Microcontroller discussion list - Public." <piclist@mit.edu>
Sent: Wednesday, January 26, 2005 9:18 AM
Subject: Re: [FAT16]: RootDirSectors round up or down?


> If I recall correctly, tracks and heads are numbered starting
> at 0, but sectors and clusters start at 1.
> You MUST round up since you are computing a size_of
> and need to get to the next available sector boundary.
> The unused entries at the end of the last FAT12/16/32 sector
> are filled with FFFE? tag that prevents their use.
>
> Don't confuse sectors, which are the media storage unit,
> with clusters, which are a collections of sectors (1-32?), but
> which are the minimum allocation unit for FAT.
>
> Looking at existing media is of course the best way to
> confirm your calculations.
> Decades ago when I was repairing disks after corruptions,
> I found it helpful to write it out, where each line
> was a media sector address, and the text
> was "BPB", "FAT1.1" "Fat1.2" .."Fat2.1"..."Dir1.",
> "Cluster1", "Cluster2" etc., plus the calculations of the pointers.
> Back then the tables weren't that big.
>
> R
>
> Padu wrote:
> > I'm reading the microsoft white paper on "FAT: General Overview of
On-Disk
> > format", mainly because I'm trying to make a PIC write to a CF card
using
> > FAT16.
> >
> > At this point, I'm just digesting the material and at the same time
checking
> > the numbers and computations of a CF card using WinHex. Somehow the way
I
> > was calculating the first data sector wasn't matching the way the CF was
> > formatted.
> >
> > Here it is an exerpt from the pdf:
> >
> > "RootDirSectors = ((BPB_RootEntCnt * 32) + (BPB_BytsPerSec - 1)) /
> > BPB_BytsPerSec;
> > Note that on a FAT32 volume the BPB_RootEntCnt value is always 0, so on
a
> > FAT32 volume RootDirSectors is always 0. The 32 in the above is the size
of
> > one FAT directory entry in bytes. Note also that this computation rounds
> > up."
> >
> > In my case, BPB_RootEntCnt = 512, bytes per sector = 512, therefore
> > RootDirSectors = 32.998.
> > According to the pdf, it round UP?!?! to 33?
> >
> > Thing is, if you do that, then the first sector is off by one.
> >
> > Here's how to calculate the first data sector:
> >
> > FirstDataSector = BPB_ResvdSecCnt + (BPB_NumFATs * FATSz) +
RootDirSectors;
> > FirstDataSector = 4 + (2 * 246) + 33 = 529
> >
> > WinHex tells me that sector 527 belongs to RootDirectory, and sector 528
is
> > the first free data sector.
> > That would match perfectly if RoodDirSectors round DOWN instead.
> >
> > Am I correct assuming that it is a print error in the PDF? Or Am I
missing
> > something?
> >
> > Padu
> >
> --
> http://www.piclist.com PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist