[rloew]

jaclaz, on 09 August 2011 - 06:23 AM, said:

To me in this context of bullding volumes that can be either a volume on Hard disk or represent a "superfloppy", a Head or a Track are exactly the same thing, for which two different names are used, one for floppies and one for Hard Disks.

A Track is one ring of data on one side of a Floppy. A Head can access an entire side, or platter in an old Hard Drive.
The same names are used for Floppies and Hard Disks.

Quote

The size of the volume in bytes is given by:
Bytes_per_Sector*Sectors_per_Head*Number_of_Heads

Yes.

Quote

or:
Bytes_per_Sector*Sectors_per_TracK*Number_of_Heads

No. This is the size of a Cylinder.

Quote

No problem whatsoever in naming the field "Sectors_per_ Track" , but then also the "Number_of_Heads" should become "Number_of_Tracks", thus losing any logical connection with the MBR.

Number_of_Tracks would not be the same. It would equal the Number of Cylinders multiplied by the Number of Heads.
The confusion occurs because of the mixture of data descriptions on the Disk with the hardware access control nomenclature.
A pure data based definition would be as follows:

Sectors per Track
Tracks per Cylinder
Cylinders per Disk (Total Cylinders)

[jaclaz]

rloew, on 09 August 2011 - 10:03 AM, said:

No. This is the size of a Cylinder.

Sure, sorry , I missed the "final" "*Number_of_Cylinders" (that is not a "field" in the bootsector) in the case of hard disk and "*Number_of_Tracks" ( or number of "whatever") (that is also not a "field" in the bootsector) in the case of floppy.

Let's take the example of a "super-floppy" of 9,437,184 bytes, 512 bytes/sector.
That makes 18432 sectors.
Let's say that we have an "extended" ED disk drive , thus m/2/36

• It has 256 "whatever #1"<-this is NOT a field in the bootsector
  
• it has 2 "whatever #2" (Sides?, Heads? Tracks?) <-this is a field in the bootsector
  
• It has 36 "whatever#3" (Sectors_per_Track? Sector per Head?) <-this is a field in the bootsector

9,437,184 is given by:
Bytes_per_Sector*whatever#3*whatever #2*whatever #1
512*36*2*256=9,437,184

