SANDISK Geometry via IOCTL_DISK_GET_DRIVE_GEOMETRY_EX

I am having difficulty with gathering correct disk geometry values for
my PC Card using IOCTL_DISK_GET_DRIVE_GEOMETRY_EX. The card I am
using is a 40MB Flash, but it has 64,225,280 bytes capacity. The
manufacturer (who I've spoken with) gave me the following values:

Cylinders: 490
Heads : 8
Sectors : 32

Doing the C*H*S*512 math gives me the correct # of bytes, as expected.
However, the call to IOCTL_DISK_GET_DRIVE_GEOMETRY_EX is returning:

Cylinders: 7
Heads : 255 <-- I'm calling tracks/cyl the "heads"..is this
wrong?
Sectors : 63

This gives me only 57,576,960 bytes! The manufacturer said that that
is "just the way Windows is." Hopefully not, because if it is so,
I'll have to go "way-low" and attempt direct ATA access via ports.
And since I can't readily find a way to get the IDE port the PC Card
is using, I will be quite out of luck.

Can anyone verify that Windows does in fact report erroneous drive
geometry with these cards? Is there a better way to gather this data?

Thanks in advance,

Eric Rudisill

Maxim
Tue Sep 21 19:15:32 CDT 2004

The CHS values are long ago fake. I see no need in paying any attention to
them, unless you will run FDISK command from Win98 :-)

Disks are working fine in NT-based Windows even with brain-damaged CHS
values, and even with CHS values which do not cover the whole disk.

The ATA disk size info used by modern Windows is
IDENTIFY_DATA::UserAddressableSectors.

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

