Jump to content

On Superfloppies and their Images


dencorso

Recommended Posts

  • 2 weeks later...

@Den: Your Superfloppy Image seems OK but it is not quite "Blank". It has three clusters marked BAD and some sort of Signature near the end. It, of course, cannot be used on a CD for Floppy Emulation.

Attached is an image of a real unusual superfloppy I've created some time ago... It can be made bootable, of course. And when transferred to a physical Zip100, after running SYS.COM on it, it realy does boot OK (I did the test).

Any reason for the 32K sized clusters? :dubbio:

It should be 2K:

http://support.microsoft.com/kb/140365/en-us

and it really should be FAT16.

Or am I missing something?

jaclaz

A: and B: are assumed to be FAT12. You cannot use FAT16 or FAT32 without problems.

A FAT12 Partition is limited to 4087 Clusters so using 2K Clusters would greatly exceed this number.

Most of the difference between FAT12 and FAT16 should be that the sectors number is at offset 19dec, the so called "Small type sectors" in a FAT 12 (thus allowing a max number of 4 bytes, i.e. 65535 sectors x 512=33,553,920 bytes actually a few less) whilst in FAT 16 (06 and 0C type, NOT 04) offset 32dec can be used (for volumes bigger than 32 Mb), the so called "Large sectors" , see also here:

http://reboot.pro/5660/

So at first sight it seems like a "hybrid" FAT12/FAT16 filesystem

Or maybe better put, it is a FAT 16 filesystem (06 or 0C) "labeled" as "FAT12".

I originally thought that the distinction between FAT12 and FAT16 was the Number of Sectors being the 16-Bit Value at Offset 0x13 vs. the 32-Bit Value at Offset 0x1C in the Boot Sector.

I now know that this is not true. A separate test is performed to get the Number of Sectors from the appropriate location. Either one can be used with FAT12 or FAT16 if the Partiiton is less than 32MiB.

The distinction between FAT12 and FAT16 is based on the number of Clusters available on the Partiition. Oddly enough, DOS and Windows 9x use different limits so it is possible to create a Partition that looks like FAT12 to one and FAT16 to the other.

SuperFloppies and CD Floppy Images have no MBR, so there is no Partition Type Code.

Link to comment
Share on other sites

@Den: Your Superfloppy Image seems OK but it is not quite "Blank". It has three clusters marked BAD and some sort of Signature near the end. It, of course, cannot be used on a CD for Floppy Emulation.

Thanks a lot! :thumbup

I've replaced the image by a corrected one. Now, the problems you've pointed out are fixed, and also now the Media Descriptor Byte is the same in the BPB and both FATs. In fact, the image has a working boot sector, so adding MS-DOS 7.10 IO.SYS and COMMAND.COM (and optionally a 0 byte MSDOS.SYS), using WinImage, should be enough for it to be able to boot.

Link to comment
Share on other sites

Attached is an image of a real unusual superfloppy I've crated some time ago... It can be made bootable, of course. And when transferred to a physical Zip100, after running SYS.COM on it, it realy does boot OK (I did the test).

Any reason for the 32K sized clusters? :dubbio: It should be 2K: http://support.microsoft.com/kb/140365/en-us and it really should be FAT16. Or am I missing something?

When I tried to load dencorso's .ima file into GRDuw v4.1.17, I got the err msg: "GRDuw - Fatal error. The Disk Image file media type is NOT supported !". This err msg may or may not mean something because one of the main issues of GRDuw is that it checks the media type before proceding. Once GRDuw passes the media type hurdle, it provides detailed info about a disk (zip, LS-120, regular floppies, Jaz) or disk image, for example the attached report in http://www.msfn.org/board/topic/151957-ls-120-superdisk-drive-under-win98-and-dos/page__view__findpost__p__970657

Edited by Multibooter
Link to comment
Share on other sites

When I tried to load dencorso's .ima file into GRDuw v4.1.17, I got the err msg: "GRDuw - Fatal error. The Disk Image file media type is NOT supported !".

Yes, the image is non-standard, I have similar problems with dmde.

I get:

Filesystem: FAT12

Bytes per sector: 512

Sectors per cluster: 64

Reserved Sectors: 1

Root dir entires: 512

Total sectors: 196608

Sectors per FAT: 9

Start offset: 0

Then I get a "Total sectors number was decreased to fit the device" .

A quick look at it with Tiny Hexer (+ my BSview structure viewer) tells me that it has a 64/32 geometry (correct for a ZIP drive) and has a "Large sectors" value of 196,608.

