421 lines
22 KiB
Plaintext
421 lines
22 KiB
Plaintext
|
||
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.... <grin>?)
|
||
|
||
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 <groan>.)
|
||
|
||
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.
|
||
|
||
|