a question about FAT12 , whats the difference between 0xFF8 - 0xFFF in FAT12

hello all , as you see in FAT12 , it says 0xFF8 - 0xFFF are used to indicate the Last cluster in file, my question is , why do we have this range for specifying the end of file!!? we could easily use 0xFFF as the indicator (or vice versa), then having this said ,the 0xff8 is in vein and thus completely useless ! :shock:
another question related to this topic is that , why cant we use those last addresses for our clusters ?

i would be very thankful if anyone help me get this ,

i myself thought of it as following but it seems im wrong :

Quote:

---

could it be that because 0xFF8-0xFFF equals 4088-4095 which exceeds the number of actual clusters usable in Fat12 structure ?
i mean because starting from 0xFF8 means the cluster you are looking for doesn't exist , ( or you have passed the boundary which specifies the last usable cluster in FAT12)
(cluster counts is 4078(0xfee) under windows, and 4084(0xff4) under linux)
we have 0x000 to 0xFFF as the range for our addresses ,and according to below:
FAT12-------------Description
0x000-------------Free Cluster
0x001-------------Reserved value; do not use
*0x002–0xFEF----- Used cluster;value points to next cluster(so this means usable clusters are up to 4079, the rest are for other purposes as you see below)
0xFF0–0xFF6-------Reserved values; do not use
0xFF7---------------Bad sector in cluster or reserved cluster
0xFF8–0xFFF--------Last cluster in file(and what remains is used to specify the end of file , actually it is used to say that you have passed the last usable cluster )


*: this actually says for addressing our clusters we have 0x002 up to 0xFEE choices(because in FAT12 there only 4077 clusters that we can use ? (why?!)) .
starting from FF0 , we address special cases , up till FF8,
From FF8 to the very end of usable addressing range which is FFF , we use the values to say what you are looking for does not exist , or there are only <FEF number of clusters you could use, now the number you specified is not in that range ,so we use it to say you reached your end of file.



am i right?

---

i really need to know this ,
thank you in advance

Master.,

wow, this is really ancient stuff :eek: and I had to look that up before answering.

I believe I never have seen an explanation why there are so many reserved cluster values, but IMO it is not that uncommon that developers reserve lots of values. And I think the number of reserved values is even growing nowadays, along with the increased number of bits available.

But if you really need a reason for that to cling to, here is one that I could imagine, although I've never seen it explained that way: The eight most significant bits of FAT entry #0 contain the media descriptor that can range from 0xF0 to 0xFF (including some more reserved values :D). The other bits of FAT entries #0 and #1 are all ones. So if some software should include these entries in a FAT scan (although that wouldn't make sense as they're always reserved) it would not find values there that might represent any potentially existent cluster. Satisfied? ;)

But you made me curious: Where the heck do you find a FAT12 file system nowadays? The only place where I can imagine one is on a floppy disc, and most computers you'll find today do not even have a drive for that unless they're quite antique.

HTH

Quote:

---

Originally Posted by Eri523

Master.,

wow, this is really ancient stuff :eek: and I had to look that up before answering.

I believe I never have seen an explanation why there are so many reserved cluster values, but IMO it is not that uncommon that developers reserve lots of values. And I think the number of reserved values is even growing nowadays, along with the increased number of bits available.

But if you really need a reason for that to cling to, here is one that I could imagine, although I've never seen it explained that way: The eight most significant bits of FAT entry #0 contain the media descriptor that can range from 0xF0 to 0xFF (including some more reserved values :D). The other bits of FAT entries #0 and #1 are all ones. So if some software should include these entries in a FAT scan (although that wouldn't make sense as they're always reserved) it would not find values there that might represent any potentially existent cluster. Satisfied? ;)

But you made me curious: Where the heck do you find a FAT12 file system nowadays? The only place where I can imagine one is on a floppy disc, and most computers you'll find today do not even have a drive for that unless they're quite antique.

HTH

---

Sir
Thank you very much .
the reason i m after it , is because our instructor told us to make an OS, this simple OS uses fat12 as its filesystem . and he made us go into the details and find out everything about what we use and why we use it this way .
im not sure i got your answer !
you mean the only reason that we dont use the last remaining addresses is because of this ? or thats why we dont use the two first FAT entries? please pardon me but i still dont get it why we cant use addresses from FF8-FFF , i understand that the first two entries are reserved , and we shouldnt touch em , and also that is media descriptor , but the instructor told us to find the reason why we dont use those remaining addresses (FF8-FFF in fat12 , or they are mainly used to specify the end of file !)for addressing clusters , he mentioned sth vague that those addresses are kinda limited and stuff ( i didnt get it ) .