Most of the difference between FAT12 and FAT16 should be that the sectors number is at offset 19dec, the so called "Small type sectors" in a FAT 12 (thus allowing a max number of 4 bytes, i.e. 65535 sectors x 512=33,553,920 bytes actually a few less) whilst in FAT 16 (06 and 0C 0E type, NOT 04) offset 32dec can be used (for volumes bigger than 32 Mb), the so called "Large sectors" , see also here:

http://reboot.pro/5660/

So at first sight it seems like a "hybrid" FAT12/FAT16 filesystem :w00t:

Or maybe better put, it is a FAT 16 filesystem (06 or 0C 0E) "labeled" as "FAT12".

Having only 9 sectors per FAT should mean that as soon as you fill the image with files there may be a problem, even with 32 Kb clusters.

9*256=2,304

2,304*32,768=75,497,472

the default for that size being around 200 (with clusters sized 2K)

200*256=51200

51,200*2,048=104,857,600

:unsure:

See also this:

http://reboot.pro/13466/

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

So at first sight it seems like a "hybrid" FAT12/FAT16 filesystem :w00t: Or maybe better put, it is a FAT 16 filesystem (06 or 0C) "labeled" as "FAT12".
@jaclaz and dencorso: Would an image file, created by GRDuw v4.1.17, of a freshly full-formatted bootable (i.e. with system files) but otherwise blank 100MB zip disk be of any help?

Nearly 2 years ago, when I intended to archive my old zip and jaz disks, I came across some old zip and jaz disks, containing files and folders created with some special Win3.x's and Win95 under various unofficial Farsi code pages, also under standard Arabic code pages. But I never got around to testing the created images, and I just left this project unfinished in the box. In any case I was able to create an image file of a 1GB jaz disk with GRDuw and then restore this image with WinImage v8.1.8100, GRDuw couldn't restore the jaz image, only create it.

Link to comment
Share on other sites

@Multibooter: The Medium ID Byte occurs in three places, at offsets 0x15 (BPB), 0x200 (1st FAT) and 0x1400 (2nd FAT). In the image attached to this post I've changed them all to F8 (a hard disk), instead of F0 (a 1.2, 1.44, 2.88 floppy or a superfloppy). Let's see how GRDuw likes this new image.

Having only 9 sectors per FAT should mean that as soon as you fill the image with files there may be a problem, even with 32 Kb clusters.

@jaclaz: While you've got the numbers from the BPB all right, what is relevant here is:

Total sectors: 196608 and Sectors per cluster: 64

So 196608 / 64 = 3072 clusters

Now, each cluster uses 1.5 bytes per cluster in a FAT-12 so this means

3072 * 1.5 = 4608 to which you may add 3 bytes which is the "FAT start signature"

So we have 4611 and 4611 / 512 = 9.006 sectors per FAT-12 :whistle:

Now, the question is, what do we do with the 0.006 sector? It means 3 bytes in the FAT-12 or 2 clusters.

So, to be on the safe side there should be 10 sectors per FAT-12, which is what mkdosfs would create, if used. I decided it was too much, and used just 9, because, in my reasoning, 196608 is the total sector count, but we should subtract from them the boot sector, 18 sectors for two FATs and the root directory. So, since we have 512 root entries and each entry takes 32 bytes, that means 32 sectors are used for the root directory! Now 1 +18 +32 = 51, and so, the available sectors are just 196608 - 51 = 196557 and 196557 / 64 = 3071.2031 clusters or 4606.8047 + 3 bytes per FAT-12 or 9.004 sectors per FAT-12. Since my really precious data wouldn't ever be in all in this image, anyway, I decided to round that to 9 sectors per FAT-12. And that means you're right: when the last cluster happen to be filled, the second FAT might be trashed. Then again, I suspect DOS simply would never use the last cluster, because it *knows* there are just 9 sectors per FAT, so this image has 32 kiB of unusable space, which I find quite acceptable. On the other hand, if I had used 10 sector per FAT-12, that would change the numbers again and 1 +20 +32 = 53 --> 196608 - 53 = 196555 --> 196555 / 64 = 3071.1719 --> 9.003 sectors per FAT-12, so two more sectors are used, of which not more than 3, and, in fact, probably only 1.5 byte would ever be used... If you transfer the image to a real Zip100 and fill it to the brim, let's see whether DOS destroys the start of the second FAT, thus corrupting the disk or if, as I presume, it'll just consider the disk filled when there's no more free space in the FAT. You've got me curious.

