What does that mean? Now there are USB keys with 16 GB. 8 GB-key has 987 cylinders, so what happen to 16 GB key?
Your spreadsheet shows only 2 GB and 8 GB examples. Could it show 16 GB example?
You have also the PTtableUSB.xls (don't remember when/how I got it) showing different CHS/LBA geometry but limited to 2 GB USB key.
Could you update it to include 4GB, 8GB and 16 GB key?
ktp, ktp, you did not make your homeworks, did you?
When passing from 8 Gb to 16 Gb you encounter the so-called CHS INT 13 barrier
That standard allocates 10 bits for the cylinder number (and thus a maximum of 1,024 cylinders), 8 bits for the head number (maximum of 256) and 6 bits for the sector number (maximum of 63, since the number 0 is not used). Multiplying these together, and assuming the standard of 512 bytes per sector, you get a maximum of 8,455,716,864 bytes. This is the largest hard disk size that can be addressed using the standard Int13h interface.
And you NEED LBA support to overcome this barrier.
Similar to the Dirk Gently's I-Ching calculator:http://www.thateden.co.uk/dirk/
that gives as a result "A suffusion of yellow" for any operation that leads to a number greater than 4, ANY value above 1023 CANNOT
be stored in partition table and is conventionally written to it as 1023.
There are 10 kinds of people in this world: those who understand binary, and those who don't.
Ray Knight's page:http://home.att.net/....htm#TblEntries
has a remarkably clear representation on how Cylinders and Sectors are actually stored in the MBR Partition Table "intertwined" in two bytes.
Since you have 10 bits available, 1023 is:|0123456789|
if you try to write 1024:
in a 10 bit space, you get:x|0123456789|
i.e. 0, which is not really what you want.
The PTtableUSB.xls was an old idea, based on the wrong
assumption that Flash based devices had to have exact sizes depending on the fixed size of the chips used.
unfortunately it seems like "final" size of the device depends also on the controllers used in the device and, moreover, on the settings that the individual OEM may use when programming the controller. Thus, that file does not apply correctly to every device.
Not being a programmer, the only practical way I ever found to get the "real" size of a device has been to use Roadkil's Disk Image or dsfo.exe to make an image of the device, not having ever had a Flash device bigger than 1 Gb, I never had the need to find a different solution, maybe for 8 or 16 Gb size this becomes unpractical, and another solution has to be found.
Probably using dsfo.exe from a batch and counting the number of iterations to copy a given chunk of data from increasing addresses to the nul
device until an error is found would work, but never tried it.
Once you have the exact size of your device, it takes just a few attempts (or you could add to CHS_LBA.XLS a line where you input the size, and it is divided sequentially by 512, S
) to get the correct number of "virtual" C