FAT12 Question

[renovatio]

First of all, Merry Christmas!!... My questions are:

[*] Is the fat12 root directory entry's first cluster zerobased, or it starts from 2 (since the first two entries from fat are reserved)
[*] The value of the cluster in fat is directly the number of the next cluster?

Thanks

[ru2aqare]

First of all, Merry Christmas!!... My questions are:

[*] Is the fat12 root directory entry's first cluster zerobased, or it starts from 2 (since the first two entries from fat are reserved)
[*] The value of the cluster in fat is directly the number of the next cluster?

Thanks

The first data cluster (which follows the root directory immediately) is cluster number two. There is no cluster zero or cluster one. This has to do with the fact that the first two entries are reserved in the FAT for the media descriptor byte.

As for your second question, yes. Each value that you read from the FAT either gives you the cluster number of the next data cluster, or is a special value (end-of-cluster-chain, reserved cluster, reserved cluster due do media error, etc.) To put it in another way, the clusters are chained together forming a linked list.

[renovatio]

thanks

[System123]

I am also busy with a FAT 12 system. I have just cached the FATS to memory the problem is I can't work out the format of the FATs.

How are they structured?

As far as I have read they 12bits (1.5 bytes)?

How do you know what file the FAT entry points to, I know they each point to a sector of the Data Area. But are the FAT entries for each File in order. Like from beginning of File to end will be right after each other?

When the end of a file is reached you will get the 0xFFF value, but if the FAT entry is 12bits then what do the other 9 bits do? or are they just blank (0x00)?

And almost forgot MERRY CHRISTMAS TO ALL.

[VolTeK]

what i don get is how do i load certain bits to detemine the time and date then size and name, where do i load them from?

[ru2aqare]

I am also busy with a FAT 12 system. I have just cached the FATS to memory the problem is I can't work out the format of the FATs.

How are they structured?

As far as I have read they 12bits (1.5 bytes)?

Yes, on a FAT12 volume (that is, on volumes with less than 4085 clusters), each FAT entry is twelve bits wide. That is, two entries are packed together into three bytes. Like this:

Code: Select all

           +--+--+--+--+--+--+--+--+
bits       | 7                   0 |
           +--+--+--+--+--+--+--+--+
byte 0     |    cluster A 0..7     |
byte 1     |  B 0..3   |  A 11..8  |
byte 2     |    cluster B 11..4    |
           +--+--+--+--+--+--+--+--+

How do you know what file the FAT entry points to, I know they each point to a sector of the Data Area. But are the FAT entries for each File in order. Like from beginning of File to end will be right after each other?

First, you don't usually know into which file does a specific entry point. You know it the other way around - which cluster does a given file start at. Note that, however, files need not be contiguous on the disk. This is where fragmentation and cluster allocation algorithms come into play. Assume that you have a volume that has, say, 5 data clusters. The volume is initially empty. You copy a file onto the volume that is three clusters long. Therefore you allocate clusters 2-4 to the file (remember, the first two clusters do not exist in the sense that you can read them from the data area). Now you copy a file onto the volume that is one cluster long. Therefore, you allocate cluster 5 to this file. Now you delete the first file, leaving clusters 2-4 and 6 unallocated and cluster 5 allocated. Now when you want to copy a file that is four clusters long, you can't find a single continuous range of free clusters. However, you can still copy the file onto the volume if you break it into two fragments: the first fragment gets clusters 2-4 assigned to it, and the last fragment occupies cluster 6. In this case, the fifth entry in the FAT (corresponding to cluster 4) stores the value six, and the seventh (last) entry in the FAT stores the end-of-file marker.

When the end of a file is reached you will get the 0xFFF value, but if the FAT entry is 12bits then what do the other 9 bits do? or are they just blank (0x00)?

The remaining bits are reserved. Remember, each entry has only twelve bits. The other four bits that you read belong to another entry, thus you have to preserve it when writing into the FAT and ignore it when reading from the FAT.

what i don get is how do i load certain bits to detemine the time and date then size and name, where do i load them from?

You read those bits from the thirty-two bytes long directory entry.

[System123]

Thank you for clearing that up for me. I think i am ready to continue now. I just want to make sure of something. When i search for a file in my root directory do i search the whole root directory in 32bit pieces until i find my file? And does this apply for subdirectories too?

[ru2aqare]

Thank you for clearing that up for me. I think i am ready to continue now. I just want to make sure of something. When i search for a file in my root directory do i search the whole root directory in 32bit pieces until i find my file? And does this apply for subdirectories too?

You check each thirty-two byte long entry until you a) locate your file (when the long file name extension is used, this gets a little complicated), or b) you reach an entry with the first byte set to zero. This zero marks the end of directory. As far as I know, no sorting of the entries is guaranteed. Some other values in the first byte mark special entries. A first byte with the value E5h marks a deleted entry (why of all values was E5h chosen???), and a first byte with value 05h marks an entry whose name starts with E5h (as far as I know, this is/was used on Japanese MSDOS, as E5h is a DBCS lead byte).

This applies to subdirectories as well, with the exception that subdirectories can be arbitrary long. In this way, subdirectories behave just like files.

[renovatio]

Hello, my loadfile function doesn't work properly, it only loads 512 kb from a file...

This are the steps:

• GetFirstCluster from Root Directory
• Add the cluster 33 and substract 2 to get the sector
• Load the sector
  
  Again:
• GetNextCluster
• Check if end of file -> if yes , goto end
• Add the cluster 33 and substract 2 to get the sector
• Load the sector
• goto Again
  
  End: ret

Are the steps correct?

Thanks.

[ru2aqare]

Seems mostly correct, however I see some points that could need attention.

First, when converting a cluster number to a sector number: sector number = (cluster-2) * sectors per cluster + start of data area + start of volume. On most FAT volumes, a cluster is not a single sector, it can be up to 32K in size (or 64 sectors, if I remember correctly). The start of volume is zero for floppy disks, and the start of the partition for hard disks. Second, I suppose your cluster 33 is related to the start of the data area, however there are three fields in the BPB that help you calculate this value: the count of FATs, the size of a single FAT in sectors and the count of reserved sectors before the first FAT. (I may be slightly wrong here - if there is no field that tells you the size of a FAT in sectors, then you can calculate it from other fields, such as the count of clusters).

The third thing to watch out for is non-512 byte sectors. Though the ATA standard say that a sector on a hard disk is 512 bytes long, the FAT specification allows for other sector sizes, too (and if I remember correctly, there are ways to format floppy disks to have 128, 256 or 1024 byte sectors).

Other than these, your steps seem correct.