A partition/volume on hard disk 18432 sectors, 512 bytes each, totaling 9,437,184 bytes in size on a hard disk with a nx64x32 CHS geometry will have (let's assume that it is a very small second partition and that we do respect cylinder/head boundaries), first partition being:
CHS 0/1/1-19/63/32 LBA 32/40928
will have:
CHS 20/0/1-28/63/32 LBA 40960/18432

9,437,184 is given by:
Bytes_per_Sector*whatever#3*whatever #2*whatever #1
512*32*(63-0+1)*(28-20+1)=9,437,184

The differences between the two bootsectors should be:

• whatever#3 (temporarily named "Sectors_per_Head") 36 vs 32
  
• whatever #2 (temporarily named "Number_of_Heads ") 2 vs 64
  
• "Sectors_Before" (or "Hidden Sectors") 0 vs. 40960
  
• "Media_Type" (this should be OK ) 240 vs 248

How can the two "whatever" be named so that they are "self-explaining" in both cases?

jaclaz

This post has been edited by jaclaz: 09 August 2011 - 11:48 AM

[dencorso]

jaclaz, on 09 August 2011 - 06:23 AM, said:

To me in this context of bullding volumes that can be either a volume on Hard disk or represent a "superfloppy", a Head or a Track are exactly the same thing, for which two different names are used, one for floppies and one for Hard Disks.

While I don't disagree with you, after some musing, I think you are insisting in using the most misleading label possible, for an otherwise simple thing. So let me make some considerations on what CHS is:

Cylinder is the set of all tracks that are at the same distance from the center. Once you define a value for "Cylinder", the position of the whole head-manifold (which moves all heads solidarily) is fixed. So Cylinder means "distance from the center".

Head is which of the heads is the head-manifold that is activated. In general, that means just which side of which plater will be used, and in this general sense, head means "side". However, after fixing the cylinder, defining a head defines one side of one platter, and as such, it does define which track inside the cylinder is used. But this is true solely when the cylinder has already been fixed. And that's why "sectors per track" is unmistakeable and graphic, while "sectors per head" requires contextualizing.

Sector indicates which part of the track selected by the other two coordinates is to be addressed.

Moreover, there's no reason at all for different uses for floppies and hard-disks, unless you go all the way back to single sided floppies, for which cylinder = track and head is irrelevant, because there can be only one (as Connor McCloud used to say ).

[jaclaz]

dencorso, on 09 August 2011 - 01:09 PM, said:

While I don't disagree with you, after some musing, I think you are insisting in using the most misleading label possible, for and otherwise simple thing
So let me make some considerations on what CHS is:

I am actually not asking for "considerations", I am only asking for two (actually three) names we can all agree upon and that are understandable by users, and that make sense BOTH when we are talking of a superfloppy image and when we are talking of a hard disk volume, and I am not "insisting" in anything, only explaining my wrong (in the sense of simplified ) way to describe things in the given context, as you may know the graphical and mechanical representations are completely meaningless on any modern (meaning what, last 15 years? ) hard disk, so that maybe was CHS.

We have THREE fields that I temporarily (and mistakenly) named:

• Sectors_per_Head
  
• Number_of_Heads
  
• Sectors_Before

How should they be named?

• Sectors_per_Track
  
• Number_of_Heads
  
• Hidden_Sectors

Is that OK?

This only affects the actual variable names, I reserve the right to call them (as I understand them the wrong way) in the "textual part":

• Sectors per Track (Sectors per Head)
  
• Number of Heads
  
• Hidden Sectors (Sectors Before)

I also asked, PLEASE for additional corrections to the two added sheets in the Workbook, and to verify and FILL the missing data.
Can I have them?
Or everything is already "perfect" (I doubt it, but I may have been lucky)

jaclaz

[rloew]

jaclaz, on 09 August 2011 - 01:30 PM, said:

We have THREE fields that I temporarily (and mistakenly) named:

• Sectors_per_Head
  
• Number_of_Heads
  
• Sectors_Before

How should they be named?

• Sectors_per_Track
  
• Number_of_Heads
  
• Hidden_Sectors

CHS is only literal for Floppies and very old Hard Drives. For everything else the interface is emulated. It is still the same protocol so the same nomenclature should be used for all.

For numbers 1 and 2, I would stick with the latter set which represents the standard nomenclature.

Number 3 is an entirely different story. It has nothing to do with CHS. Hidden_Sectors is Microsoftese. It makes little sense since earlier Partitions can lurk in the space. It would have been more appropriate for the "Reserved Sectors" field at offset 0xE. I personally would suggest "Start_Sector" as it is the primary purpose of the field in primary (possibly Bootable) Partitions. In Logical Partitions it is often set to the Offset from the corresponding Extended Partition, so "Sector_Offset" is another option.

[dencorso]

I'll review it again more closely by the weekend, but for now, here's what I got to offer:

1) For the Common Floppy Formats list:

800K size=819,200 sectors=1600 c=80 h=2 s=10 (b/s)=512 (s/c)=1 Re=112 Mt ?
1600K Re=224
1760K - 1920K Re=224

The above also adds "10" to the list of known values for sectors_per_track (aka sectors_per_head)

2) For the question of the labels, my suggestion is:

1. Sectors_per_Track
2. Number_of_Heads
3. Sectors Before

3) While I didn't review the FreeDOS bootsector sheet, I did better than that for the MS-DOS sheet:
I actually booted my 128MB SD card using that bootsector and it works OK. So I suppose it's mainly OK, but I'll review both byte by byte during the weekend.

4) I didn't review the INI sheet very closely, because it's not clear to me which application is it intended to work with. Can you please elaborate?

Later edit:
Never mind. I had failed to notice the quote below in a previous post of yours. It's clear enough. I'll review the .INI bearing it in mind.

jaclaz, on 07 August 2011 - 10:43 AM, said:

I added a tentative way of "classification" and naming and an example .ini, as I am thinking we can use a .ini file to create a "database" of known formats and/or let the user choose only a subset of the available and/or have a common "interchange" format between different utilities/scripts.

[Multibooter]

rloew, on 09 August 2011 - 02:26 PM, said:

Hidden_Sectors is Microsoftese... It would have been more appropriate for the "Reserved Sectors" field at offset 0xE. I personally would suggest "Start_Sector"

How about using the terms which Roberto Grassi, the author of GRDuw, the best software for superfloppies, has used in his Disk Information Report, e.g. http://www.msfn.org/...post__p__970657 or http://www.msfn.org/...post__p__973379

