How does BIOS autodetect a disk chs geometry
James Harris
identify the geometry (cylinders, heads and sectors) that a hard drive
has been formatted with.
http://www.p-dd.com/chapter12-page2.html
I know the disk can be accessed by LBA but the BIOS still has a way to
recognise the CHS values. So, how does the BIOS tell what geometry was
used on the disk when it was formatted?
Also, for USB flash drives what is it about the flash drive which a
BIOS or an OS uses to find out what else is on the drive?
James
Maxim S. Shatskih
> recognise the CHS values. So, how does the BIOS tell what geometry was
> used on the disk when it was formatted?
IDENTIFY ATA command.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
wolfgang kern
> http://www.p-dd.com/chapter12-page2.html
You find information about hard disks geometry in the Identify
block. But this is a fiction anyway. Modern Hd's don't follow
Sector/head/track information and fake their real geometry to
fit ye olde CHS-standard to make some older PC's understand it.
Look at partition info: if CHS values are above or at limits
then only the LBA sections are valid.
ie: 01BE 8x/0x b ;active/inactive boot + assigned drive-number
01BF..1C1 3b ;CHS boot sector [ignore if all bits set]
01c2 b ;partition type [ie: KESYS='K'=4Bh]
01c3..1c5 3b ;CHS last sector [ignore if all bits set]
01c6..1c9 4b ;(wasted) boot sectors CHS [LBA of boot-sector]*
01ca..1cd 4b ;size(in sectors) of this partition [LBA+CHS]
FD-boot images default to the disk size while USB-FD-images
seem to only know 1.44 MB formats (FAT16,1 sector/cluster)
even only the first 512 bytes where used for the boot process.
*) KESYS-partitions points to itself here because MBR==BR then.
__
wolfgang
Mike Gonta
wrote:
> Also, for USB flash drives what is it about the flash drive which a
> BIOS or an OS uses to find out what else is on the drive?
Hi James,
We know that the flash drive is just memory composed of bits.
Of course there is no C(ylinder), no H(ead), no S(ector),
no LB(lock)A. Even the bits don't stay in the same place (with wear
leveling technology).
The BIOS uses USB protocol to determine the size of the flash drive.
If the BIOS emulates the flash drive as floppy disk, the OS uses
the standard FD geometry with int 13h, dl=0.
If the BIOS emulates the flash drive as hard disk, the OS uses
either LBA (which should be supported in such a BIOS) or the CHS
geometry returned with int 13h, ah=8, dl=80h - Get Drive Parameters.
This geometry is what the BIOS will use with int 13h.
This is the common (which means I didn't invent it) technique I use
in the boot sector of pdBIOS32 so that the same FAT12 floppy disk
image will boot and run from a flash drive with either BIOS method.
It will boot and run as either A: or C: depending on the BIOS. Of
course it will also boot and run from a floppy disk.
I emphasize "boot and run" because the booting part is trivial. The
BIOS loads the first physical sector to 7C00h and jumps to it, no
problem, (after some simple, non standard checks).
In order for the rest to run ( which requires int 13h to load and if
using
CHS, which is required to run as A: or C:), int 13h function
parameters
must be based on the returned geometry and not hard coded assumptions.
Mike Gonta
look and see - many look but few see
Rod Pemberton
"James Harris" <james.h...@googlemail.com> wrote in message
news:9380e4df-0e71-4c69...@w3g2000vbd.googlegroups.com...
> I see the HDD partition table does not contain explicit info to
> identify the geometry (cylinders, heads and sectors) that a hard drive
> has been formatted with.
>
> http://www.p-dd.com/chapter12-page2.html
>
> I know the disk can be accessed by LBA but the BIOS still has a way to
> recognise the CHS values. So, how does the BIOS tell what geometry was
> used on the disk when it was formatted?
>
AIR, Hale Landis' (ATAPI code) webpages said that some of the CHS
calculations are BIOS specific. E.g., if you swap harddisks between
machines and they were formatted using CHS (not LBA), you could end up
reading different tracks.
It's probably in the first link here:
http://www.ata-atapi.com/hiw.html
Main site:
http://www.ata-atapi.com
Rod Pemberton
Maxim S. Shatskih
> calculations are BIOS specific.
Surely, a well-known fact. That's why people were using LBA mode since the very beginning in around 1995.
> machines and they were formatted using CHS (not LBA)
What is important is not formatting, but partition table creation.
Low-level format does not know on CHS (and it is rather hard to do low-level format of the ATA drive, and even the SAS controllers are dropping the format tool from the BIOS setup screen, thus requiring something like "camcontrol format da0" to do this).
High-level format in Windows is just VERIFY to all disk sectors. UNIXen I think have none, only "newfs" (same as Windows quick format).
But, when the partition is created, its MBR entry contains both CHS and LBA values. The CHS values are important at least for some OSes (old ones?).
MS's people once told on forums that Vista+ does not use old int 13h at all, and only boots using extended int 13h. But nevertheless the CHS values can still be important.
Also the boot sector code of the new partition can be CHS-dependent. It also contains CHS values in it, which must match the BIOS's one.
Aharon Lavie
wrote:
INT 13H function 48H requires DS:SI to point to a buffer upon entry.
After successful return this buffer contains HD data, CHS data
included. Up until now I assumed that the source of this information
is the HD firmware. Is there any reason to doubt this assumption?
Mike Gonta
> INT 13H function 48H requires DS:SI to point to a buffer upon entry.
> After successful return this buffer contains HD data, CHS data
> included. Up until now I assumed that the source of this information
> is the HD firmware. Is there any reason to doubt this assumption?
The HD controller option ROM relocates int 13h to int 40h, so that
fixed disk int 13h is updated, and transfers int 13h, dl<80h functions
to int 40h. This also means that for small HD's and flash drives int
13h,
ah=8 can be used to obtain CHS geometry.
Rod Pemberton
news:a2a867bf-49cb-4ea2...@j12g2000pri.googlegroups.com...
>
> INT 13H function 48H requires DS:SI to point to a buffer upon entry.
> After successful return this buffer contains HD data, CHS data
> included. Up until now I assumed that the source of this information
> is the HD firmware. Is there any reason to doubt this assumption?
>
It's my understanding the values returned by the BIOS' CHS algorithms don't
have to match the hardware's actual CHS layout. AIR, supposedly for older,
smaller harddrives upto 528MB the algorithms were "good enough" and usually
matched the hardware, but not always. I think this was covered one of the
various Phoenix EDD spec.'s. However, I doubt the later CHS values for
"extended Int 13h CHS translations" for drives upto 8.4GB match the hardware
layout at all. They just have to provide a workable translation. There
have been a number of enhancements to BIOS Int 13h over the years.
1981 IBM PC Int 13h supports floppy disk
1984 IBM PC/AT extended Int 13h support - CHS upto 528MB
1992 IBM/MS Int 13h extensions
1994 Phoenix EDD 1.0 extended Int 13h CHS translation upto 8.4GB
1996 BIOS Boot Spec. boot devices without Int 13h support
1998 Phoenix EDD 3.0 extended Int 13h for 28-bit LBA from ATA-2
I'm not sure if Int 13h was extended again for 48-bit LBA from ATA/ATAPI-6.
AIR, that Hale Landis website had a lot of good info. I probably need to
reread it...
Rod Pemberton
Aharon Lavie
I have two Phoenix documents which I downloaded from the internet a
few years ago. One, "BIOS Enhanced Disk Drive Specifications" Version
3.0 Rev 0.9, is dated March 12, 1998. The other, "Information
Technology - BIOS Enhanced Disk Drive Specifications" T13/D1484
Revision 0, is dated June 18, 2001. According to both documents, INT
13H function 48H requires that DS:SI points to a buffer upon entry;
upon successful return the data on the buffer include:
WORD offset 2: Flags.
DWORD offset 4: Number of default cylinders.
DWORD offset 8: Number of default heads.
DWORD offset 12: Number of default sectors per track.
QWORD offset 16: Number of sectors.
Within the flags, one in bit 1 (bit 1 ON) indicates: "The geometry
returned in bytes 4-15 is valid"
Regarding the number of sectors at offset 16 (i.e., the capacity of
the drive in sectors), the document states that if it exceeds 15482880
then bit 1 of the flags is cleared to zero (bit 1 OFF), i.e.,
indicating the geometry returned in the three DWORDS above is not
"valid".
The term "valid" is not defined. One may interpret it as matching the
physical geometry. Maybe. I prefer to interpret this term according to
whether or not the CHS datum is small enough to fit into the narrow
MBR CHS fields (the same as the original CHS INT 13H function 8
convention for 8086 registers). In my mind, it is "valid" if it fits.
I view hard drive geometry as virtual ever since I read that for some
hard drives the physical geometry is invisible to the software because
internal logic in the hard drive circuitry translates the software
specified geometry to meet the hard drive internal hardware
requirements.
Now back to my question. I asked if there is any reason to doubt my
assumption that the information provided by INT 13H function 48H
regarding the drive's virtual geometry is obtained from the drive's
firmware. I asked this question because if this assumption of mine is
correct then the question of the original poster has its answer: the
drive's firmware.
By the way, I am puzzled by the magic number 15482880. I cannot see
how it relates to the 8.4 GB barrier.
Rod Pemberton
>
> I have two Phoenix documents which I downloaded from the internet a
> few years ago. One, "BIOS Enhanced Disk Drive Specifications" Version
> 3.0 Rev 0.9, is dated March 12, 1998.
FYI, most standards are inclusive, i.e., they cover or reiterate all of the
information in the prior standard. That's not the case for EDD 3.0. You
probably want to get EDD 1.1 also.
> By the way, I am puzzled by the magic number 15482880. I cannot
> see how it relates to the 8.4 GB barrier.
Yeah, that number seems off a bit, doesn't it?
16,515,072 = 63 x 256 x 1024 (total BIOS CHS sectors for 8.4GB - EDD 1.1)
Well, can we calculate it... ?
15,482,880 = 63 x 256 x 960
15,482,880 = 63 x 240 x 1024
?
At least we know it's divisible by 63 heads... but as for the rest, I've
got no idea. Maybe a number of lower bits are cleared in the head or sector
values because of the CHS translation algorithm's? (in EDD 1.1)
Rod Pemberton
Maxim S. Shatskih
>> see how it relates to the 8.4 GB barrier.
>
> Yeah, that number seems off a bit, doesn't it?
Old-style stupid ATA controller hardware uses 16bits for cylinder, 4bits for head, 8 bits for sector, of total 28bits = 256M sectors = 128GB.
Old-style int 13h uses 10bits for cylinder, 8 bits for head, 6 bits for sector (in the same word as cylinder). Of total 24bits = 16M sectors = 8GB.
This is the 8GB limit.
Untranslated int 13h uses the combination of the limits - 10/4/6 - 20 bits = 1M sectors = 512MB.