16 replies to this topic

[was_jaclaz]

Just to prove that drive geometry and CHS to LBA (and viceversa) conversions do not belong to "black magic", but are actually rather easily calculated, please find attached a spreadsheet that allows these conversions.

The layout should be seen as a derivative of the display of the utility Beeblebrox:
http://students.cs.byu.edu/~codyb/

Remember that, though the spreadsheet will work as well, on real devices you CANNOT have a Cylinder > 1023!

There are two lines for each conversion mode, so that you can easily compare different values.

Have fun.

jaclaz

Attached Files

•  CHS_LBA.zip   4.69KB   3196 downloads

[ktp]

Remember that, though the spreadsheet will work as well, on real devices you CANNOT have a Cylinder > 1023!

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?

Thank you.

[was_jaclaz]

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?

Thank you.

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 !
http://www.pcguide.c...d/bios/size.htm
http://www.pcguide.c.../sizeGB8-c.html

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.

Given that :

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|
|1111111111|
if you try to write 1024:
10000000000
in a 10 bit space, you get:
x|0123456789|
1|0000000000|
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 nuldevice 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, H ) to get the correct number of "virtual" Cylinders.

jaclaz

[ktp]

@jaclaz
OK, I did not think about the int13 limit.

For your information (and advice), following are the data taken from 8 and 16GB key.

Signature given by ptedit32 on:
8 GB key
1007 cyl, 255 heads, 63 sectors per track
original:
0b-80-0-1-1-249-240-32-32-16187360
After format with hp-usb fat32:
0c-80-0-1-1-1006-254-63-63-16187329
After correction by partition magic 8.05:
0c-80-0-1-1-1006-254-63-63-16187409

16 GB key
1974 cyl, 255 heads, 63 sectors per track
original:
0c-80-0-1-1-249-141-32-32-31719392
After format with hp-usb fat32:
0c-80-0-1-1-949-254-63-63-31719361
After correction by partition magic 8.05:
0c-80-0-1-1-949-254-63-63-31728312

[was_jaclaz]

8 GB key
After format with hp-usb fat32:
0c-80-0-1-1-1006-254-63-63-16187329

Typo?
0c-80-0-1-1-1006-254-63-63-16187329
0c-80-0-1-1-1006-254-63-63-16187392

The latter one is "correct" in the sense that partition ends on Cylinder boundary.

Signature given by ptedit32 on:
8 GB key
After correction by partition magic 8.05:
0c-80-0-1-1-1006-254-63-63-16187409

This one is "correct" in the sense that partition is 0c type, thus LBA, so no CHS info is needed and probably the partition extends itself over the entire size of key.

16 GB key
1974 cyl, 255 heads, 63 sectors per track
original:
0c-80-0-1-1-249-141-32-32-31719392
After format with hp-usb fat32:
0c-80-0-1-1-949-254-63-63-31719361
After correction by partition magic 8.05:
0c-80-0-1-1-949-254-63-63-31728312

The above should probably mean two things:
1) that the HP utility key returns "A suffusion of yellow" for sizes bigger than the 8 Gb CHS barrier, BOTH in the CHS part AND LBA part of the address, 31719361, as it would be 1974-112-58, simply makes no sense, but the 949 is interesting:
Try writing 1973 (a.k.a. 1974-1) in binary (eleven bits are needed):
x|0123456789|
1|1110110101|
Now try with 949 (again, even if not needed, using eleven bits):
x|0123456789|
0|1110110101|
Or, to make the comparison easier:

11110110101=1973
01110110101=949


Starting to see a pattern?

2) that Partition Magic (or the way the geometry of the drive is seen) does also something strange, as the partition is on a Cylinder boundary, though it is not on the 1973 one, but rather on the 1974, which should imply that the key has 1975 Cylinders instead of the reported 1974.
But it seems (if, as I am assuming, you did use PM right after having used the HP utility, without 00ing the partition table) also that PM simply ignores the values previously written in the CHS part of the address.

I stand by the theory that the "correct" values of this 16 Gb key (provided that it totals 31728312 - or a few more - sectors) should be:
0c-80-0-1-1-1023-254-63-63-31728312

See also:
http://en.wikipedia....der-head-sector

and my idea is that (again theoretically) on some hardware and/or with some non LBA-aware Operating Systems the "949" could cause problems.

If you have the opportunity of making an image of the keys, it would be interesting to know the "real size" of them.

jaclaz

[ktp]

