Data Storage - Question about ATA-2 and the Fixed Disk Parameter Table

Author

Question about ATA-2 and the Fixed Disk Parameter Table

Emerald Saint

2007-11-01, 7:12 pm

Do you remember back when we had to specify the Cylinders, Heads and Sectors
(CHS) in the BIOS Setup when installing a new hard drive? There was a
'drive type' table that had ready-made sets drive parameters to pick from.
You picked one that was the best for the drive and your choice of parameters
was recorded in CMOS memory. Also, as technology evolved there was an
option to enter all the numbers by hand as a 'drive-type' called USER, and
then you weren't limited to using a ready-made set of numbers from the table
After you partitioned and formatted the drive you wouldn't change the
numbers you saved in CMOS otherwise you would corrupt the data on the drive.
I'm talking about the days before the the BIOS Setup could interrogate the
drive (auto detect) and it would give you a set of numbers obtained from the
drive.

I don't understand just exactly how the system decided what drive parameters
to write in the Fixed Disk Parameter Table (FDPT).
Also I don't understand how these two ATA-2 commands were used in the
process.
Initialize Drive Parameters Command
Identify Drive Command

I would like to get people to comment on the narration below and if possible
help me understand how they decided the numbers to write in the FDPT.

NARRATION: Every time you start the PC the drive has to 'learn' what CHS
numbers to use - it doesn't 'remember' them from before. When the PC is
starting up the mainboard start up routine reads the CMOS to find the CHS
numbers and then writes them to a temporary table in the PC's memory. Next,
the mainboard start up routine searches the system for attached drive(s) and
when it finds a drive it passes control to another routine within the ROM on
the drive. The program in the drive's ROM reads the CHS numbers from the
table in the PC's memory and sends the numbers to the drive using ATA
command called:
Initialize Drive Parameters
Actually, the command sends only the numbers for (H)eads and for (S)ectors
per track. The command doesn't contain the number for (C)ylinders - there's
no field for that number in the command.
END OF NARRATION

Presumably, if the drive knows the numbers for H and S it can figure what
the cylinder number should be.

If the drive is interrogated with the ATA command:
Identify Drive Command
The drive will tell you the CHS numbers for
The DEFAULT Translation mode, and for
The CURRENT Translation mode.

At some point the system has to decide what to write in a table in system
memory called the Fixed Drive Parameter Table (FDPT) which is pointed to by
the interrupt vectors INT 41h and INT 46h (for drives 0 and 1, if two drives
are present). The information in the FDPT is used by DOS and other programs
when the computer is up and running.

I believe the FDPT should contain numbers the system gets from the drive via
the Identify Drive Command, and not the numbers from CMOS.

I'm trying to get a better understanding of how this works.
I've looked in the ATA-1 and ATA-2 'draft' documents on-line and done lots
of web searching about this question but still haven't found an answer. I
realize this is an unusual question - especially for obsolete functions. It
is an interesting subject. If someone has similar interests about old
hardware Maybe I can help with answers. I have lots of info about some of
the old stuff.

TIA Bill S.

Maxim S. Shatskih

2007-11-01, 7:12 pm

> NARRATION: Every time you start the PC the drive has to 'learn' what CHS
> numbers to use - it doesn't 'remember' them from before. When the PC is
> starting up the mainboard start up routine reads the CMOS to find the CHS
> numbers and then writes them to a temporary table in the PC's memory.

Yes. This memory is within 0x400-0x700 physical, the BIOS data area.

>Next,
> the mainboard start up routine searches the system for attached drive(s) and
> when it finds a drive it passes control to another routine within the ROM on
> the drive.

No. No code from the drive ROMs (even if they exist) can be executed by the
host CPU. If such ROMs do exist - then only the drive's internal CPU (can be
not x86) can execute it.

Instead, the BIOS sends SET DRIVE PARAMETERS ATA command to the drive to set
its CHS translation.

> Initialize Drive Parameters

SET DRIVE PARAMETERS, and the code is in the main BIOS, not in the drive's ROM.

> are present). The information in the FDPT is used by DOS and other programs
> when the computer is up and running.

By BIOS mainly, but its usual int 13h path.

I have doubts that DOS ever used this table.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Emerald Saint

2007-11-01, 7:12 pm

There is a command in ATA-1 called
Initialize Drive Parameters (opcode 91h)
in ATA-2 it is called
Initialize Device Parameters (opcode 91h).

> No. No code from the drive ROMs (even if they exist) can be executed by
> the
> host CPU. If such ROMs do exist - then only the drive's internal CPU (can
> be
> not x86) can execute it.

