The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Поиск:  Каталог документации | Hardware

Enhanced IDE/Fast-ATA/ATA-2 FAQ [2 of 2]

This FAQ addresses issues surrounding Enhanced IDE, ATA-2, ATAPI and Enhanced BIOSes. It includes practical questions, background information and lists of net resources.
Name: Yet Another Enhanced IDE/Fast-ATA/ATA-2 FAQ
Version: 1.92
Archive-name: pc-hardware-faq/enhanced-IDE/part2
Posting-Frequency: Monthly (the 24th)
Last-modified: 1998/01/23
Maintained-by: Peter den Haan <>

  10.  ATA: harddisks
  10.1.  How does ATA(-2) work?
  10.2.  What are PIO modes?
  10.3.  What are DMA modes?
  10.4.  How are the ATA(-2,PI) I/O ports assigned?
  10.5.  What does an ATA-2 interface do?
  10.6.  What is Block mode?
  10.7.  What is LBA?
  10.8.  How does security work?
  10.9.  What is S.M.A.R.T.?
  10.10.  What is PRML?
  10.11.  What are MR heads?

  11.  ATAPI: CD-ROMs and tapes
  11.1.  How does ATAPI differ from, and coexist with, ATA(-2)?
  11.2.  What's so special about the secondary port?

  12.  The EBIOS: translation
  12.1.  Why translation?
  12.2.  How does translation work?
  12.3.  I'd like to know how translation works in detail.
  12.4.  What is in the Enhanced Disk Parameter Table?
  12.5.  How many types of translating/Enhanced BIOSes are there?

  13.  Software details
  13.1.  Details on OnTrack Disk Manager
  13.2.  How does Windows' 32-bit disk access work?

  14.  Hacker's resource guides
  14.1.  The hacker's documentation guide
  14.2.  The hacker's net.resource guide

  10.  ATA: harddisks

  This and the following sections of the FAQ are intended to provide
  additional background information for the curious. The answers here
  differ wildly in the depth in which they treat the material; pick and
  read at will. It's a FAQ, not a book.

  10.1.  How does ATA(-2) work?

  To understand the basic concepts of advanced ATA drives, one first
  needs to understand the basics of drive technology. Basically, when
  the operating system needs data to be either read or written to
  secondary storage (the hard disk), the BIOS gets the command, and
  passes that command to the drive. For operating systems other than
  DOS, the BIOS is usually replaced by the operating system's own I/O
  subsystem; the principle remains the same.

  How the command is passed, interpreted, and responded to, forms the
  basis for Advanced ATA. In a nutshell, there are seven registers that
  the BIOS writes to/reads from to create a command. An eighth register
  is used to read and write data. The signals that create these reads
  and writes are controlled by the BIOS, but their timing is determined
  by the interface hardware, and ATA specifications dictate how fast
  these signals can be asserted or deasserted. There are currently 4
  modes of Programmed Input/Output (PIO) and 4 modes of Direct Memory
  Access (DMA). The numbers all of you have been reading about are only
  a small portion of these specifications, but they are the ones that
  marketing can tout best. These "transfer rates" are a result of the
  specification that controls how fast the I/O Read and Write cycle time
  of the data register can operate at.

  10.2.  What are PIO modes?

  The PIO mode determines how fast data is transferred to and from the
  drive. In the slowest possible mode, PIO mode 0, the data cycle time
  can not exceed 600 nanoseconds. In a single cycle, 16 bits are
  transferred in or out of the drive. In a single sector, there are 256
  words (16 bits = 1 word); 2048 sectors make up a megabyte. So,

  1 cycle      1 sector       1 megabyte             2000
  --------     ---------     ------------     =     ------     = 3.3MB/s
   600ns       256 words     2048 sectors           600ns

  So, the theoretical transfer rate of PIO Mode 0 (600ns cycle time) is
  3.3 megabytes per second.

  Here are the rest of the PIO modes, with their respective transfer

     PIO mode     Cycle time   transfer rate
                  (ns)            (MB/s)

         0           600            3.3         ATA
         1           383            5.2         ATA

         2           240            8.3         ATA
         3           180           11.1         ATA-2, IORDY required
         4           120           16.6         ATA-2, IORDY required
         5            90           22.2         vaporware

  The first three, PIO modes 0 to 2, are old modes also present in the
  old ATA standard. The others (PIO 3 and 4) are ATA-2 specific and use
  IORDY hardware flow control. This means the drive can use the IORDY
  line to slow down the interface when necessary. Interfaces without
  proper IORDY support may cause data corruption in the fast PIO modes;
  in that you're stuck with the slower modes, and typically half the

  When interrogated with an Identify Drive command, a harddisk returns,
  among other things, information about the PIO and DMA modes it is
  capable of using.

  10.3.  What are DMA modes?

  DMA or Direct Memory Access means that the data is transferred
  directly between drive and memory without using the CPU as an
  intermediary, in contrast to PIO. In true multitasking operating
  systems like OS/2 or Linux, DMA leaves the CPU free to do something
  useful during disk transfers. In a DOS/Windows environment the CPU
  will have to wait for the transfer to finish anyway, so in these cases
  DMA isn't terribly useful.

  There are two distinct types of direct memory access: third-party DMA
  and first-party or busmastering DMA. Third-party DMA relies on the DMA
  controller on the system's mainboard to perform the complex task of
  arbitration, grabbing the system bus and transferring the data. In the
  case of first-party DMA, all this is done by logic on the interface
  card itself. Of course, this adds considerably to the complexity and
  the price of a busmastering interface.

  Unfortunately, the DMA controller on ISA systems is ancient and slow,
  and out of the question for use with a modern harddisk. VLB cards
  cannot be used as DMA targets at all and can only do busmastering DMA.
  It is only on EISA- and PCI-based interfaces that non-busmastering DMA
  is viable: EISA type 'B' DMA will transfer 4MB/s, PCI type 'F' DMA
  between 6 and 8MB/s.

  Today, all modern chipsets, including the ubiquitous Triton chipsets,
  incorporate a busmastering DMA capable ATA interface. Efforts to
  standardize the DMA hardware will ensure stable and reliable software

  Anyway, the DMA modes supported are:

          DMA Mode      Cycle time   transfer rate
          Single word    (ns)           (MB/s)

              0            960            2.1         ATA
              1            480            4.2         ATA
              2            240            8.3         ATA
              0            480            4.2         ATA
              1            150           13.3         ATA-2
              2            120           16.6         ATA-2