This post has been edited by Multibooter: 09 August 2011 - 05:19 PM

[rloew]

Multibooter, on 09 August 2011 - 05:18 PM, said:

rloew, on 09 August 2011 - 02:26 PM, said:

Hidden_Sectors is Microsoftese... It would have been more appropriate for the "Reserved Sectors" field at offset 0xE. I personally would suggest "Start_Sector"

How about using the terms which Roberto Grassi, the author of GRDuw, the best software for superfloppies, has used in his Disk Information Report, e.g. http://www.msfn.org/...post__p__970657 or http://www.msfn.org/...post__p__973379

It uses the standard notation for CHS.
It also uses "Hidden Sectors" which a number of people, including me, object to.

[jaclaz]

rloew, on 09 August 2011 - 07:47 PM, said:

It also uses "Hidden Sectors" which a number of people, including me, object to.

Yes, it is "innatural".
Both "Start_Sector" and "Sector_Offset" are both better, the "Sectors_before" comes from the same comparison about different "partition related tools":
http://jaclaz.alterv...B/USBstick.html

SectBefore	
StartSector	
Sectors Before	
Relative Sectors	
Starting

I find it a plain English way (without entering in the detail tha LBA sectors are numbered from 0) to describe what the field should contain, still in the "hard disk" world, the LBA start address is the number of "sectors before" and:

TotSectors	
NumSectors	
Sectors	
Total Sectors

is the number of sectors in the partition, corresponding to either of the two fields "Small_Type_Sectors" and "Large_Sectors", where also as seen before there is not yet an univocal agreement:

Quote

"Sectors 16" and "Sectors 32"

@dencorso
The idea of the .ini has several "goals"

• have a "standard" way to exchange "complete" information about such images/formats. As we have seen in this an similar threads it is easy to forget "passing" a parameter (like the number of "ROOT" entries) and often sources you can find miss this or that detail
  
• a .ini file (besides being parsable by *anything*, including batches ) can be posted "as is" on the board or inside an e-mail, or whatever
  
• using a .ini the spreadsheet could output such a .ini and one could use a "generic" batch or program to simply load the .ini settings, being it "plain text" it could be easily modified/tweaked without any spreadsheet app and without actually changing values in the batch, everyone could write his/her own little program to read the "common format" .ini and produce the image, adding also features like "full", "truncated" and "sparse" (this could be "cross-platform")
  
• another operation that could be done through an "extension" of the app could be replacing what bootpart does (with a number of limitations) and/or correcting the "Sectors Before" to make logical volumes inside extended bootable, the use of the .ini would be a way to put down all data needed when performing this "kind" of operation and then each program may take from it only what is needed and there could be an app that dreates the .ini from an existing volume or image
  
• additionally, in situations like the "flashing cursor" or "j in top left of the screen" the user asking for help may run a little app to create the .ini and post it, and it would be a breeze to troubleshoot the issue...
  
• the thing I find more needed is the actual image naming convention (the actual "section" of the .ini) as I often (please read as "always") find myself with a bunch of images with a name that give no hints of their contents, if we could devise a way of naming that would give a hint of the way the image was made, it's size and "contents" (in the sense of boot code in it) it would solve or mitigate this problem, and I am pretty sure I am not the only one having it

jaclaz

[dencorso]

I see. I think the best way to determine the contents of the bootstrap code might be:

1. Copy the whole bootsector to a temporary buffer
2. Zero-out the first 64 bytes to remove the BPB down to a paragraph boundary.
3. Calculate the MD-5 Hash for the resulting image in the buffer.

This is fast and efficient, provided we create a list of such "truncated MD-5"s for all "known bootstraps"
The "truncated MD-5 of bootsector" or "partial bootstrap MD-5" would become an entry in the .INI, of course.

MD-5s have been gathering discredit in recent times because they're not unuque. However, they're way better than CRC-32s, and, moreover, only in very contrieved situations does their non-uniqueness manifest itself, so I do think they're still distinctive enough for our purposes and small enough, when compared with their "better" competitiors.

[rloew]

dencorso, on 10 August 2011 - 12:36 PM, said:

I see. I think the best way to determine the contents of the bootstrap code might be:

1. Copy the whole bootsector to a temporary buffer
2. Zero-out the first 64 bytes to remove the BPB down to a paragraph boundary.
3. Calculate the MD-5 Hash for the resulting image in the buffer.

