>I ditched up some info on partition/disk formats used on PC systems,
>I found it in a program called HelpPC, in the DOS collection on
>SimTel download site.
>It seems a bit old (dated 1991 or so), but I have a feeling this was
>checked with/compiled from info on many systems, and might be a good
>reference.
Good idea. But I don't agree in the meaning of clusters above #(F)FF0.
Let's discuss later... 8-)
>Anyway, the best way to determine how to make this distinction in
>parttitions & disk types, I think would be to read out exact
>bootsector-info, and maybe some of the first or last data sectors/FAT
>elements, from as many actual disks you can find, like:
Knowing disk size, FAT type and such parameters, why we need to know the
disk type?
>hint: forget about MSX HD's, you might check'm, but I have a feeling
>the way many of these are partitioned, is incompatible with other
>systems, using some home-built format...
But the format of the boot sector of each partition must be the same, else
MSX-DOS would not manage it.
Another question is where to find the start of each partition: if disk has
not the standard disk partition table that you describe below, only the
device which formatted the disk knows how these partitions are arranged.
MegaSCSI disks formatted with ESE-ASPI format and disks formatted with IDE
interface have this table. I don't know about how do it old SCSI controllers.
>BTW: on formatting a disk, I think it would be best to fill in every
>field in the bootsector that you know the meaning of, when you can
>fill it some meaningfull way. Regardless of wheter you think it's
>used or not.
>(You know Murphy; if you don't, it'll give trouble some place)
All the fields' meaning are clear. No? You and me are clearing it now,
right? ;-)
>-According to this info, cluster numbers FF0h (FAT12) and FFF0h
>(FAT16) can be used, only FF1h resp. FFF1h and higher have special
>meaning. I thought someone mentioned earlier, that FF0h resp. FFF0h
>had this special meaning (bad cluster), which doesn't match this
>info.
I find in the Microsoft page the following information recently:
"MS-DOS determines the FAT size based on the number of clusters.
If there are 4085 or fewer clusters, a 12-bit FAT is used.
If there are 4086 or more clusters, a 16-bit FAT is used."
In a FAT12 system with 4085 clusters, maximum cluster number is 4086 (first
one is 2). This is #FF6. Just add another F for FAT16 systems. I think that
in this subject, for the first time in my life, I agree with Micro$oft! 8-)
>-What does this 'number of hidden/reserved sectors' in the bootsector
>(word at offset 1Ch) stand for?
>If I'm not mistaken, this normally reads 0001h, and I suspect this
>might be the number of sectors before the FAT(s). So, normally 1 (1
>bootsector), but if different, this would mean: bootsector, some more
>'reserved/hidden sectors', FAT, etc.
>But is that actually true? Does anyone have some good info on
>that?
You're right and mistaken at the same time. Ok, step by step. What you
described is the "number of sectors unused by MS-DOS", with offset #0E. It
is normally 1, referring to the boot sector itself, as you said.
Offset #1C, which is normally 0 and not 1, seems to be the number of
sectors BEFORE the boot sector! At least, this is true in ZIP disks (boot
sector is placed in the physical sector #14, and data in #1C is #0014,
coincidence?). Anyway I think it is not used by system. In ESE-ASPI disks
this field is always 0, and all partitions are recognized by my PC.
>-In relation to this: what exactly is the number of the 1st data
>sector? You might think: number of FATs x sectors per FAT +
>directory sectors (#entries/16) + 1 bootsector.
>Looking at the above, it might also be: number of FATs x sectors per
>FAT + directory sectors + number of reserved sectors.
>As these are normally 1, it wouldn't differ, but if this field is
><>1, what would be the right calculation method then?
The second answer is the correct one. But as you say, this is always 1 so
it is not worth to worry about it.
>-Isn't it so that clusters 0 & 1 are normally not used (FAT entries
>for this filled with media descriptor and FFh's), and that the first
>data sector(s) corresponds with cluster #2?
>How is this for FAT16?
Yes, clusters 0 and 1 do not exist, and in a disk with N clusters they have
numbers from 2 to N+1.
In a FAT12 disk, first three bytes of FAT are always "<ID> FF FF". In a
FAT16 disk, these bytes are four: "<ID> FF FF FF".
>I think generally, the best way to determine the disk format, is to
>check first whether it is a valid bootsektor. Like check if 1st
>byte=EBor E9h, maybe check some other things, and if correct, try to
>determine the actual format from the bootsector parameters.
To check the first byte=EB/E9, the sector size=512 and the cluster size=2^n
should be enough I think. Also, first FAT bytes can be check for searching
"<ID> FF FF (FF)". MSX-DOS does something like this.
>(and use calculated number of clusters to separate between
>FAT12/FAT16, as Nestor suggested).
(-v-)v
>F9: double sided disk (720k) on MSX, used for several different types
>of disk on PC.
1.2M and 720K disks.
>F0: would be 'illegal' (at least I haven't seen any 'official'
>definition of this one anywhere), but I've seen it used for RAMdisks,
>MSX HD's, etc.
M$ says:
"F0: other media (e.g. floppy, double-sized, 18 sectors per track --
1.44M,3.5")"
>If all fails: 'unsupported disk type'
Or just "not a DOS disk".
>Then there's something else to note:
>You all talk of FAT12 <-> FAT16, like there's nothing else. Ofcourse
>these 2 are most common I'd say, but there's also FAT32 (Win95), HPFS
>(High Performance Filing System, used with OS/2?), NTFS (Windows NT
>file system), etc. etc. (different formats for Unix as well?).
I promise you that I'll be really happy with FAT16! I don't need more!! 8-)
>Ofcourse you can't handle all these file systems, but it would be
>usefull to know exactly what defines a FAT12 or FAT16 disk, and what
>might be some other format.
I think the described methods are enough...
>> > - Look at position #26 of boot sector. If it is #29, the disk is
formatted
>> > with MS-DOS 4 or higher. Then it can be either FAT12 or FAT16.
>So, for instance for FAT32, this byte would be <>29h ?
>I have my doubts on that one...
If FAT32 uses same bootsector as FAT12/16 (I don't know), surely you will
find "FAT32" string. And if same cryterium is used as in the FAT12->16
case, then "FAT32 is used when clusters number is greater than
65536-something". 8-)
>> > Now look at position #36. You will find either the string "FAT12" or
"FAT16".
>Sure...for MS-DOS compatible formatted disks.
MS-DOS 4 or higher!
>And how about disks
>formatted with PC-DOS, or DR-DOS? I have my doubts...
>Not there for MSX formatted disks either.
Because of this, I proposed to rely on the clusters number for determine
the FAT size.
>The info attached to this mail says:
>FF1h (4081 decimal) or more clusters -> FAT16
>less -> FAT12
M$ says NO! 8-)
Besides this should be no problem. Look at this table (also a gift from M$
page):
Drive size FAT type Sectors per cluster
---------- -------- -------------------
0MB-15MB 12 8
16MB-127MB 16 4
128MB-255MB 16 8
256MB-511MB 16 16
512MB-1023MB 16 32
1024MB-2048MB 16 64
If you calculate the number of clusters for every exterme case (for example
128MB-1byte with 4 sectors/per cluster) as ((size in Kbytes)*2-(512 sectors
per 2 FATs)-(32 sectors per 512 root directory entries)-(boot
sector))/(sectors per cluster), you will obtain always a number below 65521
(#FFF1). Try it! ;-)
>BTW. does this number of clusters include cluster number 0 & 1?
No. Clusters 0 and 1 just do not exist.
>This would also determine a MINIMUM size for FAT16 formatted disks
>(which would then be FF1h clusters, with 1 sector per cluster, some 2
>MB.). You might check that against the total number of sectors; if a
>disk would be too small even for this, then it's surely not FAT16
>formatted.
Yes, but... too forced checking method I think.
>> > Head and cylinder can be ignored, in fact MegaSCSI puts it to 0 when
doing
>> > ESE-ASPI format.
>> I don't think this is a good idea; this chs-data should be filled in so
>> you can connect this hd to a pc. Like you said: it is used by pcbios.
>Yep, fill it in if possible.
It is not necessary if you don't want to boot in a PC with this disk.
>What's the problem on working with 32-bit sector numbers anyway? Is
>it so difficult for programmers to handle 32 bits, if they already
>HAVE to handle 24 bits?
For passing a sector number to a physical disk access routine you need
three registers if sector number is 24bit, four if it is 32bit. It is the
only problem I see, and not very big.
>Didn't anyone notice, that MSX-DOS (1 as well) already uses 32-bit
>numbers for file sizes? I can't remember ever hearing a programmer
>complain that that gave so much work, if only it were 24 bits...
Who designed MS-DOS wanted to be well prepared for future expansions, so 32
bits were reserved for file sizes even if first disks had a maximum size of
32Mb. MSX-DOS is just a copy of MS-DOS in this subject.
>> Advantages of the DE-pointer: I can't find any.
>> Advantages of the fixed address: faster
>Wrong! With the pointer-method I proposed, programmers CAN set unused
>bits once, and leave these unchanged between calls, if they want to.
>As I mentioned, the driver should only use it as input, and not
>modify it. The programmer can put such a sector number anywhere
>he/she likes, and simply pass the address of it.
Right... and as I said already N times: I don't like the idea of modifying
MSX work area.
>BTW. the number of sectors is defined as 1...255, and it may actually
>be 255 (!), because for MSX-DOS 1, the sector size need not be 512,
>but can be smaller or bigger, like 128, 256 or 1024 bytes.
>So it's perfectly possible that some old DOS1-compatible driver
>could be passed 255 sectors to read/write, if it would use a 128 byte
>sector size (some 32 KB. this would be).
<>512 bytes for sector size? This really exists??
>Ofcourse most interfaces use only 512 byte sector size, and this was
>fixed for DOS2, I think.
In DOS2, sector size is officially always 512.
-----------------------------------------------------------------------------
Konami Man - AKA Nestor Soriano (^ ^)v - Itsumo MSX user
http://www.geocities.com/SiliconValley/Bay/9797/msx.htm
[EMAIL PROTECTED] ICQ#: 18281450
"In Windows 98, 3.000 found failures of W95 have been corrected..."
Translation: 3.000.000 not found failures continue without being corrected...
----------------------------------------------------------------------------
-
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED] and put
in the body (not subject) "unsubscribe msx [EMAIL PROTECTED]" (without the
quotes :-) Problems? contact [EMAIL PROTECTED] (www.stack.nl/~wiebe/mailinglist/)
****
