SOLUTION TO 1024 CYLINDER LIMIT
Tom Maki
sza...@saul2.u.washington.edu (Janos Szamosfalvi) writes:
>If "HALF THE WORLD" weren't stupid they'd switch to SCSI. ;-)
>
>No more problem with 1024+ cylinders, with more than 2HD's, with
>slave/master setups, etc., etc., ad nauseam. But if the few
>bucks of savings worth the grief, go for it!! <GRIN>
Well, I agree that SCSI is a better interface, but you can still run
into problems-- recently I got a Toshiba 3501B CD-ROM... the first one
wasn't recognized during the SCSI bus scan... I returned it and had
the same problem with the second... figured out the drive was expecting
'host initiated negotiation' and my Ultrastor 34f was configured for
'target initiated negotiation'!
Also, the >1024 cylinder problem still exists for SCSI. I have a 2GB DEC
drive that has 2082 cylinders-- even with 64 sides, 63 sectors/track
translation I would lose a few MB if I ran DOS (luckily I don't; I just
have to be careful where I put my boot partitions).
Cheers,
tom
maki...@gold.tc.umn.edu
Stannon Yen
>Come up with your ONE-AND-ONLY, FANTASTIC, LOW-COST (!!!!) SOLUTION to the
>1024 cylinder problem that HALF THE WORLD IS SUFFERING FROM.
Is the 1024 cylinder limit really so serious? I have a 540MB HD and
I solve the problem by simply partition the HD. It's extremely easy and
I think every DOS user should consider it. Smaller partition gives small
cluster size and save more space, BTW.
Regards,
CT Yen.
--
Ham sandwich is better than nothing.
Nothing is better than always lucky.
Therefore, ham sandwich is better than always lucky.
Peter Herweijer
>Herman Vroomen (hvroomen@prle) wrote:
>
>: Come up with your ONE-AND-ONLY, FANTASTIC, LOW-COST (!!!!) SOLUTION to the
>: 1024 cylinder problem that HALF THE WORLD IS SUFFERING FROM.
>
>If "HALF THE WORLD" weren't stupid they'd switch to SCSI. ;-)
>
>No more problem with 1024+ cylinders, with more than 2HD's, with [...]
Duh. People buying (E)IDE interfaces without BIOS run into problems. Big
deal. People buying SCSI interfaces without BIOS can't even BOOT.
Therefore, EIDE is superior to SCSI :^P
That should be enough stupid talk for this week. We now go back to our
scheduled programme...
- Peter Herweijer
pie...@sci.kun.nl
Janos Szamosfalvi
: Also, the >1024 cylinder problem still exists for SCSI. I have a 2GB DEC
: drive that has 2082 cylinders-- even with 64 sides, 63 sectors/track
: translation I would lose a few MB if I ran DOS (luckily I don't; I just
: have to be careful where I put my boot partitions).
That`s probably the limitation of DOS -- no single partition can
exceed 2 gigabytes.
Janos Szamosfalvi
: >If "HALF THE WORLD" weren't stupid they'd switch to SCSI. ;-)
: >
: >No more problem with 1024+ cylinders, with more than 2HD's, with [...]
: Duh. People buying (E)IDE interfaces without BIOS run into problems. Big
: deal. People buying SCSI interfaces without BIOS can't even BOOT.
And which SCSI HA's comes without ROM? The HA for CD-ROM's and the
sound-cards....
Phil Ngai
>If "HALF THE WORLD" weren't stupid they'd switch to SCSI. ;-)
At least IDE users don't have to deal with different SCSI devices
having the connector on different sides of the board and twisted
flat cables...
--
A well-regulated militia being essential to the security of a Free State,
the right of the states to form militias shall not be infringed.
Stannon Yen
>DOS will only allow partitions within the 1024 cylinder limit. Whether you
>create one large partition, or a bunch of small ones doesn't matter. You
>still can't get beyond the 1024 cylinders. Its still a good idea to use
>small partitions, for as you mention, the benefit is small clusters. With
>OS/2, you are better off with large partitions since the clusters are
>always 512bytes. OS/2 must boot from partition within 1024, however can
>use data-partitions beyond 1024.
But you can create an extented partition with > 1024 cylinders
and create logical partitions in the extented partition. Which is what I
have done. And you may then fully utilize the HDD.
James L. Triplett
In article <D2Lquo.1J4@eng_ser1.erg.cuhk.hk>, yen...@cs.cuhk.hk (Stannon Yen) writes:
>bk...@FreeNet.Carleton.CA (George Gebara) writes:
>
>>DOS will only allow partitions within the 1024 cylinder limit. Whether you
>>create one large partition, or a bunch of small ones doesn't matter. You
>>still can't get beyond the 1024 cylinders. Its still a good idea to use
>>small partitions, for as you mention, the benefit is small clusters. With
>>OS/2, you are better off with large partitions since the clusters are
>>always 512bytes. OS/2 must boot from partition within 1024, however can
>>use data-partitions beyond 1024.
>
> But you can create an extented partition with > 1024 cylinders
>and create logical partitions in the extented partition. Which is what I
>have done. And you may then fully utilize the HDD.
>
>
doesn't matter how creatively you partition it; DOS can only use 1024
cylinders! That is why LBA was invented: to translate the drive parameters
into one that DOS can use. If your drive has 2100 cyl, 16 heads, DOS will
only see 1024 cyl, 16 heads. Using LBA convinced DOS on my computer that
it was 524 cyl, 64 heads. THEN DOS can use it with no problem, and you
can use the entire drive capacity!!!
--
=====================================================================
| James L. Triplett, FMS Programmer | "Eagles soar, but weasles |
| Honeywell ATS, Phoenix, Arizona | never get sucked into jet |
| trip...@ecc6.ateng.az.honeywell.com | engines" |
=====================================================================
Peter Herweijer
>No, no, no! Without LBA, FDISK will still only see 1024 cylinders! It
>doesn't matter how creatively you partition it; DOS can only use 1024
>cylinders! That is why LBA was invented: to translate the drive parameters
>into one that DOS can use.
Still not right. LBA has nothing to do with breaking the 1024 cylinder
barrier. I know that the two are often equated...
>Using LBA convinced DOS on my computer that it was 524 cyl, 64 heads.
...for example, in BIOS setups. Nevertheless, it is _translation_ which
convinced DOS, not LBA. This is equally possible using oldfashioned CHS
style addressing.
LBA was invented because the CHS style address has lost all relation to
physical geometry anyway. It is a minor optimization, no more.
- Peter Herweijer
pie...@sci.kun.nl
John H. Anderson
>trip...@ecc8.ateng.az.honeywell.com (James L. Triplett) writes:
>
> >No, no, no! Without LBA, FDISK will still only see 1024 cylinders! It
> >doesn't matter how creatively you partition it; DOS can only use 1024
> >cylinders! That is why LBA was invented: to translate the drive parameters
> >into one that DOS can use.
>
>Still not right. LBA has nothing to do with breaking the 1024 cylinder
>barrier. I know that the two are often equated...
Isn't there a FAQ on these questions?
Where is it?
*************************************
* John H. Anderson *
* Internet: john-a...@ti.com *
* N5OPY *
* CompuServe: 71174,2625 *
*************************************
George Gebara
> trip...@ecc8.ateng.az.honeywell.com (James L. Triplett) writes:
>
> >doesn't matter how creatively you partition it; DOS can only use 1024
> >cylinders! That is why LBA was invented: to translate the drive parameters
> >into one that DOS can use.
>
> barrier. I know that the two are often equated...
>
>
> convinced DOS, not LBA. This is equally possible using oldfashioned CHS
> style addressing.
>
> LBA was invented because the CHS style address has lost all relation to
> physical geometry anyway. It is a minor optimization, no more.
>
Using Logical Block Addressing in itself does not solve the partition size
barriers, however "LBA" as a standardized method of bios-drive-os
interaction certainly does.
Peter Herweijer
>Using Logical Block Addressing in itself does not solve the partition size
>barriers, however "LBA" as a standardized method of bios-drive-os
>interaction certainly does.
DOS interacting with the BIOS using LBA? What have you been smoking?
- ph
James L. Triplett
LBA pro, and about all it does is drive parameter translation. Doesn't LBA
stand for Logical Block Addressing? (as opposed to "physical", i.e., what
the drive reports to DOS)
Stannon Yen
>That's only what you THINK you have done. DOS can never access cylinders
>outside the 1024 cylinder limit with the notorious 10 bit addressing.
>That's why SCSI, EIDE and other advanced hardware / software solutions
>involve the sector translation, without which you are wasting 30 megs or
>so out of your 540MB drive. It's well addressed in the FAQ.
Alright! I HAVE partition a CONNER 540MB harddisk with my 3yr old
386DX-40 / ISA / IDE controller into a 250MB primary and a 290MB
extended partition. And in the 290MB extended partition, I made 250MB
logical partition and a 40MB logical parition. Which they sum up into
3 partitions (3 Drive letters) and 540 million bytes in total. I copy
image data into both the primary and the logical paritions until all
the partitions are full. And then I selectively check the image files
(from begin to bottom) on all partitions and they all prove to be valid.
This is what I HAVE DONE. I did that purely for testing and the
result proved that I can make use of the whole 540MB of the HDD without
using any special disk manager. It is NOT my imagination and NOT WHAT I
THINK I HAVE DONE.
The test may not tell that it works on all HDDs but it at least show
that it works on my case - which is a case with old, nothing special
configurations.
Stannon Yen
>No, no, no! Without LBA, FDISK will still only see 1024 cylinders! It
>doesn't matter how creatively you partition it; DOS can only use 1024
>cylinders! That is why LBA was invented: to translate the drive parameters
>into one that DOS can use. If your drive has 2100 cyl, 16 heads, DOS will
>only see 1024 cyl, 16 heads. Using LBA convinced DOS on my computer that
>it was 524 cyl, 64 heads. THEN DOS can use it with no problem, and you
>can use the entire drive capacity!!!
FDISK DO report 1060 cylinders when I partition my HDD. I have tried
using sector translation well before by changing 1060 cyl, 16 head into
530 cyl, 32 head and it turn out to be a complete failure after a little
less than 1MB of files are copied onto the HDD.
Peter Herweijer
>FDISK DO report 1060 cylinders when I partition my HDD.
Are you using OS/2, Linux or whatever? There is no way Microsoft DOS'
FDISK will report 1060 cylinders.
>I have tried using sector translation well before by changing 1060 cyl,
>16 head into 530 cyl, 32 head and it turn out to be a complete failure
Well, yes, it's your BIOS that's supposed to do translation, not you
yourself.
- Peter Herweijer
pie...@sci.kun.nl
George Gebara
>
> >Using Logical Block Addressing in itself does not solve the partition size
> >barriers, however "LBA" as a standardized method of bios-drive-os
> >interaction certainly does.
>
>
> - ph
Smoked yes, but didn't inhale!
Why is it that OS/2's IBM1S506.ADD driver will not work when I use my
systems 'large-mode' of drive mapping? My QTLPS540 is mapped as 1120-16-59
normal and as 560-32-59 in large-mode. Why is it that WDC's
32bit-disk-access driver won't work? Why is it that both drivers only
support LBA mapping? Why not 'large-mode', when the CHS values are
identical (at least for my drive)?
John Wehman
trip...@ecc8.ateng.az.honeywell.com proclaims...
>>
>So what exactly is your definition of LBA????? The card I bought was called
>LBA pro, and about all it does is drive parameter translation. Doesn't LBA
>stand for Logical Block Addressing? (as opposed to "physical", i.e., what
>the drive reports to DOS)
To quote from the ATA-2 spec:
"LBA (Logical block address)
This term defines the addressing mode of the device as being by the linear mapping of
sectors from 0 to a device specific maximum LBA number. The maximum LBA number cannot
exceed 268 435 455."
This term is nothing more than addressing a location on the drive in a linear fashion.
It has nothing to do with breaking the 1024 limit. The company that made your card
was just jumping on (the wrong) bandwagon by labeling it LBA Pro (of course, I haven't
actually seen your card...it may well do LBA, but it also does translation (via
on-board BIOS) that is completely independent of LBA)
--------------------------------------------------------------------------
John Wehman -The opinions I express are solely
jwe...@picosof.com my own and in no way reflect those
john_...@notes.seagate.com of my employer's.
408-439-2123
--------------------------------------------------------------------------
Andy Hon Wai Chu
>joh...@uhunix2.uhcc.Hawaii.Edu (Jiyon Lee) writes:
>>That's only what you THINK you have done. DOS can never access cylinders
>>outside the 1024 cylinder limit with the notorious 10 bit addressing.
>>That's why SCSI, EIDE and other advanced hardware / software solutions
>>involve the sector translation, without which you are wasting 30 megs or
>>so out of your 540MB drive. It's well addressed in the FAQ.
> Alright! I HAVE partition a CONNER 540MB harddisk with my 3yr old
>386DX-40 / ISA / IDE controller into a 250MB primary and a 290MB
>extended partition. And in the 290MB extended partition, I made 250MB
DOS will only report the true size of your HDD which is 516Meg, so where
did you get the 540 total from (I am using the same Conner CFA540A, I
assumed). If you really get all of you HDD then you are the lucky one
with a good BIOS. BUT you solution will not work with the others which
don't have a good BIOS which support LBA or extended CHS translation.
In fact, you don't even need to format the 40meg as logical partition
because if you can see the 290, you can format them as one 290 partition.
aC
>logical partition and a 40MB logical parition. Which they sum up into
>3 partitions (3 Drive letters) and 540 million bytes in total. I copy
>image data into both the primary and the logical paritions until all
>the partitions are full. And then I selectively check the image files
>(from begin to bottom) on all partitions and they all prove to be valid.
> This is what I HAVE DONE. I did that purely for testing and the
>result proved that I can make use of the whole 540MB of the HDD without
>using any special disk manager. It is NOT my imagination and NOT WHAT I
>THINK I HAVE DONE.
> The test may not tell that it works on all HDDs but it at least show
>that it works on my case - which is a case with old, nothing special
>configurations.
>Regards,
>CT Yen.
>--
>Ham sandwich is better than nothing.
>Nothing is better than always lucky.
>Therefore, ham sandwich is better than always lucky.
--
Andy Hon Wai Chu
email: umch...@ccu.umanitoba.ca
from: University of Manitoba, Canada
Peter Herweijer
>In a previous posting, Peter Herweijer (pie...@sci.kun.nl) writes:
>> bk...@FreeNet.Carleton.CA (George Gebara) writes:
>>
>> >Using Logical Block Addressing in itself does not solve the partition size
>> >barriers, however "LBA" as a standardized method of bios-drive-os
>> >interaction certainly does.
>>
>> DOS interacting with the BIOS using LBA? What have you been smoking?
>
>Smoked yes, but didn't inhale!
:^)
>Why is it that OS/2's IBM1S506.ADD driver will not work when I use my
>systems 'large-mode' of drive mapping? My QTLPS540 is mapped as 1120-16-59
>normal and as 560-32-59 in large-mode. Why is it that WDC's
>32bit-disk-access driver won't work?
Both of these bypass the BIOS...
>Why is it that both drivers only support LBA mapping?
Ask the programmers.
>Why not 'large-mode', when the CHS values are identical (at least for
>my drive)?
Because they cannot correctly read, interpret and act upon an enhanced
drive parameter table? Because your BIOS doesn't build a correct EDPT?
Because they, too, equate translation with LBA for some reason? How am I
to know?
- Peter Herweijer
pie...@sci.kun.nl
Stannon Yen
>DOS will only report the true size of your HDD which is 516Meg, so where
>did you get the 540 total from (I am using the same Conner CFA540A, I
>assumed). If you really get all of you HDD then you are the lucky one
>with a good BIOS. BUT you solution will not work with the others which
>don't have a good BIOS which support LBA or extended CHS translation.
I'll know if it is only due to the M/B or not because I will soon
change the motherboard. (possibly another ISA M/B) However, I have to
say that I have only a simple IDE interface (I have tried both Super
IDE (IDE + AT I/O) card and old IDE card).
BTW, I'm not using CFA540A. I'm using CFS540A.
>In fact, you don't even need to format the 40meg as logical partition
>because if you can see the 290, you can format them as one 290 partition.
Well... I partition it to 250 + 40 simply because there is a change
in cluster size in 256MB parition.
Hale Landis
how they support drives with >1024 cylinders or >528MB capacity.
Perhaps some of you will find it interesting or informative.
Perhaps it will help some of you understand why LBA alone
does not solve the >528MB problems. Send me email if you
have any comments. This will probably become part of the
next version of my ATA/IDE/EIDE/FastATA FAQ.
Here goes...
===
I have updated my descriptions of the various BIOS INT 13H types
including new information and incorporating some suggestions.
Any comments?
===
Please read carefully. There is lots of information here that
can sound confusing the first time you read it.
Some definitions:
* 528MB - The maximun drive capacity that is supported by 1024
cylinders, 16 heads and 63 sectors (1024x16x63x512). This
is the limit for CHS addressing in the original IBM PC/XT
INT 13H BIOS.
* 8GB - The maximum drive capacity that can be support by 1024
cylinders, 256 heads and 63 sectors (1024x256x63x512). This
is the limit for the BIOS INT 13H AH=0xH calls.
* CHS - Cylinder/Head/Sector.
* EDPT - Enhanced fixed Disk Parameter Table -- This table
returns additional information for BIOS drive numbers 80H and
81H. The EDPT for BIOS drive 80H is pointed to by INT 41H.
The EDPT for BIOS drive 81H is pointed to by INT 46H. The
EDPT is a fixed disk parameter table with an AxH signature
byte. This table format returns two sets of CHS information.
One set is the same as returned by INT 13H AH=08H and is a
translated CHS. The other set is the CHS used at the drive
interface. This type of table allows drives with >1024
cylinders or drives >528MB to be supported. The translated
CHS will have <=1024 cylinders and (probably) >16 heads. The
CHS used at the drive interface will have >1024 cylinders and
<=16 heads. It is unclear how the IBM defined CE cylinder is
accounted for in such a table. Compaq probably gets the
credit for the original definition of this type of table.
* FDPT - Fixed Disk Parameter Table - This table returns
additional information for BIOS drive numbers 80H and 81H.
The FDPT for BIOS drive 80H is pointed to by INT 41H. The
FDPT for BIOS drive 81H is pointed to by INT 46H. A FDPT does
not have a AxH signature byte. This table format returns a
single set of CHS information. The CHS information returned
by this table is probably the same as that returned by INT 13H
AH=08H. However, not all BIOS properly account for the IBM
defined CE cylinder and this can cause a one or two cylinder
difference between the number of cylinders returned in the
AH=08H data and the FDPT data. IBM gets the credit for the
original definition of this type of table.
* LBA - Logical Block Address.
* MBR - Master Boot Record (also known as a partition table) -
The sector located at cylinder 0 head 0 sector 1 (or LBA 0).
This sector is created by an "FDISK" utility program. The MBR
may be the only partition table sector or the MBR can be the
first of multiple partition table sectors that form a linked
list. A partition table entry can describe the starting and
ending sector addresses of a partition (also known as a
logical volume or a logical drive) in both CHS and LBA form.
Partition table entries use the CHS returned by INT 13H
AH=08H. Older FDISK programs may not compute valid LBA
values.
* OS - Operating System.
* Translated CHS - A CHS used at the INT 13 interface that uses
>16 heads while keeping the number of cylinders <=1024 and the
number of sectors <=63. This allows support of up to 8GB
drives. This scheme started with either ESDI or SCSI adapters
many years ago. There is no standard (de facto or otherwise)
that documents the actual CHS-to-CHS translation algorithm
used on read/write calls.
First, please note that this is written with the OS implementor
in mind and that I am talking about the possible BIOS types as
seen by an OS during its hardware configuration search.
Second, because there can be multiple BIOS types in any one
system, each drive may be under the control of a different type
of BIOS. For example, drive 80H (the first hard drive) could be
controlled by the original system BIOS, drive 81H (the second
drive) could be controlled by a option ROM BIOS and drive 82H
(the third drive) could be controller by a software driver.
Also, be aware that each drive could be a different type, for
example, drive 80H could be an MFM drive, drive 81H could be an
ATA drive, drive 82H could be a SCSI drive.
Third, not all OS's understand or use BIOS drive numbers greater
than 81H. Even if there is INT 13H support for drives 82H or
greater, the OS may not use that support.
Fourth, the BIOS INT 13H configuration calls are:
* AH=08H, Get Drive Parameters -- This call is restricted to
drives up to 528MB without CHS translation and to drives up to
8GB with CHS translation.
* AH=41H, Get BIOS Extensions Support -- This call is used to
determine if the IBM/Microsoft Extensions or if the Phoenix
Enhanced INT 13H calls are supported for the BIOS drive
number.
* AH=48H, Extended Get Drive Parameters -- This call is used to
determine the CHS geometries, LBA information and other data
about the BIOS drive number.
* the FDPT or EDPT -- While not actually a call, but instead a
data area, the FDPT or EDPT can return additional information
about a drive.
* other tables -- The IBM/Microsoft extensions provide a pointer
to a drive parameter table via INT 13H AH=48H. The Phoenix
enhancement provides a pointer to a drive parameter table
extension via INT 13H AH=48H. These tables are NOT the same
as the FDPT or EDPT.
Note: The INT 13H AH=4xH calls duplicate the older AH=0xH calls
but use a different parameter passing structure. This new
structure allows support of drives with up to 2^64 sectors
(really BIG drives). While at the INT 13H interface the AH=4xH
calls are LBA based, these calls do NOT require that the drive
support LBA addressing.
I assume the following:
a) All BIOS INT 13H support has been installed by the time the OS
starts its boot processing. I'm don't plan to cover what
could happen to INT 13H once the OS starts loading its own
device drivers.
b) Drives supported by INT 13H are numbered sequentially starting
with drive number 80H (80H-FFH are hard drives, 00-7FH are
floppy drives).
I have identified the following types of BIOS INT 13H support as
seen by an OS during its boot time hardware configuration
determination:
BIOS Type 1
Origin: Original IBM PC/XT.
BIOS call support: INT 13H AH=0xH and FDPT for BIOS drives
80H and 81H.
Description: Supports up to 528MB from a table of drive
descriptions in BIOS ROM. No support for >1024 cylinders or
drives >528MB.
Support issues: For >1024 cylinders or >528MB support, either
an option ROM with an INT 13H replacement (see BIOS types 4-7)
-or- a software driver (see BIOS type 8) must be added to the
system.
BIOS Type 2
Origin: Unknown, but first appeared on systems having BIOS
drive type table entries defining >1024 cylinders. Rumored to
have originated at the request of Novell or SCO.
BIOS call support: INT 13H AH=0xH and FDPT for BIOS drives
80H and 81H.
Description: For BIOS drive numbers 80H and 81H, this BIOS
type supports >1024 cylinders or >528MB without using a
translated CHS in the FDPT. INT 13H AH=08H truncates
cylinders to 1024 (beware of buggy implementations). The FDPT
can show >1024 cylinders thereby allowing an OS to support
drives >528MB.
Support issues: Actual support of >1024 cylinders is OS
specific -- some OS's may be able to place OS specific
paritions spanning or beyond cylinder 1024. Usually all OS
boot code must be within first 1024 cylinders. The FDISK
program of an OS that supports such partitions uses an OS
specific partition table entry format to identify these
paritions. There does not appear to be a standard (de facto
or otherwise) for this unusual partition table entry.
Apparently one method is to place -1 into the CHS fields and
use the LBA fields to describe the location of the partition.
It is unclear if such a partition table entry will be ignored
by an OS that does not understand what it is. For an OS that
does not support such partitions, either an option ROM with an
INT 13H replacement (see BIOS types 4-7) -or- a software
driver (see BIOS type 8) must be added to the system.
Note: OS/2 can place HPFS partitions and Linux can place
Linux partitions beyond or spanning cylinder 1024. (Anyone
know of other systems that can do the same?)
BIOS Type 3
Origin: Unknown, but first appeared on systems having BIOS
drive type table entires defining >1024 cylinders. Rumored to
have originated at the request of Novell or SCO.
BIOS call support: INT 13H AH=0xH and FDPT for BIOS drives
80H and 81H.
Description: This BIOS is like type 2 above but it allows up
to 4096 cylinders (12 cylinder bits). It does this in the INT
13H AH=0xH calls by placing two most significant cylinder bits
(bits 11 and 10) into the upper two bits of the head number
(bits 7 and 6).
Support issues: Identification of such a BIOS is difficult.
As long as the drive(s) supported by this type of BIOS have
<1024 cylinders this BIOS looks like a type 2 BIOS because INT
13H AH=08H should return zero data in bits 7 and 6 of the head
information. If INT 13H AH=08H returns non zero data in bits
7 and 6 of the head information, perhaps it can be assumed
that this is a type 3 BIOS. For more normal support of >1024
cylinders or >528MB, either an option ROM with an INT 13H
replacement (see BIOS types 4-7) -or- a software driver (see
BIOS type 8) must be added to the system.
Note: Apparently this BIOS type is no longer produced by any
BIOS vendor.
BIOS Type 4
Origin: Compaq. Probably first appeared in systems with ESDI
drives having >1024 cylinders.
BIOS call support: INT 13H AH=0xH and EDPT for BIOS drives
80H and 81H if the drive has >1024 cylinders.
Description: Supports >1024 cylinders using a EDPT.
Support issues: This BIOS type may support up to four drives
with a EDPT (or FDPT) for BIOS drive numbers 82H and 83H
located in memory following the EDPT (or FDPT) for drive 80H.
BIOS Type 5
Origin: The IBM/Microsoft BIOS Extensions document. For many
years this document was marked "confidential" so it did not
get wide spread distribution.
BIOS call support: INT 13H AH=0xH, AH=4xH and EDPT for BIOS
drives 80H and 81H.
Description: A BIOS that supports very large drives (>1024
cylinders, >528MB, actually >8GB), and supports the INT 13H
AH=4xH read/write functions. The AH=4xH calls use LBA
addressing and support drives with up to 2^64 sectors. These
calls do NOT require that a drive support LBA at the drive
interface. INT 13H AH=48H describes the CHS used at the INT
13 interface and the CHS or LBA used at the drive interface.
This BIOS supports the INT 13 AH=0xH calls the same as a BIOS
type 4.
Support issues: While the INT 13H AH=4xH calls are well
defined, they are not implemented in many systems shipping
today. Currently undefined is how such a BIOS should respond
to INT 13H AH=08H calls for a drive that is >8GB.
Note: Support of LBA at the drive interface may be automatic
or may be under user control via a BIOS setup option. Use of
LBA at the drive interface does not change the operation of
the INT 13 interface.
BIOS Type 6
Origin: The Phoenix Enhanced Disk Drive Specification.
BIOS call support: INT 13H AH=0xH, AH=4xH and EDPT for BIOS
drives 80H and 81H.
Description: A BIOS that supports very large drives (>1024
cylinders, >528MB, actually >8GB), and supports the INT 13H
AH=4xH read/write functions. The AH=4xH calls use LBA
addressing and support drives with up to 2^64 sectors. These
calls do NOT require that a drive support LBA at the drive
interface. INT 13H AH=48H describes the CHS used at the INT
13 interface and the CHS or LBA used at the drive interface.
This BIOS supports the INT 13 AH=0xH calls the same as a BIOS
type 4. The INT 13H AH=48H call returns additional information
such as host adapter addresses, DMA support, LBA support, etc
(in the Phoenix Enhanced Parameter Table data area).
Support issues: The Phoenix document can be interpreted such
that this type of BIOS supports INT 13H AH=41H and AH=48H
without also supporting the AH=4xH read/write calls. Phoenix
did not intend this interpretation of the specification and it
is unknown if there are any implementations that do not
implement the AH=4xH read/write calls. Currently undefined is
how such a BIOS should respond to INT 13H AH=08H calls for a
drive that is >8GB.
Note: Support of LBA at the drive interface may be automatic
or may be under user control via a BIOS setup option. Use of
LBA at the drive interface does not change the operation of
the INT 13 interface.
BIOS Type 7
Origin: Described in the Western Digital Enhanced IDE
Implementation Guide.
BIOS call support: INT 13H AH=0xH and FDPT or EDPT for BIOS
drives 80H and 81H.
Description: Supports >1024 cylinders or >528MB using a EDPT
with a translated CHS *** BUT ONLY IF *** the user requests
LBA in the BIOS setup and the drive supports LBA. As long as
LBA is enabled, this BIOS looks like a BIOS type 4 with an
EDPT. When LBA is disabled, this BIOS looks like a BIOS type
2 with an FDPT. This BIOS may support up to four drives in
the same manner as described in BIOS type 4.
Support issues: If the user changes the LBA setting in BIOS
setup, the FDPT/EDPT could change which may cause data
corruption. The user should be warned to not change the LBA
setting in BIOS setup once the drive has been partitioned.
BIOS Type 8
Origin: Unknown. Perhaps Ontrack's Disk Manager was the
first of these software drivers. Another example of such a
drive is Micro House's EZ Drive.
BIOS call support: Unknown (anyone care to help out here?).
Description: A software driver that "hides" in the MBR such
that it is loaded into system memory before any OS boot
processing starts. I don't know how these drivers respond to
INT 13H AH=08H or how they set up drive parameter tables
(anyone care to help out here?).
Support issues: Several identified -- Some OS installation
programs will remove or overlay these drivers; some of these
drivers do not perform CHS translation using the same
algorithms used by the other BIOS types; special OS device
drivers may be required in order to use these software drivers
For example, under MS Windows the standard FastDisk driver
(the 32-bit disk access driver) must be replaced by a driver
that understands the Ontrack, Micro House, etc, version of INT
13H.
BIOS Type 9
Origin: SCSI host adapters.
BIOS call support: Probably INT 13H AH=0xH and FDPT for BIOS
drives 80H and 81H, perhaps INT 13H AH=4xH.
Description: Most SCSI host adapters contain an option ROM
that enables INT 13 support for the attached SCSI hard drives.
It is possible to have more than one SCSI host adapter, each
with its own option ROM. Drives >528MB are supported via
CHS-to-(SCSI)CHS or CHS-to-(SCSI)LBA. INT 13H AH=08H returns
a translated CHS. The FDPT probably will exist for SCSI
drives with BIOS drive numbers of 80H and 81H and probably
indicates the same CHS as that returned by INT 13H AH=08H.
Other BIOS calls (most likely host adapter specific) must be
used to determine other information about the host adapter or
the drives.
Support issues: Some SCSI host adapters will not install
their option ROM if there are two INT 13H devices previously
installed by another INT 13H BIOS (for example, two
MFM/RLL/ESDI/ATA drives). Other SCSI adapters will install
their option ROM and use BIOS drive numbers greater than 81H.
Some older OS's don't understand or use BIOS drive numbers
greater than 81H. SCSI adapters are currently faced with the
>8GB drive problem.
/end/
--
\\===============\\=======================\\
\\ Hale Landis \\ 303-548-0567 \\
// Niwot, CO USA // lan...@sugs.tware.com //
//===============//=======================//
Charles Thomas Lecklider
_He_ may have been smoking, but DOS is quite happy about my BIOS, LBA and my
1.2G drive, and _I_ haven't.
--
Mr. Invisible - now with added visibility!!
(quoth the Raven, 'Nevermore')
stephb
>
>
>_He_ may have been smoking, but DOS is quite happy about my BIOS, LBA and my
>1.2G drive, and _I_ haven't.
>--
>
As long as you've got SOMETHING translating that drive under 1024 cylinders,
DOS is going to be a happy camper. Ontrack Computer System's Disk Manager
software does a very nice job of this as does the Track mapping feature on
some IDE cards and in some of the newer BIOSes. LBA is going to sidestep the
whole issue by avoiding C-H-S addresses completely and going straight to relative
block addresses.