64 Bytes is not enough. FAT32's BPB extends to 0x5A (90 Bytes). In addition it has another Sector of Code.

[dencorso]

Very true... OK. If it should cater for FAT-32 too, let's make it thus:

1. Copy the whole bootsector to a temporary buffer
2. Zero-out the first 96 bytes to remove the BPB down to a paragraph boundary.
3. Calculate the MD-5 Hash for the resulting image in the buffer.

As for the fact that the bootstrap is divided in two sectors, I'd bet the MD-5 of just the last 416 bytes of the 1st sector should still be distinctive enough.

[allen2]

Sorry to intrude on this thread, but instead of calculating a md5 of something this small, i would compress it with 7zip (for example):
- You might be interested in looking at it after and you can't get it from its md5.
- You 'll have a limited number of md5 of bootstrap.
- Someone might have created a new bootstrap and then you'll need to update your md5 reference.
- How are you going to handle the unknown md5 ? If your entire bootstrap is stored, you can find the closest one (with a binary comparison for example) but you can't do this with md5.
- As you said 2 md5 might be identical and the probability for such thing on such a low number of bytes should be extremely low but even then you might want to be sure that they're different or not.
Sorry again if i am totally of topic there.

This post has been edited by allen2: 10 August 2011 - 11:37 PM

[jaclaz]

FAT32 has actually three of them sectors, but I thought we were (at the moment) inside the FAT12/16 realm.

With FAT32 we additionally have the "third" sector being in "variable places", namely, for the ones I remember:

• MS_DOS sector 2
  
• NT sector 12
  
• ReactOS 14

