Jump to content

On Superfloppies and their Images


dencorso

Recommended Posts

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.

The size of the volume in bytes is given by:

Bytes_per_Sector*Sectors_per_Head*Number_of_Heads

Yes.

or:

Bytes_per_Sector*Sectors_per_TracK*Number_of_Heads

No. This is the size of a Cylinder.

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. :unsure:

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)

Link to comment
Share on other sites


No. This is the size of a Cylinder.

Sure, sorry :blushing: , 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 :w00t:, thus m/2/36

  1. It has 256 "whatever #1"<-this is NOT a field in the bootsector
  2. it has 2 "whatever #2" (Sides?, Heads? Tracks?) <-this is a field in the bootsector
  3. 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:

  1. whatever#3 (temporarily named "Sectors_per_Head") 36 vs 32
  2. whatever #2 (temporarily named "Number_of_Heads ") 2 vs 64
  3. "Sectors_Before" (or "Hidden Sectors") 0 vs. 40960
  4. "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? :unsure:

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

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. :P 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 :) ).

Link to comment
Share on other sites

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 :P

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 :ph34r: ) 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? :unsure:) hard disk, so that maybe was CHS.

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

  1. Sectors_per_Head
  2. Number_of_Heads
  3. Sectors_Before

How should they be named?

  1. Sectors_per_Track
  2. Number_of_Heads
  3. Hidden_Sectors

Is that OK? :unsure:

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

Link to comment
Share on other sites

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

  1. Sectors_per_Head
  2. Number_of_Heads
  3. Sectors_Before

How should they be named?

  1. Sectors_per_Track
  2. Number_of_Heads
  3. 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.

Link to comment
Share on other sites

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.

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.
Link to comment
Share on other sites

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. or

Edited by Multibooter
Link to comment
Share on other sites

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. or

It uses the standard notation for CHS.

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

Link to comment
Share on other sites

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.altervista.org/Projects/USB/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:

"Sectors 16" and "Sectors 32"

@dencorso

The idea of the .ini has several "goals" :w00t:

  • 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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Edited by allen2
Link to comment
Share on other sites

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

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:

(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. :whistle:

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

Why not simply have:

the original bootsector(s) copy.

apply to it a .ini with all the values we will change, exception made for:

  1. Jump_Bytes
  2. OEM_String
  3. System_ID
  4. Magic_bytes

set to 00's?

jaclaz

Link to comment
Share on other sites

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).

LINUX41.7z

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...