again Thank you very much for your time , i really appreciate it .

hi
see this link:
http://www.oldlinux.org/Linux.old/di...s/cnix/FAT.pdf

page: 12

Master.,

building a compete OS (although it might not be a big one) looks like more than plain high school stuff to me.

It is quite common that programmers don't explain what their "reserved for future expansion" stuff might mean sometime. This is natural because its future stuff. If they could explain it, maybe they might find a much better occupation than being a programmer! :D

It is quite common, too, that much of that reserved stuff, if any at all, is never used until the software becomes obsolete. But the opposite might happen as well: They run out of reserved values. In that case, data structures might be extended, new structures added or even new API functions may be introduced. In the Win sphere this often results in names ending on "Ex".

My explanation that the reserved cluster numbers might have to do with the range of valid media descriptors in the first two FAT entries was just a crutch, thying to find something at all that might explain it.

Wikipedia has a nice article on the FAT file system. Maybe I should have looked there first before digging out my old books (yes: real books made of paper! :rolleyes:) I found no explanation of the cluster number mystery there, too, but it has a lot of related links to other sites that I didn't want to follow myself, at least now. Most of them appear to be about FAT32, though, but the mystery has not been removed up to that version of the file system.

But I don't think you should worry too much if you don't find an explanation for that. I haven't seen one in decades, so your instructor IMO should not really expect that you find one in some weeks. But if you really do find it, tell me! I'm really curious and like that conspiracy theory stuff... :D

When your instructor spoke about that these cluster numbers are a limited resource, I think he meant that a limited number of clusters is one of the major disadvantages of nearly all incarnations of the FAT file system. And gaining another seven possible cluster numbers would not really help there.

BTW, while thinking about the FAT file system I found another mystery: Why are the first two entries of the FAT reserved at all? Just to store the media descriptor doesn't look like a really good reason to me, as this is only a duplicate of the media descriptor field in the BPB, stored in the boot sector, and I think any file system driver has to hold a copy of that BPB anyway. This duplicate field looks just like another possible source of file system inconsistencies... :D

Possible explanation: The inventors of the file system might have initially thought of the FAT as a description of more or less the entire file system (including the root directory, but excluding the FAT itself and the boot sector). But this explanation isn't really good: The only disk format that this would be true for (i.e. the size of the root directory is equivalent to two clusters) are DS-DD diskettes with a capacity of 320 kB (8 sectors per track), media descriptor 0xFF. But this format is quite uncommon, disks with 9 sectors per track (360 kB) are really more common. (But maybe that was not the case in the early days of the FAT file system.)

HTH, so far... :)

Ah, and, asalehian,

thanks for posting the link to that PDF file. It made me really curious! But the pages around 12 in that document didn't contain any information that we didn't already know (I think, as far as I'm speaking for Master. here)... :o

Quote:

---

Originally Posted by Eri523

Master.,

building a compete OS (although it might not be a big one) looks like more than plain high school stuff to me.

It is quite common that programmers don't explain what their "reserved for future expansion" stuff might mean sometime. This is natural because its future stuff. If they could explain it, maybe they might find a much better occupation than being a programmer! :D

It is quite common, too, that much of that reserved stuff, if any at all, is never used until the software becomes obsolete. But the opposite might happen as well: They run out of reserved values. In that case, data structures might be extended, new structures added or even new API functions may be introduced. In the Win sphere this often results in names ending on "Ex".

My explanation that the reserved cluster numbers might have to do with the range of valid media descriptors in the first two FAT entries was just a crutch, thying to find something at all that might explain it.

Wikipedia has a nice article on the FAT file system. Maybe I should have looked there first before digging out my old books (yes: real books made of paper! :rolleyes:) I found no explanation of the cluster number mystery there, too, but it has a lot of related links to other sites that I didn't want to follow myself, at least now. Most of them appear to be about FAT32, though, but the mystery has not been removed up to that version of the file system.

But I don't think you should worry too much if you don't find an explanation for that. I haven't seen one in decades, so your instructor IMO should not really expect that you find one in some weeks. But if you really do find it, tell me! I'm really curious and like that conspiracy theory stuff... :D

When your instructor spoke about that these cluster numbers are a limited resource, I think he meant that a limited number of clusters is one of the major disadvantages of nearly all incarnations of the FAT file system. And gaining another seven possible cluster numbers would not really help there.

BTW, while thinking about the FAT file system I found another mystery: Why are the first two entries of the FAT reserved at all? Just to store the media descriptor doesn't look like a really good reason to me, as this is only a duplicate of the media descriptor field in the BPB, stored in the boot sector, and I think any file system driver has to hold a copy of that BPB anyway. This duplicate field looks just like another possible source of file system inconsistencies... :D

Possible explanation: The inventors of the file system might have initially thought of the FAT as a description of more or less the entire file system (including the root directory, but excluding the FAT itself and the boot sector). But this explanation isn't really good: The only disk format that this would be true for (i.e. the size of the root directory is equivalent to two clusters) are DS-DD diskettes with a capacity of 320 kB (8 sectors per track), media descriptor 0xFF. But this format is quite uncommon, disks with 9 sectors per track (360 kB) are really more common. (But maybe that was not the case in the early days of the FAT file system.)

HTH, so far... :)

