Micro Firmware Tech Support

DOS Compatibility Mode on 3rd or 4th IDE Drives Over 4.2GB Using ECHS Translation Under Windows 95


Filename: W95ECHS.TXT
WWW URL:  http://www.firmware.com/support/bios/w95echs.htm
FTP URL:  ftp://ftp.firmware.com/text/w95echs.txt
Revision: 07/31/97  TLS  Micro Firmware Technical Support
Summary:  Describes a bug in Windows 95 that causes drives over 4.2GB
          on the secondary IDE channel to run in compatibility mode
          if using ECHS translation.

Symptom

Maxtor 85120A8 5GB IDE drive installed as 3rd or 4th drive using ECHS translation causes any drives on secondary IDE interface to use DOS Compatibility Mode and causes exclamation point to appear on second IDE controller in Device Manager. No other problem with operation of drive. This also occurs with any IDE drive over 4.2GB that uses 16 heads. The problem should not occur with a drive over 4.2GB that uses 15 heads. Changing translation type in CMOS setup to Assisted LBA allows drives to work in 32-bit mode.

This problem will also occur with any IDE drive on the secondary channel over 528MB setup in CMOS using any values for heads and/or sectors other than the factory values, regardless of the translation type.


Possible Cause of Problem

Windows 95 32-bit device driver cannot determine the translation type in use, since it cannot locate FDPT for 3rd or 4th drives to get physical CHS values and is probably using factory CHS parameters returned by the drive instead of current CHS parameters. Explained in detail below.


Background Information

A BIOS will build a Fixed Disk Parameter Table (FDPT) for each drive type installed. An older BIOS may build just one FDPT for 2 drives if they are both the same type (Type 2, etc.). In newer BIOSes such as Phoenix 4.x, a separate drive type is defined for each user-defined drive (including autotyped drives). As an example, a new Phoenix BIOS will normally have types 1-39 as defined in older BIOSes and will also have a type 40, 41, 42, and 43 for the 1st, 2nd, 3rd and 4th user-defined drives. Since the older drive types are not normally used in newer systems, there is usually a FDPT for each drive. Newer BIOSes which can handle hard drives larger than 504MB will build an Enhanced FDPT (EFDPT) for any drives requiring translation. The FDPT and EFDPT are both 16-byte structures containing information about the installed hard drives including CHS parameters. Some obsolete information is no longer defined in the newer Enhanced FDPT. The Enhanced FDPT contains both the logical CHS parameters (after translation) and the physical CHS parameters (as reported by CMOS setup). Normally DOS gets the CHS values by calling Int 13h Function 8, which then gets the CHS values from the FDPT (or translated CHS values from the Enhanced FDPT). Some information in the FDPT for the first two drives can also be accessed through Int 41h and Int 46h, which are pointers to the first and second FDPTs.

IDE drives can return 512 bytes of information about themselves when queried with the Identify Device (previously Identify Drive) command as defined in the ATA specification. When a modern BIOS autotypes an IDE drive, it is just issuing the Identify Device command and throwing away most of the information. In addition to the factory CHS parameters, the Identify Device command returns information such as whether or not the drive supports LBA addressing, the model number, the serial number, and the current CHS parameters. Some of this information is fixed and some is changeable. The current CHS parameters are the values used in CMOS setup. The drive must have this information so it knows how it is being addressed. The current CHS parameters are sent to the drive by the BIOS on each power-on (or anytime the drive is reset) using the Initialize Device Parameters (previously Set Drive Parameters) command. These values are stored in registers where they can be accessed by the Identify Device command.

Until around 1994, the BIOSes on most PCs were limited to 504MB hard drives. This chart illustrates that limitation:


Int 13h BIOS ATA Specification Combined
Limits Limits Limitation

Cylinders: 1024 (10 bits) 65536 (16 bits) 1024

Heads: 256 (8 bits) 16 (4 bits) 16

Sectors: 63 (6 bits) 256 (8 bits) 63

Total Size: 8GB 128GB 504MB

For drives 504MB and under, no translation is needed, the CHS parameters are passed to DOS directly through the FDPT. Newer BIOSes ("translating BIOSes") overcome this limitation by reducing the number of cylinders and increasing the number of heads when passing CHS values from the drive to the OS, through the EFDPT. So a 540MB drive with CHS values of 1048 x 16 x 63 would be translated to 524 x 32 x 63. This is known as CHS translation or CHS to CHS translation or Extended CHS (ECHS) translation. This type of translation should theoretically work up to the limit of 8GB. However, there is a limitation in DOS (all versions, including WIN95) that gives us trouble when we hit 4.2GB.

The problem with drives over 4.2GB shows up when there are 16 heads and the cylinders exceed 8191, which causes the translated heads value to be 256. Due to a limitation in DOS, it can deal with heads up to 255 but can not handle 256 heads. This is probably due to allocating only 8 bits to store the number of heads. 8 bits can hold values up to 255. 256 "wraps around" to 0.