"Eric Rudisill" <erudisill@ascensionhealth.org> wrote in message
news:21208a24.0409211230.63f02230@posting.google.com...
> I am having difficulty with gathering correct disk geometry values for
> my PC Card using IOCTL_DISK_GET_DRIVE_GEOMETRY_EX. The card I am
> using is a 40MB Flash, but it has 64,225,280 bytes capacity. The
> manufacturer (who I've spoken with) gave me the following values:
>
> Cylinders: 490
> Heads : 8
> Sectors : 32
>
> Doing the C*H*S*512 math gives me the correct # of bytes, as expected.
> However, the call to IOCTL_DISK_GET_DRIVE_GEOMETRY_EX is returning:
>
> Cylinders: 7
> Heads : 255 <-- I'm calling tracks/cyl the "heads"..is this
> wrong?
> Sectors : 63
>
> This gives me only 57,576,960 bytes! The manufacturer said that that
> is "just the way Windows is." Hopefully not, because if it is so,
> I'll have to go "way-low" and attempt direct ATA access via ports.
> And since I can't readily find a way to get the IDE port the PC Card
> is using, I will be quite out of luck.
>
> Can anyone verify that Windows does in fact report erroneous drive
> geometry with these cards? Is there a better way to gather this data?
>
> Thanks in advance,
>
> Eric Rudisill

Dave
Tue Sep 21 19:54:48 CDT 2004

Eric,

I too have seen totaly bogus numbers from IOCTL_DISK_GET_DRIVE_GEOMETRY and
IOCTL_DISK_GET_DRIVE_GEOMETRY_EX. while reading CF cards (and IIRC USB
memory too).

I have had luck using the low level ATA commands that are the
GetDriveParameters (i forget which ones right now)...

You don't need ATA via ports though if you open the physical device.

FWIW different CF readers have given me different BAD values.. go figure...

Dave August


"Eric Rudisill" <erudisill@ascensionhealth.org> wrote in message
news:21208a24.0409211230.63f02230@posting.google.com...
>I am having difficulty with gathering correct disk geometry values for
> my PC Card using IOCTL_DISK_GET_DRIVE_GEOMETRY_EX. The card I am
> using is a 40MB Flash, but it has 64,225,280 bytes capacity. The
> manufacturer (who I've spoken with) gave me the following values:
>
> Cylinders: 490
> Heads : 8
> Sectors : 32
>
> Doing the C*H*S*512 math gives me the correct # of bytes, as expected.
> However, the call to IOCTL_DISK_GET_DRIVE_GEOMETRY_EX is returning:
>
> Cylinders: 7
> Heads : 255 <-- I'm calling tracks/cyl the "heads"..is this
> wrong?
> Sectors : 63
>
> This gives me only 57,576,960 bytes! The manufacturer said that that
> is "just the way Windows is." Hopefully not, because if it is so,
> I'll have to go "way-low" and attempt direct ATA access via ports.
> And since I can't readily find a way to get the IDE port the PC Card
> is using, I will be quite out of luck.
>
> Can anyone verify that Windows does in fact report erroneous drive
> geometry with these cards? Is there a better way to gather this data?
>
> Thanks in advance,
>
> Eric Rudisill

erudisill
Wed Sep 22 08:35:33 CDT 2004

Thanks for the replies!

I didn't give enough info earlier. Sorry. The reason the CHS values
are important to me is that I "inherited" some code that actually
performs a format on the card. My constraints are that I have to use
this format utility within the "upgraded" application (to WinXP.)

Previously, this application was a Win95 User Mode front-end that made
calls into a VxD which provided basic identify, read/write, and
general PCMCIA CardServices functions. The VxD in turn had some
assembly routines embedded which performed the appropriate ATA
register/port calls.

Currently, I am enumerating the DISK devices via IoGetDeviceInterfaces
and then calls to IOCTL_STORAGE_QUERY_PROPERTY to determine my
removable media. Then, using the link name of the removable media, I
use ZwCreateFile() to open the device and read/write to individual
sectors. This works rather well, and I am able to perform a format on
the disk using the "inherited" code. In fact, if I plug the
manufacturer's geometry values into the format variables, I get a
perfect format! Full capacity! So since this is working so nicely,
I'd like to keep it this way.

However, it hinges on the fact that I need to get that drive geometry.
I hate to bring this up, but do you think the IDE_PASSTHROUGH would
help me out here? Just for this one ATA IDENTIFY command to retrieve
the true geometry values? (That's what the original VxD did..an ATA
IDENTIFY via asm.) If so, can someone point me in a direction to
accomplish this? I'm sure I need to discover the port address of the
PC Card, and after considerable searching, I can't a straight-forward
method for this either.

Again, thanks for your replies and assistance.

Eric Rudisill

Dave
Wed Sep 22 17:30:04 CDT 2004

Max may correct me here.. it's been a while since I was doing this, but IIRC
the ATA_PASSTHROUGH on the PHYSICAL device will work. As he said though..
Scr#@ the CHS stuff, go LBA and be done with it....

Dave


"Eric Rudisill" <erudisill@ascensionhealth.org> wrote in message
news:21208a24.0409220535.2e4c73f2@posting.google.com...
> Thanks for the replies!
>
> I didn't give enough info earlier. Sorry. The reason the CHS values
> are important to me is that I "inherited" some code that actually
> performs a format on the card. My constraints are that I have to use
> this format utility within the "upgraded" application (to WinXP.)
>
> Previously, this application was a Win95 User Mode front-end that made
> calls into a VxD which provided basic identify, read/write, and
> general PCMCIA CardServices functions. The VxD in turn had some
> assembly routines embedded which performed the appropriate ATA
> register/port calls.
>
> Currently, I am enumerating the DISK devices via IoGetDeviceInterfaces
> and then calls to IOCTL_STORAGE_QUERY_PROPERTY to determine my
> removable media. Then, using the link name of the removable media, I
> use ZwCreateFile() to open the device and read/write to individual
> sectors. This works rather well, and I am able to perform a format on
> the disk using the "inherited" code. In fact, if I plug the
> manufacturer's geometry values into the format variables, I get a
> perfect format! Full capacity! So since this is working so nicely,
> I'd like to keep it this way.
>
> However, it hinges on the fact that I need to get that drive geometry.
> I hate to bring this up, but do you think the IDE_PASSTHROUGH would
> help me out here? Just for this one ATA IDENTIFY command to retrieve
> the true geometry values? (That's what the original VxD did..an ATA
> IDENTIFY via asm.) If so, can someone point me in a direction to
> accomplish this? I'm sure I need to discover the port address of the
> PC Card, and after considerable searching, I can't a straight-forward
> method for this either.
>
> Again, thanks for your replies and assistance.
>
> Eric Rudisill

David
Thu Sep 23 09:08:46 CDT 2004

I have read the various replies and they are 'correct' but useless. The
problem is that 'geometry' is a bogus idea with today's drives, but
necessary because of the way the boot records function. The only item of
real importance is the total number of sectors. You can get the correct
information by issuing a IOCTL_DISK_GET_DRIVE_GEOMETRY which is supported on
all versions of NT/2000/XP/2003. Issue it to a handle opened upon the
PhysicalDriveN device. The only item of interest is the total number of
sectors.

Microsoft has changed format to default to 63 sectors per track and 255
heads (tracks/cyl). Bad decision, but it makes the math easier, but that
means each cylinder is 8,225,280 bytes in size. Any amount of space that is
less than this amount will not be used. For smaller drives, such as flash
memory, it is really a bad idea. I wrote a format program that can format
SmartMedia by using the SSFDC specs. It recognizes SmartMedia by the total
number of sectors being available and permits to user to override that
choice. The SSFDC format has two purposes: 1) Getting the full data
capacity of the media. 2) Aligning logical blocks (clusters) with the
physical blocks on the media. Normally flash memory must be erased at the
physical block level and then the data is written. If a cluster spans more
than one block, it requires a lot of internal memory or device driver
allocated memory for SmartMedia and non-mass storage compliant
readers/writers. The internal controllers built into CompactFlash hide
this, but the manufacturers know how the physical blocks are implemented and
you don't want every write to require multiple read, erase, write actions,
even internal to the device. Flash memory has a limited number of erase
cycles which increase with each generation of the technology, but it is much
more limited than hard drives. SmartMedia was designed so that the devices
writing to it would always write a logical block to a new physical block
every time in a LRU algorithm to prevent one physical block from being
written too many times.