Summed up here:
http://www.msfn.org/...t/page__st__103
(I presume - but haven't checked - that FreeDOS is similar to MS-DOS)

Using an MD5 or even a simpler algorithm is OK, I don't think we will ever have enough samples to have even a minimal possibility of a collision.

Personally I think that zeroing out a number of initial bytes in the sectors is not the "right" approach.

Why not simply have:
the original bootsector(s) copy.
apply to it a .ini with all the values we will change, exception made for:

• Jump_Bytes
  
• OEM_String
  
• System_ID
  
• Magic_bytes

set to 00's?

jaclaz

[dencorso]

The FAT-32 "bootsector" actually comprises 3 sectors, but since the second of these is the FSINFO sector, the bootstrap itself is somewhat less than 2 sectors, like I said.

Now, if we just consider the FAT12/16 bootsector for the moment, by simply zeroing out the first 64 bytes, we loose just the initial jump and two bytes of code before the region that would be preserved. I think that's acceptable. A more extensive idea would be just to zero out the BPB, then calculate the MD-5. Then again allen2 is right when he says that compressing the actual bootstrap might be more useful, although that would be less compact.

Another question you posed and that remained unanswered:
The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that.

I've revised the bootsector sheets and they are correct, byte-by-byte. An interesting fact is that, when the FreeDOS bootsector is compared to the one present in the released floppy image version of FreeDOS 1.0 Final (2006-08-11), the bootstrap code in both is identical, but they have different OEM names, the one in your worksheet using the already classic FreeDOS, while the FreeDOS 1.0 Final (2006-08-11) floppy has "LINUX4.1" (attached).

Attached File(s)

•  LINUX41.7z (614bytes)
  Number of downloads: 3

[rloew]

dencorso, on 11 August 2011 - 04:55 PM, said:

Another question you posed and that remained unanswered:
The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that.

As far as I know the OEM Field at Offset 3 is not part of the BPB. The BPB that is used internally starts at Offset 0xB. That would make the two fields above BPB+8 and BPB+0x11 respectively.
Total Sectors (16) takes priority over Total Sectors (32) so only one is relevant in any given situation. I just list "Total Sectors" in my Software as having both would be an invalid combination.

Due to bugs in the standard Boot Code and extended features I have added, I have my own Versions of the Boot Codes as well.

[dencorso]

rloew, on 11 August 2011 - 10:18 PM, said:

dencorso, on 11 August 2011 - 04:55 PM, said:

Another question you posed and that remained unanswered:
The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D, and I think this is good, in that it does not create ambiguity. I do think "Total Sectors (16)" and "Total Sectors (32)" are good labels. Of course, everybody else will disagree, but life is like that.

As far as I know the OEM Field at Offset 3 is not part of the BPB. The BPB that is used internally starts at Offset 0xB. That would make the two fields above BPB+8 and BPB+0x11 respectively.

Very true. You're right, of course.

[jaclaz]

dencorso, on 11 August 2011 - 04:55 PM, said:

've revised the bootsector sheets and they are correct, byte-by-byte. An interesting fact is that, when the FreeDOS bootsector is compared to the one present in the released floppy image version of FreeDOS 1.0 Final (2006-08-11), the bootstrap code in both is identical, but they have different OEM names, the one in your worksheet using the already classic FreeDOS, while the FreeDOS 1.0 Final (2006-08-11) floppy has "LINUX4.1" (attached).

Yes/No.
I just tested, see here:
http://reboot.pro/15123/
the FreeDOS and it has another OEM name, FRDOS4.1.

You can call the 2nd sector whatever you want , but if the theme is "making a filesystem from scratch" you will have to create the 2nd sector too.

About the OEM field being part or not (it is not) of the BPB (already cited):
http://homepage.ntlw...name-field.html
the issues are TWO as I see it:

• some boot code will check it nonetheless
  
• the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names

a good example of the latter is the DOS 8.0/WinME floppy embedded in XP/2003's diskcopy.dll:
http://www.911cd.net...showtopic=16745

Quote

*-v4VIHC

I have no idea if it can happen that it creates non-batch compatible string (like one containing ! or & or <>, etc.)

Stiil trying to get an agreement:

• Size in sectors (small-16)
  
• Size in sectors (large-32)

or

• Number of sectors (small-16)
  
• Number of sectors (large-32)

(just to be homogenous with other field names, you don't have "Total FAT(s)" or "Total Heads" ....)

jaclaz

This post has been edited by jaclaz: 12 August 2011 - 04:38 AM

[dencorso]

jaclaz, on 12 August 2011 - 02:14 AM, said:

• Number of sectors (small-16)
  
• Number of sectors (large-32)

I agree to the above, gladly.

The image that has "LINUX4.1" is bona-fide: see for yourself <link>

jaclaz, on 12 August 2011 - 02:14 AM, said:

the stoopid volume tracker of WIn9x/Me writes "crazy" OEM names

It can be prevented in virtually all cases by adding these three binary values:
All disks 02 00 90
Every disk FE 01 55 AA
PC-DOS1 00 00 EB 2F 14
to the key:
MyComputer\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\FileSystem\NoVolTrack
For more details see this post elsewhere, and, of course, KB148637.

[jaclaz]

dencorso, on 12 August 2011 - 02:49 AM, said:

The image that has "LINUX4.1" is bona-fide: see for yourself <link>

Yep, I was not doubting it in the least , only re-marking that our good FreeDOS friends have not much "order" or "tidyness" in what they release.
As soon as the good guys at reboot.pro will have finished playing with the board in order to make it "better" (please read as "ruining senselessly an otherways perfectly working setup to add some completely unneeded eye-candy" ) you will be able to have a look at what I needed to do in order to get a "right" SYS.COM.

Here is a google cache:
http://webcache.goog...boot.pro/15123/
Fixed (seemingly):
http://reboot.pro/15123/
After my little odissey (and probably somehow thanks to it ), the file was fixed, thanks to the good FreeDOS guy , and the current version (august 10, 2011):
http://www.fdos.org/kernel/sys/
has also RX-DOS and DE (stoopid Dell RMK):

Quote

/OEM : indicates boot sector, filenames, and load segment to use
/OEM:FD use FreeDOS compatible settings
/OEM:DR use DR DOS 7+ compatible settings (same as /OEM)
/OEM:PC use PC-DOS compatible settings
/OEM:MS use MS-DOS compatible settings (up to 6.x)
/OEM:W9x use MS Win9x DOS compatible settings (7.x+)
/OEM:Rx use RxDOS compatible settings
/OEM:DE use DEll Real Mode Kernel settings
default is /OEM:AUTO, select DOS based on existing files

About Volume track, sure , that key is useful to set it in "your own" Win9x/Me, I was trying to say that most people won't have it, and thus you can easily get an image (or bootsector) with "absurd" OEM field contents (and the original MS floppy image mixup is a proof of how common this can be, basically any "MS-DOS floppy" made on XP the "standard way" will have such a botched OEM).

jaclaz

This post has been edited by jaclaz: 12 August 2011 - 04:39 AM