From: EHudak@ix.netcom.com (Edward Hudak)
Newsgroups: comp.sys.ibm.pc.misc,comp.sys.ibm.pc.hardware.systems,comp.sys.ibm.pc.hardware.storage
Date: 8 Mar 1995 21:11:15 GMT

========================================================================
====
     Chapter 1 - TECHNICIANS' GUIDE TO PC HARD DISK SUBSYSTEMS

   (This article is being posted directly to various newsgroups in hope 
of)
   (stopping the clutter of "me-too" requests.   E-Mail copies will 
follow.)
   (PLEASE READ my Notices and Personal Rants at the end of this 
chapter.)

(c) 1992,1995
========================================================================
====
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 64 watts was 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.  

========================================================================
====

COMING SOON - CHAPTER 2 - Inside Hard Drives and Controllers :
                          -Parts and Components
		          -also suggestions for must reading material

========================================================================
====
NOTICES & PERSONAL RANTS :
========================================================================
====

INTERNET APOLOGIES : My original article, offering this booklet was 
posted 
Jan. 29, 1995.  I have had lots of replies, BUT - all kinds of people 
insisted on replying by follow-up articles instead of private Mail.  
This 
proved downright embarrassing! I only wanted E-MAIL responses.

Since that time I have learned about using "FollowUp-To:", thanks to 
Ralph 
Valentino (also Bruce Burrell has been great in forwarding stray replies 
to 
me, and Craig Champlin has directed traffic).  I now know the sin of 
cross 
posting to several newsgroups.  Each Reply-Posting is mirrored all over 
the 
place.  Sorry for the clutter!

DISTRIBUTION : This chapter will be sent by E-Mail to some 2,300 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 
- 
all future chapters will be posted to a select number of New Groups and 
I am 
currently trying to make arrangements for an ftp site.

If anyone specifically requires E-mail, please 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
or electronically, 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.  

Till Next Time ...

N.

========================================================================
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