And, just to keep related things together, I think it proper that I should quote this older post here:

BTW, the FAT article in the Wikipedia (link) gives 4078 clusters as the maximum for FAT12, and their reasoning seems correct to me.

4078 is based on the standards.

DOS and Windows computes the number of available Clusters then tests it against a threshold. If below, assume FAT12. If above, assume FAT16.

To complicate things further, DOS and Windows do not even use the same threshold. DOS uses 4086 and Windows uses 4085. A partition could be interpreted as FAT12 by DOS and FAT16 by Windows.

FAT16/FAT32 discrimination is even worse. DOS uses 65526 as a threeshold, Windows tests the 16-Bit # of Sectors per FAT field.

Still according to the above cited Wikipedia page, under Linux, FAT12 is limited to 4084 clusters, adding to the confusion.

Empty_FAT12_SFloppy_Zip100_F8.7z

Link to comment
Share on other sites

@dencorso

Good. :)

Everything seems more clear.

The big difference in calculations was the 1.5 bytes (FAT12) vs. the 2 bytes (FAT16) :blushing:

I still think though that *somehow* using the "large sectors" field represents cheating :ph34r:;) and exploiting some kind of deficiency (or unintended feature) of the filesystem drivers/whatever.

I mean, most probably,and as rloew just confirmed, the driver/whatever is the same for FAT12/16 and the code somehow reads "large sectors" if "small sectors" is 0 no matter the "declared" FAT12 filesystem, whilst it strictly uses the 1.5 bytes depending on the same "declared" FAT12.

Running chkdsk on the mounted image gives 3070 clusters, which seems right (and entirely addressable).

We have:

1 = bootsector

9+9 FAT tables

512/32=16 Root directory

1+9+9+16=35 sectors that count anyway as one cluster

So there should be just one cluster (plus the "spare" sectors above 64-35=29) that are not in any way "addressable".

But if you use 10 sectors per FAT, I see no drawbacks, and you get an entire additional cluster addressable!

@rloew

Sure, the 01/04/06/0C 0E were only to "identify" different "versions", and their respective limits (that were "overtaken" by the new filesystem drivers/whatever).

If you don't use mkisofs, what do you use to create a .iso?

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

Sure. Done. Here it is. And by mounting using your VDM and chkdsk (on XP SP3, of course), I confirm exactly one cluster gets added, as expected. So here is a lesson for me: never round down the sectors per FAT number, even when the residue is minimum.

And BTW, just for the record: I originally put 2 instead of 64 heads, but when used in a real Zip100, the ZipDrive corrects it to 64 heads silently! And as the geometry is irrelevant, because the ZipDrive knows for a fact that there are exactly two heads and, since there is no MBR in a superfloppy, it never really gets used, because the 1st sector of the volume is also the 1st sector of the disk, no translation being necessary, IMO. Ken Kato's VDK doesn't care either. But other programs may be misled by it...

Empty_10sec_FAT12_SFloppy_Zip100.7z

Link to comment
Share on other sites

The Medium ID Byte occurs in three places, at offsets 0x15 (BPB), 0x200 (1st FAT) and 0x1400 (2nd FAT). In the image attached to this post I've changed them all to F8 (a hard disk), instead of F0 (a 1.2, 1.44, 2.88 floppy or a superfloppy). Let's see how GRDuw likes this new image
GRDuw cannot read the modified .ima file either and produces the same err msg about the media type.

I have just:

1) made a long format of a 100MB zip with Iomega Tools, selecting "Make disk bootable"

2) created with GRDuw an image of bootable zip disk

3) inserted another zip disk into the zip module

4) reloaded the .ima image file into GRDuw

5) wrote the .ima image file with GRDuw onto that 2nd zip disk

Surprise: At the end of verification the following warning msg is displayed: "GRDuw - Message. The disk into the drive does not match with that in the memory image !" I repeated 3) to 5) once more, same err msg. So apparently GRDuw cannot clone a zip disk, in contrast to LS-120 disks.

Out of curiosity, I created an image (2) of the cloned zip disk, and made a compare in Beyond Compare/Hex Viewer. 2 bytes in track 0 were different from the 1st image. I have attached a screenshot.

post-183045-0-19281700-1310719694_thumb.

Edited by Multibooter
Link to comment
Share on other sites

@dencorso

As often happens, yes and no. :ph34r:

Remember the CHS/LBA issues on 2K/XP bootsectors? ;)

I guess we are simply LUCKY that it doesn't applies to FAT16 bootesector code.