This may be dealt with in various ways as newer BIOSes address this problem. At the time of this writing (04/97) there is no actual "industry standard". It appears that there are two basic translation schemes being implemented to address this problem:

1. "Assisted LBA"

This is the term used by Phoenix to describe one type of translation used to address this problem. This method appears to be used by the AMI/Intel BIOSes on newer Intel Pentium motherboards and is referred to as "LBA" in the Translation Type option in CMOS setup in those BIOSes. This also appears to be the translation method used on some EIDE adapter cards with enhanced BIOSes, such as the Promise EIDEMAX and the SIIG EIDE Master. This method basically just reduces 256 heads to 255 heads. There's a little more to it - here is an example using the Maxtor 85120A 5GB IDE drive:

The drive should autotype in CMOS setup to its factory parameters of 9924 x 16 x 63. The BIOS will then multiply these 3 numbers together to get the total number of sectors, which would be 10,003,392. This total is then divided by 63 which would be 158,784. This number is then divided by 1024 to determine the value to use for heads, which must be 16, 32, 64, 128, or 255. The result here is 155, which is then adjusted up to 255. 158,784 is then divided by the number of heads, in this case 255, which gives us 622.682.. which would round down to 622. So we end up with a translated geometry of 622 x 255 x 63.

2. "Revised ECHS"

(This name was made up for lack of anything else just to use in this document). The translation method currently used in BIOSes that support drives over 504MB is referred to as ECHS (Extended Cylinder Head Sector) and employs "bit-shifting". This translation method can be revised so that it works for drives over 4.2GB. This involves reducing the heads from 16 to 15 and then multilplying the cylinders by 16/15 BEFORE applying the ECHS translation. This means that the CHS parameters sent to the drive with the Set Drive Parameters command will be different from the factory CHS parameters (which will show up in CMOS setup).

Both of the above translation methods are implemented in the current revisions of all of the Micro Firmware Phoenix 4.x BIOS upgrades. It is important to note that with the Assisted LBA method, the current CHS values that the BIOS sends to the drive are the same as the factory CHS values that the BIOS gets from the drive when it autotypes the drive, while with the ECHS method, the current CHS values sent to the drive will be different from the factory CHS values.

For more information on translation types, see the following documents:

http://www.firmware.com/support/bios/over4gb.htm

http://thef-nym.sci.kun.nl/~pieterh/storage.html


Detailed Explanation of Problem

Windows 95 by default would prefer to use its built-in 32-bit disk access driver to handle hard drives, since this provides better performance. The 32-bit device driver replaces the BIOS services, since the BIOS calls expect the system to be in real mode rather than protected mode. In order to access the drive properly, the Windows 95 32-bit disk driver needs to know what kind of translation is being used by the BIOS. It can determine this by comparing the logical and physical CHS values. The logical values can be obtained from the FDPT by calling Int 13h Function 8 (or using Int 41h or 46h for 1st and 2nd drives). The physical values can be obtained from the drive (using the Identify Drive command) or from the FDPT through Int 41h (for the 1st drive) and Int 46h (for the 2nd drive). (Int 13h Function 8 does not return physical CHS values).

What we think is happenning is that Windows 95's 32-bit disk driver is getting the logical CHS values from the FDPT using Int 13h Function 8 and getting the physical values for the 1st and 2nd drive using Int 41h and Int 46h and the physical values for the 3rd and 4th drives from the drives using the Identify Drive command (since there is no widely supported way to access the FDPT for the 3rd and 4th drives). The problem here would be that Windows 95 is getting the factory CHS values from the drive instead of getting the current CHS values from the drive. Since the factory CHS values and current CHS values returned by the drive are the same when using Assisted LBA Translation but different when using ECHS translation, this would explain the problem. In fact it does appear that the ESDI_506.PDR driver is only accessing the first 53 words (106 bytes) of data returned by the Identify Drive command. The current CHS values are in words 54, 55, and 56.

This problem exsits in all versions of Windows 95. For now, the solution would be to use Assisted LBA translation for drives larger than 4.2GB on the secondary IDE channel, or just use the drive in in DOS compatibility mode. We contacted Microsoft in May 1997, when we discovered this, to report the bug. This was too late to get it fixed in Windows 95, but it should be fixed before Windows 98 is released. It may be fixed in Memphis Beta 3.


SALES - SUPPORT - CONTACT - LINKS - HOME


Micro Firmware, Inc.
330 W. Gray Street
Norman, Oklahoma 73069-7111
Toll-Free Sales (USA/Canada): 1-800-767-5465 or 1-888-4-PC-BIOS
Support & Sales: +1 405-321-8333
Sales Department FAX: +1 405-573-5535
Technical Support FAX: +1 405-321-8342
Email: sales@firmware.com support@firmware.com

© 1998 Micro Firmware, Inc. - All Rights Reserved
While every attempt is made to ensure the accuracy of our support documents, Micro Firmware provides these documents on an AS-IS basis for information purposes only.