Int 13h extensions

[mori]

Hi,

I have a 40Gb drive which, when I partition with fdisk, gives somes very
strange figures for starting and ending values of CHS of the partitions
(don't have them to hand but not important at the minute),
soooooooo............

used Int 13h with AH=48h and DL=80h (drive C to get the (correct?) drive
parameters with these results returned in the DS:SI buffer....

1A 00 0A 00 FF 3F 00 00 0F 00 00 00 3F
00 00 00 80 2D C9 04 00 00 00 00 00 02

which translates to....

offset 04h DW -> 00003FFF cylinders
offset 08h DW -> 0000000F heads
offset 0Ch DW -> 0000003F sectors per track

which equals EC3C4Fh sectors on the disk which doesn't agree with

offset 10h QW -> 0000000004C92D80

which is supposed to be 'total number of sectors on drive'

offset 02h is the information flags word and has a value of 000Ah ->
0000000000001010b

bit 1 being set (as above) indicates that
'cylinder/head/sectors-per-track information is valid'

using ptsde disk editor and loading physical device - hard disk 1 (drive C)
it says that there are sectors 0 - 80287199d
or 0 - 4C915DFh which is *near* to the value in offset 10h above and roughly
40Gb. I cannot get to the end of the drive with ptsde.

This is a brand new drive.

Is there something wrong with the drive so that I can't view any sectors
above 65075231d (3E0F81Fh) with ptsde?

How is ptsde coming up with it's given number of sectors which disagree with
Int 13?

Any insight would be greatly appreciated

tia

mori

 

[Folkert Rienstra]

Hi,

I have a 40Gb drive which, when I partition with fdisk, gives somes very
strange figures for starting and ending values of CHS of the partitions
(don't have them to hand but not important at the minute), soooooooo............

used Int 13h with AH=48h and DL=80h (drive C to get the (correct?) drive
parameters with these results returned in the DS:SI buffer....

1A 00 0A 00 FF 3F 00 00 0F 00 00 00 3F
00 00 00 80 2D C9 04 00 00 00 00 00 02

which translates to....

offset 04h DW -> 00003FFF cylinders

16383 P-CHS cylinders

offset 08h DW -> 0000000F heads

16 P-CHS heads

offset 0Ch DW -> 0000003F sectors per track

63 P-CHS sectors

which equals EC3C4Fh sectors on the disk

15,481,935 sectors, ~8GB, close to the CHS limit.

which doesn't agree with

offset 10h QW -> 0000000004C92D80

80293248 sectors, ~41GB.

which is supposed to be 'total number of sectors on drive'

LBA sectors, which is correct. CHS is limited to 8GB.

offset 02h is the information flags word and has a value of 000Ah ->
0000000000001010b

bit 1 being set (as above) indicates that
'cylinder/head/sectors-per-track information is valid'

Which it is.

using ptsde disk editor and loading physical device - hard disk 1 (drive C)
it says that there are sectors 0 - 80287199d or 0 - 4C915DFh which is
*near* to the value in offset 10h above and roughly 40Gb.

Derived from the LBA sectors number, no doubt.

I cannot get to the end of the drive with ptsde.

This is a brand new drive.

Is there something wrong with the drive so that I can't view any sectors
above 65075231d (3E0F81Fh) with ptsde?

32GB ? Likely a programming error in ptsde.
Many programmers miss the finer points of CHS.

There is a 65,535 limit on P-Cyl, a 16 limit on P-Heads and a 255 limit on P-Sec.
giving 65535x16x63x512=32,790,200,000 CHS capacity range according to
some programmers (no one uses more than 63 sectors per track, right?).

What they missed is that CxHxS(x512 Bytes) cannot exceed 8GB.

How is ptsde coming up with it's given number of sectors which disagree with
Int 13?

It rounds to a full cylinder worth.
All indications are that ptsde works with CHS internally. It's flawed.

Any insight would be greatly appreciated

Really? I got a different impression in another thread.

 

[mori]

16383 P-CHS cylinders


16 P-CHS heads


63 P-CHS sectors


15,481,935 sectors, ~8GB, close to the CHS limit.


80293248 sectors, ~41GB.


LBA sectors, which is correct. CHS is limited to 8GB.


Which it is.

This is the part I'm not sure about. I assumed, as I can't find any
reference to answer this, that because this is the Int13 extensions, they
are obviously aware of the CHS limitations (as you rightly state). Therefore
I would have thought that bit 1 above would *not* have been set thus showing
that the CHS info is, in fact, not valid.

Derived from the LBA sectors number, no doubt.


32GB ? Likely a programming error in ptsde.
Many programmers miss the finer points of CHS.

There is a 65,535 limit on P-Cyl, a 16 limit on P-Heads and a 255 limit on P-Sec.
giving 65535x16x63x512=32,790,200,000 CHS capacity range according to
some programmers (no one uses more than 63 sectors per track, right?).

What they missed is that CxHxS(x512 Bytes) cannot exceed 8GB.


It rounds to a full cylinder worth.
All indications are that ptsde works with CHS internally. It's flawed.

I also had doubts about ptsde's maths. In loading a partition of ~1.2Gb
(2,570,337 sectors), ptsde *actually* loads sectors 63 - 2,570,400. This is
1 sector too many and the *final* sector is in fact the first sector of the
next partition, containing it's partition table and pointer. *Very
dangerous*

Really? I got a different impression in another thread.

Just, I had seen a few posts where you knocked others people's reasoning
while failing to provide an alternative. I think others also have this
impression.
Anyway, I am more than pleased with your input to this thread and thank you
for the same

mori

 

[Folkert Rienstra]

This is the part I'm not sure about. I assumed, as I can't find any
reference to answer this, that because this is the Int13 extensions, they
are obviously aware of the CHS limitations (as you rightly state).

There is no reason why CHS_only Int13 wouldn't know about it either.

Therefore I would have thought that bit 1 above would *not* have been
set thus showing that the CHS info is, in fact, not valid.

That is all what can be addressed using CHS, so it is 'in fact' valid.

Sometimes the values are more than 8GB worth, reflecting the LBA capa-
city and then the CHS values are set to be invalid in information flags.
I'm at a loss though why sometimes the CHS values reflect the LBA capacity
(with information flag set to false) and sometimes it is just set to maximum.

I also had doubts about ptsde's maths. In loading a partition of ~1.2Gb
(2,570,337 sectors), ptsde *actually* loads sectors 63 - 2,570,400. This is
1 sector too many and the *final* sector is in fact the first sector of the
next partition, containing it's partition table and pointer. *Very dangerous*


Just, I had seen a few posts where you knocked others people's reasoning
while failing to provide an alternative.

Maybe I should shutup and let the helpful but clueless people let you
all get all the oh so wrong but oh so seemingly 'helpful' "impressions".

I think others also have this impression.

Impressions can be desceiving, especially to those that mistake politeness for
helpfulness.

 

[mori]

Just as an 'extra'....

I can read absolute sectors 0 - 80293247 with no problem ....
trying to read absolute sectors 80293248 onwards returns 'Bad sector' i.e.
Ext Int13h AH=42h -> CY with AH = 0A
instead of the expected (well, what I expected anyway) AH = 04, sector not
found¿

Maybe I should shutup and let the helpful but clueless people let you
all get all the oh so wrong but oh so seemingly 'helpful' "impressions".

)


Impressions can be desceiving, especially to those that mistake politeness for
helpfulness.

true ;-)

 

[Folkert Rienstra]

Just as an 'extra'....

I can read absolute sectors 0 - 80293247 with no problem ....

As expected.

trying to read absolute sectors 80293248 onwards returns 'Bad sector' i.e.

Which suggests an 'UNC' error returned.

Ext Int13h AH=42h -> CY with AH = 0A

instead of the expected (well, what I expected anyway) AH = 04,
sector not found

Which suggests that the sector should be there but the drive mechanics couldn't
find it: 'IDNF'.

Actually, I would expect an error return like 'out of range', either by
bios internal checks or returned by the drive not accepting the command.

The ATA spec though appears to let the drive manufacturer decide whether
to use 'IDNotFound' or 'ABoRT'.

Bad sector is indeed out of expectation.
Of course all of this is a bit academic since you are supposed not to access
a drive beyond it's address range.
That's why the CHS and LBA parameters are there in the first place.

 

[Antoine Leca]

Hi Folkert,

Some fine points asked:

In Folkert Rienstra va escriure:

16383 P-CHS cylinders


16 P-CHS heads

I do not have the copy of the EDD standard at hand, but I feel surprised you
put +1 to the head count and not to the cylinder count.

I'd expected 00000010 (heads) in DWord 08.

15,481,935 sectors, ~8GB, close to the CHS limit.

BTW (I know Folkert knows that), it's my understanding 16383x16x63 is the
CHS geometry returned by all the current disks (which have much higher
capacity); perhaps even specified by ATA-5 or -6.

There is a 65,535 limit on P-Cyl, a 16 limit on P-Heads and a 255
limit on P-Sec.

If I get you correctly, the cylinder number would be between 0 and 65534.
Why is 65355 forbidden (again, do not have the relevant standard available,
lazy me, it is easier to ask).



Antoine

 

[Folkert Rienstra]

Hi Folkert,

Some fine points asked:

In news:[email protected], Folkert Rienstra va escriure:

I do not have the copy of the EDD standard at hand, but I feel surprised you
put +1 to the head count and not to the cylinder count.

Good point. I didn't even notice it. I mainly put it there for my own use,
to set it off against 256 (or 255 or 254 if you will), the L-CHS head count.
Unconsciously added +1 and assumed 16.

I'd expected 00000010 (heads) in DWord 08.

You're right. The numbers here are capacity related so the number is
not the highest head number as I falsely assumed, it's already plus one.
So 15 indeed means 15 heads, plural.

The answer may be here:
"
(ATA/ATAPI-6) C.2.2 Word 3

IDENTIFY DEVICE data word 3 (Default Heads) does not specify a value greater than 16. If the device has
less than or equal to 8,257,536 sectors, then set word 3 to 16 heads. If the device has more than 16,514,064
sectors, then set word 3 to 15 heads. If this value is set to 16 when the device has more than 16,514,064
sectors, some systems will not boot some operating systems.
"

BTW (I know Folkert knows that), it's my understanding 16383x16x63 is the
CHS geometry returned by all the current disks (which have much higher
capacity); perhaps even specified by ATA-5 or -6.

The same unconscious mistake I'm afraid.
The piece I copied it from clearly says 15, not 16.

I should have just copied it:
"
(ATA/ATAPI-6)
6.2 Register delivered data transfer command sector addressing

A CHS address is made up of three fields: the sector number, the head number, and the cylinder number.
Sectors are numbered from 1 to the maximum value allowed by the current CHS translation but shall not
exceed 255. Heads are numbered from 0 to the maximum value allowed by the current CHS translation but
shall not exceed 15. Cylinders are numbered from 0 to the maximum value allowed by the current CHS
translation but shall not exceed 65,535.
"

If I get you correctly, the cylinder number would be between 0 and 65534.

Uh no. The values I mentioned (bar the mistake) are the maximum number allowed.

Why is 65535 forbidden

So it's not.