partition table entry info

[falure]

I have a 3gb virtual disk(16-head, 63-secPerTrack, 6200-cyl) on vmware. I have partitioned it with fdisk into 3 partitions. Here are my MBR partition entries:

80 01 01 00 XX XX XX ... Primary partition
00 00 41 05 XX XX XX ... Extended partition
00 00 00 00 ....
00 00 00 00 ....

__ _____
| |
Head   --- 10bit cyl num, 6 bit sector num

I can find my primary function is realy at head-01 cyl-00 sec-01 but my extended partition is not at head-00 cyl-21(decimal) sec-01. Also it is nonsense to search second partition at that address because my primary partition has 1Gb size and extended partition must be ahead of it. But 21*16*63*512 is not about 1Gb size..

There is an absolute-sector-address of partition on an partition-entry structure and it is 0x201d80 and when I convert it to CHS format it is head-00 cyl-2088 sec-01. And when I check that address...bomm. my extended partition is standing there... Than why is this difference? I mean absolute-address of a partition in a partition-entry differs than head-cylsec info?

Im missing something but what???

Then I decided to use absolute-LBA address of partitions in partition entries. But whenever I search for my 3rd partition, the lba addr on extended partition table for my 3rd partition is false... (It says it is in the middle of second partition...)

I wonder which info in partition table do u you, absolut-LBA addr or head_CylSec addr?

Or what am I missing?

Thanks for any help, document or url..

[Candy]

I have a 3gb virtual disk(16-head, 63-secPerTrack, 6200-cyl) on vmware.
.....
Head???--- 10bit cyl num, 6 bit sector num
......
There is an absolute-sector-address of partition on an partition-entry structure and it is 0x201d80 and when I convert it to CHS format it is head-00 cyl-2088 sec-01.

Bold is my emphasis. What can fit in a 10-bit number? Both 6200 and 2088 don't fit. Why then is the number different? Because CHS wasn't being used for a few decades now already.

[falure]

Because CHS wasn't being used for a few decades now already.

Yeah, I agree with you, and checked it before. A simple C program, by using biosdisk can read surprisingly CORRECT SECTOR's when I send biosdisk(_CMD_READ, 0x80, 0, 0x41, 0x5, 1, buf). I have found my extended partition sector...????

Anyway... should I use absolute sector address??(It worked when I search extended partition, but failed when I try to find 3rd partition)

You, the ones implemented partition reading, what do you do for reading extended partition info??

Any example, document or help will be appreciated... thanks...

[Candy]

You, the ones implemented partition reading, what do you do for reading extended partition info??

Any example, document or help will be appreciated... thanks...

I didn't implement it. I repartitioned my own harddrive using winhex to figure out how it worked.

You need to use the LBA values for most, because CHS is very limited (8GB max, iirc). LBA is limited to 2TB per partition and 2TB offset, so it'll stretch until LaCie invents a 2TB disk, which will take at least a few months... They're at 1.6TB now.

[falure]

Yeah, I think I should use LBA... But lba addr in extended partition sector for my 3rd partition is wrong. And a tutorial advices using chs values, not lbas in partition entries. Im missing something but what... anyway Ill check it again... Thanks

[Candy]

Yeah, I think I should use LBA... But lba addr in extended partition sector for my 3rd partition is wrong. And a tutorial advices using chs values, not lbas in partition entries. Im missing something but what... anyway Ill check it again... Thanks

Do you have an exact dump of that last partition entry?

[JAAman]

its been a while since i looked at the specifications but(iirc):
if CHS is used, the values in LBA field are undefined (may exist but point to garbage)
if LBA is used, the values in CHS are undefined (may exist but point to garbage)

therefore you must use another method of identifying the use of LBA or CHS entries:
this is why FAT uses separate partition types for LBA or CHS (for FAT32 and NTFS (mabey FAT16 also? unsure)) if partition type is:

0B == FAT 32 (using CHS entry)
0C == FAT 32 (using LBA entry)

06 == FAT 16 (using CHS entry)
0E == FAT 16 (using LBA entry)

