I have not gotten FAT32 to run yet... I'm still fighting with pata. But if someone is bored and needs some light entertainment, I'll talk about FAT a bit :-)
The scenario is a playing machine with 9 switches you throw balls on. Each switch, when hit, plays a different sound. When you've hit the middle switch for the 10th time, a very long "winning" sound is played. The sounds are stored as wav files on the media to easily play without decoder chips, so the files are quite large. There can not be a long delay from hitting the button to the starting of the sounds. Sounds are stored on a 1GB media. The maximum number of clusters for FAT32 is 2^28=268435456. Not to waste to much file space, it's formatted with a cluster size of 2 sectors (=1024 bytes). The media thus contains 1048576 clusters, the size of the FAT is 1048576/128=8192 sectors. The long sound takes 500MByte, and uses therefore 4096 FAT sectors. reading them all to search for fragments would take about 3 seconds, which should be inacceptable. Now, the middle switch is hit for the 10th time. We've found the big file in the directory and start to play. The directory tells us the first cluster of the file, the Volume Boot Record tells us where to find the FAT. We're reading sector (FAT location + (first file cluster /128)) for this is the sector in which the FAT chain for the file starts. Inside this sector, at dword position (first file cluster % 128) we'll find the next cluster address for the file. Now for the FAT cache: We'll take, say, 16 dwords as cache. dword is 32 bit. FAT entries only use 28 bits, so we've got four bits to spare in every dword. Let's put a meaning to them: 0000 This cache entry is not used, end of cache 0001 This entry is the start of the file 0010 This entry is a single-cluster fragment 0100 This entry is the start of a multi-cluster fragment 0101 This entry belongs to a multi-cluster fragment, but we havent read enough yet to say if it is the end of the fragment or not. 0111 This entry is the end of a multi-cluster fragment 1000 This is the pointer to the next-to-read FAT entry, we don't know yet if it is a single or multi-cluster fragment Now, we'ver read one sector of FAT, and start filling the cache (after having at least cleared the uppermost four bits of all 16 entries). The starting pointer will go to cache entry 0 with type 0001. The corresponding FAT entry will point us to the next cluster. If that next cluster does not reside in the same sector of the FAT, we'll write it to cache entry 1 as type 1000. We're done for now, and can access the file sectors. As soon as a sector is adressed that does not sit in the clusters we already know, we'll come back to get more FAT data. If the next cluster does reside in the same sector of the FAT, it will still go to cache entry 1. The type depends on the content of the pointer: If it points to just the next cluster, the type is 0100. If it points to another cluster within the same FAT sector, the type is 0010. If the file is heavily fragmented and we reach cache entry 14, the cluster it points to goes as type 1000 to cache entry 15, even if it resides in the current sector. We have no choice of reading that FAT sector again, once we're reaching the end of the cache. If the file is not fragmented, we'll end up with the first cluster address as type 0001 in chache entry 0, the second cluster address as type 0100 in cache entry 1, and the first cluster adress outside the FAT sector we had read as type 1000 in cache entry 3. fingers bleeding... I may continue one day if noone objects... Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
