Hi all,
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.
I attached the info on partition tables, bootsector & FAT info to
this mail, hope you will get it okay...
I suggest you put such info from different sources side by side, and
make some comparisons, maybe that will clear up some points which
aren't quite clear.
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:
MSX formatted disk (SS)
" " " (DS)
" " " (SS/DS, formatted with DOS2)
MSX-formatted HD disk?
PC 720k format
PC 1.44M format
If you have a PC:
your own harddrive (and maybe 2nd or 3rd)
maybe the same on some of your friend's PC's
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...
Put that side by side, and that should make it pretty clear how such
bootsectors, partition tables etc. are actually used/filled in with
current systems.
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)
Fields that are not really clear: give 'm the same values they have
on other systems; if these are different, give 'm the most commonly
used value, or make 'm 0, etc.
Some interesting things:
-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.
-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?
-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?
-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?
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.
(and use calculated number of clusters to separate between
FAT12/FAT16, as Nestor suggested).
If this fails, take 1st byte (media descriptor) of sector 1 (which
should be assumed to be the 1st FAT sector then), and see if you can
match that with some known disk format.
I would do this only as a last resort, the media descriptor alone is
rather unreliable, as it's used very differently across systems. For
instance:
F8: SS disk on MSX, harddisk on PC.
F9: double sided disk (720k) on MSX, used for several different types
of disk on PC.
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.
If all fails: 'unsupported disk type'
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?).
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.
If you only say, oh: no FAT12 -> FAT16, you might screw up badly a
disk if it was formatted with FAT32 or some other system. As before,
you don't have to be able to handle it, but it's sure usefull to be
able to spot it.
Jon De Schrijder <[EMAIL PROTECTED]> wrote:
> > - 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...
> > Now look at position #36. You will find either the string "FAT12" or "FAT16".
Sure...for MS-DOS compatible formatted disks.
But for all important versions (4.x, 5.x, etc.) ? And how about disks
formatted with PC-DOS, or DR-DOS? I have my doubts...
Not there for MSX formatted disks either.
> > You can also look at the number of clusters (calculated from the number of
> > sectors, the cluster size, and the number of sectors used for FAT and
> > directory). 4086 clusters or more means FAT16 in use, else, FAT12.
The info attached to this mail says:
FF1h (4081 decimal) or more clusters -> FAT16
less -> FAT12
sounds logical here, when FF1h would be the 1st value for a cluster
number, that has a special meaning.
If you put that border on 4086 clusters (FF6h), what about clusters
FF1-FF5 then? Were these not illegal (as 'normal' cluster numbers,
that is) for FAT12 disks?
BTW. does this number of clusters include cluster number 0 & 1?
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.
> > 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.
> BTW what is the state of the DISKIO 32(24)bit entry??
>
> 24bit/32bit:
> *advantages 24bit: faster, current interfaces already use 24bit
> sectornumbers (they can handle large (partitioned) harddisks; but the
> absolute (24bit or bigger?) sectoraddresses are sent to the hd)
> I know about the IDE that handling 24bitnumbers is a lot easier than more.
> (there is a 24bit division needed to convert the logical sectornumber to
> chs-format (Cylinder,Head,Sector))
> Since most users will never attach an hd >24bitsectors, it is a waist of
> time to perform 32bit division...)
> *advantages 32bit: the ability to attach extremely big hd's to your msx.
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?
When you need to write a 24-bit division routine (>16 bit), it's
probably a small extra trouble to make it 32 bit right there.
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...
So why not make it a 32-bit number? It's easy now, and might save a
lot of trouble later on. If you think you don't need 'm, just zero
the higher bits. But if you CAN use 32-bit sector numbers, they would
be supported by the rest of the system as well, no need to write your
own DOS version for that.
> What about the sectornumber itself?
> *complete number is fetched from memory, pointed by DE
> *lowword in DE, highword from a fixed location in page3 (>#f380)
> Note that in both cases for every diskiocall the memory which keep a part
> of the sectornumber has to be updated by the calling program. (necessary
> when the sectornumber exceeds the 16bit boundary when reading/writing more
> than one sector) So it has not the advantage of 'if we have to read/wr a
> lot of sectors, just leave the highwordmemorylocation unaltered.'
> It is much faster to rewrite this memorylocation always, than to check if
> the 16bitboundary will be exceeded.
>
> 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.
With the high part of the sector number at some fixed location, you
WOULD have to set that entirely for each call, as such a location
might be used for other purposes between DISKIO-calls.
Besides: even with a 24-bit sector number: would you keep that stored
entirely in Z80 registers throughout an important part of your
program?
I don't think so. You'll probably put that in some memory location
anyway.
With my method, you can just pass the address of that, and you're
done. With the other method, you'd have to fetch this number, and
store it elsewhere before each DISKIO-call.
> The other parameters: Carry for write/read, HL=DTA B=#sectors C=mediaID
>
> Question: does someone know if the output of the function is specified?? I
> know of Carry and A-register for indicating errors. But I've read
> somewhere also B-register for indicating the 'amount of read sectors'???
> Is this true? (I don't think so)
I quote from the MSX Technical Databook:
Outputs:
If successfull, carry flag cleared
Otherwise, carry flag set,
A = error code
(0, 2, ..., 12, some more codes for DOS2)
B = number of remaining sectors
And this number of remaining sectors is actually returned in
practice, although this is used seldom by programs.
(equal to input number if nothing could be done)
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).
Ofcourse most interfaces use only 512 byte sector size, and this was
fixed for DOS2, I think.
I'm not sure about 0 sectors, although 'illegal', should this be read
as 256 (most likely crashing the machine), or as 'do nothing'?
Greetings,
Alwin Henseler ([EMAIL PROTECTED])
http://huizen.dds.nl/~alwin/msx (MSX Tech Doc page)
HelpPC 2.10 Quick Reference Utility Copyright 1991 David Jurgens
Boot Sector (since DOS 2.0)
Offset Size Description
00 3bytes jump to executable code
03 8bytes OEM name and version
0B word bytes per sector
0D byte sectors per cluster (allocation unit size)
0E word number of reserved sectors (starting at 0)
10 byte number of FAT's on disk
11 word number of root directory entries (directory size)
13 word number of total sectors (0 if partition > 32Mb)
15 byte media descriptor byte (see MEDIA DESCRIPTOR)
16 word sectors per FAT
18 word sectors per track (DOS 3.0+)
1A word number of heads (DOS 3.0+)
1C word number of hidden sectors (DOS 3.0+)
20 dword (DOS 4+) number of sectors if offset 13 was 0
24 byte (DOS 4+) physical drive number
25 byte (DOS 4+) reserved
26 byte (DOS 4+) signature byte (29h)
27 dword (DOS 4+) volume serial number
2B 11bytes (DOS 4+) volume label
36 8bytes (DOS 4+) reserved
- implementation format not guaranteed in all OEM DOS releases
- BIOS expects a boot sector of 512 bytes
- DOS 3.2 began reading BIOS Parameter Block (BPB) information from
the boot sector, previous versions used only the media byte in FAT
- DOS 4.x added offsets 20-3Dh and offset 20h determines the number
of sectors if offset 13h is zero
- hard disks have a master boot record and partition boot records;
the master boot record and Disk Partition Table (DPT) share the
same sector
HelpPC 2.10 Quick Reference Utility Copyright 1991 David Jurgens
FAT - File Allocation Table
12 Bit Meaning 16 Bit
000 free space 0000
FF1-FF7 bad track marking FFF1-FFF7
FF8-FFE may be used to mark end of a file chain FFF8-FFFE
FFF standard marker for end of a file chain FFFF
- the FAT is implemented as an array containing a linked list
for each file; the files directory entry has a pointer to the
first cluster which contains the cluster number of the next
cluster in the chain until the pointer contained is FFFh
(12 bit FAT) and FFFFh (16 bit FAT) marking end of file
- DOS maintains two copies of the FAT, but does not use the
second copy for anything other than a mirror image of the
first; CHKDSK doesn't even read the second FAT
- disks with FF1h clusters and above use 16 bit FAT tables, disk
with less use 12 bit FAT tables
- DOS 4.x did not change the size of the cluster number as some
suggest, but instead increased the size of the sector number
- bytes 0 of the FAT contains the Media Descriptor Byte
Calculating 12 bit FAT Entries
1. Get starting cluster from directory entry.
2. Multiply the cluster number just used by 1.5
3. The whole part of the product is the offset into the FAT,
of the entry that maps to the cluster in the directory.
This entry contains the number of the next cluster.
4. Move the word at the calculated FAT into a register.
5. If the last cluster used was an even number, keep the low order
12 bits of the register, otherwise, keep the high order 12 bits.
6. If the resultant 12 bits are (0FF8h-0FFFh) no more clusters
are in the file. Otherwise, the next 12 bits contain the
cluster number of the next cluster in the file.
Calculating 16 Bit FAT Entries
1. Get the starting cluster of the file from the directory.
2. Multiply the cluster number found by 2.
3. Load the word at the calculated FAT offset into a register.
4. If the 16 bits are (0FFF8h-0FFFFh) no more clusters are in
the file. Otherwise, the 16 bits contain the cluster number
of the next cluster in the file.
To convert the cluster to a logical sector number (relative
sector, similar to that used by DEBUG, int 25h and 26h):
1. Subtract 2 from the cluster number
2. Multiply the result by the number of sectors per cluster.
3. Add the logical sector number of the beginning of the data area.
- see MEDIA DESCRIPTOR
HelpPC 2.10 Quick Reference Utility Copyright 1991 David Jurgens
Disk Partition Table (Fixed disk boot record)
Offset Represents: (see format below)
01BE Partition 1 data table (16 bytes)
01CE Partition 2 data table (16 bytes)
01DE Partition 3 data table (16 bytes)
01EE Partition 4 data table (16 bytes)
01FE Signature (hex 55 AA, 2 bytes)
Offset from beginning of partition data shown above:
Offset Size Description
00 byte boot indicator
01 byte beginning sector head number
02 byte beginning sector (2 high bits of cylinder #)
03 byte beginning cylinder# (low order bits of cylinder #)
04 byte system indicator
05 byte ending sector head number
06 byte ending sector (2 high bits of cylinder #)
07 byte ending cylinder# (low order bits of cylinder #)
08 dword number of sectors preceding the partition
0B dword number of sectors in the partition
Boot indicator (BYTE)
00 - non-bootable partition
80 - bootable partition (one partition only)
System Indicator (BYTE)
00 - unknown operating system
01 - DOS with 12 bit FAT, 16 bit sector number
02 - XENIX
04 - DOS with 16 bit FAT, 16 bit sector number
05 - DOS Extended partition (DOS 3.3+)
06 - DOS 4.0 (Compaq 3.31), 32 bit sector number
51 - Ontrack extended partition
64 - Novell
75 - PCIX
DB - CP/M
FF - BBT
Signature
Hex 55AA marks the end of valid boot sector. This is also
required in each of the partition boot records.
Sector/Cylinder
2 bytes are combined to a word similar to INT 13:
³7³6³5³4³3³2³1³0³ 1st byte (sector)
³ ³ ÀÄÁÄÁÄÁÄÁÄÁÄÄ Sector offset within cylinder
ÀÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄ High order bits of cylinder #
³7³6³5³4³3³2³1³0³ 2nd byte (cylinder)
ÀÄÁÄÁÄÁÄÁÄÁÄÁÄÄÄÄÄ Low order bits of cylinder #
- all partitions begin on sector 1 head 0, except the first
partition which follows the disk's master boot record and begins
in sector 2
- some of this information may vary with some variants of DOS 3.2
and DOS 3.3 that use their own sectoring scheme for large disks
- see INT 21,32 Disk Partition Table
