On Tue, 1 Dec 1998, Nestor Soriano wrote:

> >To determine if a drive uses a DOS-FAT12 or a DOS-FAT16 system: I don't
> >think you can derive this information from a bootsector of a partition;
> 
> Of course you can:
ok!

> 
> - 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.
> 
> Now look at position #36. You will find either the string "FAT12" or "FAT16".
> 
So if we will make some fat16-formattingprogram, we will have to format in
MS-DOS 4 way.

> 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.
> 
> >but it can be obtained from the MasterBootRecord of a harddisk. (=absolute
> >sector 0) This sector contains the partition table and for each partition
> >also a kind of code (#00=disabled partition, #01=DOS-FAT12, #xx Linux,
> >#yy=DOS-FAT16 #zz=DOS-FAT32LBA etc., etc.)
> 
> There is four primary partition entries in the physical sector 0:
> 
> #1BE: First partition entry
> #1CE: Second partition entry
> #1DE: Third partition entry
> #1EE: Fourth partition entry
> 
> Data in these partitions are:
> 
> +0: #80 = Active partition
>     #00 = Not active partition
To be more exactly:
      #80 = boot from this partition at starup
      #00 = don't boot from this partition at startup
(so only one of the four entries can have #80)

> +1: Head of first sector
> +2, +3: Cylinder and sector of first sector, in a strange format designed
> for PC BIOS
> +4: Partition type. Intiristing types for us are:
>     #0: Unused 
#00 =partition disabled

>     #1: MS-DOS, FAT12, <32Mb
>     #4: MS-DOS, FAT16, <32Mb
>     #5: MS-DOS, extended
>     #6: MS-DOS, >32Mb
> +5: Head of last sector
> +6,+7: Cylinder, sector of first sector (see +2,+3)
> +8 - +11: First physiscal sector of partition
> +12: Partition lenght in sectors
> 
> 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.

> 
> If partition is extended, search for a new partition table in its first
> sector.
> 
> >I think it is a good idea to pass this information through the GETDPB
> >(Get diskparameter block function, address #4016 I think) A DPB field is
> >21 bytes long and it is filled in by the diskrom.
> 
> It is easier to rely in the clusters number cryterium, I think. Then DPB
> format must not be modified.
nevertheless the DPB can be used for passing extra info about
read/writeable, devicetype (SCSI/ATA-IDE/ATAPI/...), ...

It should be possible in future to use a single program for playing
audiocd's on all types of interfaces, setting read-only, ... The way to go
is to define some new rombiosentries (for example for sending
commandpackets to SCSI or ATAPI devices, enabling/disabling readonlymode,
...)
Obtaining the devicetype can be done by GETDPB for a specific 
localdrivenumber. Note the fact that at one interface there can be more 
than one devicetype (for example a hd and a cdrom) so you must get a
devicetypenumber for each localdrive.

A CDplayerprogram can look for such a device and if it exists, communicate
with it through the newdefined biosentries.

It is also useful for a new DOSkernel(or your patch): when it gets the DPB
of a drive and the devicetype is a CDROM, it can read cdromsectors
through diskio and interpret them as a cdromdirectory; no msxcdex is
needed anymore.


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.

I think all agreed on using bit7 of the localdrivenumber to indicate 32bit
sectornumbers.

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

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)

Jon




****
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/)
****

Reply via email to