Apparently not a typo. And the difference between the 2 values is 63 !
1) Yep, you are right pointing out HP-USB problem.
2) I think you are right. The right value 31728312 was suggested by PM8 but I did not apply first its suggestion for correction.
So the bad geometry remained. Now I accept the correction by PM8:
(before correction, PM8 said chs length 15261687, lba length 31719361, file system length 31719361) and suggested
the right value 31728312.

And now the signature of 16GB key is :
0c-80-0-1-1-1023-254-63-63-31728312
(exactly as Jaclaz's theory ).

[ktp]

I notice that this FAT32 formatter is very good. It does not appear to have the problem with big key as HP-USB.
Source code available, and one can set the cluster size used, which is excellent.
http://www.ridgecrop...fat32format.htm

[was_jaclaz]

I notice that this FAT32 formatter is very good. It does not appear to have the problem with big key as HP-USB.
Source code available, and one can set the cluster size used, which is excellent.
http://www.ridgecrop...fat32format.htm

Yep , the only problem with it is that (at least last time I checked it):
http://www.911cd.net...o...19056&st=49
it did not create a bootable volume, so it is an excellent idea if you use the grub4dos MBR and "bypass" the bootsector by directly chainloading a system file, otherwise one needs to patch the bootsector adding the boot code.

However, once you have a properly made MBR partition table, the ordinary 2K/XP format works allright anyway.

jaclaz

[ktp]

@jaclaz

I agree. So the best would be fat32format then grub4dos MBR invoking boot sector, or fat32format followed by bootsect /nt52 (or bootsect /nt60).

[was_jaclaz]

Attached a "new" version of CHS_LBA.

Please take note that it is still a "mature ALPHA" or "VERY early BETA".

Sheets are protected, with empty password.

Have fun.



jaclaz

Attached Files

•  CHS_LBA_v2.zip   66.2KB   1288 downloads

[wimb]

Wow , this is looking very good.

Very interesting and a lot to study first.

[joakim]

Very nice work indeed. Especially with "graphical illustrations" in spreadsheets.

Well done!

Joakim

[was_jaclaz]

Yep , have you ever seen anything by me that is NOT "nice"?



Seriously, I posted it to see how it is seen by other members, I do expect (possibly constructive) comments.

I plan to extend it with bootsectors and a way to write a file to be possibly feeded to echoo.com or a similar app.

I am SLOWLY working to understand the tinyhexer syntax, it could be a good interface for extracting data from MBR's and bootsectors, feed them to the spreadsheet and then from it re-write them to sectors.



jaclaz

[joakim]

Seriously, I posted it to see how it is seen by other members, I do expect (possibly constructive) comments.

I plan to extend it with bootsectors and a way to write a file to be possibly feeded to echoo.com or a similar app.

I am SLOWLY working to understand the tinyhexer syntax, it could be a good interface for extracting data from MBR's and bootsectors, feed them to the spreadsheet and then from it re-write them to sectors.

Maybe not the constructive feedback you expected, but I did not quite understand how to use tinyhexer for my own tool, from the command line. How would you automate the hexediting of \\.\PhysicalDriveN? Would that be through imported scripts? Or is such functionality limited to files (as opposed to PhysicalDrives)? Why use tinyhexer for extracting data, when dsfi/dsfo can do it? I ask this because I thought of making a command line hex editor (autoit/dsfi/dsfo)..

Did you mean writing directly from spreadsheet to sectors on physicaldrive, or from spreadsheet to file to sector?

Joakim

[was_jaclaz]

NO, if using the spreadsheet and echoo.com (and dsfo/dsfi) an intermediate "plain text" file would be needed or a batch with embedded data.

I was looking for including "everything" in a tinyhexer script.

I actually do not understand your question:

Command line parameters
Here the command line parameters supported by Tiny Hexer are listed.


--------------------------------------------------------------------------------


The following command line parameters are supported:

....
/s filename: The Tiny Hexer Script file filename is opened and executed.
/sp arguments: modifies the /s parameter, adds one or more parameters arguments (separated by blanks) to the commandline of the script to be executed (see PARAMS() function). You can use single quotation marks to distinguish multiple parameters containing blanks (E.g. mpth.exe /sp "'filename with blanks.txt' 100" /s script.mps)
Note: /sp arguments must precede the /s parameter! (E.g. mpth.exe /sp c:\boot.ini /s scripts\checksums.mps)

Difficult part is understanding/learning/writing/debugging the actual script.

Or am I missing something?

jaclaz

[joakim]

Just ran into a nice command line hex editor for files (not physicaldrives) less than 2Gb. It is 8Kb only.

Name is Hexalter

http://www.kuwanger..../hexalter.shtml

Joakim

[Brito]

Topic closed. Please open a new topic and keep it on track.

Thanks.