299 lines
14 KiB
Plaintext
299 lines
14 KiB
Plaintext
From: datarec@inforamp.net (Nicholas Majors)
|
|
Subject: Chapter 1 - Technicians' Guide to Hard Disks (REPOST)
|
|
Date: 25 Mar 1995 18:45:09 GMT
|
|
|
|
|
|
========================================================================
|
|
Chapter 1 - TECHNICIANS' GUIDE TO PC HARD DISK SUBSYSTEMS
|
|
========================================================================
|
|
copyright (c) 1992, 1995
|
|
|
|
Nicholas Majors,
|
|
|
|
DATA RECOVERY LABS
|
|
(division of Data Recovery Services Inc) Voice : 1-416-510-6990
|
|
1315 Lawrence Avenue East - Unit 502 FAX : 1-416-510-6992
|
|
Don Mills, Ontario, Canada M3A 3R3 Email : datarec@the-wire.com
|
|
========================================================================
|
|
|
|
INTRODUCTION :
|
|
|
|
This booklet (now electronic) is published as a service of Data
|
|
Recovery Labs. Its purpose is to provide the fundamental knowledge of
|
|
concepts and terminology that is necessary to deal with the
|
|
complexities of hard disk subsystems. It is not a technical reference
|
|
guide and should not replace original documentation made available by
|
|
manufacturers.
|
|
|
|
Every day we meet and deal with technicians and support personnel who
|
|
install, upgrade and maintain hard drives, without knowing exactly
|
|
what they are and how they work. Gaining a working knowledge of disk
|
|
subsystems is not a simple task and requires much study - and -
|
|
experience. Don't expect any book, training course, or manual to make
|
|
you into an expert. However, if you read and understand most of this
|
|
material, you will be off to a fine start.
|
|
|
|
The principal author is Nick Majors. He has been in the industry
|
|
since 1979, designing and developing hardware and operating system
|
|
enhancements and performance tools. He is an experienced machine
|
|
language programmer and has provided technical training to support
|
|
personnel for some of Canada's leading banks, corporations, government
|
|
departments and PC service organizations. He is Manager of Technical
|
|
Services for Data Recovery Labs which he founded in 1989.
|
|
|
|
While this booklet deals primarily with PC and PC compatible
|
|
platforms, there is much information to benefit support personnel with
|
|
other hardware platforms.
|
|
|
|
Every effort has been made to ensure accuracy, but misprints and
|
|
ambiguities may still remain, so please use caution.
|
|
|
|
========================================================================
|
|
HISTORY AND OVERVIEW :
|
|
|
|
The original IBM PC, introduced in 1981, did not support any type of
|
|
hard drive. Program code in the BIOS did not recognize any such
|
|
device and early versions of DOS precluded mass storage by limiting
|
|
the maximum number of directory entries. This is not surprising when
|
|
you consider that the original 4.77 MHz PC came with 16 K of RAM,
|
|
expandable to 64 K on the motherboard. Even floppy drives and a disk
|
|
operating system were options to upgrade the built in cassette
|
|
recorder port and ROM basic.
|
|
|
|
To utilize a hard drive in a PC requires:
|
|
|
|
- a Hardware IRQ (interrupt request)
|
|
- I/O port addresses for the controller
|
|
- a DMA channel (now optional)
|
|
- low level program code
|
|
- a physical interface to the bus (expansion slot or built-in)
|
|
- operating system support
|
|
- sufficient power and cooling
|
|
|
|
After DOS 2 introduced the sub-directory system and support for mass
|
|
storage devices, companies started selling hard drives for the PC.
|
|
These were external cabinets that contained the disk itself, a
|
|
controller card, and a dedicated power supply (since the PC's 63.5 watts
|
|
were insufficient). Migrating from other architectures, these units
|
|
connected to the PC through cabling to an 8 bit adapter card that
|
|
plugged into an available expansion slot. These subsystems were
|
|
configured to use one of the available IRQ's, DMA channels, a range of
|
|
I/O ports, and program code that was made available through a device
|
|
driver loaded into memory after startup (booting from a floppy).
|
|
|
|
In 1983, the IBM XT (eXTended) was unveiled with its built-in 10 MB
|
|
fixed disk. IBM worked with a company (Xebec, I think) to take the
|
|
controller components normally located in the external cabinet and
|
|
build them right onto a bus interface card, creating what we commonly
|
|
call the "hard disk controller".
|
|
|
|
Program code was provided by a ROM chip on the controller card which
|
|
supplemented subroutines in the BIOS, and the internal power supply
|
|
was upgraded to 135 watts to provide power for the internally mounted
|
|
drive.
|
|
|
|
The XT design utilized :
|
|
|
|
- IRQ 5
|
|
- I/O port addresses 320-32f
|
|
- DMA channel 3
|
|
- Program Code from adapter ROM at c8000
|
|
- DOS 2.0 or higher
|
|
|
|
Several companies started manufacturing and selling similar
|
|
drive/controller packages with various improvements including higher
|
|
capacities, superior performance and built-in floppy controller
|
|
components on the same card (to save an expansion slot). These third
|
|
party subsystems could even be added to an original PC, so long as the
|
|
internal power supply was also upgraded.
|
|
|
|
In 1984, the IBM AT (Advanced Technology) brought a complete overhaul
|
|
to hard disk systems. Program code was included in the motherboard ROM
|
|
BIOS, eliminating the need for a ROM chip on the new 16 bit controller
|
|
card, and a higher quality drive improved access times. The system
|
|
included use of newly added higher IRQ's, eliminated the use of DMA
|
|
for hard drives, and changed the range of I/O addresses.
|
|
|
|
The AT design utilized :
|
|
|
|
- IRQ 14
|
|
- I/O port addresses 1f0-1f8
|
|
- DMA channel - none
|
|
- Program Code from motherboard ROM BIOS
|
|
- DOS 2.0 or higher
|
|
|
|
Hardware configuration details for the AT, including hard disk
|
|
parameters, were stored in a low power CMOS chip connected to a small
|
|
battery, eliminating many of the motherboard configuration dip
|
|
switches and jumpers. The battery allowed information to be
|
|
maintained while the computer was turned off and information could be
|
|
changed by running a setup program from disk.
|
|
|
|
The original AT supported 14 different drive types, recognizing
|
|
specific hard disks ranging from 10 to 112 MB. Any drive with
|
|
physical parameters that did not match one of these types needed a ROM
|
|
extension on the controller card or a device driver loaded during
|
|
boot-up.
|
|
|
|
DOS versions prior to 4.0 (or 3.31) did not support partitions larger
|
|
than 32 MB no matter how big a drive was. This was because of sector
|
|
numbering that could not exceed 16 bit values (up to 65,536 sectors).
|
|
To make a larger partition required the use of special software like
|
|
Ontrack's Disk Manager. This software was so popular that many drive
|
|
manufacturers shipped it with their product. Unfortunately, while
|
|
this offered one of the better solutions, it did pose compatibility
|
|
problems for many disk utilities because, in effect, you had a non-DOS
|
|
partition.
|
|
|
|
Many people opted instead to divide their drives into 32 MB partitions
|
|
creating a C: D: E: etc. up to the physical capacity. Prior to DOS
|
|
3.3, even this was not possible, because DOS did not recognize
|
|
extended partitions!
|
|
|
|
The number of drive types supported by CMOS has expanded to over 40
|
|
and most current BIOS's provide a user definable type to allow
|
|
parameters to match any drive. Most PC's today still rely on this
|
|
original CMOS drive type scheme to configure and control hard disks,
|
|
though many architectures and BIOS's have changed how the information
|
|
is stored and updated.
|
|
|
|
This inherently creates certain limiting factors, including a problem
|
|
with more than two hard drives and BIOS/OS limits to recognizing more
|
|
than 1024 cylinders, 16 heads and 63 sectors per track. Various
|
|
technologies must be used to translate non-compliant physical
|
|
geometries into logical parameters recognized by the system to
|
|
maintain compatibility with operating system and utility programs that
|
|
are tied to these limits.
|
|
|
|
With each sector holding 512 bytes of data this allows for drives no
|
|
larger than 504 MB.
|
|
(1024 X 16 X 63 = 1,032,192 sectors X 512 = 528,482,304 bytes)
|
|
|
|
To understand this limit, we have to examine how hard drives are
|
|
accessed by a PC.
|
|
|
|
Primarily, I/O commands are sent to the controller via a range of
|
|
reserved port addresses. This is a very complicated and tedious
|
|
process and the ROM BIOS includes a subroutine (INT 13) to perform
|
|
these tasks for you. The DOS operating system then has certain
|
|
functions that further simplify the process. They include INT 25/26
|
|
functions to read and write absolute sectors to the drive as well as
|
|
higher level functions (INT 21) to Open files, Close files, Write data
|
|
to files, etc. Most programs rely on these DOS functions to control
|
|
access to hard drives and DOS in turn calls the INT 13 BIOS
|
|
subroutines which do the actual I/O commands.
|
|
|
|
All of these subroutines are assembly language code that are loaded
|
|
into memory from either your BIOS chip(s) or Operating System files at
|
|
startup.
|
|
|
|
Assembly language routines store and manipulate values in registers
|
|
within the CPU. The lowest common denominator for INTEL based PC's is
|
|
16 bit registers. Any program or routine that wants to be backward
|
|
compatible, must use these base registers whether run on an 8088 or a
|
|
Pentium. This basic INT 13 is the backbone of PC compatibility and
|
|
uses 16 bit registers in the following way:
|
|
|
|
DX - 8 bits for head number - 8 bits for drive number
|
|
CX - 10 bits for cylinder number and 6 bits for sector number
|
|
|
|
The largest 10 bit number possible is 1023 hence the limit on cylinder
|
|
numbers (from 0-1023) and the largest 6 bit number is 63 (from 1-63)
|
|
allowing 63 sectors per track.
|
|
|
|
But note - the DX register allows a maximum of 255 heads, not the 16
|
|
that original specifications called for. This is what allows various
|
|
translation schemes to deal with drives up to 8 GB while remaining INT
|
|
13 compatible.
|
|
|
|
If the DX register allows 8 bits for drive number, shouldn't it be
|
|
able to control 255 drives instead of only two?
|
|
|
|
When the INT 13 sends commands to your controller, it must know the
|
|
physical geometry of the drive in question. During initialization of
|
|
the PC, values for disk types are read from CMOS and stored into an
|
|
area of RAM called the BIOS DATA AREA. Pointers to those entries are
|
|
stored in the Interrupt Vector Table (at addresses 0:104h and 0:118h).
|
|
The table only reserved pointers for two drives, so even if your CMOS
|
|
held more values, the standard routines wouldn't know how to deal with
|
|
them.
|
|
|
|
Why were the INT 13 routines so limited? They were written at a time
|
|
when 10 and 20 MB drives were the norm, and 120 MB was unbelievable.
|
|
They were designed to communicate with a specific controller
|
|
interface, the ST412/506 standard (WD1003 controller), and the specs
|
|
for passing parameters included only 10 bits for cylinders number, 4
|
|
bits for head number and a single bit for drive number.
|
|
|
|
Some of these limitations have been overcome in the past by replacing
|
|
the PC's INT 13 sub- routines with code that could recognize and deal
|
|
with different devices. That's why virtually all SCSI adapter cards
|
|
include a ROM chip and you must set the drive type to ZERO. In
|
|
effect, no standard drives installed for the motherboard BIOS to
|
|
control.
|
|
|
|
NetWare and other advanced Operating Systems use the drive type only
|
|
long enough to boot- up and then replace the INT 13 code with their
|
|
own device drivers. You then need to load a different .DSK file
|
|
written specifically for each type of controller.
|
|
|
|
In the past couple of years, many motherboard and controller BIOS's
|
|
have been enhanced to deal with ever increasing demands, but the
|
|
process of establishing new standards has led to continuing confusion
|
|
and compatibility problems.
|
|
|
|
========================================================================
|
|
END OF CHAPTER 1
|
|
========================================================================
|
|
|
|
COMING SOON - CHAPTER 2 - Inside Hard Drives and Controllers :
|
|
- Parts and Components
|
|
- also suggestions for must reading material
|
|
|
|
========================================================================
|
|
NOTICES & PERSONAL RANTS :
|
|
========================================================================
|
|
|
|
INTERNET APOLOGIES : The original artiticle, offering this booklet, was
|
|
posted Jan. 29, 1995. I have had lots of replies, BUT - all kinds of
|
|
people insist on replying by follow-up articles instead of private
|
|
Mail. This proved downright embarrassing! I only wanted E-MAIL
|
|
responses. Sorry for the clutter!
|
|
|
|
DISTRIBUTION : Chapters 1-2 will be sent by E-Mail to some 2,700
|
|
people who requested it and is being posted to various News groups.
|
|
The work to maintain a mailing list is much more trouble than it's
|
|
worth, therefore - future chapters will be posted to a select number of
|
|
New Groups and Bulletin Boards.
|
|
|
|
Files can be obtained by ftp. Look for "hdtech??.txt"
|
|
|
|
ftp site: archive.umich.edu in /msdos/info/disk
|
|
|
|
mirror : wuarchive.wustl.edu in /systems/ibmpc/umich.edu/info/disk
|
|
(Note - This mirror is not always up to date)
|
|
|
|
ftp site: ftp.wi.leidenuniv.nl in /pub/faqs
|
|
|
|
Also Daniel Tauritz has a home page with links to this document plus a
|
|
number of hard drive FAQs:
|
|
|
|
http://www.wi.leidenuniv.nl/~dtauritz/ata.html
|
|
|
|
If anyone specifically requires E-mail, send me a note with "e-mail
|
|
please" as the subject. I will be glad to accommodate them, assuming
|
|
it's a manageable number. I cannot provide hard copy or S-Mail.
|
|
|
|
RIGHTS : This material is copyright (C) 1992,1995 by Nicholas Majors
|
|
and Data Recovery Labs. Feel free to distribute it as either hard
|
|
copy, electronically, or by BBS - with full copyright credit to both.
|
|
|
|
COMMENTS & CRITICISM : I look forward to receiving suggestions,
|
|
improvements, additions, (and yes even compliments) to this material.
|
|
Please bear in mind who this has been written for - tech support
|
|
personnel, not end-users and not engineers or hardware designers.
|
|
|
|
========================================================================
|
|
|
|
|