Ah, and, asalehian,

thanks for posting the link to that PDF file. It made me really curious! But the pages around 12 in that document didn't contain any information that we didn't already know (I think, as far as I'm speaking for Master. here)... :o

---

thank you very much dear Eri523 for your time .
i am an university student :d lol not a high school student :d and the reason we are told to dig this far is to know FATS better, (starting with fat12 and going on and proly being able to develop ours )
anyways , about your question on FAT12 two entries which is used for media description ,
i have already found the reason ( this was also one of those questions we were asked to find the answer for ) and here it is :
A DOS 1.X boot sector didn't use to provide any details about the disk, there were only 2 types of disks supported so it wasn't a problem. To identify which disk type it was the first two entries in the FAT were used, this has stuck and has become known as the FAT signature.
after that the media descriptor was moved to bpb and the fat structure remained still afterward.
source : FOXy2K: FAT System Guide
my prof told me sth about the addressing limitation stuff, he actually accepted my theory on this topic , but he said there is another reason ( gotta discover it through mathematics , as he told me that i need to do some mathematics " and we were interrupted :( , )
i'll be in contact with him , and when i figure out what he means , i'll post it here.

Master.,

I didn't really suspect you to be a high school kid, especially not after having a look at your profile page. ;) And the topic of your question as well as the way you asked didn't look like that either. But I have seen that there are some of them around here, regularly running into that "no homework" policy here on the forums. :) (Well, it's not really a strict "no homework" policy, but I'm not going into details as I think both of us are knowing what it's about.)

Starting with FAT (at least the incarnations 12 and 16, without VFAT) as an example of file systems appears to be a good choice to me, as they are fairly simple.

Thanks for instructing me about the history of that FAT signature; I didn't know that yet. I think the two disk formats supported by that DOS 1.x (on the IBM, see below) were the ones with media descriptors 0xFF and 0xFE.

I had used DOS 1.x myself on a Sirius/Victor (that looked quite high-end compared to my TRS-80 at home) long ago but I didn't delve into the details of its file system then. (I had already done that on the TRS-80 and some CP/M machines, though.) The Sirius, although using a variant of DOS on the same CPU, was completely non-IBM-compatible and had diskette formats that were quite different. But as they were completely incompatible and thus could never be mixed, it might well have used the same media descriptors.

There was a variant of the Sirius with a 10 MB hard disk too, but as DOS 1.x did not support volumes larger than about 1 MB (and no subdirectories, in the Win world known as folders nowadays), the HD had to be partitioned into at least 10 tiny logical drives. Really unhandy! :D

I'm not sure about the IBM-XT here, but the IBM-AT with a 20 MB HD came with DOS 2.x right from the start, which supported subdirectories and could handle at least the 20 MB as a single volume. (These subdirectories were a quite new concept to us these days...)

Ah, that nostalgic stuff... :rolleyes:

If there really should be a mathematical reason for the limited number of clusters aside from 16-bit registers (which could have been easily overcome by sacrificing a little processing speed), I look forward to knowing it!

I'm quite interested in some more information about the OS you are going to build, in case you might want to reveal it. Is it going to run on a real machine or some virtual stuff? In either case: which architecture? Which feature set is the OS planned to suppord and shall it be compatible to something I might have already heard about? And last but not least: What language are you going to use to implement it?

Looking forward to your next post... :)

They never anticipated the NEED for a larger hard drive than 16-bit. DOS had to do some tricks to address memory, in the beginning.

Quote:

---

Originally Posted by Eri523

Master.,

I didn't really suspect you to be a high school kid, especially not after having a look at your profile page. ;) And the topic of your question as well as the way you asked didn't look like that either. But I have seen that there are some of them around here, regularly running into that "no homework" policy here on the forums. :) (Well, it's not really a strict "no homework" policy, but I'm not going into details as I think both of us are knowing what it's about.)

Starting with FAT (at least the incarnations 12 and 16, without VFAT) as an example of file systems appears to be a good choice to me, as they are fairly simple.

Thanks for instructing me about the history of that FAT signature; I didn't know that yet. I think the two disk formats supported by that DOS 1.x (on the IBM, see below) were the ones with media descriptors 0xFF and 0xFE.

I had used DOS 1.x myself on a Sirius/Victor (that looked quite high-end compared to my TRS-80 at home) long ago but I didn't delve into the details of its file system then. (I had already done that on the TRS-80 and some CP/M machines, though.) The Sirius, although using a variant of DOS on the same CPU, was completely non-IBM-compatible and had diskette formats that were quite different. But as they were completely incompatible and thus could never be mixed, it might well have used the same media descriptors.

There was a variant of the Sirius with a 10 MB hard disk too, but as DOS 1.x did not support volumes larger than about 1 MB (and no subdirectories, in the Win world known as folders nowadays), the HD had to be partitioned into at least 10 tiny logical drives. Really unhandy! :D

I'm not sure about the IBM-XT here, but the IBM-AT with a 20 MB HD came with DOS 2.x right from the start, which supported subdirectories and could handle at least the 20 MB as a single volume. (These subdirectories were a quite new concept to us these days...)

Ah, that nostalgic stuff... :rolleyes:

If there really should be a mathematical reason for the limited number of clusters aside from 16-bit registers (which could have been easily overcome by sacrificing a little processing speed), I look forward to knowing it!

I'm quite interested in some more information about the OS you are going to build, in case you might want to reveal it. Is it going to run on a real machine or some virtual stuff? In either case: which architecture? Which feature set is the OS planned to suppord and shall it be compatible to something I might have already heard about? And last but not least: What language are you going to use to implement it?

Looking forward to your next post... :)

