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!
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Command Line Switches <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Background <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Outline <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
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)
|
|||
|
<20>
|
|||
|
<20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD> <20>i<EFBFBD>
|
|||
|
s<><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD>
|
|||
|
<20>
|
|||
|
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)
|
|||
|
<20>
|
|||
|
<20>i<EFBFBD> <20>i<EFBFBD>
|
|||
|
s<><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD> <20>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD>s<EFBFBD><73><EFBFBD> <20>
|
|||
|
<20>
|
|||
|
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.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> App Notes <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>Ŀ
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD> Error Messages <20><><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
<EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD><EFBFBD>
|
|||
|
|
|||
|
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.
|
|||
|
|
|||
|
|