You can write a format program that will take the total number of sectors
and perform math to find a geometry that will permit it all to be used.
Remember that a 'format' is just a logical concept and only SCSI drives and
floppies have a physical format capability while running on a Windows
system. Most IDE drives can only be physically formatted at the factory or
with special tools and/or equipment. They have automatic spare allocation
capability so reformatting as we used to do with MFM drives is not
necessary.

"Eric Rudisill" <erudisill@ascensionhealth.org> wrote in message
news:21208a24.0409211230.63f02230@posting.google.com...
>I am having difficulty with gathering correct disk geometry values for
> my PC Card using IOCTL_DISK_GET_DRIVE_GEOMETRY_EX. The card I am
> using is a 40MB Flash, but it has 64,225,280 bytes capacity. The
> manufacturer (who I've spoken with) gave me the following values:
>
> Cylinders: 490
> Heads : 8
> Sectors : 32
>
> Doing the C*H*S*512 math gives me the correct # of bytes, as expected.
> However, the call to IOCTL_DISK_GET_DRIVE_GEOMETRY_EX is returning:
>
> Cylinders: 7
> Heads : 255 <-- I'm calling tracks/cyl the "heads"..is this
> wrong?
> Sectors : 63
>
> This gives me only 57,576,960 bytes! The manufacturer said that that
> is "just the way Windows is." Hopefully not, because if it is so,
> I'll have to go "way-low" and attempt direct ATA access via ports.
> And since I can't readily find a way to get the IDE port the PC Card
> is using, I will be quite out of luck.
>
> Can anyone verify that Windows does in fact report erroneous drive
> geometry with these cards? Is there a better way to gather this data?
>
> Thanks in advance,
>
> Eric Rudisill