---

thank you for your precious time :) i really appreciate it .
first of all this so called Os development, we the student ( i'd better say i :)) ) are planning to make, was not considered to be a huge stuff , just a tiny university project.
the prof told us to make a very simple os in asm which would boot up and then get installed and then provide us with some very basic utilities . it was never intended to be a huge project , most of the students are reluctant to these kind of projects , but not me , i've been always dreaming of a day which i would myself , try to make an os , its huge excitement to me .and now i got the chance.
our prof taught us this very simple OS development stuff for our system programming course. i find it exciting and want to continue it ,
i myself plan to code in C++, its easier for me , and the debugging is extremely easy , and needless to say i can implement what i have in mind easier .well as its plain as day im not gonna make another Windows7 :lol , )
the reason im so curios about these fat stuff is that , i like reinventing the wheel , let it be too primitive , but i like the challenge . and i really like to know how did those programmers, first os developers think and how they came up with a plan for their problems ?
i found a website which was so far so great for guys like me . :
http://www.brokenthorn.com/Resources/OSDev0.html

i really enjoyed talking to you , and still do :) )
again thankyou for your time
Hossein

Quote:

---

Originally Posted by dglienna

They never anticipated the NEED for a larger hard drive than 16-bit. DOS had to do some tricks to address memory, in the beginning.

---

thank you , but dont you think its little bit awkward to think like that ? i mean the fat developers . the industry was flourishing , and yet it is , how come they would think like that?

Because that was 25 years ago. 8088's were the HOT device at the time...

Hossein,

let's start with the end of your post: Thank you for the link to that OS development course. Really interesting! :cool: I immediately read the entire chapter 0 you linked to and after that put the TOC page into my favorites menu for later use. I have just wondered why this is on a site titeled Borken Thorn Entertainment. I suppose that for most people (even including lots of software developers) writing OSs is not what they would call fun... :D

Are you planning to use that emulator/debugger package that is mentioned there? This would answer my question about the "hardware" your OS is about to run on. I do not know that software myself, but I somehow doubt that it would directly support MSVC++ for instance, if you want to use that. Therefor I don't really see what you mean when you talk about easy debugging.

