Windows NT Super Tune-Up Kit

home *** CD-ROM | disk | FTP | other *** search

/ Windows NT Super Tune-Up Kit / PIE-WindowsNTSuperTuneUpKit-1997.iso / HD_UTIL / EIDE_FAQ / EIDEFAQ2.HTM < prev

Wrap

Text File | 1997-01-20 | 42KB | 859 lines

Enhanced IDE/Fast-ATA/ATA-2 FAQ [2 of 2] Name: Yet Another Enhanced IDE/Fast-ATA/ATA-2 FAQ Version: 1.8 Archive-name: pc-hardware-faq/enhanced-IDE/part2 Posting-Frequency: Monthly (the 24th) Last-modified: 1996/08/21 URL: http://thef-nym.sci.kun.nl/~pieterh/storage.html 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? 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, 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 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 3 90 22.2 proposed The single word DMA modes are hardly useful and will be obsoleted in ATA-3. 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 folders don't bother to point out the difference. 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 seperately. 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. 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 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/>. ! 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 descructive. 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:199x, revision 3, proposed American National Standard 948D. o AT Attachment-3 Interface (ATA-3), ANSI ASC X3T10 working draft, revision 5. 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 (landis@sugs.tware.com) 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 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. ! ! ! -- pieterh@sci.kun.nl http://thef-nym.sci.kun.nl/~pieterh/