[dencorso]

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

Attached File(s)

•  Empty_FAT12_SFloppy_Zip100.7z (14.59K)
  Number of downloads: 25

[rloew]

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

Quote

dencorso, on 13 July 2011 - 04:18 PM, said:

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

Quote

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.

[dencorso]

rloew, on 13 July 2011 - 06:30 PM, said:

@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!
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.

[Multibooter]

jaclaz, on 14 July 2011 - 03:33 AM, said:

dencorso, on 13 July 2011 - 04:18 PM, said:

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.micro...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/...post__p__970657

This post has been edited by Multibooter: 14 July 2011 - 11:26 AM

[jaclaz]

Multibooter, on 14 July 2011 - 11:23 AM, said:

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


See also this:
http://reboot.pro/13466/


jaclaz

This post has been edited by jaclaz: 16 July 2011 - 01:25 PM

[Multibooter]

jaclaz, on 14 July 2011 - 01:04 PM, said:

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

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

[dencorso]

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

jaclaz, on 14 July 2011 - 01:04 PM, said:

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

rloew, on 03 March 2010 - 11:54 PM, said:

dencorso, on 03 March 2010 - 10:40 PM, said:

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.

Attached File(s)

•  Empty_FAT12_SFloppy_Zip100_F8.7z (14.59K)
  Number of downloads: 13

[jaclaz]

@dencorso
Good.
Everything seems more clear.
The big difference in calculations was the 1.5 bytes (FAT12) vs. the 2 bytes (FAT16)
I still think though that *somehow* using the "large sectors" field represents cheating 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

This post has been edited by jaclaz: 16 July 2011 - 01:25 PM

[dencorso]

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

Attached File(s)

•  Empty_10sec_FAT12_SFloppy_Zip100.7z (14.6K)
  Number of downloads: 10

[Multibooter]

dencorso, on 15 July 2011 - 12:24 AM, said:

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.

Attached File(s)

•  differences_original_vs_cloned_zip_disk.gif (7.11K)
  Number of downloads: 14

This post has been edited by Multibooter: 15 July 2011 - 04:11 AM

[jaclaz]

@dencorso
As often happens, yes and no.
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

[Multibooter]

jaclaz, on 15 July 2011 - 07:09 AM, said:

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

[rloew]

jaclaz, on 15 July 2011 - 01:35 AM, said:

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

[dencorso]

I've done my best to split the CD floppy emulation without mangling either part.
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.

Attached File(s)

•  Empty_10sec688d_FAT12_SFloppy_Zip100.7z (14.61K)
  Number of downloads: 10

[jaclaz]

rloew, on 15 July 2011 - 12:02 PM, said:

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

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

• DOS <3.3
  
• DOS 3.3
  
• DOS 4.0
  
• DOS <=6.22
  
• 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".

jaclaz

This post has been edited by jaclaz: 16 July 2011 - 01:24 PM

[rloew]

jaclaz, on 16 July 2011 - 10:11 AM, said:

rloew, on 15 July 2011 - 12:02 PM, said:

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

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

• DOS <3.3
  
• DOS 3.3
  
• DOS 4.0
  
• DOS <=6.22
  
• DOS >= 7.0

on a set of 01/04/06/0C 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

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

jaclaz

Of course I was referring to the later DOS Versions. The early ones had many limitations.
DOS 3.3 would be limited to 32MB.
Superfloppies and CD Floppy Emulations do not use Partition Codes, so that issue does not apply.
The Partition Type for the LBA version of FAT16 is 0x0E not 0x0C. Type 0x0C is the LBA Version of FAT32.

[jaclaz]

rloew, on 16 July 2011 - 01:17 PM, said:

The Partition Type for the LBA version of FAT16 is 0x0E not 0x0C. Type 0x0C is the LBA Version of FAT32.

Yes, my bad corrected in previous post(s))

jaclaz

[dencorso]

Well, since the 100 MB image works OK in a real Zip100, I think the next step would be to create a bootable FAT-12 128 MB SD card and boot from it, for us to have an air-tight proof-of-concept that the real limit of FAT-12 is 128 MB. This may take some time, because 128 MB are not findable around here anymore... I'm going to get a good one, preferably a SanDisk or a Transcend from eBay. When I get it, I'll post my results. Would Bart PE or LiveXP boot from FAT-12? Can the FAT-16 NT boot sector be coerced to work with FAT-12? Seeing how FAT-12 and FAT-16 share code, I bet it would. What do you all think about it?

[rloew]

dencorso, on 16 July 2011 - 05:41 PM, said:

Well, since the 100 MB image works OK in a real Zip100, I think the next step would be to create a bootable FAT-12 128 MB SD card and boot from it, for us to have an air-tight proof-of-concept that the real limit of FAT-12 is 128 MB. This may take some time, because 128 MB are not findable around here anymore... I'm going to get a good one, preferably a SanDisk or a Transcend from eBay. When I get it, I'll post my results. Would Bart PE or LiveXP boot from FAT-12? Can the FAT-16 NT boot sector be coerced to work with FAT-12? Seeing how FAT-12 and FAT-16 share code, I bet it would. What do you all think about it?

You can always create a smaller Partition than the Device size, or use a Hard Disk Partition for proof of concept.
Non-Bootable Partitions can be as much as 256MB without Patching DOS, although some utilities don't work.

The NT Boot Sector may be modifiable to support FAT12 but I suspect that NTLDR will not work

[dencorso]

rloew, on 16 July 2011 - 06:06 PM, said:

The NT Boot Sector may be modifiable to support FAT12 but I suspect that NTLDR will not work.

Well, that's a can-of-worms I'm saving for later.
I can always hope NTLDR will work, until proven wrong by a test.
But first we must know whether the boot sector will find NTLDR, to give it a chance to work (or fail)...