Surely you don't plan to make another Win7. If anyone would try to do that alone, the hardware it is supposed to run on will be obsolete by far when he finishes... ;) ... if, and only if that might be done in a single person's lifetime at all...

I have liked to re-invent the wheel sometimes myself too. It is not only a nice challenge but also can be a great training for learning new techniques. But as time went by, these wheels kept becoming more and more complex... :(

dglienna's point about what they thought while creating something like FAT16 sounds reasonable to me. The most "recent" book I have that covers these things is from 1992 (IOW pre-Win95 and in particular pre-FAT32). It talks about FAT16 partitions with a maximum size of 2 GB, using clusters of 32 kB (64 sectors). I did not take the effort of really thinking about whether more might have been possible. 32 kB per cluster is already unhandy enough. The first machine I ran Win95 on was a P133 with 64 MB of RAM (quite a lot then) and a 3 GB hard disk that was partitioned into three FAT16 volumes of 1 GB each (16 kB clusters). This looked like being at the edge of reason at that time. Note that FAT32 was not introduced until Win95b.

Missed something? Well, that would be something to look forward to in the next post... :wave:

by the ease in debugging , i meant , if i happen to mess sth up while i'm trying to code an os,
the C++ language is far more readable and hence easier to maintain than the Assembly language which i am now coding in .
and yes im planning to use that Bosch emulator ,if im not mistaken it completely emulates a PC so this will give me a chance to test my newly state of the art OShttp://smiley.ttaaeell.co.cc/bmc/TAE...20%2893%29.gif without ruining my whole system .:)
and about that win7 stuff yeah sure thing .
by the way i really liked that part you said about wheels ,

Quote:

---

"But as time went by, these wheels kept becoming more and more complex"

---

it is sure a bitter truth , anyway not everyone is meant to know everything as it is Impossible , being a deep well in one major is way better than being a shallow ocean in all majors .

and about the dglienna's previous idea and yours, well , i think you guys are right

Another one on re-inventing wheels (I knew I had missed something... :D):

At least once I have done something like the complete opposite of re-inventing: Once I encountered severe performance issues repeatedly scanning a large linked list in a loop. After some thinking, I added some auxiliary pointers to the list that allowed me to skip a number of list items under certain (quite common) circumstances, thus allowing some kind of "fast forward" on the list. It gave me a dramatic performance boost and I was quite proud of what I had written there, bur didn't pay too much attention to it afterwards.

Some years later, some university guy (well, he became quite famous in the meantime, so I terribly under-rate him by using that term :blush:) came up with a basically quite similar thing, put it on a nice mathematical base and published it. Today this data structure is commonly known as skip list.

BTW, later I noticed that similar or even better results could be accomplished using an array of linked lists under the right circumstances. This is by far not that esoteric though... :D

And, Hossein, how did you manage to put that spectacular bouncing smily into your post?

Quote:

---

Originally Posted by Eri523

Another one on re-inventing wheels (I knew I had missed something... :D):

At least once I have done something like the complete opposite of re-inventing: Once I encountered severe performance issues repeatedly scanning a large linked list in a loop. After some thinking, I added some auxiliary pointers to the list that allowed me to skip a number of list items under certain (quite common) circumstances, thus allowing some kind of "fast forward" on the list. It gave me a dramatic performance boost and I was quite proud of what I had written there, bur didn't pay too much attention to it afterwards.

Some years later, some university guy (well, he became quite famous in the meantime, so I terribly under-rate him by using that term :blush:) came up with a basically quite similar thing, put it on a nice mathematical base and published it. Today this data structure is commonly known as skip list.

BTW, later I noticed that similar or even better results could be accomplished using an array of linked lists under the right circumstances. This is by far not that esoteric though... :D

And, Hossein, how did you manage to put that spectacular bouncing smily into your post?

---

about that inventing the wheel you did in the past , would it not qualify you to be the first one who created that kind of algorithm or stuff ?
as you mentioned that university guy presented an optimized version of the fast skip ?!

and about that smiley , there is a website which have many great smileys called kolobok, you can use that website , aside from that there is also an application which gives you alot of these cool smileys , you can find it here the good part about this software is that , you can add your own smileys and thus it saves you the trouble of copying -pasting the urls.
you find your desired smileys at kolobok, and get their url and import them to this software , now the rest is a piece of cake .
you can find many smilies like these by googling .
----
Free Smileys
smileyarena