From pieterh@sci.kun.nl Fri Sep 22 14:57:53 1995 Return-Path: Received: from wn1.sci.kun.nl (wn1.sci.kun.nl [131.174.8.1]) by mailhost.WI.LeidenUniv.NL (8.6.10a/FHM-1.20-M) with ESMTP id OAA23176 for ; Fri, 22 Sep 1995 14:57:48 +0200 (MET) Received: from wn3.sci.kun.nl by wn1.sci.kun.nl via wn3.sci.kun.nl [131.174.80.3] with ESMTP id OAA22557 (8.6.10/2.13); Fri, 22 Sep 1995 14:57:13 +0200 From: Peter Herweijer Received: by wn3.sci.kun.nl id OAA04340 (8.6.10/2.1); Fri, 22 Sep 1995 14:57:12 +0200 Date: Fri, 22 Sep 1995 14:57:12 +0200 Message-Id: <199509221257.OAA04340@wn3.sci.kun.nl> To: clau@netcom.com, dtauritz@WI.LeidenUniv.NL, lps@rahul.NET Subject: YA ATA-2 FAQ [2/2] Status: RO Name: Yet Another Enhanced IDE/Fast-ATA/ATA-2 FAQ Version: 1.2 Archive-name: pc-hardware-faq/enhanced-IDE/part2 Posting-Frequency: Monthly (the 24th) Last-modified: 1995/09/22 URL: http://www.wi.leidenuniv.nl/ata Maintained-by: Peter Herweijer (CONTINUED FROM PART 1) - Technicalities - This part of the FAQ is 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. 3.1.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 IO 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 7 registers, the Task File, 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. 3.1.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 | these are the 1 383 5.2 | old ATA modes 2 240 8.3 | 3 180 IORDY 11.1 4 120 IORDY 16.6 The ATA-2 specific modes (3 and 4) use IORDY hardware flow control. This means that 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; with these you're stuck with the slower modes, with 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. 3.1.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: DMA and busmastering DMA. Ordinary 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 busmastering 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, proper software support for DMA is still rare, as are interfaces supporting it. Anyway, the DMA modes supported are: DMA Mode: Cycle time transfer rate Single Word: (ns) (MB/s) 0 960 2.1 | also in ATA 1 480 4.2 | 2 240 8.3 Multiword: 0 480 4.2 | also in ATA 1 150 13.3 2 120 16.6 Note that some 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. Needless to say, the advertisements and glossy sales stuff don't bother to point out the difference. 3.1.4 How are the Task File and data I/O ports assigned? The Task File registers and the data register of the primary ATA channel occupy the following I/O addresses (in hexadecimal notation): Register Read Function Write Function 1F0 Read Data Write Data (16 Bits) (16 bits) 1F1 N/A Set Features Data 1F2 Status of sector Write sector count count for command setup 1F3 Location of starting Write sector start sector for command setup 1F4 Location of Cyl-low Write cyl-low location for command setup 1F5 Location of Cyl-high Write cyl-high location for command setup 1F6 Head/device selection Write device selection and head selection for command setup 1F7 Device Status Device command ! 3F6 Alternate Status Device Control ! 3F7 Drive Address ! ! 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. 3.1.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 more, 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. The following figure defines the relationships between the interface signals for both 8-bit and 16-bit PIO data transfers. |<------------ 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) 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 the 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 they are completely incompatible with each other in this respect. 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. 3.1.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 (0xC4) and the Write Multiple Command (0xC5) 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: - A read command has been issued, and the requested data is in the drive's buffer, ready to be taken by the host. - 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. 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. 3.1.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. ! 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 in some cases increase. 3.2.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 8-bit Task File used by harddisks is not large enough 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, for example 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 looks completely different and should be treated in a different way by the (intelligent) controller. 3.2.2 What's so special the secondary port? Nothing, in principle. A secondary IDE port has been reserved in the PC I/O map for ages (base address 170, 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. 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. 3.3.1 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. [1] 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. 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. (CHS) stands for Cylinder, Head, Sector addressing. [2] 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 are two translation steps, T1 and T2. T2 is the translation performed by the BIOS. This procedure breaks the 528MB 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 you usually enter in your BIOS setup is the logical geometry, not the translated one. In case of doubt, consult the BIOS manual. [3] 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 528MB barrier in essentially the same way as extended CHS does. Because it is somewhat simpler to use a single linear number to address a sector on the harddisk compared to a CHS type address, this often is _slightly_ (read: insignificantly) faster. Depending on the quality the drive's LBA implementation, it may even turn out to be slower. A translating BIOS can be implemented via 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 the 540 Meg drive: it has 1057 cylinders, 16 heads. Well, DOS can only handle 1024 cylinders, but it can address up to 255 heads. So, the x-lating BIOS will pass to the O/S, via INT 13 calls, the geometry 528 (1057/2 (approx)) and 32 heads (16 *2). Then, when the O/S 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 old software ! interface. 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. ! 3.3.2 I'd like to know how translation works in detail. You asked for it :^) If a drive is less than 528MB, 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 528MB, 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 INT 13H 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 INT 13H 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. 3.3.3 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 is more or less standard across various flavors of translating BIOSes. 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. 3.3.4 What are the issues concerning OnTrack's Disk Manager? This is a cross between a background section and a mini-FAQ on Disk Manager. If you want to know more or have problems, read this. 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. At present, it 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, 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. 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. The second, and perhaps most important, 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 DiskManager write a new MBR. Third, 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 that are to be corrected in version 7. They are not fully compatible with the device drivers of most VLB ATA(-2) interfaces; also, non-drive (ATAPI) devices on the chain are not supported. Disk Manager v6.x also only supports DOS (and Windows 3.x) because of the nonstandard partitioning scheme used (v7.x will be fully compatible with OS/2 Warp, Windows NT and Windows 95; Linux has been successfully installed, but has not be through the full test program, so compatibility is not guaranteed). Actually, Windows 95 will support 6.x and above Disk Manager 'out of the box', as will new versions of OS/2 Warp and Windows NT 3.5.1. IBM and MicroSoft have created fixes that allow older versions of OS/2, Warp and Windows NT to work with Disk Manager v6.x. A final concern is disk utilities. If the utility in question hooks INT13 to directly to the hardware (bypassing DOS in the process) it is not going to "see" DDO and could 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. 3.3.5 How many types of translating/Enhanced BIOSes are there? Too many. See the preceding question 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. 3.4 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 device built in: *wdctrl. Unfortunately, this device only supports controllers that are strictly compatible with the WD1003 standard; this excludes SCSI, ATA-2, CHS translation, disks with more than 1024 cylinders and even some features of ATA. 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). 3.5.1 The hacker's documentation guide ! AT Attachment Interface for Disk Drives, ANSI X3.221-1994, Approved ! May 12, 1994. AT Attachment Interface with Extensions (ATA-2), ANSI ASC X3T10 working draft, revision 3, proposed American National Standard 948D. AT Attachment-3 Interface (ATA-3), ANSI ASC X3T10 working draft, revision 1. ! ATA packet Interface for CD-ROMs, SFF-8020, Revision 1.2, June 13 ! 1994. ! Western Digital Enhanced IDE Implementation Guide, by Western Digital Corporation, revision 5.0. Fast ATA Sourcebook, Quantum Corporation, November 1994. Enhanced Disk Drive Specification, by Phoenix Technologies Ltd., version 1.1, January 95. 3.5.2 The hacker's net.resource guide Hale Landis (landis@sugs.tware.com) has posted a technical discussion of various BIOS types and how they support drives with more than 1024 cylinders on csip.hardware.storage. This is available from Daniel Tauritz' ftp and www sites (see the user's resource guide) and is invaluable to programmers having to deal with this mess. Lately, he has released a veritable flood of 'how it works' documents dealing ! with boot sectors, MBRs and partition tables. They have been archived ! at ftp://fission.dt.wdc.com/pub/otherdocs/pc_systems/how_it_works. 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 mailing lists themselves can be accessed through majordomo@dt.wdc.com; send a message To: majordome@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. Other pointers are appreciated. (EOF)