On a side note, VDK without a .pln file descriptor will default to 64/32 anyway, and 2K/XP will use LBA data anyway.

@multibooter

Those two difference are OK and *somehow* "logical".

The one at offset 0x1C is sectors before (or "reserved sectors"), in your snippet it has a value of 0x00000000 and 0x00000020, i.e. 32.

The one at offset 0x24 represents "drive number" and is 0x00 in floppy and superfloppy (F0) or normally 0x80 (aka drive 128) on HD (F8).

If you compare the bootsector of the image dencorso posted, you will see that it has at 0x15 F0 whilst your snippet has F8.

Basically GRDUW seemingly *somehow* transformed the "superfloppy" into a hard disk volume, maybe (or maybe NOT) connected to the "partitioned type" of ZIP disk.

jaclaz

Link to comment
Share on other sites

@multibooter

Those two difference are OK and *somehow* "logical"... Basically GRDUW seemingly *somehow* transformed the "superfloppy" into a hard disk volume, maybe (or maybe NOT) connected to the "partitioned type" of ZIP disk.

Good to hear this. I had created the 2 images with the GRDuw option AbsRW (other options are BIOS and IoCtrl) in the left-bay zip drive module of my old 7500 Inspiron laptop. This left-bay zip drive module fits into the 7500, but was actually made for the older Inspiron 7000. It has a big sticker by Dell on it: "For Inspiron 7000 ONLY" and has produced surprising results in the past, possibly because of some incompatibility in the BIOS.

OT: Here another example of a BIOS incompatibility (or just a bad LS-240 drive?): About 2 years ago I tried to build an LS-240 left-bay module, which Dell never offered for the Inspiron 7500, they have only LS-120 modules. I had replaced the LS-120 drive in the Dell left-bay LS-120 module with an LS-240 drive taken from an IBM Thinkpad LS-240 Ultrabay 2000 drive module. The LS-240 drive from the IBM module was detected by the Dell Inspiron, could read from an LS-120 diskette, but not from an LS-240 diskette, and when trying to format a 1.44 floppy disk to 32MB, SuperWriter32 broke off after 7% :(

OT: Left-bay modules in the Inspiron 7500 are usually bootable (except for the left-bay HDD module containing a 2nd or 3rd HDD), while right-bay modules are not. Dell never made a left-bay zip drive module for the Inspiron 7500, only a non-bootable right-bay zip drive module. When I have both zip drive modules inserted into my old Inspiron 7500 (i.e. into the right and left bays), I can use them at the same time, very convenient for comparing/copying etc. of 2 zip disks. I can also have both the bootable LS-120/DVD combo module and the right-bay zip drive module inserted. It is much more convenient to change laptop drive modules than to disconnect/reconnect IDE devices inside a desktop.

Link to comment
Share on other sites

@rloew:

Sure, the 01/04/06/0C 0E were only to "identify" different "versions", and their respective limits (that were "overtaken" by the new filesystem drivers/whatever).

jaclaz

DOS and Windows do not seem to care what the Partition Type Code is, if in the allowed range, when determining Filesystem Type.

.

Link to comment
Share on other sites

I've done my best to split the CD floppy emulation without mangling either part. :blushing:

It's not perfect, but I think it worked...

BTW, the image below wastes not a single sector! What did I do? Easy: just added the formerly unusable 11 sectors to the root directory, which now holds 688 entries. :w00t:

Empty_10sec688d_FAT12_SFloppy_Zip100.7z

Link to comment
Share on other sites

DOS and Windows do not seem to care what the Partition Type Code is, if in the allowed range, when determining Filesystem Type.

Sure :thumbup they do not, as the DOS and Windows we are currently using were all made AFTER the "invention" of types 04, 06 and 0C 0E, this is IMHO the same "side effect" as the "large Sectors vs. Small Sectors".

If you try:

  1. DOS <3.3
  2. DOS 3.3
  3. DOS 4.0
  4. DOS <=6.22
  5. DOS >= 7.0

on a set of 01/04/06/0C0E partitions, your mileage should (and will) vary ;)

I think that in common language we could consider:

  • FAT12 an ancestor of FAT16
  • FAT16 04 a sub-set of FAT 06
  • FAT 16 06 a sub-set of FAT 0C 0E

Then draw a line around 1995 and say that everything coded after is accessing *any* of the above in the same way (which allows for some of the tricks we are discussing).

As I see it, trying dencorso'S image in DOS 3.3 should fail, as that version of Dos should know nothing about "Large sectors". :unsure:

jaclaz

Edited by jaclaz
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...