SHAREWARE VERSION IDE BOOSTER IDE Booster will shut down after 10,000 reads/writes. This should give the average user about 8 hours of testing time to evaluate if IDE Booster is effective. The counter is reset after rebooting the machine allowing for another 10,000 reads/writes to the disk. The registered version of IDE Booster allows for unlimited reads/writes. The block device driver for AT/IDE interface hard disk drives that enables MULTIPLE SECTOR Block Transfer Mode. IDE Booster is a block device driver that is designed exclusively for AT/IDE Hard Disk Drives. Many newer IDE drives have the built in capability to significantly increase their Data Transfer Rates by activating the MULTIPLE SECTOR Block Transfer Mode. In a typical scenario, the transfer rate can be increased by up to 45% over the rate offered by the motherboard bios. Some of the newest motherboards and high-end Host Adapters are beginning to offer this MULTIPLE Mode, but this great feature of our new IDE drives has essentially remained untapped.... until now, thanks to IDE Booster! ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³±±± Command Line Switches ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ No Command Line Switches - Driver will NOT load since it requires the command line switches for instruction. B(?)xx - Block Size of xx for Unit ?. Where (?) is replaced by either 0 or 1 and xx is replaced by a value (typically an even number) indicating the number of Sectors Per Block (SPB). The SPB value cannot exceed the maximum number of sectors per interrupt defined in the drive's own microcode. RM(?) - Activate READ MULTIPLE for unit ?= 0 or 1. WM(?) - Activate WRITE MULTIPLE for unit ?= 0 or 1. P - Pause the progress of the config.sys after loading IDE Booster. Press C to continue. This is handy when confirming the status of the driver. Example: device=IDEBOOST.EXE B016 RM0 WM0 B132 RM1 P means: block size of 16 for unit 0 with READ and WRITE MULTIPLE, block size of 32 for unit 1 with READ MULTIPLE only, with a "Press C to Continue" pause after loading. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³±±± Background ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ MULTIPLE SECTOR Block Transfer Mode has its origins in the ESDI hard disk drive interface. Just prior to the development of the AT/IDE interface, the ESDI controllers were about ready to institute this very interesting ability. Similar to the IDE inquiry command, ESDI drives will report 512 bytes of information about themselves where word 47 is a yes/no variable about Multiple Sector capability. If the byte is "yes" then the following bytes will tell how many maximum sectors per interrupt may be used. The rapid pace of hard drive technology, however, has since made the ESDI interface obsolete. This is lamentable from the standpoint that the interface has a sterling reputation for quality and the drives for ruggedness. ESDI drives were typically large capacity units (of the time) that found homes in file servers and other environments that demanded critical performance from their drives. Most network managers will speak highly of the interface. Drive manufacturers soon found that the cost per megabyte could be drastically reduced by building the controllers directly onto the drive. This concept holds true for the AT/IDE interface (as well as SCSI, but that's a whole different ball game). This integrated controller also allowed the drive manufacturers to use Zone Bit Recording methods (variable sectors per track) and drive geometry translation schemes to exceed the DOS limitation of 1024 cylinders max. By building RAM buffers into the drives we finally begin to reach the point in hard drive technology where MULTIPLE SECTOR Block Transfer Mode begins to be a reality. A discussion about the microcode which manages the drive RAM buffer is worthwhile. Just like the RAM memory in our systems, the RAM buffers on an AT/IDE drive should be thought of as a "memory pool". Today's modern drives have buffers that range from simple to sophisticated. The simplest buffer schemes employ basic Read Look Ahead techniques that operate on the assumption that the next data you will request will be contiguously after the data you just got. These Look Ahead buffers generally are FIFO types (first in, first out) that either read a pre defined number of sectors, or read through to the end of the physical cylinder. It is easy to imagine that the transfer rate and speed of the data delivery to the host system is greatly increased when it is dumped from RAM to RAM (nanoseconds) instead of physically picking it up off of the drive (milliseconds). The early AT/IDE drives had buffers of only 2 to 8 KiloBytes. In terms of sectors, that is 4 to 16 (2 512 byte sectors equal 1 KiloByte). This is enough to Read Ahead the rest of a track of a 17 sector per track drive (typical of the day). Reading Ahead to the end of the cylinder requires a much larger amount of memory. Also, basic competition amongst the drive manufacturers to be faster "than the other guy" has caused the buffer sizes to increase. Other factors like spindle speeds, recording densities, and access times combine together to be part of the overall improvements that have increased drive performance. When the RAM buffer reaches a certain point in size, either the Read Look Ahead must cross a physical cylinder boundary or something else more desirable; this moves us into Segmented Buffers. From here we see Adaptive Segmented Buffers, and so on. A typical modern drive may describe its buffer as Read Look Ahead Multi-Segmented Adaptive, combining all types. Write caching is the current newcomer to drive buffer techniques. These are interesting in that the drive reports that a write has completed as soon as the data arrives in the buffer, thereby freeing up the interrupt hold on the CPU, allowing it to move on to more processing. Then the drive, under its own control, attends to laying down the data on the spinning magnetic media. This happens very quickly and does not carry with it the same negative implications that some report about write caching software. The balance between RAM allotted to write cache and read cache is usually preset to around 40/60 and may someday actually dynamically adjust to true system usage. You can begin to see that these models employ sophisticated microcode and algorithms working with a memory pool which is subdivided into various areas. The size of this total buffer memory is climbing continuously, with state-of-the-art models offering 1 megabyte of RAM. (Why do I get the feeling that this will be old news in a few months.... ?) So, what about MULTIPLE SECTOR Block Transfer? Simple, really... whatever Block Size is set, is deducted from the memory pool. For example, if a 32 sector block is set, then 16 KiloBytes of RAM are removed from the Read/Write caching on the drive. While this sounds like a setback, an actual increase in the Data Transfer Rate results from the way this can interact with DOS. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³±±± Outline ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Fortunately for all of us, the convenience of personal computers is due, in large part, to the simplification of the User Interface. We have the advantage today, over the early pioneers, of being able to simply sit down and create within our applications. We "suspect" that low level hardware operations are taking place as we work, because the equipment tends to respond to our commands. We see the hard drive activity light flicker when we open and close our files. This is as it should be for the popular acceptance of personal computers in our society. User Interfaces have become friendlier each day, and will continue to do so. We can all look forward to the near future when systems interact with more than just our fingers. In some respects, interface is synonymous with translator. As we work within our high level applications, layers of translations are taking place to convert our commands into machine language. We enjoy the benefit of not needing to know how these clever manipulations are done and can count ourselves lucky in the process. A typical read translation sequence might be as follows: 1. Application Command Open File This level has its own layers of simplification, but roughly boils down to the fact that as a programmer's source code is prepared for use, a compiler translates the file handling components into the standard DOS level software interrupts, notably Interrupt 21. source code: assign DataFile the name mydata.dat open (DataFile) read (DataFile, DataWeNeed) : Int 21, Fn 3Fh so many sectors... close (DataFile) use (DataWeNeed) These DOS interrupts provide even the programmer with the ability of being able to avoid low level interaction with the system and allows an application to operate on many types of machines. Once an application issues a DOS file command, the programmer can count on a trustworthy sequence of events and can just let it happen while waiting for a confirmation of success from the operating system. (Some say that a REAL programmer always begins with COPY CON PROGRAM.EXE .) 2. DOS File Allocation Table (FAT) The resident portion of our operating system, that part which always stays in memory, is triggered into action by the DOS read file interrupt. The first order of business is to determine if the file already exists, and if it does... where? The DOS file directories are used to make this determination and give the operating system a starting point. DOS uses a method of ordering our data into clusters, or groups of sectors, that begins with zero and numbers on up to the end of a drive's partition. This might be thought of as a kind of linear, two dimensional map and is sometimes call logical block address. Since most files are larger than a single cluster, the location of the next cluster after the start is required. This location of the next portion of the file is determined by inspecting the File Allocation Table. This table tells DOS the logical whereabouts of the next data; which does not necessarily contiguously follow the location of the last data. With DOS reading the data into memory as it goes along, these steps are repeated until the end of the file is reached. The link from location to location create a virtual chain of connections that insure that data is not lost. 3. DOS Kernel Resident Block Device Driver To this point the data is logically ordered in the two dimensional manner described above. Yet, we need to translate this into a specifically located sector on the drive, itself. Disk drives order their data by Cylinders, Heads and Sectors which is a kind of spacial three dimensional coordinate. The transition from the logical linear location to the physical spacial location is the job of DOS's own Resident Block Device Driver (Block a.k.a Disk). This requires a straight forward calculation whose result depends on the individual geometry of the drive being accessed; this geometry is stored in the Boot Records and things called Bios Parameter Blocks and is read into memory when the operating system loads. If an imaginary drive had 10 sectors per track, 10 heads, and 10 cylinders, the drive would have a total of 1000 sectors. If we were to count up through the sectors, the Heads digit (10's) would increment after the ninth sector and the Cylinders digit (100's) would increment after the ninth head. With this model, it is easy to see the relationship between the logical and physical locations. For example, the 123rd logical sector might physically be located at Cyl=1, Hd=2 and Sect=3. Aside from the fact that DOS doesn't recognize a zero in the sectors digit, this is the oversimplified way things are. Disk drives, however, come in many different capacities and make calculating a physical location more interesting. A drive with 17 Sectors per track, 6 Heads and 820 Cylinders would find the 123rd sector at Cyl=1, Hd=1 and Sect=3 (right?). 4. Interrupt 13 Call Fun and games aside, the DOS Block Device Driver then builds a hardware interrupt command that says something like "unit 0, at cylinder 1, head 1, sector 4... read it." Things start to look just like assembly language programming at this point: mov ah, 02h ; read function mov al, 1 ; number of sectors mov ch, 1 ; cylinder number mov cl, 4 ; sector number mov dh, 1 ; head number mov dl, 0 ; unit number int 13 ; disk interrupt Believe it or not, the fact is we still are looking at a language designed to provide a user friendly interface, really. Many programmers actually write their programs at this level because the finished and compiled code ends up being smaller and faster than the code produced by higher level programming languages like Basic, Pascal and C. 5. AT BIOS Port Address Command Interrupt 13 Function 02h is a program, too, in a way. Its routines are provided on a chip we all have someplace in our system, called a BIOS (Basic Input Output Services). When we power on the computer the contents of the BIOS are stored in memory and everything we do flows through these routines. All the hardware components of the computer - video, disk, keyboard, etc. - have complicated little routines which handle communicating with the hardware device. Repetition is the name of the game at this level. In the case of our read a file example, every involved sector is seeked to (sought?), read from and checked out for success, individually. What is simplified for convenience as Int 13 Fn 02h ends up being a near endless stream of machine language Port Address commands. Hard disk drives have a specific port address at 1F0h for the Primary port address and 170h for the Secondary port address. While Int 13 serves both hard and floppy disk drives, the port addresses for these two different types of drives are split apart and managed by separate BIOS routines. 6. Enter IDE Booster We've finally reached the level where it is time to consider how IDE Booster figures into the scheme of things. First, it is important to look at the challenge faced by the BIOS programmer. The hard disk drive to be used in the computer system will be one of many hundreds of types across several interfaces that range from old to new, all needing to be supported by the one BIOS routine. Given this obligation, the routines that are written are understandably generic with the same code that runs our older MFM drive also running our new AT/IDE drive. The need for general compatibility creates a situation where the special enhancements of the modern AT/IDE disk drive are left unsupported. The phrase "Multiple Sectors Per Interrupt" correctly implies the notion that normally we have only one sector per interrupt. This is the case with the standard BIOS service and is the default start up configuration of the drive. The following diagram shows that a large amount of time is spent in overhead checking the interrupt after every sector read from the port: Interrupt Confirmation (overhead) ³ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ Úi¿ sÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄÄÙ ÀsÄ ³ Sector Read With Multiple Sector Block Transfer Mode enabled on the drive, block size equals to 8, a flow of data like this results: Interrupt Confirmation (overhead) ³ Úi¿ Úi¿ sÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÙ ÀsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÄsÄÄÙ À ³ Sector Read A new routine is required to pass this type of data flow back to DOS; software of this type is called an Interrupt Service Routine (ISR). IDE Booster is an ISR replacement for the native BIOS Int 13 read and/or write hard disk drive service routines. IDE Booster resides in memory, monitoring all Int 13 requests. When a Read and/or Write request comes along, it intercepts the command and manages it directly, "hand carrying" it through to the port addresses, and the drive. The turn around time on the delivery of the data is significantly improved because much of the overhead from the interrupt confirmations has been eliminated. This causes the Data Transfer Rate to increase significantly. IDE Booster is loaded as a device driver through the Configure System CONFIG.SYS file. Since IDE Booster operates at such a low level, it remains compatible with virtually all applications. A few noteworthy exceptions do exist and are noted in the App Notes section, below. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³±±± App Notes ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ Some Application Notes: 1. We've seen a few programs which provide an interesting "public safety" feature, namely that they block attempts to write to track 0 (i.e. cylinder 0, head 0). The purpose is to provide a layer of defense against boot sector viruses. Since this is such a good idea, we decided to join in and provide the same protection. After all, our device driver is custom tailored to reading and writing to the hard disk drive and this capability only added a byte or two of additional code. IDE Booster provides this general safety precaution because no legitimate applications have any business, whatsoever, writing changes to sectors on this track without your knowledge. Reading data on track 0 is allowed, however writing to track 0 will produce a write protect error. If you need to modify data on these "hidden" sectors, then you will need to REM out the device=ideboost.exe statement in the config.sys, and reboot. 2. Drive compression software programs like DoubleSpace work perfectly well with IDE Booster. 4. Concerning Windows Swap Files: A Temporary swap file works because the file is like any other typical file with FAT updates. A Permanent swap file doesn't work because it is unlike any other typical file. Basically, a permanent swap file locks itself into an area on the drive and never moves, and since it never moves, DOS and FAT updates are no longer required. A permanent swap file is read and written directly with Int13 and cannot handle multiple sector block transfer mode. Windows should refuse to load if it sees an Int13 interrupt service routine like IDE Booster. We'd like to point out that the net gain in data transfer rate, while in Windows, from using multiple sector block transfer mode access to a temporary swap file far exceeds the gain of using native Int13 access to a permanent swap file. 5. DOS version levels and OEM versions of DOS work because they all follow the same standards accessing Int13. 6. When determining the value for Sectors Per Block (SPB) in the registered version, it is worth noting that the rate of change in the Data Transfer Rate tends to level out around 32 sector per block. Even if your drive says it can handle a higher amount, you'll probably find the increase is fairly small and not really worth it considering the RAM requirement is removed from the drive's buffer memory pool (i.e. read/write caching on the drive). 7. The Sector Per Block value can be odd or even values, however setting values to 2, 4, 8, 16, or 32 seem to make better sense as they are more adapted to the math routines involved. 8. File defragmentation and optimization utilities will generally work well with IDE Booster, however it is a good practice to simplify one's system before running this type of utility by disabling programs like drive caching software and IDE Booster. Always make sure you have a current backup before optimizing a hard disk drive. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³±±± Error Messages ±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±±³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ The device driver may display a single of error message during the loading process of the CONFIG.SYS file. It is "Error Loading IDE Booster" and results from the drive returning an aborted command when the set multiple command is issued.