💾 Archived View for gemini.spam.works › mirrors › textfiles › computers › DOCUMENTATION › ideboost.t… captured on 2022-06-12 at 06:34:13.
-=-=-=-=-=-=-
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.