Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

On Superfloppies and their Images

- - - - -

  • Please log in to reply
161 replies to this topic

#1
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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 Files




How to remove advertisement from MSFN

#2
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag
@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.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.

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#3
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

#4
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag


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

Edited by Multibooter, 14 July 2011 - 11:26 AM.


#5
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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, 16 July 2011 - 01:25 PM.


#6
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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.

#7
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

Attached Files



#8
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@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, 16 July 2011 - 01:25 PM.


#9
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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 Files



#10
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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 Files


Edited by Multibooter, 15 July 2011 - 04:11 AM.


#11
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@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

#12
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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

#13
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

@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.
.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#14
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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:

Attached Files



#15
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

jaclaz

Edited by jaclaz, 16 July 2011 - 01:24 PM.


#16
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag


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

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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#17
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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


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

jaclaz

#18
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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?

#19
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

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
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#20
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

#21
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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

Why it shouldn't work?
I mean NTLDR does work on a "normal" FAT12 floppy, I don't see any "normal" reason why the bootsector shouldn't find NTLDR.
Making NTLDR based floppies to boot machines with a corrupted NTLDR or BOOT.INI is (was) a normal task:
http://support.micro...kb/305595/en-us
http://www.xxcopy.com/xxcopy33.htm

jaclaz

#22
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

Well... since we've agreed that a filesystem is a bunch of bytes (or whatever) that can be divided in a System Area and a Data Area (we did agree to that, didn't we?), I'm thinking that there's one more concept I'd like to find a common terminology for:
(i) By looking at the floppy disk format list I posted, we can easily see that the maximum a common "1.44 MB" FDD can actually format is a 83 * 21 * 2 * 512 floppy, which means 1,784,832 bytes or 1.70 MiB (before adding the filesystem), the so called "1.74 MB" floppy.
(ii) The "2.88 MB" floppy uses a special FDD, which can create twice the sectors the normal one can.
So I conclude that the most extreme floopy format possible (although I've never heard about anyone ever having formatted a floppy like this) should be a 83 * 42 * 2 * 512 floppy, which means 3569664 bytes or 3.40 MiB (before adding the filesystem), which might be called a "3.49 MB" floppy.
Hence, I propose that we use floppy disk format or floppy disk image to refer solely to formats or images having up to 3.5 MiB of total capacity, and that anything above that should be called a superfloppy. Of course, floppy formats or images must represent a single device, starting in a boot sector (or be fully zeroed). Of these, all that have a capacity >= "1.44 MB" would receive a Medium Type Byte = 0xF0.
Anything having a MBR and partitions (regardless of being a ZipDisk, a pendrive, or other hardware, or their respective images) would be called a "hard disk image/device" or "hard-disk-like image/device", and have Medium Type Byte = 0xF8.
Please let me know your opinion.

#23
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,108 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

Well... since we've agreed that a filesystem is a bunch of bytes (or whatever) that can be divided in a System Area and a Data Area (we did agree to that, didn't we?), I'm thinking that there's one more concept I'd like to find a common terminology for:
(i) By looking at the floppy disk format list I posted, we can easily see that the maximum a common "1.44 MB" FDD can actually format is a 83 * 21 * 2 * 512 floppy, which means 1,784,832 bytes or 1.70 MiB (before adding the filesystem), the so called "1.74 MB" floppy.
(ii) The "2.88 MB" floppy uses a special FDD, which can create twice the sectors the normal one can.
So I conclude that the most extreme floopy format possible (although I've never heard about anyone ever having formatted a floppy like this) should be a 83 * 42 * 2 * 512 floppy, which means 3569664 bytes or 3.40 MiB (before adding the filesystem), which might be called a "3.49 MB" floppy.
Hence, I propose that we use floppy disk format or floppy disk image to refer solely to formats or images having up to 3.5 MiB of total capacity, and that anything above that should be called a superfloppy. Of course, floppy formats or images must represent a single device, starting in a boot sector (or be fully zeroed). Of these, all that have a capacity >= "1.44 MB" would receive a Medium Type Byte = 0xF0.
Anything having a MBR and partitions (regardless of being a ZipDisk, a pendrive, or other hardware, or their respective images) would be called a "hard disk image/device" or "hard-disk-like image/device", and have Medium Type Byte = 0xF8.
Please let me know your opinion.

Guess again. Amigas Format 1802240 Bytes on a HD (1.44MB) Floppy using their standard Format. Non-Standard formats can easily reach 1966080 Bytes or more.

USB Drives can be used with or without a MBR. They still use 0xF8.

I think that 0xF0 is needed for Floppy-like Drives (Drives that mount as A: or B:). Otherwise use 0xF8.
DOS 7 handles A: and B: Drives differently than C: or higher.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#24
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,023 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

OK. Except for formats having their own 0xFX code, 0xF0 for what will become A: or B: and 0xF8 for all other cases is a rule-of-thumb that makes sense to me.
However, 1966080 Bytes is 1.88 MiB, which is still < 3.5 MiB... and I don't think Amigas can use a "2.88 MB" drive.
Or are you suggesting we should put the floppy/superfloppy frontier at 4 MiB GiB? What is a superfloppy for you?
Please elaborate.

#25
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

OK. Except for formats having their own 0xFX code, 0xF0 for what will become A: or B: and 0xF8 for all other cases is a rule-of-thumb that makes sense to me.
However, 1966080 Bytes is 1.88 MiB, which is still < 3.5 MiB... and I don't think Amigas can use a "2.88 MB" drive.
Or are you suggesting we should put the floppy/superfloppy frontier at 4 MiB GiB? What is a superfloppy for you?
Please elaborate.

There is the 2M formats too. :unsure:
http://en.wikipedia.org/wiki/2M_(DOS)

the max capacity on ED disks is

~4,100,000 bytes (4004 KiB)

(4 Gib is seemingly a bit too much ;) :whistle:)

+------------------------------------+
                                 ¦   Double  ¦   High    ¦ Extrahigh  ¦
 +-------------------------------+-----------+-----------+------------+------+
 ¦ Absolute record before 2M     ¦  820.0 Kb ¦ 1394.0 Kb ¦     --     ¦      ¦
 ¦ Maximum 2M capacity (2MF /M)  ¦  902.0 Kb ¦ 1558.0 Kb ¦     --     ¦ 5.25 ¦
 ¦ Minimum 2MGUI capacity        ¦  976.6 Kb ¦ 1639.8 Kb ¦ 1203.1 Kb  ¦ (5¼) ¦
 ¦ Physical limits (82 tracks)   ¦ 1001.0 Kb ¦ 1668.2 Kb ¦ 1228.8 Kb  ¦      ¦
 +-------------------------------+-----------+-----------+------------+------¦
 ¦ Absolute record before 2M     ¦  984.0 Kb ¦ 1722.0 Kb ¦ 2880.0 Kb  ¦      ¦
 ¦ Maximum 2M capacity (2MF /M)  ¦ 1066.0 Kb ¦ 1886.0 Kb ¦ 3772.0 Kb  ¦  3.5 ¦
 ¦ Minimum 2MGUI capacity        ¦ 1176.0 Kb ¦ 1972.0 Kb ¦ 3944.0 Kb  ¦ (3½) ¦
 ¦ Physical limits (82 tracks)   ¦ 1201.2 Kb ¦ 2002.0 Kb ¦ 4003.9 Kb  ¦      ¦
 +---------------------------------------------------------------------------+

jaclaz




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users