Hard Drive Terms Reference
Copyright (C) 1997 by Erik van Straten.
All (registered) trademarks are recognized.
Last major change: 04/16/1997 by EvS. Last file modification:
TIP: having problems with hypertext jumps in frames? Then mark the
following string: http://www.computercraft.com/docs/evsterms.shtml
and copy it to the clipboard, paste into your browser's URL line and press
- General Terms: Cache,
Write-Cache, Write-Back, LazyWrite, Write-Through
- Harddrive terminology: Cylinder,
Head, Side, Track,
- Chips: ROM, EPROM,
FLASH-ROM, FLASH-EEPROM FLASH-RAM,
Shadow RAM, Cache RAM, Static
- BIOS-Level Disk Access: WD1003, AT command
set, INT13, DMA, Direct
Memory Access, Bus Master DMA,
Fast PIO modes, Programmed I/O,
HDD BlockMode, MultiSector Setting, Blocks per Interrupt, Sectors/IRQ,
32BDA, 32-Bits Disk Access, FastDisk,
LBA, CHS, XCHS, Translation,
Ontrack Diskmanager (DDO, Dynamic Drive Overlay), Microhouse EZ-Drive,
Partition, primary partition, extended partition,
logical partition or logical drives,
Partitioning, Partition Efficiency,
Suggested Partition layout, MBR,
Master Boot Record, Formatting, Low-Level Formatting,
BootSector, FAT, File Allocation
- Operating System Software: BIOS,
DOS, DOS622, WfW, WfW311, WfWG311,
W310, W31, Windows 3.1, W311,
Cluster, SMARTDRV.EXE, SmartDrive,
32BFA, 32-Bit File Access, VFAT
- 32BDA Warning
Quantum Data Loss page, to my
tools page or
to the COMPUTERCRAFT
IRQ (Interrupt Request) - Lines on the bus used to signal hardware
I/O (Input Output) - Peripherals accessible by the CPU through
registers at specific I/O addresses (or I/O ports).
PIO (Programmed Input Output) - Exchange of data between memory and
peripherals by means of Input Output commands.
DMA (Dynamic Memory Access) - Transferring data directly between
memory and peripherals without going through the CPU.
ISA (Industry Standard Architecture) - 8 bit and 16 bit expansion
slots used by PC, XT, and AT designs. Often called IBM Standard Architecture.
EISA (Extended Industry Standard Architecture) - Developed by several
independent manufacturers (Compaq, AST, Zenith, Tandy, etc.) to standardize 32
bit operation and combat IBM's MCA.
MCA (Micro Channel Architecture) - Expansion bus introduced by IBM in
1987, used by some (but not all) PS/2 models.
PCI (Peripheral Component Interconnect) - High speed bus developed by
Intel to support the demands of Pentium and 486 based computers.
VLB (VESA Local Bus) - High speed, 32 bit extension to the ISA bus
promoted by the VESA (Video Electronics Standards Association).
ST506/412 - Standard interface used on XT and AT drives and
controllers. Originally developed by Seagate Technologies to support their ST506
(5 MB) and ST412 (10 MB) drives. The entire controller mechanism is located on a
controller card and communications between the drive and controller flow over 2
ribbon cables - one for drive control and one for data.
ESDI (Enhanced Small Device Interface) - Developed by Maxtor in the
early 1980's as an upgrade and improvement to the ST506 design. While the drive
does not have an embedded controller, one of the most critical functions
,encoding-decoding, is performed on the drive. This allows for faster
communications and higher drive capacities. Uses the same cabling as ST506
interface, but carries different signals on each line.
SCSI (Small Computer System Interface) - Based on an original design
by Shugart Associates, SCSI is not specifically a drive interface, but a method
of allowing different devices to communicate with a PC. For hard drives the
entire controller is built onto the drive PCB, allowing for very high speed
transfers to and from the drive. Fully interpreted, parallel data is then
transferred to and from the PC by way of a single cable through a bus interface
that has configured the device as a hard drive.
IDE (Integrated Drive Electronics) - A technology pioneered by Compaq
and Conner that embedded a controller onto the hard disk PCB while maintaining
compatibility with the register level commands sent by the computer's INT 13
routines. IDE drives are configured and appear to the computer like standard
ATA (AT Attachment) - Implementation of the IDE design with a 16 bit
AT style controller on board the drive.
XTA (XT Attachment) - Rarely used implementation of IDE with an
integrated 8 bit XT controller.
ATA-2 - Enhancement to the AT Attachment standard to provide for
considerable performance improvement and more sophisticated drive
EIDE (Enhanced IDE) and FAST-ATA - Various implementations of the
ATA-2 standard as marketed by Western Digital (EIDE) and Seagate/Quantum
MFM (Modified Frequency Modulation) - Common technique used to encode
the magnetic fluxes recorded on a drive into data. Still used on floppy drives
and most original XT and AT systems. Notice that most drive types supported in
CMOS have 17 sectors per track. This is the standard density for MFM encoding.
RLL (Run Length Limited) - Encoding method that allows 50% more
information to be recorded on a track than MFM. Actually accomplished by
recording more fluxes for every byte, but packing them more tightly onto the
surface. Often called 2,7 RLL because the recording scheme involves patterns
with no more than 7 successive zeros and no less than two.
ARLL (Advanced Run Length Limited) - More complex yet powerful
derivatives of the RLL scheme. Include 1,7 and 3,9 encoding.
- Cache: generally a buffer between a slow and a fast device.
Initially, data transfered from the slow device is passed to the
fast device at the rate of the slow device, but meanwhile, the
data that flows is also stored in the buffer. If the fast device
requests the same data, before the buffer is flooded with other
information, then the buffer can pass the requested data to the fast
device, without accessing the slow device. If the buffer has filled up
completely, typically the LRU (Least Recently Used) algorithm is used for
deciding which part of the buffer can be overwritten with new data. Cache
can be found in decicated RAM chips, but also in
software algorithms exploiting normal DRAM in a PC for caching relatively
slower devices like harddrives. Typical examples are
SmartDrive or the built in VCache (32BFA) in
WfW311. Most motherboards have
cache RAM in between the CPU and normal RAM.
the device and the cache are synchronized, i.e. contain the same data!
- Write-Cache, Write-Back, LazyWrite, Write-Through: Usually when
data is ment to be written to a device, this is done immediately. Mostly
it is also written to cache, in order to have it in the buffer if a
read-request for that same data is issued next. This technique is called
write-through. However, if the data has been written to the buffer, it is
also possible to delay the actual write of that data to the device.
This technique is referred to as write-back, LazyWrite and Write-Caching.
One advantage of this technique is that the CPU (read: user) does not have
to wait for the actual write to the device, which can happen when the CPU
has more time later, or in the form of a background process. Secondly,
often some part of the just-written data will be modified again. For
example, this happens to directory sectors when you copy a number of files
to that directory. Having write-caching enabled saves a lot of time
because updating the FAT's and directory sectors is suspended until all
file-contents have been written, which also saves a lot of time because
now much less head seeks have to take place (between the directory, FAT
and the area on disk where the actual filecontents are written).
Warning: one should realize, that data which was not physically
written to a disk is lost forever when a power failure occurs, or when the
user switches off the PC to soon. Some harddisks (mainly SCSI) allow
internal write-caching, and if they do, it can often be switched off,
which may be a smart thing to do if the PC is to be used by unexperienced
users and is not backed up by an UPS (Uninteruptible Power Supply).
Another problem related to write-caching is that bad sectors will not be
noted immediately. Most Operating System (and BIOS) routines will return
an error value to a program when a file-write was unsuccessful. However,
with write-caching, that return-value will always be a "success" value,
because the Operating System MUST assume that the diskwrite will succeed
later! Should an error occurs later, when the data is actually being
written to disk, then the Operating System has no means of informing the
program that the data could not be written (in fact, the program may not
be running anymore!). In that case, it usually halts the system with a
"blue screen", and you will loose all unsaved data in all open
applications. Fortunately, most harddrives are very reliable, and in
addition, they have internal schemes to "remap" bad sectors to other
physical locations on the drive without the Operating System (and user!)
being aware of this. However. floppy drives do NOT have this feature.
Therefore I strongly advise not to enable and use write-caching for
- Cylinder: concentrical tracks on one or more disksides the
harddrive's read/write head can be positioned over. The heads are mounted on a
"fork" which positions all heads in a certain cylinder position.
- Head, Side: this refers to the harddrives read/write head currently
active. Since most harddrives have at least 2 heads also the term Side
is used for referring which disk and side has an "active" head over it.
- Track: the combination of the cylinder all heads are over, and
the selected head.
- Sector: the smallest unit that can be read from/written to a disk.
Without special drivers, DOS and windows can only cope with 512-byte sectors.
All hardware devices containing some kind of microprocessor need software to
start-up, get running, or "boot" with. That software cannot be stored on a disk,
since microprocessors do not know how to access them.. They need other chips and
a program to tell them how to do that, in order to read the actual operating
system from the disk. That program is usualy stored in ROM, EPROM or FLASH-ROM,
and the other chips are usually in the chipset on your
- ROM: Read Only Memory. A chip that contains software routines
and/or data which were stored in it during the manufacturing process. It's
contents cannot be altered in any way except by unexpected failure.All
hardware devices containing some kind of microprocessor need software to
"boot" with. That software cannot be stored on a disk, since microprocessors
do not know how to access disks. They need a program to tell them how to do
that, in order to read the actual operating system from the disk. That program
is usualy stored in ROM, EPROM or FLASH-ROM. The BIOS
stored in ROM is usually a part of the Operation System.
- EPROM: Erasable Programmable Read Only Memory. EPROM's can be
erased a number of times using UV (Ultra Violet) light. Afterwards they can be
reprogrammed using an EPROM-programmer, a process sometimes called "burning".
- FLASH-ROM, FLASH-EEPROM, FLASH-RAM: just like a ROM, will have it's
contents unchanged when power is switched off. However, it's contents can be
altered by special software. Mostly it is partitioned into sections, where
some sections can be write-protected by a switch or a jumper.
- Shadow RAM: A disadvantage of the various ROM types is that they
have long access times compared to RAM, making them slow. Further, they
typically are 8-bits wide. The fact that 486 processors access 32 bits, and
Pentium chips even access 64 bits from RAM at a time, makes this comparison
even worse. That is why typically ROM contents are copied to RAM during the
boot process. The RAM used for that is mostly called "Shadow RAM" and is part
of the normal memory (DRAM) in you PC. Mostly the BIOS/chipset will
write-protect it after having copied the ROM contents into it.
- Harddrive Cache, Harddrive Buffer: most harddrives have RAM built
in that stores often accessed sectors. The buffer is also used for read-ahead
purposes. When software reads a sector from disk, it often will also want to
read the next sector, but only after processing data from the first sector. If
the software requests the next sector after the processing-delay, that next
sector may have already rotated away under the drive's read/write head, and
thus it will take an extra revolution of the disk to read that next sector.
The read-ahead mechanism mostly reads in an entire track, or even tries to
predict which sectors may be requested next. Pretty complicated algorithms may
be in use for this. Among others, Quantum has some information about
algorithms like these:
- Cache RAM, Static RAM: a special type of RAM that often is much
faster than normal RAM (like DRAM, SDRAM, EDO and BEDO: I won't go into those
here). Often static RAM is used as cache between the CPU
and main memory. This impoves execution speed of routines that are used often
and of data that is read from/written to often. Static RAM is also used as
built-in harddrive cache. The term static refers to the
fact that no special tricks are required to have the RAM retain it's data
(except for having the supply voltage available). Compare this to DRAM
(Dynamic Random Access Memory) chips, they need a mechanism that "refreshes"
bits in order to retain the data. Compared to DRAM, Static RAM usually has a
lower access time, is more expensive, mostly has much less KBytes/chip and
usually does not have multiplexed address lines.
- Chipset: mostly 2 to 5 microchips on your PC's motherboard. They
form the interface between the CPU and other devices like DRAM, cache-RAM, I/O
ports etc. Nowadays they usually include 2 fast IDE controllers. The
complexity of these chips, also called ASIC's (Application Specific Integrated
Circuit), starts getting pretty near that of other high-tech chips like CPU's.
That is why they also can have some bugs in them, depending on manufacturer,
type and revisison. For example, the RZ1000 chip (part of an Intel chipset) is
known to cause data-corruption on EIDE drives under certain Operating Systems.
- Microcontroller, Firmware: A microcontoller is a special-purpose
CPU (Central Processing Unit, or MicroProcessor), often with extra I/O ports
built in. It runs on a program generally called the firmware, which is usually
stored in ROM or FLASH-RAM (which may or may not be part of the
microcontroller chip). Current harddives are complete computers of their own.
The microcontroller inside is responsible for a lot of things, including
positioning the heads over the right tracks, transferring data to and from the
attached cable (to the HD controller on the motherboard), recalibrating the
drive and for internal translation.
Microcontrollers are also used in automobiles, washingmachines and microwave
ovens (just to name a few). Like other software, firmware can have bugs, and
sometimes a replacement or an update is necessary. For example, the firmware
in Western Digital harddisks can be updated using a special program that runs
on a PC. I expect harddrives from other manufacturers to have similar
possibilities. While the drive's Serial Number is ususally printed on the top
of the harddrive, the Firmware Revision (or version) number is not. However,
you can obtain both (serial number and firmware rev.) numbers using a modern
harddrive diagnostics program. These programs issue an "Identify Drive"
command, and the harddrive will respond with a lot of details, including those
numbers. Check my
tools page for some
diagnostics programs that reveal this information.
BIOS-Level Disk Access
- ROM-BIOS: This is actually more or less a part of the
Operating System's BIOS.
- WD1003, AT command set: the standardized interface for old IDE
(non-EIDE) harddrives. Drivers and BIOS releases that conform to this standard
use the drive in CHS mode, and thus limit the drive
to 528MB (where M equals 1,000,000) or 504MB (where M equals 1024x1024). This
is due to the fact that this standard command set has the following maximum
- Cylinder range from 0..1023 (1024 cylinders in total)
- Read/write head selection range from 0..15 (16 in total)
- Sector selection (on the current track) range from 1..63 (63 in total,
for historical reasons counting starts at 1 here)
- INT13: In Intel-based PC's, usually Operating System functions are
called via software-interrupts (a software-interrupt is actually a
"subroutine" called by software, not to be confused by a hardware interrupt,
which get's called when a hardware event takes place which has caused the
CPU's interrupt-input to change in potential). Somewhere at a low memory
address there is a pointer table. The pointers in it point to Operating System
functions. One of them is used for Int13, which happens to be the entry point
for a number of low-level disk access routines in the BIOS, like functions to
read and write "absolute" (specified in Cylinder/Head/Sector values) sectors.
At entry of the basic Int13 routine, the contents of one of the CPU registers
defines which sub-function to call. Most Int13 sub-functions use other CPU
registers to pass the values for the cylinder, head, sector, number of sectors
to transfer and a memory address. The fact that only 10 bits are used for
specifying the cylinder value in these Int13 routines causes the infamous 1024
cylinder or 504/528MB limit, which can only be overcome by some
translation tricks, or by no longer using this BIOS
call. However, for compatibility reasons with DOS programs this routine cannot
simply be discarded. A proper Windows 32BDA driver
replaces all INT13 functionality..
- DMA, Direct Memory Access: a technique that allows other devices
than the CPU to write to memory (RAM). In most computers this is the preferred
technique to transfer lots of data fast. Basically, the CPU tells the DMA
controller which device to access and where in RAM to read the data from, or
write the data to. After these instructions, the DMA controller transfers the
requested data and notifies the CPU when it is ready. However, in standard AT
compatible PC's the built-in DMA controller has a number of serious
limitations: it's speed and memory ranged are limited by the AT bus
specifications which means that it runs at 8MHz (limiting actual speed at a
few MB/second) and can only access 16MB RAM at max. Typically, the AT-DMA
controller is no longer used for harddrive communication, but floppy-drives
and soundcards often still use it. Both EISA en Intel-PCI based motherboards
have a new DMA controller, that does not have the limitations of the AT-DMA
controller. Some 32BDA drivers may be using fast DMA
modes, but as far as I know most BIOS'es stick to fast PIO modes. A problem
exists with DMA and Operating Systems that use Virtual Memory. One of the
implictions of virtual memory is that a virtual address (the one used by
software, for example the address where a database-record should be loaded)
does not have to be the same as the physical address. Because older drivers
may be unaware of this sitation, a technique called DOUBLE-BUFFER was
introduced, which prevents the DMA controller form transferring data to a
wrong address (physical address, since that's all controllers know about). The
DOUBLE-BUFFER technique reserves a memory block that has the same virtual as
physical address, which is where the DMA controller reads from and writes to.
It is the job of the Operating Software to transfer the data from virtual
memory to the buffer and back. Of course, some overhead is involved in this.
- Bus Master DMA: Usually this means that not the onboard DMA
controller is used, but rather one on an expansion card. However, in my
opinion that is not a good explanation. As far as I know, for "normal DMA",
the DMA controller will request the CPU if it can take over address and
data lines in order to access memory; the CPU may agree on this or not. A "Bus
Master DMA" controller has the power to make the CPU shut-up regardless
what the CPU thinks about this. You should realize that only one device at a
time can access main memory (DRAM), either the CPU or the DMA controller. This
means that each of them will have to wait for the other. Also see
PIO vs DMA.
Of course, cards mounted in AT-slots will have the same limitations as
the onboard AT-DMA controller (i.e. 8MHz and 20 address lines limiting memory
access to 16MB). Current motherboards equipped with modern chipsets and a PCI
bus often have a 32-bit (accesses 32-bit wide RAM simultaneously) Bus Master
DMA controller built-in. This PCI-DMA controller does not have the limitations
of the old AT-DMA controller (which is still supported by the way) but
requires special drivers to be activated. Only true multi-tasking operating
systems like Windows NT, OS/2 and Linux will benefit from this, because these
DMA controllers allow the CPU to spend most of it's time on a foreground
process, while in the background a filetransfer can take place. Therefore
there are no busmasterdrivers available for DOS/WfW (as far as I know, please
let me know if I'm wrong!).
- Fast PIO modes, Programmed I/O: To overcome the slow transfer modes
from the AT-DMA controller in PC's with fast CPU's and fast harddrives, PIO
was invented. Instead of using the AT-DMA-controller to transfer data, now the
CPU takes care of transferring 16-bit words to and from the harddrive. This
involves a lot of CPU overhead, which is not so bad on more-or-less
single-tasking operating systems like WfW (see also PIO vs
DMA). Currently PIO modes 0 through 4 are common, where 0 is slowest. For
the slower PIO modes 0, 1, and 2, data is simply "put" on the cable (either by
the drive or the CPU, depending on the operation being a read or write) while
the sender assumes the receiver reads the data within a specified amount of
time, depending on the PIO mode used. For PIO modes 3 and 4 a "handshake-line"
called IORDY (I/O Ready) is used to synchronize this communication, which
takes place at really high speed. Some older and cheaper motherboards have
problems with PIO 4: data corruption without a warning may occur, causing
programs to fail or compressed files to show CRC-errors if you unpack them.
Data-corruption may also be caused by too long datacables. PIO works as
follows: when a sector mus be read from the drive, the CPU will issue a
command to the drive to do so, and then the CPU can do other things. The drive
will find the requested sector and read it into it's internal harddrive-cache.
When the full sector has been read, it will issue a hardware interrupt
signalling the CPU that the data is available. Then the CPU will read the data
(2 bytes at a time) with high speed from the harddrive and write it to main
memory in one burst. See also HDD BlockMode for a
- PIO vs DMA: A lot of people argue that DMA is much better than PIO,
since PIO transfers involve a lot of CPU overhead (the CPU is actually reading
bytes from the harddrive interface and writing them into main memory, or in
the other direction for diskwrites). However, during DMA transfers the CPU
cannot access main memory. Some smart chipsets may allow the CPU to continue
reading from/writing to cache-RAM, but this is rather tricky. Imagine what
happens when the CPU is reading data from a cache-area, that is supposed to be
a representation of main memory, which was just overwritten by the DMA
controller! The trick to prevent these mismatches is called bus-snooping (the
chipset keeps an eye on the address lines, and if it sees that data at an
adrdress which is also in the cache is modified, then 2 things can happen: 1)
either that cache-entry is invalidated, effectively causing the CPU and
chipset to need access to RAM causing a block until the DMA transfer is done,
or 2) the chipset ALSO reads the DATA that is transfered to main memory and
updates the cache accordingly. Of course this trick will not work if the CPU
writes to the cache, since it is possible that the data, from the address the
CPU really ment to write to, is currently being transferred to disk, causing
Alternatively, the simple solution is to stop the CPU during DMA
transfers. However, even in case the CPU is put on hold during DMA transfers,
the CPU overhead is less since no instructions have to be read from memory to
do the PIO transfers (a DMA controller is based on hardware, it does not read
"program instructions" to do it's job). Further, moderate DMA data-transfers
will occupy the buses for only a few percent of time. So DMA may indeed allow
the CPU to do more things than PIO would (depending on the chipset), but it
typically does not result in a 100% CPU availability during data transfers!
- HDD BlockMode, MultiSector Setting, Blocks per Interrupt, Sectors/IRQ:
This fast PIO-mode option allows the CPU to transfer
multiple sectors in one burst, instead of just one sector. Because DOS stores
files in clusters, accessing a file means that DOS will request the BIOS to
read bunches of (for example) 16 sectors (see
Partition Efficiency). If the BIOS (actually the CPU reading instructions
from the BIOS) would read 1 sector at a time, then this means that the
following things happen:
- A read-request is sent to the drive
- The drive finds the sector and reads it into it's harddrive-cache,
meanwhile the CPU can do other things
- The drive issues a hardware interrupt
- The CPU transfers the data
- A read-request for the next sector is sent to the drive
- However, the harddrive didn't stop rotating after the previous sector.
It may take a full revolution before the next sector is read (assumed it is
on the same track, and no head seek is involved, which is often the case).
For a 5000RPM drive this means a delay of 12 milliseconds! By the way, that
is why old drives used to have "Interleaving": an imaginary disk with 4
sectors/track would have sectors numbered as 1,3,2,4 (or even 1,4,3,2).
After reading sector 1, the transfer to memory takes place (while sector 3
spins under the head), and when sector 2 is requested, it will be there.
Possibly modern drives are interleaved as well, but this is not "visible"
from the outside, and may depend on the manufacturer. This is yet another
reason why you should never low-level format IDE drives.
Further, there is some overhead involved in each hardware interrupt: the
CPU must save all it's registers in some safe place (the stack) because it
needs those registers during the data transfer, and afterwards, restore the
register contents and continue with what it was doing before. For both reasons
BlockMode was invented. With BlockMode enabled, the CPU will request a range
of sectors, which the harddrive will read into it's internal cache, and issue
only 1 interrupt to initiate the data-transfer to memory in 1 big burst. Of
course, both the harddrive (firmware and cache-size) and the Int13 routine
must support this. However, having the BIOS Int13 routine using BlockMode,
does not necessarily mean that BlockMode is used by Windows. That depends on
the 32BDA driver used. The number of sectors per interrupt is also called the
"blocking factor" and is typically 8 or 16 for recent harddrives. Most BIOSes
will determine and use this number on a per-drive bases. This allows the
concurrent use of old and new drives, and not have the old drive limiting the
preformance of the new drive. The software will only benefit from BlockMode if
it asks the BIOS (or driver, like the 32BDA driver) to read multiple sectors;
only in that case indeed multiple sectors will be read from disk. Therefore,
especially FAT filesystems with large clustersizes will benefit most from
BlockMode (unless compressed with DoubleSpace or DriveSpace, but I wouldn't
use those performance-killers anyway, considering the current harddrive
prices). However, without BlockMode, things aren't as bad as it seems. This is
due to the fact that most harddrives will do read-ahead's when 1 sector is
requested: the drive will be loading followup sectors in the harddrive-cache
without having been asked for it, yet, which typically happens next.
This reduces much of the problem to the extra CPU overhead involved in
- 32BDA, 32-Bits Disk Access, FastDisk: a means for windows to bypass
the BIOS to directly access the harddisk using a protected mode driver. It's
job, like the BIOS INT13 routines, is to actually
transfers sector contents to/from memory. W31 and WfW come with a built-in
driver called WDCTRL which only supports WD1003
compatible drives (smaller than 528MB), and as such is useless for current
drives. It is loaded from SYSTEM.INI in section [386Enh] in a as device=*wdctrl.
If you do not have such a line in SYSTEM.INI, then you're not running it, if
you do however, this doesn't necessarily mean it matches your drive(s)! See my
32BDA warning below. 32BDA was introduced in
MS-Windows V3.10. Although the name "32-Bit" seems to suggest that data is
transferred 32-bit at a time, this is not true for IDE (and EIDE) drives,
since they have a 16-bit AT interface with 16 (electrical) data-lines. As
such, this is a physical limitation. Theoretically the combination of an
appropriate 32BDA driver, controller and a Wide-SCSI drive could result in
actual 32-bit transfers (I don't know if something like this really exists).
The name 32-Bit only has to do with the fact that this is a Virtual Device
Driver which uses 32-bit instructions and CPU-registers , and runs in
Some commonly used 32BDA drivers for Windows are, to name a few:
- Device=*WDCTRL: the W31 and WfW built-in 32BDA driver which only
supports WD1003 compatible drives. Therefore typically useless.
- ONTRACKW.386: a 32BDA driver made by
Ontrack and licensed to
Quantum. I found the latest version,
V1.06 in the complete Ontrack DiskManager driver-set V7.12 (licenced to
Quantum). See my
page. This driver is known to also work on non-Quantum drives (without
having any Quantum drives installed) but using it that way is a violation of
the copyright on it.
- WDCDRV.386: a 32BDA driver written by
Western Digital. Version 2.6 has some
extra options for tuning, I once tried fiddling with them but didn't notice
any performance differences. Version 2.6 is the version that came with
Ontrack Diskmanager V6.03 for WD drives. It only works if you have at least
one WD drive connected. Apart from the problems reported in this artcile it
worked flawlessly with a Quantum Fireball TM2100A and a WDAC31600,
regardless which was slave and which was the master drive. However, I saw
recently that WD no longer supports Ontrack software and has switched to
Ontrack's competitor, Microhouse. I'd like to note here that I never
had any problems with either Ontrack Diskmanager V6.03 or WDCDRV.386 V2.6. I
have them running on at least 10 PC's.
- MH32BIT.386: a 32BDA driver written by
Microhouse. Note that older
versions of this driver will only run when EZ-Drive is installed on the
- SGAT.386, SEG32BIT.386: 32BDA drivers for
Note that when you install Windows95 over your current Windows 3.x files,
Win95 may refuse to run in 32-bit mode and will use DOS-compatibility mode
instead (which really slows down your system). Removing the line
device=xxxx.386 (where xxxx is one of the drivers above) usually helps.
- LBA, CHS, XCHS, Translation: terms used mainly in BIOS setup
screens. LBA means Logical Block Addressing, often incorrectly referred to as
a scheme to overcome the 504/528MB limit in BIOSes caused by the
INT13 interface (when a harddrive is marked for LBA
access in the BIOS, then the BIOS will ALSO take care of the necessary
translation). CHS refers to the old Cylinder/Head/Sector addressing (WD1003);
which limits drives to 504/528MB. From a DOS point of view, XCHS is a the same
as LBA, since the BIOS will apply a translation for both modes (the difference
is only in how the BIOS communicates with the harddrive). Since all modern
drives support LBA it is best to avoid XCHS if possible. The following table
shows the various standards involved as limiting factors:
|EIDE controller CHS
|EIDE controller LBA
|BIOS INT13 call
|CHS via INT13
|LBA/XCHS via INT13
In the table above, M equals 1024x1024 and G equals 1024x1024x1024. The
upper two data rows show which commands are sent to the drive by the
BIOS; the lower three rows show how "DOS" (the Disk
Operating System, i.e. on the level of files and directories) communicates
with the BIOS. When the EIDE drive is used in LBA mode, then all bits are
grouped together to form one "word" of 28 bits, allowing 2^28 combinations,
which provides for the ability to address approx. 268 million sectors of 512
bytes each, yielding 128GB.
The BIOS takes care of the actual transfer of sectors from the harddisk to RAM
and backwards. DOS calls the BIOS through standardized routines, that is, with
standardized parameters. And that's where the problem is. Simply said, the
BIOS routine "ReadSector" takes parameters with maximum values
displayed in the "BIOS INT13 call" row in the table above. However, the
hardrive, which contains the EIDE controller, also has maximum
values in the commands that are passed to it. The unfortunate combination of
both worlds (BIOS and EIDE) results in the restricted maximum values shown in
the "CHS via INT13" row (note that EIDE can handle a max. of 16 heads, while
INT13 can handle a max. 1024 cylinders).
Because the maximum values of both BIOS and EIDE are standardized, not much
can be done about this, except by a trick called translation, used by the BIOS
modes LBA and XCHS. DOS can call the BIOS Read-Sector routine while specifying
1 out of 256 heads and 1 out of 1024 cylinders, but the harddrive can only
handle 1 out of 16 heads, but on the other hand, upto 65636 cylinders.
Translation solves this IN the ReadSector routine (in the BIOS): it
devides the head value it got from DOS by 16 and at the
same time multiplies the cylinder value it got from DOS by
16. For a 7.8GB drive, the translationfactor 16 is the
only posibillity. For smaller drives, often smaller translationfactors (i.e.
2, 4 or 8) are used. Device-drivers like Ontrack Diskmanager
use a similar translation. In the case of LBA, the passed CHS values are
converted into a logical block number which addresses the harddrive as one
large array of sectors (counting starts with 0 here).
Note: since real 32-bit Operating Systems have their own 32-bit BIOS
built-in (they fully bypass the 16-bit ROM-BIOS) and directly access the EIDE
controller, they can handle drives upto 128GB (note that LBA is not limited to
7.8GB, but only LBA via INT13 is). Of course, if any INT13 functionality is
supplied in such an OS, access via that call will be limited to the first
7.8GB of the drive. A nasty problem here is the boot process: files involved
in that boot process must be stored within the first 7.8GB (1024 cylinders at
256 heads and 63 sectors/track) of the drive, because the
ROM-BIOS has to take care of loading them. However, I expect a "smarter"
BIOS standard soon.
Translation also takes place within the harddrive.
Modern drives typically have more cylinders, 2-6 read/write heads, a variable
number of sectors/track (more on the outer tracks than on the inner, to keep
the Bits-Per-Inch value as high as possible over the disks). However, the BIOS
and operating system are unaware of this since the
microcontroller in the harddrive fully takes care of it.
Because of the fact that drives do internal translation anyway, they do NOT
mind how you address them: for an imaginary drive of 63MB (with 512
bytes/sector) it makes no difference if you specify it as 2048/1/63 (C/H/S) or
512/4/63, as long as the total number of sectors you can access does not
exceed the total number of sectors actually on the drive. Note that you cannot
exceed any of the maximum INT13 values here: max. 1024 cylinders, 16 heads and
63 sectors/track. Also note that if you change settings like this in your
BIOS, or switch from XCHS to LBA, then you will have to repartition your
drive, and reformat the partitions on it! One more remark: changing PIO- or
BlockMode has nothing to do with how your drive is partitioned, and as
such, can be done without repartitioning. However, make a backup first, since
other problems may cause data corruption (i.e. too fast PIO-mode or a to high
blocking-factor not properly supported by the drive, cabling and BIOS).
- Ontrack Diskmanager (DDO, Dynamic Drive Overlay), Microhouse EZ-Drive:
Drivers that allow the use of harddrives larger than 504/528MB in older PC's.
BIOS routines need not reside in ROM or even in shadow-RAM. The addresses in
RAM where most BIOS routines are located, are stored in a "pointertable" (this
incomplete explanation is just for sake of simplicity, don't flame me please).
This means that DOS doesn't have to know where the routines are in memory.
Instead, it knows which entry in the pointertable stores the address of the
(for example) ReadSector routine, and if it wants to call that routine, it
reads it's address from the pointertable and then makes the CPU continue
execution of instructions at that address. This setup allows for easy
replacement of BIOS routines, and that is where drivers like Ontrack
Diskmanager and Microhouse EZ-Drive fit in.
These drivers simply replace BIOS routines by their own, translation-capable
equivalents. There are a number of problems involved however:
- One problem is that these drivers are stored on disk, and are read
from that disk before the translation is active, since they're not
running yet! This means that the drivercode must be stored in the first
cylinder of the disk, and therefore cannot be placed in a normal file
(except when you boot from another disk that does not need translation, like
a harddrive smaller than 504/528MB, or a floppy).
- Secondly, not really a problem but a must. If you boot from a floppy,
there should be NO way by which you can access the harddrive, since
translation is not active. Therefore, if you only have 1 harddisk and 1
floppy drive in your PC, and you do a full boot from floppy you will only
have drive letter A: (and no C:). However, this affects the following
- Once the driver is loaded, you should not be able to overwrite it's code
on the harddrive by programs like FDISK, which overwrites the first sector
of the drive! Therefore a "cloaking" mechanism is used by these drivers.
- Apart from the translation-factor, Ontrack Diskmanager also
introduce an offset or shift. This means that after it's
loaded, they will fake DOS in such a way that DOS thinks it is accessing
cylinder 0/side 0, while it actually is accessing cylinder 0/side 1
etcetera! This prevents programs like FDISK from overwriting the driver
code, provided that the driver is loaded! If you add an
Operating System to your drive, and boot from the OS-setup floppy (either
at the start of the installation or reboot halfway the process) then the
translationdriver will not be loaded, and the Operating System will
probably think you have a brandnew disk (because it is inaccessible) and
starts partitioning it. Of course, this causes all files on your drive to
- EzDrive uses a different approach. It only "cloaks" the real MBR when
it is loaded; the EzDrive code is in the first track (63 sectors) of the
drive. When you read or write the MBR (CHS 0,0,1), EzDrive will actually
pass you or let you write to the next sector (CHS 0,0,2) When you
read/write CHS 0,0,2, you'll end up there as well. This method has two
implications: the driver code can be overwritten more easily, but on the
other hand, an uninstall of EzDrive is much easier than Ontrack
Diskmanager, since all partitions point to the right locations (while
Ontrack partitions point to locations with a 63 sector offset).
- Another problem is where to put the replacing routines in RAM; you don't
want them to reduce your conventional DOS memory with a couple of KB's,
since then that superduper game might not run anymore...Therefore they use a
number of tricks to finally get loaded in UMB's (memory between 640K and
1MB). Ontrack Diskmanager needs only 64 bytes of conventional memory when
properly installed (I haven't examined how Microhouse EzDrive handles this).
If you're careful when installing new operating systems (first boot from
the harddisk to load the driver, and when it prompts you to press a key to
continue the boot process from floppy, do so) you shouldn't have any problems
with these drivers. In fact, where I work we have a number of 486 PC's with
Western Digital drives ranging from 540MB upto 1.6GB, all with Ontrack
Diskmanger V6.03 (licensed to Western Digital) installed, and never had a
single problem related to DiskManager. I have only experimented a bit with
Microhouse's Ez-Drive, but now of others who use it without problems.
Some people fear performance degradation because of drivers like these. I did
not test it but that seems very unlikely. The translation scheme used only
involves a small number of CPU instructions, while the competition, a
translating BIOS, would have to perform similar operations! What IS likely to
cause performance degradation is not software, but hardware. Typical PC's that
require these drivers have VLB or ISA only (no PCI) buses and slower CPU's.
Theoretically VLB-EIDE controllers are okay, but in practice they can hardly
be compared with a decent PCI-based EIDE interface. By the way, if you have an
ISA card with a translation-ROM, make sure it is "shadowed" to RAM (check your
BIOS setup). If not, HD performance will be ssslllooowww.
- Partition, primary partition, extended partition, logical partition or
logical drives: A partition is a subsection of the disk which starts right
after the preceding partition table sector, and ends at the end of the drive
or with the last sector preceding the next partition table sector. For DOS,
only a primary partition can be bootable, and always get "lower" drive letters
assigned than other partitions do. This explains why people have C: and E: on
their primary and D: and F: on their secondary drive. An Extended Partition is
used to store Logical Partitions or Logical Drives in. Generally
DOS/Windows-compatible partitions are referred to as FAT-partitions.
- Partitioning: this refers to the proces that writes only a few
sectors to the drive containing partition tables, and in case of the MBR, the
bootcode if the partition is "active" (bootable). It does NOT assign drive
letters or anything alike! However, drive letters assigned later by
DOS/Windows may be affected by the partition layout and types you choose. Make
sure that you have correctly setup your drive in the BIOS setup. You cannot
change modes from XCHS to LBA (or backwards) after partitioning without the
risk of trashing your drive (see also Translation).
The table below shows some maximum values for partitions with optimal
clustersize for FAT16 partitions. Note that FDISK uses 1024x1024 bytes for a
MegaByte, while some other programs including Ontrack Diskmanager (and
harddrive manufacturers in general) usually use 1,000,000 bytes for a MegaByte:
|Partition Size in MB
|Partition Size in MB
|Partition Size in Cylinders (at
16 heads and 63 sectors/track)
|Cluster Size in
|Cluster Size in
I have read that 4GB FAT16 partitions with 64KB clusters are possible as
well. However, FDISK cannot create them, and I wouldn't be surprised if
low-level programs like Norton Utilities would not know how to handle these.
Further, if you're a video freak, this won't help. The max. filesize in DOS,
Windows and Windows95 is 2GB, and in practice you won't be able to access
files much larger than 1GB. I suggest that you stick with max 2GB partitions,
or use NT with NTFS partition(s).
- Partition Efficiency: With a large cluster size, a lot of disk
may be wasted (see the table above). This is typically the case when you have
a large number of small files. For example, I have installed Borland C++ V5.0
Developer Suite on a single 256MB partition, and added some other small files.
When I run chkdsk on it, it reports "4,096 bytes in each allocation unit" and
"65,444 total allocation units on disk" which is an optimal situation for a
disk with "268,066,816 bytes total disk space". Chkdsk also reports that there
are "20,344,832 bytes available on disk". If I add up the total number of
bytes in files (4,595,712 bytes in 7 hidden files, 2,609,152 bytes in 629
directories and 240,517,120 bytes in 3,887 user files) then I end up with
247,721,984 in total. Somehow I have lost 20,344,832 bytes (20MB) of disk
You can imagine that I would have lost much more if I would have installed BC5
on a bigger partition... Anyway, since each file (and subdirectory) uses at
least one cluster, a rough estimation is that you will loose half a cluster of
diskspace per file and subdirectory. This means that if you have 1900 files
and 100 subdirectories, you'll typically loose at least 8MB on a 512MB
partition, 16MB on a 1GB partition and 32MB on a 2GB partition. However, the
numbers typically get even worse for larger partitions, since then more files
will even be smaller than half a cluster. For example, your AUTOEXEC.BAT may
fit in 512 bytes but will use 32KB on a 2GB partition!
NOTE: under some conditions FDISK may round up instead of down, i.e. sometimes
when you enter 512MB as a partitionsize it will end up being 513MB, which is
just a little too high! However, FDISK immediately shows what value is going
to use, so if you see the number 512 you typed being changed into 513, simply
re-enter it as 511.
- Suggested Partition layout: I am used to store the operating
system(s) and applications on the C: drive. If a harddisk is large enough, I
would create a 1GB C: partition (not bigger)! This may not be optimal, but
often 512MB is simply not enough. Then I'd create a smaller D: drive, either
256 or 512MB, depending on the total size of the harddisk(s). The D: drive is
usually used to store smaller files on, like letters etc. Typical 1.6GB
harddrives will have room for one 1GB and one 512MB partition. What remains is
typically less than 15MB which I'll keep unused (these are the inner and thus
slowest tracks of the drive anyway). On larger harddrives I'd add some
partitions, possibly a large one to store big files on (ZIP files, AVI etc.)
and, if required, another smaller partition to store additional small files on
(for example, letters from 1995 and before, in case I like to have them
- MBR, Master Boot Record: the first sector on a drive (i.e. cylinder
0, head 0 and sector 1). It contains BOTH the primary partition table AND code
that is loaded to a standardized address in RAM by the
ROM-BIOS of your PC (which starts the boot process from your harddrive).
Usually that code will read the bootsector from the
primary partition and pass control to the code in there. Nowadays the
partition table ONLY describes the size and layout of the primary partition,
and optionally has a pointer (i.e. CHS value) to a followup partition table
sector. Note that a drive may not have a primary partition. If mounted as a
slave drive, most partitioning programs will create a primary partition table
without a primary partition; however, the program will create an
extended partition (which is pointed to by an entry in the primary partition
table). The extended partition typically holds 1 or more "logical drives",
which are sub-partitions within the extended partition. This sounds
complicated, and it is. Most partioning programs try to hide this complexity
from the user but only get this job done partially in my opinion.
Also note that the MBR is not really stored in cylinder 0, head 0 and
sector 1 when a program like Ontrack Diskmanager is
- Formatting, Low-Level Formatting: this is very confusing to most
people. Formatting a floppy generally means that BOTH a low-level and a
high-level format take place. The low-level format overwrites full
tracks consisting of multiple sectors, headers and trailers. Each sector is
preceded by a header and gets a trailer written behind it. Only the sectors
and trailers are updated when you copy a file to the floppy (effectively
writing sectors), the headers are used for finding the start of each sector on
the track and are only read from (except during a format operation).
The low-level format calculates a CRC-checksum (CRC = Cyclic Redundancy Check,
a special algorithm that is very sensitive to even the slightest change in
data) from each sector it writes, and writes that calculated checksum to the
trailer. After low-level-formatting each track, the format program simply
reads all sectors and trailers in it, recalculates the checksum from each
sector and compares it to the checksum in the trailer. If they don't match,
the sector is considered "bad". It stores all bad sector locations in RAM for
later use. After finishing ALL tracks on both sides, the format program will
do a high-level format of the floppy. That means that it will write a proper
bootsector, clear both FAT's and the rootdirectory of the drive. Then it will
recall the bad sectors found and adjust the FAT's accordingly. If you run
FORMAT with the /S option, it will also copy IO.SYS, MSDOS.SYS, COMMAND.COM
(and if it can find one of them, DBLSPACE.SYS or DRVSPACE.SYS) to the floppy.
Finally format it will prompt you for a volume label.
However, the DOS FORMAT program only knows how to low-level format
floppies, not harddrives, due to the fact that sector
header/trailer information varies widely between harddrive manufacturers and
models. Further, the number of sectors on a track is fixed for floppies (DOS,
not for some Mac floppy formats) but varies on most harddrives. And finally,
EIDE harddrives are preformatted by the manufacturer typically with dedicated
programs that leave some space on the drive to "remap" bad sectors to, should
they show up over time. This means that if the microcontroller in the drive
detects a bad sector, it will try to reread a number of times until the
checksum matches. Then it will mark that sector as bad, and store the
information in another sector. All this is invisible from DOS. However, for
fast AV (Audio Video) or multi-speed CDROM writers this may mean a hickup in
the datastream coming from the drive, not only when the bad sector is
detected, but also afterwards because the drive will have to fetch sector data
from another physical location on the drive (possibly involving extra
head-seeks). Therefore, instead of low-level formatting your EIDE drive when
it was trashed somehow, first make sure that there are no other problems
involved (i.e. too fast PIO mode, *wdctrl in use for a large incompatible
drives, buggy CDROM drivers, too long datacables (ribbons) between your
controller and drives, bad RAM or bad cache RAM etc).
I strongly advise you NOT to use the "format" option in most BIOS'es
(reachable from the BIOS setup screen). This FORMAT option was useful for old
MFM and RLL drives, and usually DESTROYS EIDE drives! If you need to "repair"
an EIDE drive (bad sectors, or "undestructible" viruses etc.) it is best to
use a tool that simply overwrites all sectors. This will force the drive to
"remap" bad sectors itself. Nearly all bad sectors that are not remapped can
be detected by either FORMAT or SCANDISK (surface scan option) and they will
mark the clusters containing bad sectors as bad in the FAT. See my
tools page for
programs that can "clear" an EIDE drive. However, if your drive is still under
warranty I suggest you try to have it replaced by your supplier or the
manufacturer if you keep getting more bad sectors. If these are really due to
the drive itself then often the number of bad sectors will keep growing each
time you use the drive. And modern operating systems using
write-caching are extremely intolerant for bad
- BootSector: the first sector in each partition. It stores
information like the number of sectors/cluster, the partitionsize, the number
of sectors/FAT and the number of sectors in the partition. Also it has code to
load IO.SYS and MSDOS.SYS which are used by the boot process which is of
course only used in the active, primary partition that is used to boot.
- FAT, File Allocation Table: a number of consecutive sectors in
between the partition table and the rootdirectory on each partition, used to
determine which clusters are used to store file-contents in, which clusters
are free, and which clusters are invalid due to one or more bad sectors. For
historical reasons the FAT table has a duplicate FAT table stored right after
it. NOTE: The following section applies to FAT16 only! The bootsector,
FAT's and rootdirectory are not stored using clusters, and are fixed in size
(i.e. number of sectors). That is why you can have a full rootdirectory, while
subdirectories can grow unlimited (until you have no more free clusters). Each
cluster in a partition is assigned a 2-byte entry in the FAT (i.e. 16 bits, a
typical value for large harddrive partitions; floppies and small partitions
may use 12 bit FAT entries). This limits a partition to a little less than
65536 clusters. That is, BTW, the reason for the huge clusters found on large
partitions. A better name for FAT would, in my opinion, have been CAT for
Cluster Allocation Table. Since each cluster has a FAT entry, the opposite is
true as well: each FAT entry is related to a cluster. That means that for
example FAT entry number 1234 is related to cluster number 1234! Now here is
how DOS exploits this: if the FAT entry contains a 0 (i.e. the two bytes are
both zero) then the cluster is unused (there is no cluster 0, in fact, both
cluster numbers 0 and 1 are reserved, and so is a short range just below
65535; the first real cluster on a partition is cluster number 2). Any nonzero
FAT entry value means that the cluster is NOT free. If the cluster involved
contains part of a file, then the corresponding FAT entry will contain the
number of the next cluster (and FAT-entry) of that file! If it has the
value 65535 (the largest number you can store in 2 bytes) then that indicates
that the corresponding cluster is the last cluster of the file. Another
FAT-value is reserved for indicating that a cluster is bad. Those are the
reasons for having somewhat less than 65536 possible clusters.
- FAT32: Windows95 OSR2 has the possibillity to
create so-called FAT32 partitions. Windows95 OSR2 is NOT available in the
shops, it can only be legally obtained by buying a new PC (OEM
PC-manufacturers can sell you a PC with this Win95 release), or you will
receive it when you are a MSDN level 2 (or higher) member. The "FAT" part of
FAT32 works the same as previous FAT implementations (i.e. FAT16 and FAT12).
However, since each FAT entry now consists of 4 bytes, upto 4,294,967,296
clusters (minus a few reserved values) can be addressed. At first, that seems
to solve the partition efficiency problems. But in fact it introduces another
problem, especially when using large partitions. For example, consider a 2GB
drive with 1 partition; when formatted using FAT32 it will have 4KB clusters
(8 sectors/cluster). Because of that, it will have approx. 500,000 clusters.
Since each FAT32 entry uses 4 bytes, each FAT will use 2MB of diskspace!
As with FAT12 and FAT16, each FAT is stored twice (note that the max. size of
one FAT16 table is 128KB). This means that the first 4MB of your 2GB disk will
be used for administrative purposes. That is not so bad for a 2GB drive. What
is a problem however, is that this may slow down your PC considerably if you
do not have much free RAM and your applications do a lot of diskaccesses.
Things get a lot worse when the disk becomes fragmented. The reason for this
is, that it is not likely that the full 2MB FAT will be cached in RAM (unless
you have for example 64MB of RAM installed). If your application accesses
files (or file contents) randomly on the disk, the chance will be small that
the required FAT entry is in the cache. Therefore it must be read from disk,
which requires a time-consuming head-seek to the outer tracks of the disk
(where the FAT is located) and back to the area where the file is located.
Therefore I would not advise people who are developing large, multi-source
file, C++ programs or randomly accessing a large database, to use FAT32. A
small FAT16 partition (i.e. 256MB, 512MB) will do fine for the case where you
have a large number of small files, and you won't be wasting much space on a
2GB FAT16 partition if you only have large files on it.
Apart from the fact that a FAT32 partition uses 4 bytes/FAT entry, there are
some more differences. I had a look with a diskeditor, and I'll describe what
I found for the 2GB FAT32 partition. Note that all this is just experimental,
and may be plain wrong:
- The partition "type" field of a FAT32 partition has value 0Bhex (11
decimal), and is stored in the MBR as expected. The MBR layout has not
changed as far as I could see. This means that OSR2 should be able to
coexist with other partition types (for example NTFS and Linux). Florian
Painke reported (thank you, Floh!) that OSR2 can use the following partition
types (all values in hexadecimal):
- 0x05 Extended partition using standard INT13 (limits drive to 7.8GB)
- 0x06 Normal FAT16 partition using standard INT13 (7.8GB max)
- 0x0B FAT32 partition
- 0x0C FAT32 partition using INT13 Extensions
- 0x0E FAT16 partition using INT13 Extensions (otherwise the same as
- 0x0F Extended Partition using INT13 Extensions (otherwise the same as
NOTE: to prevent OSR2 from using any of the new partition formats
0x0B..0x0F use FDISK /X to partition the drive. This is a necessity if you
need to access the partitions from DOS.
The INT13 Extensions handle LBA addresses using 64 bits (note that an LBA
address points to a sector of 512 byes). We won't be running into this
limit for some time I guess.
- The "bootsector" now consists of multiple sectors, 6 in my case, of
which the first 3 contain non-zero data and are terminated with 55AA (hex).
I'll refer to this set of 6 sectors as the boot-block. It contains a
"dirty-flag" which is cleared when the PC is properly shut-down; if the PC
crashes this flag will not be cleared. When Win95 boots and finds that this
flag is not cleared, it will run SCANDISK first.
- A copy of this bootblock is stored right after the original (i.e.
another 6 sectors).
- Next you'll find the original and the copy of the FAT (2MB each!)
- After the second FAT, the first cluster starts. In contrary to FAT12 and
FAT16, an OSR2/FAT32 rootdirectory does not have a fixed size, but uses
clusters like subdirectories already did. This is a good thing, because you
may run out of rootdir entries sooner then expected. The "old" Win95 uses
DOS format, which be default creates 512-entries rootdirectories. 512 sounds
a lot, but a long filename is stored in multiple entries. Each entry is 32
bytes long, the long filename is stored in UniCode (2 bytes per character)
and some of the 32 bytes cannot be used in order for DOS not to treat long
filename entry as a 8.3 entry. The result is that you'll rapidly run out of
rootdirectory space when you use a lot of long, long filenames in FAT16, but
not in FAT32.
- The function "ReadSector" (C function absread() or INT 26) will return
an error 511. This function is used by many diskutilities in "normal mode".
Probably Microsoft has disabled the use of the function to prevent people
from completely messing up their disk when running them. However, for
example Norton Utilities will run in "physical mode". It then uses INT13
diskaccess, and has no "understanding" of partition structures etc. and will
only read and display "raw" sectors.
- Long Filenames are still stored in the "clumsy" manner, a 8.3 equivalent
and multiple (32-bytes) directory entries to store the long filename.
- Windows95 OSR2 will not install if it can find any WIN.COM on your
harddrive(s), because it is not intended as an update.
Operating System Software
- BIOS: Basic Input Output System. The BIOS is a set of software
routines which are mostly called via an operating system layer, but sometimes
directly from applications. Hardware components are hardly standardized. The
job of the BIOS is to form a standardized, relatively device independant
interface to the rest of the Operating System. For example, you can call a
BIOS routine to put a character on the screen, without knowing what graphics
card is installed. Much the same, you can tell it to read a sector from disk
by specifying the drive, cylinder, head and sector-on-a-track value while also
supplying a memory address where you want the sector contents to end up at.
You won't have to worry about DMA channels, PIO modes and whatever, the BIOS
takes care of this. A standard part of the BIOS is in the ROM-BIOS of your PC,
other parts are in stored in ROM on your graphics or VGA controller, some
parts are loaded from disk during boot (IO.SYS) and other parts can be found
on optional controllers like SCSI adapters etc. Also, most operating systems
will replace some or all of the BIOS functionality stored in the BIOS ROM. For
example, Windows NT only requires the ROM-BIOS to be able to boot. As soon as
replacement BIOS routines have been loaded from disk, the ROM-BIOS will no
longer be used (since it consists of 16-bits code).
- DOS, DOS622: Microsoft's MS-DOS V6.22
- WfW, WfW311, WfWG311: Microsoft's MS Windows for Workgroups V3.11.
WfW is a major improvement over all other 16-bit windows versions, since it
offers 32BFA. Especially when combined with
32BDA, all file and drive accesses (to drives that
support 32BFA) will be done by 32-bit, protected-mode code, which improves
reliability and performance a lot.
- W310, W31, Windows 3.1: Microsoft's MS-Windows V3.10
- W311: Microsoft's Windows V3.11. This basically is an updated W31.
It cannot be compared to WfW311 since it lacks peer-to-peer network
connectivity and 32BFA.
- Windows: either W31, W311 or WfW311, depending on context (but
not X-Windows, Windows 95 or Windows NT etc.)
- Windows95: the version released in August 1995. It uses DOS to
store files but uses multiple directory entries in order to store long
- Windows95 OSR2: see FAT32 for some
information. Here is a site that has more info on Windows95 OSR2:
- Cluster: DOS/Windows have all file contents stored
in clusters. Each cluster consists of at least one sector, but typically
clusters on a harddrive consist of 16, 32 or even 64 sectors (see
Partioning). Each file, no matter how small, uses
at least 1 cluster of diskspace (see Partition
Efficiency). Both DOS and Windows will read and write entire clusters when
accessing files, not individual sectors.
- DiskCache: A cache either implemented in
software (like smartdrv.exe) or in hardware (a caching
- SMARTDRV.EXE, SmartDrive: a DOS program (16-bits) that
caches disk information. The program uses extended memory
to store information read from disks, not only harddrives but also removable
media like floppy- and CDROM drives. Often requested information, like the
rootfirectories and FAT tables will be accessible much faster after smartdrv
has loaded them into memory. If WfW311 is properly
installed and optimized, it will not use smartdrv for caching the harddrives
on the primary IDE controller, because it uses 32BFA for
that. However, performance of harddrives connected to the secondary IDE
contolller and of removable media may improve a lot if smartdrv is used as
well. However, while both 32BFA and smartdrv serve a similar purposes, 32BFA
allocates it's memory dynamically, while smartdrv does not. Therefore smartdrv
has options to determine how much memory it should allocate in a plain DOS
session, and how much it should during a Windows session, which is important
if you do not have much RAM in your PC.. Therefore most people will have
smartdrv loaded from their autoexec.bat as follows:
LH C:\DOS\SMARTDRV.EXE /X 2048 128
The "LH" command tries to load the program "high" (in Upper Memory Blocks
or UMB's, between 640K and 1MB RAM) if possible. The /X parameter disables
write-caching, the 2048 value specifies that
smartdrv should allocate 2048KB in a plain DOS session, while the 128
specifies that the memory allocated by smartdrv for the cache should be
reduced to 128KB when Windows is started. Note that Windows
32BFA/VFAT uses write-caching by default. Note: in this documents I will
refer to smartdrv as V4.0, which comes with DOS6 and up. The version of
smartdrv V3.x that comes with Windows 3.0 (you shouldn't be using that
anymore!) is actually very different from V4.0, because it operates at the
INT13 level (making it suitable for IDE drives only, not
for floppy drives and CDROM players etc.) while smartdrv V4.0 operates at the
"cluster" (i.e. DOS) level.
- 32BFA, 32-Bit File Access, VFAT: a means for WfW311
to bypass DOS 16-bits code to manage file I/O at the
partition-level. This is a relatively high-level Operating System
layer that does NOT access the disk directly, but rather leaves that to
BIOS-level routines, either implemented by the ROM-BIOS or
dedicated drivers, including 32BDA drivers. It is used to
access (sub-) directories, FAT's and files and does this by specifying logical
sector numbers. It simply treats all sectors in a partition (i.e.
drive-letter) as an array of sectors, and doesn't know about the actual
disk-geometry. This is comparable to LBA (which treats the full drive as an
array of sectors) while here the partition is treated as an array of sectors.
As with LBA, logical sector numbering starts with 0 (note that sectors on a
track start with 1). By default, 32BFA also caches disk
information, and uses write-caching by default.
32BFA will not function if the program IFSHELP.SYS is not loaded from
CONFIG.SYS, and if there are any open files when Windows is started. As far as
I know, 32BFA does not support (E)IDE harddrives connected to
the secondary IDE controller! Further, it does not support floppy-drives and
CDROM players. Also, some network drivers are known to cause 32BFA not to
function properly. To check if 32BFA is in use for your drives, execute the
"386 Enhanced" program in Control panel, and then click on the "Virtual
Memory" button. "File Access: 16-Bits" for a drive means that for that drive,
32BFA is NOT in use. If 32BFA does not support a drive,
smartdrv may take over (unless you have instructed smartdrv not to do so
with "smartdrv x-" where x is your drive). There is a special FAQ
dedicated to 32BFA problems, see my
32-Bit Disk Access Warning
WARNING: Do NOT enable 32BDA if you are
not absolutely sure that you have installed the proper driver. In contrary to
what most people think, NOT having the entry "Use 32-Bits Disk Access" grayed is
NOT a guarantee that you are allowed to enable it! This "gray level" depends on
a line in SYSTEM.INI in section [386Enh] being there or not:
||it's Off, but NOT grayed, thus can be enabled
||it's already On
|-no such line-
||the entry in the Virtual Memory Settings will be grayed and thus
cannot be enabled.
Only Windows SETUP determines whether your drive(s) conform to the
WD1003 specification, the only spec. supported by the windows built-in driver
WDCTRL. If any of them (including ATAPI CDROM drives and SCSI drives) does not,
it will not add the line with the "32BitDiskAccess" parameter. Otherwise it will
add the parameter, but set it's value to "Off". You'll have to switch it on
manually through the Virtual Memory Settings dialogbox.
Therefore, if you copy your Windows setup from an old drive to a new and
bigger drive (or just ADD an ATAPI CDROM or bigger harddrive) without
adding an appropriate driver, then you WILL be able to check the entry "Use
32-Bit Disk Access" in the Virtual Memory Settings dialogbox, if you did not
already. Windows will not automatically uncheck this for you if you
change your hardware configuration, but usually it will detect the change, and
refuse to load 32BDA while issuing an error message. But under some
circumstances it will not detect the change, which typically causes you
to corrupt data on your drive(s), including trashing the partition table, FAT's
and rootdirectory sectors, rendering the entire drive inaccessible!
This page is NOT intended to be a replacement for the excellent information in
the various FAQ (Frequently Asked Questions) files and web pages around the world
(see my tools page
for some pointers). I only wanted to explain a number of terms related to the
document that describes the
problems with Quantum
Fireball TM drives I experienced (although I admit it got longer than
planned). I did my best to supply reliable and correct information here, but,
since I'm only human, I may be wrong. Please let
me know if you disagree or have any
other remarks about this page. If I consider them relevant I may update this
If you have general questions about hard drives, disk managers, formatting,
possible bugs and fixes etc., please ask those questions in one of the Usenet
Newsgroups; for PC related storage devices this would be
comp.sys.ibm.pc.hardware.storage. If you don't have a newsreader, most
wwwbrowsers will accept the following URL: news://your.news.server/comp.sys.ibm.pc.hardware.storage
where you must of course replace your.news.server by your favorite host.
Before posting messages (asking questions) in any newsgroup, please read the
newsgroup's FAQ to make sure that you are not asking a Frequently Asked
Question; see my tools
page for some pointers to FAQ's. When I have time, I will be reading some of the
postings in the PC storage group, but lots of other, often much more experienced
people do as well, and they often come up with answers I am not aware of. So
check it out!
I cannot and will not take any responsibility if you experience damage or loss
of data or any other inconvenience caused by anything written here by me. In
other words, anything you do is your own responsibility, don't blame me!