05 == extended partion (using CHS entry)
0F == extended partion (using LBA entry)

this way, a program can always know which entries are to be used (not sure what the MBR does, since it doesn't know about partition types: it may just assume CHS for older MBR programs, and LBA in newer MBR programs)

[falure]

Here is a summary:

I have a 3gb virtual disk installed in vmware and partitioned it with [bold]Win95-startupDisk[/bold] version of FDisk into 3 equal 1Gb parts. When I checked them with a small c program using biosdisk function, I have found them in following positions (by using dumps).

1- biosdisk(0x80, 0, 0, 1, 1, buf);
2- biosdisk(0x80, 0, 5, 41, 1, buf);
3- biosdisk(0x80, 0, 9, 81, 1, buf);

I mean it works fine and as most partitiontable tutorials. But the values are nonsense, and when I try to find them by using my own hddread function, it failed to find right sectors. I have attached my mbr and partitiontable sector dumps(taken by that small program). First dump is my mbr and shows my primary partition and an extended partition entry. Second is extended partition entry and shows my second partition and 3rd partition link. And 3rd dump shows my 3rd partition entry.

Here is my question. WHat is exact CHS and LBA values of my partitions???

PS: win95 startupdisk version of fdisk is used and as I understood from tutorials I swallowed, some conversion algorithms (chs <-> lba) are changed and there is logical CHS and physical CHS to be considered.

Thanks for helps....

[JAAman]

on newer HDDs, LBA should be ignored altogether (it is really limiting, and the drive has to change it back to LBA anyway)

normally CHS is calculated as:

cyl = LBA/(SectorsPerTrack*TotalHeads)
sector = LBA%SectorsPerTrack
head = (LBA/SectorsPerTrack)%TotalHeads

This can be easily done in ASM with:

Code: Select all

mov eAX,[LBA]
mov eBX, [SectorsPerTrack]
xor eDX,eDX

div eBX
mov [sector], eDX
mov eBX,[TotalHeads]
xor eDX,eDX
div eBX

mov [head],eDX
mov [cyl], eAX

this formula shouldn't ever change, but the CHS entries don't have to be valid for LBA formated partitions

[bluecode]

on newer HDDs, LBA should be ignored altogether (it is really limiting, and the drive has to change it back to LBA anyway)

perhaps you mean CHS here?

[JAAman]

yes i did!! (can't believe i did that)

[falure]

Then what are LBA values for my partitiontable sectors according to dumps I sent?

[JAAman]

i would guess that the LBA values in that particular MBR would be correct -- but the CHS values may be unreliable -- you would need to calculate them from the LBA as i showed above

what is you partition type? is it an LBA-FAT or a CHS-FAT

0B == FAT 32 (using CHS entry)
0C == FAT 32 (using LBA entry)

06 == FAT 16 (using CHS entry)
0E == FAT 16 (using LBA entry)

05 == extended partion (using CHS entry)
0F == extended partion (using LBA entry)

[Candy]

OK, lemme read the partition table

you have one partition type 0x06 (DOS FAT16) from 0x3F with length 0x201D41.
You have one partition type 0x0F (DOS extended LBA) from 0x201D80 with length 0x3FDC80 (or, a maximum of 0x5FFA00)

Second image:

One partition from 0x3F with length 0x1FFDC1 in the logical section, so that's 0x201DBF to 0x401B41. It's type 06 (DOS FAT16)
Second partition from 0x1FFE00 with length 0x1FDE80, so that's 0x401B80 to 5FFA00. It's type 05 (DOS extended)

Third bit:

One partition from 0x3F with length 0x1FDE41. It's type 06 So, it runs from 0x401BBF to 0x5FFA00.

So, I can tell you now that the LBA values are all correct.

Ignore the CHS values.

[falure]

Oh....
I have thought that the LBA values or CHS values are absolut-LBA values. I mean, LBA, starting from the first sector of disk everytime. As you said they are not absolute, they are relative-LBA values...

Humm... I hope I understood it correctly, Ill check it at home....
Thanks for help...