I'm not sure what you mean. PC cards often had code in ROM that became
part of the PC's address space. You can find it by searching in a certain
range of the PC's memory using a tool like DEBUG. The code is in blocks
identified with a signature word. Often a PC card had some code that
executed during initialization AND ALSO some other code that was in the PC's
address space. But I am sure you are correct - the code I referred to in my
post probably wasn't executed by the PC. I said that incorrectly in the
post.

But do you know how the data in the FDPT gets determined ? In particular,
the number for cylinders ? The ATA Initialize Drive Command only sends
numbers for
(H)eads and (S)ectors per track. That is for sure. It doesn't send a number
for cylinders. Presumably the drive doesn't need to be told how many
cylinders. But it seems only reasonable to ask the drive what coordinate
system it thinks it has been told to use. If the mainboard start up routine
puts the numbers from CMOS in the FDPT, that seems unwise. It should ask
the drive what it's going to use for C, H and S dimensions (via Identify
Drive Command). But I don't know that for sure. That's actually what I'm
trying to find out. I can't check that stuff by testing - not since many
years ago.

BIOS doesn't talk to the drive using INT 13h. BIOS talks to the drive using
ATA commands - Int 13h routines talk to the drive using ATA commands.

Maxim S. Shatskih

2007-11-02, 1:15 am

> I'm not sure what you mean.

On-drive ROMs.

>PC cards often had code in ROM that became
> part of the PC's address space. You can find it by searching in a certain
> range of the PC's memory using a tool like DEBUG. The code is in blocks
> identified with a signature word. Often a PC card had some code that
> executed during initialization AND ALSO some other code that was in the PC's
> address space.

We were speaking about on-drive ROMs.

> But do you know how the data in the FDPT gets determined ? In particular,
> the number for cylinders ?

From BIOS's CMOS memory, where it is set by the user, often using the results
of IDENTIFY command (auto-detect).

> system it thinks it has been told to use. If the mainboard start up routine
> puts the numbers from CMOS in the FDPT, that seems unwise. It should ask
> the drive what it's going to use for C, H and S dimensions (via Identify
> Drive Command).

This is done in a BIOS setup screen usually.

> BIOS doesn't talk to the drive using INT 13h.

DOS talks to drive using int 13h.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Emerald Saint

2007-11-06, 1:14 pm

Maxim. Thanks for your reply. I believe you are right about drives not
having ROMs. Some older ISA card controller boards had ROMs but I have
never seen a chip that looks like a ROM chip on a drive. However some
soldered-on ROMs probably don't look much different than other chips.

The ATA commands have all the functions needed to convey the geometry
information to and from the drive (except I don't understand about cylinder
number as I mentioned previously). So there is no reason a ROM would be
used to determine the geometry information. I had read where ROMs were used
like that but now I realize that was on the very old ISA boards I mentioned
above.

Thanks for your help.

Bill S.

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
news:fgeekp$jm5$1@news.mtu.ru...
>
> On-drive ROMs.
>
>
> We were speaking about on-drive ROMs.
>
>
> From BIOS's CMOS memory, where it is set by the user, often using the
> results
> of IDENTIFY command (auto-detect).
>
>
> This is done in a BIOS setup screen usually.
>
>
> DOS talks to drive using int 13h.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>

Maxim S. Shatskih

2007-11-07, 7:15 am

First, the drive can have ROM. But this ROM is only used by the drive's
circuit processor, and not by the main CPU.

Second, the _IDE controller_ had its own ROM (implemented as extension ROM
for a main BIOS) in PC/XT. Starting from PC/AT, the int 13h code for hard disks
was embedded into the main BIOS.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Emerald Saint" <xp.student@comcast.net> wrote in message
news:_sCdnXLJ4t2TLK3anZ2dnUVZ_gydnZ2d@co
mcast.com...
> Maxim. Thanks for your reply. I believe you are right about drives not
> having ROMs. Some older ISA card controller boards had ROMs but I have
> never seen a chip that looks like a ROM chip on a drive. However some
> soldered-on ROMs probably don't look much different than other chips.
>
> The ATA commands have all the functions needed to convey the geometry
> information to and from the drive (except I don't understand about cylinder
> number as I mentioned previously). So there is no reason a ROM would be
> used to determine the geometry information. I had read where ROMs were used
> like that but now I realize that was on the very old ISA boards I mentioned
> above.
>
> Thanks for your help.
>
> Bill S.
>
>
>
>
>
>
> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
> news:fgeekp$jm5$1@news.mtu.ru...
>
>