!           DMA/16         120           16.6         Ultra-ATA
!           DMA/33          60           33.3         Ultra-ATA

  The single word DMA modes are hardly useful and are obsoleted in
  ATA-3.  Note that some older interfaces are able to use these DMA
  modes as a way to communicate with the drive, without actually doing
  direct memory access at all. In these cases, the DMA modes are just
  used as glorified PIO modes.

  10.4.  How are the ATA(-2,PI) I/O ports assigned?

  The registers of the primary ATA channel occupy the following I/O
  addresses (in hexadecimal notation):

     Register      Read Function             Write Function

     01F0h         Read Data                 Write Data
                   (16 Bits)                 (16 bits)
     01F1h         Error register            Set Features Data
     01F2h         Status of sector          Write sector count
                   count                     for command setup
     01F3h         Location of starting      Write sector start
                   sector                    for command setup
     01F4h         Location of Cyl-low       Write cyl-low location
                                             for command setup
     01F5h         Location of Cyl-high      Write cyl-high location
                                             for command setup
     01F6h         Head/device selection     Write device selection
                                             and head selection for
                                             command setup
     01F7h         Device Status             Device command

     03F6h         Alternate Status          Device Control
     03F7h         Drive Address

  Note that the floppy disk controller's disk change flag shares 03F7h
  which makes life difficult for designers that want to implement disk
  and floppy controllers separately. From this point of view it may come
  as no surprise that some of the problems in the CMD640x and RZ1000
  'EIDE' interface chips touched upon elsewhere in this FAQ are floppy

  There is no reason why there can't be a large number of interfaces
  like this one. There is a de facto standard for four of these ports:

    Interface number     CS0-decode    CS1-decode    IRQ number

            1            01F0h-01F7h   03F6h-03F7h    14
            2            0170h-0177h   0376h-0377h    15 or 10
            3            01E8h-01EFh   03EEh-03EFh    12 or 11
            4            0168h-016Fh   036Eh-036Fh    10 or 9

  Only the first two enjoy really widespread support; for the secondary
  port, IRQ15 is the most commonly used interrupt by far. Potential BIOS
  support for arbitrary extra ports is found only in the Phoenix

  10.5.  What does an ATA-2 interface do?

  Interfaces have come a long way since the ordinary ISA IDE consisting
  of little more than a simple buffer. ATA-2 boards have to support at
  least PIO modes 0 and 3, usually support many more modes, and will
  have to ensure that the correct timing is used at the ATA interface
  for each of these modes. Since the timing specifications are quite
  complicated, a great deal of flexibility is necessary to implement the
  ATA-2 standard correctly.
                               |<------------ t0 ------------------------>|
                         __________________________________________       |
  Address Valid *1 _____/                                          \________
                        |<-t1->|<----------- t2 ----------->|<-t9->|      |
                        |      |____________________________|<---t2i----->|_
  DIOR-/DIOW-      ____________/                            \_____________/
                        |      |                            |      |
                        |      |                    ________|__  ->|   |<-t8
  Write Data    *2 --------------------------------<___________>------------
                        |      |                   |<--t3-->|  |       |
                        |      |                          ->|t4|<-     |
                        |      |                     _______|___ ____  |
  Read Data     *2 ---------------------------------<___________X____>------
                      ->|t7|<- |                    |     ->|t6 |<-  | |
                        |  | ->| tA |<-             |<-t5-->|<-t6Z-->|
                        |  |___________________________________________|
  IOCS16-          ________/        |               |                  \____
                                    |             ->|tRd|<-            |
  IORDY            XXXXXXXXXXXXXXXXX____________________/
    *1 Device Address consists of signals CS0-, CS1- and DA2-0
    *2 Data consists of DD0-15 (16-bit) or DD0-7 (8-bit)

  The above figure defines the relationships between the interface
  signals for both 8-bit and 16-bit PIO data transfers.

  In this diagram, t0 denotes the read/write cycle time, the most
  significant determining parameter for PIO mode throughput. As you can
  see, there is a lot more to the various PIO and DMA modes than this
  read/write cycle time only. To design a low-cost interface that fully
  adheres to the ATA-2 specification is quite a challenge. The common
  approach is to make the timing completely software programmable;
  unfortunately, the way ATA cards are programmed has not been
  standardized and differs radically between cards.  The consequence is
  that you will typically need interface-specific drivers for each and
  every operating system used in order to profit from the fast transfer

  10.6.  What is Block mode?

  Multiple Read/Write commands (reduces Interrupts to host processor).

  Besides the obvious transfer increase, Fast-ATA and many other drives
  allow for Read/Write Multiple commands, which increase the number of
  sectors passed without intervening interrupts. This lessens the host's
  overhead, as every interrupt causes the CPU to do a context switch,
  check the device and set up the data transfer (or perform the transfer
  itself in the case of PIO).

  The Read Multiple Command (0C4h) and the Write Multiple Command (0C5h)
  are drive-level commands that can transfer multiple sectors of data
  without asserting the IRQ line of the drive, signaling the processor
  that a drive operation is pending.

  The IRQ line is asserted when:

  o  A read command has been issued, and the requested data is in the
     drive's buffer, ready to be taken by the host.

  o  A write command has been issued, and the data has transferred to
     the drive's buffer. If write caching is disabled, the IRQ won't be
     asserted until the data has been completely written to the media.

  During normal reads and writes, the interrupt can constantly bother
  the CPU, and depending on the processor and the task at hand (multi-
  tasking OS, Unix, etc), there can be long delays in having the CPU
  service the drive. The advent of Read/Write Multiple allows many
  sectors (from 2 up to as many as 128) to be transferred in one go,
  completing the task in as much as 30% faster times.

  On single-tasking operating systems like DOS, any improvement over a
  few percent usually indicates bad buffer cache management on the part
  of the drive.

  Warning: some old drives have a buggy block mode implementation and
  may corrupt data.

  A final remark: the block size that is optimal for drive throughput
  doesn't have to be the best for system performance! For example, the
  DOS FAT filesystem tends to favor a block size equal to the cluster
  size. Do not trust low level benchmarks when tweaking the block size,
  but use an application level benchmark suite instead.

  10.7.  What is LBA?

  LBA is a means of linearly addressing sectors addresses, beginning at
  sector 1 of head 0, cylinder 0 as LBA 0, and proceeding on to the last
  physical sector on the drive, which, for instance, on a standard 540
  Meg drive would be LBA 1,065,456. This is new in ATA-2, but has always
  been the one and only addressing mode in SCSI. Note that LBA does not
  allow you to address more sectors than CHS style addressing would.

  LBA reduces CPU overhead in OSs that use LBA internally, but on the
  other hand takes a little more time when ordinary CHS based BIOS calls
  are used (eg. DOS). Beware that depending on the way LBA is
  implemented in the harddisk firmware, the overhead on the part of the
  drive may increase.

  10.8.  How does security work?

  Security mode implements a simple password protection scheme. Security
  can affect just write operations, or both reads and writes. Non-data
  operations (such as Identify Device) can always be executed regardless
  of the security status.

  There are two security levels: High and Maximum. If the user password
  is lost and High level security is set, the drive can still be
  unlocked with the Master password.  At Maximum level, there is no way
  to unlock the drive without erasing all user data.

  After a number of incorrect passwords the drive will reject further
  passwords until a powerdown or hard reset. This makes guessing the
  password by brute force very difficult.

  10.9.  What is S.M.A.R.T.?

  S.M.A.R.T. or Self Monitoring Analysis and Reporting Technology allows
  the drive to report about certain types of degradation or impending
  failure. This allows the operating system to take the necessary
  precautions and warn the user. The OEM release 2 of Win95 and the next
  OS/2 version (Merlin) will be SMART aware.
  The utility of this feature will initially be quite limited, though,
  because many failure modes (including the infamous Monday morning
  failure) can't be sensed in advance.

  At present only few utilities exist to examine the S.M.A.R.T. status
  of a drive. These include Micro House EZ-S.M.A.R.T. and Symantec
  S.M.A.R.T. Doctor.

  10.10.  What is PRML?

  The Partial Response Maximum Likelihood or PRML read channel is
  quickly replacing the ordinary peak detection channel as a mass market
  technology. Briefly, where a peak detection channel uses a
  comparatively simple analogue technique to extract the digital data
  from the signal picked up by the read head, a PRML channel digitizes
  the signal and employs digital processing techniques to reconstruct
  the data. Thanks to these DSP techniques a PRML channel can still work
  reliably on very closely packed data where the distinction between
  individual bits tends to blur. The end result is a faster, higher
  capacity drive.

  For a more thorough discussion of this topic, take a look at Quantum's
  excellent white papers <>.

  10.11.  What are MR heads?

  Magnetoresistive or MR drive heads are quickly replacing the old
  inductive heads in all sections of the harddrive market. For more
  information, see for example

  11.  ATAPI: CD-ROMs and tapes

  11.1.  How does ATAPI differ from, and coexist with, ATA(-2)?

  For the sake of compatibility with non-ATAPI aware software that might
  mistake an ATAPI device for a harddrive, the device pretends it isn't
  there until it's waken up by a special sequence of commands. Once
  activated, it uses a command protocol that radically differs from that
  used by harddisks.

  The reason is that the ATA command and register set is not adequate to
  support some CD-ROM command structures. Therefore, only a minimum of
  traditional ATA commands are supported by ATAPI devices.  For most of
  their functions, these devices rely on the ATAPI Transport Protocol
  using packets of at least 12 bytes sent, as data, through the Data
  Register. These packet commands have been derived from the SCSI
  command set; this makes it reasonably easy to rewrite existing SCSI
  CD-ROM and tape drivers for ATAPI hardware.

  Beware that non-ATAPI aware 'intelligent' controllers, mainly caching
  controllers, will be mightily confused by packet commands.
  Traditionally, the data register is only used to transport 512-byte
  sectors; a 12-byte command packet is a completely different kind of
  animal and should be treated in a different way by the (intelligent)

  11.2.  What's so special about the secondary port?

  Nothing, in principle. A secondary IDE port has been reserved in the
  PC I/O map for ages (base address 0170h, IRQ 15), and adapters that
  could be configured as secondary have been available for quite some
  time, even though BIOS support was lacking. So while it is a part of
  EIDE, there is actually nothing new about this feature, except that
  the possibility of connecting tape drives and CD-ROMs to the ATA
  adapter has transformed four device support from a luxury into a

  Actually, there is another reason to provide a secondary port for
  ATAPI devices. There are a number of advanced hardware features for
  harddisk interfaces, such as prefetch buffers and write behind, that
  may get in the way of ATAPI compatibility. This means that if the
  software drivers of an intelligent ATA-2 port are not ATAPI-aware, or
  simply don't work as they should, you may run into sticky problems.
  Especially if you have an ATAPI CD-ROM that doesn't support PIO mode 3
  transfers, a secondary port that provides only basic ATA features is a
  good way to avoid a lot of headaches.

  Finally, an ATAPI device on the primary port will cause Windows
  FastDisk drivers that aren't ATAPI aware to fail.

  Nothing prevents you from defining more ports like the primary and the
  secondary one; in addition to these two, the tertiary and quaternary
  one are semi-standard. See section 10.4 for the port and IRQ
  assignments of all these ports.

  12.  The EBIOS: translation

  12.1.  Why translation?

  Both the 'int13' software interface used by the BIOS to communicate
  with the outside and the Cylinder/Head/Sector (CHS) fields in the
  partition table reserve

  o  10 bits for the cylinder field, for a total of up to 1024

  o  8 bits for the head field, good for up to 256 heads;

  o  6 bits for the sector field, which gives a maximum of 63 sectors
     since for historic reasons the sector field starts at sector 1, not

     The maximum disk capacity accessible through the traditional int13
     interface is therefore 8GB (1024*256*63 sectors of 512 bytes). In
     some books, you may encounter references to 12-bit cylinder
     numbers; this extension (using the upper two bits of the sector
     field) was never widely implemented and isn't supported anywhere.

  Now IDE disks have their own set of limitations; these disks, no
  matter if they're ATA/IDE or ATA-2/EIDE, use

  o  16 bits for the cylinder field, giving 65536 cylinders;

  o  4 bits for the head field, or only 16 heads at most;

  o  8 bits for the sector field.

     This is good for a maximum disk capacity of 128GB. However, combine
     this with the BIOS limitations and you suddenly can't see more than
     the first 1024 cylinders of the IDE disk, which makes for a limit
     of just 504MB or 528 million bytes. This is unacceptable today. In
     the long term, the BIOS limit of 8GB is just as unacceptable, but
     as a short term solution it is desirable to get the maximum out of
     the standard int13 interface with IDE drives. This is where
     translation comes in.

  12.2.  How does translation work?

  There are roughly three ways today's BIOSes can handle translation:
  standard CHS addressing, Extended CHS addressing, and LBA addressing.
  Translation does NOT automatically imply LBA, as you will see.

  o  Standard CHS: no translation at all :-(

     Communication between drive, BIOS and operating system goes like

          +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
          |                       |    |         |    |   & APPS   |
          |   physical      T1   logical        logical            |
          | geometry used  ====> geometry ----> geometry           |
          |internally only        (CHS)           (CHS)            |
          |                       |    |         |    |            |
          +-----------------------+    +---------+    +------------+

     There is only one translation step, T1, which is internal to the
     drive ('universal translation'). The drive's actual, physical
     geometry is completely invisible from the outside---the Cylinders,
     Heads and Sectors printed on the label for use in the BIOS setup
     have nothing to do with the physical geometry! The logical
     geometry, used throughout, is subject to both IDE's limitation to
     16 heads and to the BIOS' limitation of 1024 cylinders, which gives
     the (in)famous 504MB limitation.

  o  Extended CHS

          +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
          |                       |    |         |    |   & APPS   |
          |   physical      T1   logical   T2  translated          |
          | geometry used  ====> geometry ====> geometry           |
          |internally only        (CHS)           (CHS)            |
          |                       |    |         |    |            |
          +-----------------------+    +---------+    +------------+

     Logical geometry is used to communicate between the drive and the
     BIOS, while a different, translated geometry is used to communicate
     between the BIOS and everything else.

     There is an additional translation step, T2, performed by the BIOS.
     This procedure breaks the 504MB barrier because the geometries used
     are not subjected to the BIOS and IDE limitations simultaneously:
     the logical geometry is subject to IDE's 16 head limitation, but
     not to the 1024 cylinder limitation. For the translated geometry,
     it is just the reverse.
     Most BIOSes denote extended CHS translation with 'Large'. Note that
     the geometry usually entered in the BIOS setup is the logical
     geometry, not the translated one. In case of doubt, consult the
     BIOS manual.

  o  Logical Block Addressing (LBA)

     Here, the logical geometry is dispensed with entirely and replaced
     by a single, large, linear block number. This makes far more sense
     than using a logical geometry that is completely fake anyway.

          +-------- DRIVE --------+    +- BIOS --+    +---- OS ----+
          |                       |    |         |    |   & APPS   |
          |   physical      T1    linear   T2  translated          |
          | geometry used  ====> block no.====> geometry           |
          |internally only        (LBA)           (CHS)            |
          |                       |    |         |    |            |
          +-----------------------+    +---------+    +------------+

     This breaks the 504MB barrier in essentially the same way as
     extended CHS does. Conceptually, using a single linear number to
     address a sector on the harddisk is simpler than a CHS style
     address, but it takes more CPU cycles and is sometimes slower on
     the drive side as well. The differences are pretty insignificant
     either way.

     A translating BIOS can be implemented via the system BIOS or on-
     board controller BIOS. Basically, this takes the drive's logical
     default geometry, and if the cylinder count is beyond 1024, will
     divide the cylinder count by an appropriate factor and multiply the
     heads by the same. For instance, let's take a 540 Meg drive: it has
     1057 cylinders, 16 heads, and 63 sectors per track. Well, the int13
     interface used by the BIOS to talk with the world can only handle
     1024 cylinders, but it can address up to 255 heads. So, the x-
     lating BIOS will pass to the OS, via int13 calls, the geometry 528
     cylinders (1057/2 (approx)) and 32 heads (16*2). Then, when the OS
     makes a request to the drive, the BIOS will re-translate the
     request to the original order, or to an LBA number if LBA is
     enabled. This allows for capacities of up to 8 gigabytes.

  A final word about the 8GB capacity limit, which is inherent in the
  int13 interface and cannot be solved without ditching the traditional
  calls. To that purpose, the IBM/Microsoft int13 extensions document
  specifies a new interface between the BIOS and the operating system or
  applications. These extended int13 calls are made in terms of LBA
  addresses and can handle huge disks. Note that the BIOS is required to
  translate these LBA addresses back to CHS if the drive doesn't support
  LBA---exactly the reverse of the translation process outlined above.

  12.3.  I'd like to know how translation works in detail.

  You asked for it :-)

  If a drive is less than 504MB, it should have a logical geometry, as
  reported in Identify Device words 53-58, of 1024 or less cylinders, 16
  or less heads and 63 or less sectors. Such a drive can be addressed
  directly without invoking this algorithm.  For drives over 504MB, the
  CHS address received by the BIOS from DOS must be converted to an
  Extended CHS address, or an LBA address. We'll assume ECHS for now.
  First, during BIOS setup, the BIOS must determine the value of N. This
  value is used to convert the drive's geometry to a geometry that the
  BIOS can support at the int13 interface. This interface requires that
  Cyl be less than or equal to 1024. The number of cylinders (Identify
  Device word 1) is divided by N while the number of heads (Identify
  Device word 3) is multiplied by N. N must be 2, 4, 8,..., a power of

  Second, in most translating BIOSes, the following algorithm is used
  whenever INT 13H is called to perform a read or write:

       eCyl    = ( Cyl * N) + ( Head / dHead ); /* head DIV dHead */
       eHead   = ( Head % dHead );              /* head MOD dHead */
       eSector = Sector;                        /* used as is     */

  By way of example, assume the drive's geometry is 2000 cylinders, 16
  heads and 63 sectors (these numbers are in Identify Words 1, 3, and 6)
  and that the BIOS determines the value of N to be 2. The BIOS reports
  to DOS that the drive has 1000 cylinders, 32 heads and 63 sectors when
  int13 ah=08h function is called. This is 2016000 sectors.

        Cyl/Head/Sector   eCyl/eHead/eSector         LBA

            0/0/1                0/0/1                  0
              :                    :                    :
           500/0/1              1000/0/1            1008000
          500/15/63            1000/15/63         1009007
           500/16/1             1001/0/1            1009008
          500/31/63            1001/15/63         1010015
           501/0/1              1002/0/1            1010016
              :                    :                    :
          999/31/63            1999/15/63         2015999

  Note the following about this algorithm: The physical ordering of
  sectors on the drive is unaffected---sector n is followed by sector
  n+1 for all CHS and Extended CHS and LBA addresses. This is the only
  sane way of implementing translation, but unfortunately NOT ALL BIOSES
  DO IT THIS WAY. This means that changing translation modes may be a
  dangerous thing to do.

  12.4.  What is in the Enhanced Disk Parameter Table?

  In a standard BIOS, the Fixed Disk Parameter Table (FDPT) contains
  information about the geometry of the harddisk(s). It more or less
  contains the same information as the drive type entry in the CMOS
  setup. A program that wants to use the harddisk on a low level,
  bypassing DOS, normally uses the BIOS' int13 functions to achieve

  The Enhanced fixed Disk Parameter Table (EDPT) is an extension of the
  ordinary FDPT that makes use of undefined fields to provide
  information about the translation mode used. It uses a magic number
  (A0 in byte 3) and a checksum (in byte 15) to ensure that software
  cannot mistake random data for an EDPT. This practice is more or less
  standard across various flavors of translating BIOSes, with differing
  magic numbers.

  On top of this, the Phoenix Enhanced BIOS standard specifies a number
  of extended int13 functions and a 16 byte FDPT extension. The latter
  contains detailed information about the current PIO or DMA type, block
  mode used, LBA or (E)CHS addressing, 32 bit transfer mode, media type
  (removable, CD-ROM), control port base and IRQ. In other words, it
  covers all new features of the ATA family and is flexible enough to
  accommodate more than four devices, nonstandard port addresses and
  IRQs. Proper support of all this is important to achieve any degree of
  Plug'n'Play functionality with ATA hardware. The WD EIDE BIOS lacks
  all these features.

  12.5.  How many types of translating/Enhanced BIOSes are there?

  Too many. See question 12.4 for a discussion of some of the
  differences between a Phoenix EBIOS and a WD EBIOS. For a more
  exhaustive discussion of BIOS types, Hale Landis' effort is
  indispensable---see the resource guide below.

  13.  Software details

  13.1.  Details on OnTrack Disk Manager

  Disk Manager 6.x and above is a piece of software that performs the
  translation necessary to access harddisks of more than 1024 cylinders
  with DOS/Windows. This is achieved by installing a Dynamic Drive
  Overlay (DDO) to translate drive parameters. The driver provides only
  the basic translation functions, without EDPT or extended int13 calls.
  Of course, this is less of an issue in a software driver than in a
  system BIOS.

  If Disk Manager (DM) is used to format only the slave drive, the DDO
  can be installed in the config.sys as an ordinary device driver
  (device=dmdrvr.bin). On the other hand, using DM on the master drive
  isn't quite that easy from a technical point of view. Since you must
  boot DOS from the master drive, and you must load the DDO before you
  can access the drive, the only option is to load it very early during
  the boot process, even before the operating system itself. Changes are
  made to the Master Boot Record (MBR) to accomplish this 'pre-boot

  This scheme works fine, but has a few drawbacks.

  o  First, DDO as a pre-boot loader has implications for floppy boots.
     If you boot directly from a floppy, DDO does not have a chance to
     boot and the partition does not make sense. This can be remedied by
     having a line in the config.sys on the floppy which reads
     "device=dmdrvr.bin". You can also watch for the press spacebar to
     boot from floppy message when booting from the hard drive.

  o  The second drawback is that operating system installations
     routinely overwrite the MBR with their own boot code. The DDO is no
     longer loaded and your partition will be inaccessible until you let
     Disk Manager write a new MBR.

  o  Third, a nonstandard partitioning scheme is used whereby the data
     is offset by one track. This is completely transparent as long as
     the drive is accessed through the DDO; however, many operating
     systems want to replace the DDO by their own disk routines and will
     have to be aware of this scheme.

     Windows 95 will support Disk Manager 6.x and above 'out of the
     box', as will new versions of OS/2 Warp, Windows NT 3.5.1 and Linux
     1.3.x. IBM and Microsoft have created fixes that allow older
     versions of OS/2, Warp and Windows NT to work with Disk Manager.
  o  Fourth, corruption of the DDO sector will result in a DDO Integrity
     Error.  While it is fairly easy to re-write the DDO sector (use the
     dmcfig.exe utility on your DM diskette), this is is a sign of a
     bigger problem (eg. virus) rather than a problem in
     itself---contact Ontrack tech support ( for

  An advantage of formatting the master drive with DM instead of loading
  the DDO from config.sys is that you can use Windows for Workgroups'
  32-bit file access on both drives---if you use dmdrvr.bin, the slave
  drive is restricted to 16-bit file access.

  The 6.x versions of Disk Manager have some additional disadvantages
  which are corrected in version 7:

  o  They are not fully compatible with the device drivers of most VLB
     ATA(-2) interfaces; also, ATAPI CD-ROM and tape devices on the
     chain are not supported.

  o  A final concern is disk utilities. If the utility in question goes
     directly to the hardware, without going through the DD overlay, it
     can potentially be destructive. Ontrack's policy on this is to
     refer compatibility questions to the manufacturer of the utility as
     they cannot possibly maintain compatibility charts for all versions
     of all utilities.

  You can find more information on the various versions of Disk Manager
  on OnTrack's www site <>.

  13.2.  How does Windows' 32-bit disk access work?

  32-bit disk access (32BDA), also known as FastDisk, is a set of
  protected-mode drivers that direct int13 calls to the hard disk
  controller through a protected mode interface. For the latter the hard
  disk controller has to supply an appropriate virtual device driver

  Windows ships with one such driver built in: *wdctrl.  Unfortunately,
  this device only supports controllers that are strictly compatible
  with the WD1003 standard; this excludes SCSI, ATA-2, LBA or CHS
  translation, disks with more than 1024 cylinders and even some
  commonplace features of ATA such as block mode. If it detects one of
  these during the initialization phase it will refuse to load. In
  today's computers, this means that *wdctrl will rarely do the job and
  an external VxD must be used.

  32BDA has two advantages over disk access through the BIOS. First,
  since the FastDisk VxD is re-entrant, it enables Windows to use
  virtual memory for DOS sessions. Using virtual memory without 32BDA
  could create a deadlock situation if a page fault is generated during
  the execution of BIOS routines. Since the BIOS is not re-entrant, it
  is not possible to use a BIOS call to read the page from disk until
  the first BIOS call has terminated; on the other hand, this BIOS
  thread must remain suspended until the swapped out page has been read.

  So 32BDA enables Windows to manage memory much more efficiently with
  one or more DOS sessions open.

  The second advantage of 32-bit disk access is that it saves two
  (relatively slow) switches between virtual and protected mode per disk
  I/O call. Take, for instance, a disk read performed by a DOS
  application. In the absence of 32BDA, each such call causes the
  following sequence of events:

   1     Application     calls INT21 to read from disk
   2     Windows         traps the call, switches to protected mode
   3     Windows         switches to real mode, returns to DOS
   4     DOS             makes int13 call to BIOS disk routines
   5     Windows         traps the call, switches to protected mode
   6     Windows         switches to real mode, returns to BIOS
   7     BIOS            acts upon int13 call and does the read
   8     Windows         traps the return from int13, switches to PM
   9     Windows         switches to RM, returns the result to DOS
  10     DOS             receives the result, passes on to application
  11     Windows         traps the return from DOS, switches to PM
  12     Windows         switches to RM, returns result to application
  13     Application     receives the result from the INT21 call

  Using 32-bit disk access replaces steps 6 to 8 by a single call to the
  FastDisk VxD. This removes two mode switches, resulting in a usually
  small disk performance improvement. (Steps 3-11 also apply to native
  Windows applications).

  14.  Hacker's resource guides

  14.1.  The hacker's documentation guide

  Unfortunately, this lists consistently eludes being entirely up to
  date, but it should get you started.

  o  AT Attachment Interface for Disk Drives, ANSI X3.221-1994, Approved
     May 12, 1994.

  o  AT Attachment Interface with Extensions (ATA-2), ANSI ASC
     X3.279-1996, revision 3, proposed American National Standard 948D.

  o  AT Attachment-3 Interface (ATA-3), ANSI ASC X3.298-199x.

  o  AT Attachment-4 Interface (ATA-4), X3T13 draft.

  o  ATA packet Interface for CD-ROMs, SFF-8020, Revision 1.2, June 13

  o  Western Digital Enhanced IDE Implementation Guide, by Western
     Digital Corporation, revision 5.0.

  o  Fast ATA Sourcebook, Quantum Corporation, November 1994.

  o  Enhanced Disk Drive Specification, by Phoenix Technologies Ltd.,
     version 1.1, January 95.

  14.2.  The hacker's net.resource guide

! Hale Landis ( has written a number of "how it works"
! documents dealing with boot sectors, MBRs and partition tables. These
! are available in a ZIP archive from
  Also, he has an extensive description of BIOS types, invaluable for
  programmers, a "Facts and Fiction" series that dispels a couple of
  common myths, and more. These, together with the How It Works
  documents (in case you cannot FTP) are available from his mail server;
  to get started, send an e-mail message



  This server, like the WD FTP site (in /pub/standards) has a copy of
  the ATA-2 standard as well.

  <>, a Western Digital FTP site, contains
  loads of material pertaining to the SFF Committee, the ATA, ATA-2 and
  ATAPI standards, the Phoenix Enhanced BIOS spec, and archives of the
  various reflectors (mailing lists, such as the ATA-2 and ATAPI lists).
  Look in /pub/standards/; the SFF stuff is in
  /pub/standards/sff/specs/, the x3t13 in /pub/standards/x3t13/. The
  mailing lists themselves can be accessed through;
  send a message



  to get more information.

  <> also contains information
  about ATA, ATA-2, ATA-3, SCSI-2 and many more standards.
  <> has many Phoenix specs such as
  their Enhanced BIOS document.

  <> Tech sheets (I really have to take a look
  there someday).

  Other pointers are appreciated.

Inferno Solutions
Hosting by

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру