Партнёры:
Хостинг:
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
URL: http://come.to/eide
Maintained-by: Peter den Haan <pieterh@sci.kun.nl>
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,
mathematically,
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
rates:
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
bandwidth.
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
support.
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
Multiword
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
related.
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
specification.
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____________________/
|<-------tB-------->|
*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
modes.
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 <http://www.quantum.com/products/whitepapers/>.
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
<http://www.seagate.com/new/sep96/mr_techp.shtml>.
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)
controller.
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
necessity.
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
cylinders;
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
0.
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
this:
+-------- 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
2.
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
this.
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
loading'.
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 (tech@ontrack.com) for
assistance.
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 <http://www.ontrack.com>.
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
(VxD).
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
1994.
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 (hlandis@ibm.net) 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
<ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works/>.
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
______________________________________________________________________
To: hiw@sugs.tware.com
help
end
______________________________________________________________________
This server, like the WD FTP site (in /pub/standards) has a copy of
the ATA-2 standard as well.
<ftp://fission.dt.wdc.com/>, 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 majordomo@dt.wdc.com;
send a message
______________________________________________________________________
To: majordomo@dt.wdc.com
help
end
______________________________________________________________________
to get more information.
<ftp://ftp.symbios.com/pub/standards/io> also contains information
about ATA, ATA-2, ATA-3, SCSI-2 and many more standards.
<ftp://www.ptltd.com/pub/phoenix_docs/> has many Phoenix specs such as
their Enhanced BIOS document.
<ftp://hddtech.millcomm.com> Tech sheets (I really have to take a look
there someday).
Other pointers are appreciated.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |