Jump to content

On Superfloppies and their Images


dencorso

Recommended Posts

I have succeeded in booting the 1K Floppy with a 512B Bootstrap Sector without a DDO using a heavily modified IO.SYS. A DDO should allow using an unmodified TBPLUS IO.SYS.

Using 4K Sectors, it may be possible to Format 1.92MB.

1.92MB turned out to be a little too optimistic. I only succeeded in creating a 1.6MB Bootable Floppy and that was with 1K Sectors.

Link to comment
Share on other sites


Is anyone able to post up a boot image that makes a 20mb boot floppy? It needs to be able to be booted by dos and run a dos program. I'll be using windows 98 boot files (io.sys etc).

I've tried to accomplish this myself but the information I'm finding on the net, tbh is just not helpful or a bit beyond me :(

All I want to do is have a image file i can add/remove stuff from that will boot and is not constrained by the 1.44/2.88mb size limit.

I've tried that 32mb superfloppy image that was in a thread here but can't get it to boot successfully in vmware.

Edited by pengo
Link to comment
Share on other sites

Is anyone able to post up a boot image that makes a 20mb boot floppy? It needs to be able to be booted by dos and run a dos program. I'll be using windows 98 boot files (io.sys etc).

I've tried to accomplish this myself but the information I'm finding on the net, tbh is just not helpful or a bit beyond me :(

All I want to do is have a image file i can add/remove stuff from that will boot and is not constrained by the 1.44/2.88mb size limit.

I've tried that 32mb superfloppy image that was in a thread here but can't get it to boot successfully in vmware.

Has the needed image grown in size?

It was 12 Mb until recently.... :whistle:

This thread has been split from the other one (on which you ALREADY posted and I just replied to you):

(please, never, never, NEVER double post) in an attempt to better focus each one.

We already got the idea of your problem there is no need to post on BOTH therads (AND on 911CD), rest assured we will try and help you, BUT ONLY in one place (and right now it seems to me like the "right" one is the new thread you started on 911CD):

http://www.911cd.net/forums//index.php?showtopic=24618&hl=

Let's avoid "polluting" several threads with bit and pieces and keep everything together, OK? :)

jaclaz

P.S.: I see that there is now also a thread on reboot.pro ALSO :w00t::

http://reboot.pro/15784/

Edited by jaclaz
Link to comment
Share on other sites

This is just to remind you that WinImage may not be the best tool to populate a superfloppy.

When I tried, it messed-up that good 36MiB blank superfloppy image, and yielded nothing useful. It sure merits further investigation, which I didn't yet do. But, be that as it may, VDM is the way to go to populate the image, because we do know for sure that VDM works.

Here's what I did, using the tools I already had, and a lot of patience:

(i) Tried to populate my original image with WinImage, but the result had messed-up FATs and was unbootable. I may have been unlucky in this attempt, but I did not stop to test whether WinImage always blorks the FATs or if it indeed was an unfortunate run.

(ii) Tried to populate my original image using jaclaz's VDM, which relies on Ken Kato's VDK, and this worked like magic! Then I run Win XP's chkdsk on it and it reported no problems.

(iii) Proceeded to boot the image directly with grub4dos, and succeeded. Then, while booted from the image, run MS-DOS SCANDISK (from Win ME) on it, and it found no problems. Here's the relevant excerpt of my MENU.LST:

title RRL 36MiB

find --set-root --ignore-floppies /boot_fd.ima

map /boot_fd.ima (fd0)

map --hook

rootnoverify (fd0)

chainloader --force (fd0)+1

@pengo:

Cross-posting (on different forums) and specially double-posting (on different threads) only irritates the very people whose help you're seeking, so it should be avoided.

Link to comment
Share on other sites

  • 3 weeks later...

An update.

Please find attached a .xls with the "FINAL" list of "known Floppy Formats".

It would be appreciated if the values in them were checked by someone else than me.

The real news (though probably very few people will appreciate the importance of them :ph34r:) is that with some patience (and a couple mindboggingly complex :angel Excel Formula's ;)) I have (hopefully) transformed the table/list from "static" to "dynamic", in the sense that the three fields:

  1. Sector(s) per FAT
  2. Sector(s) per Cluster
  3. Root Entries

Are now calculated even for "known floppy formats" (and they actually seem like OK :thumbup ).

Checks, tests, opinions, etc. are welcome. :)

In the spreadsheet there is also a "temporarily" added sheet about the 4078/4084 and 65518/65524 issue, after reviewing a bit the sources, it seems to me like the lower values are some kind of "myth" :w00t: that perpetuated itself by cross-referencing sources (involving also the good Linux guys for some time :whistle: ).

My choice is to use ECMA 107:

ECMA 107: 4,084/65,524

jaclaz

P.S.: Attachment removed, current version attached to post #143

Edited by jaclaz
Link to comment
Share on other sites

Way to go, jaclaz! :thumbup

Now, here are my comments:

1) I do like standards myself, and ECMA 107 is a generally very sane one at that.

However, putting 0x(F)FF0-0x(F)FF5 in use results in a whopping 0.15% gain in maximum size, but *is* less safe.

So, my 2 ¢ here are, let's stick with the "other sources", which, pace ECMA 107, *is* a de-facto standard.

2) There is a misformating in the numeric "0" cells which are adjacent to the ASCII text "'000" cell thoughout the "clusters" page, so that instead of them showing "0", they show "-" (it's just a cosmetic issue, solved using "Format Cell", but since you favor, with good reason, locked worksheets, this should be set right for them to display nicely).

3) Testimage #1 and Testimage #2 are identical.

4) Although the BPB allows it, since the Root Directory Entries is two bytes long, more than 512 255 Root Directory Entries can cause problems, as described in KB120138.

Your worksheet puts to use all that we've learned in our floppy/superfloppy/El-Torito discussions and more, in a wonderful way!

You do rock! :thumbup

Link to comment
Share on other sites

1) I do like standards myself, and ECMA 107 is a generally very sane one at that.

However, putting 0x(F)FF0-0x(F)FF5 in use results in a whopping 0.15% gain in maximum size, but *is* less safe.

So, my 2 ¢ here are, let's stick with the "other sources", which, pace ECMA 107, *is* a de-facto standard.

Having analyzed DOS 7 and Windows 98SE Code, it is safe to use 0x(F)FF0-0x(F)FF5. Windows allows 0x(F)FF6 but DOS does not.

4) Although the BPB allows it, since the Root Directory Entries is two bytes long, more than 255 Root Directory Entries can cause problems, as described in KB120138.

I did not find an issue with more than 255 Root Directory Entries in KB120138. In fact, it describes the norm of 512 Root Directory Entries used on Hard Disks.

Although Floppy Disks typically use less than 255 entries, I don't think it is a limit there either. It would be a waste though, if it isn't a multiple of 16 (for 512 Byte Sectors).

I have yet to find a limit below 65540 for the maximum number of directory entires, except for the total disk size as in the case of floppies.

Link to comment
Share on other sites

On 11/26/2011 at 11:44 PM, rloew said:
I did not find an issue with more than 255 Root Directory Entries in KB120138. In fact, it describes the norm of 512 Root Directory Entries used on Hard Disks.

The known issues are listed in the 1st section ("Symptoms") of KB120138. The "Applies To" section lists specifically Win 95 and Win 98FE as the OSes where those issues are said to happen.

0x(F)FF6 is truly dangerous to allow, as you just pointed out. However, there's still another thing to be considered, that's not on the current worksheet. Whether we agree to 4084 or 4078 as the maximum number of sector, adress of the last cluster will be 4085 or 4079, because we are counting from 2. When one counts from zero, the maximum address will be the total number minus one, but when the counting starts with 2, the maximum address is the total number *plus* one! The same considerations also apply to FAT-16, of course.

KB120138 - Errors Creating Files or Folders in the Root Dir.pdf

Link to comment
Share on other sites

I did not find an issue with more than 255 Root Directory Entries in KB120138. In fact, it describes the norm of 512 Root Directory Entries used on Hard Disks.

The known issues are listed in the 1st section ("Symptoms") of KB120138. The "Applies To" section lists specifically Win 95 and Win 98FE as the OSes where those issues are said to happen.

Using your link to KB120138, I am still not seeing a limit of 255 mentioned anywhere. It does say that on a Hard Disk you will be limited to less than 512 File Names if you use Long File Names.

Link to comment
Share on other sites

To ensure compatibility with MS-DOS, Windows 95 uses a standard file allocation table (FAT) file system. The root directory for a FAT drive has a fixed size and is stored in a fixed location on the disk. All hard disk drives use 32 sectors of 512 bytes each to store the root directory. This limits the root directory on a hard disk drive to 16K: 32 sectors x 512 bytes per sector = 16,384 bytes, or 16K.

Precisely. And 16,384 bytes / 32 bytes per dir entry = 512 entries. The just didn't spell it, but iths there all right. Of course, the entries I've mentioned are short filenames... otherwise, less than 512 files are possible becaus LFNs use more than one 32 byte entry, or, put in a differnt way, they use multiple entries for each file.

Link to comment
Share on other sites

@dencorso

1) NO.

The ECMA is the "right" approach.

If you take some time around you will see that the actual sources for the 4078 are (directly or INdirectly) just:

  1. Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157.
  2. Brian Jenkinson, Sammes, A. J. (2000). Forensic Computing: A Practitioner's Guide (Practitioner Series). Berlin: Springer. pp. 157. ISBN 1-85233-299-9. "...only 2^12 (that is, 4096) allocation units or clusters can be addressed. In fact, the number is less than this, since 000h and 001h are not used and FF0h to FFFh are reserved or used for other purposes, leaving 002h to FEFh (2 to 4079) as the range of possible clusters."

or the Wikipedia article that cites those two.

The good Linux guys evidently trusted this info:

http://www.oldlinux.org/Linux.old/distributions/cnix/FAT.pdf

but later, see here:

http://www.win.tue.nl/~aeb/linux/fs/fat/fat-2.html

they decided to use the "right" value 4084.

I expected (and rloew quickly and kindly complied :thumbup ) some experiments to be carried (I already did a few of them and a F0 through F5 gave no problem whatsoever).

No matter how hard you (and Peter Norton and Brian Jenkinson :whistle: ) stamp your feet, the statement/assumptions that values F0 and F5 are not usable/are reserved has been demonstrated m00t.

On the other hand, it would be easy (for the ones that prefer following this myth) to change the 4084 and 65524 values in the two formulas that contain them, but it would be IMHO "wrong", and besides (notwithstanding) the trifling practical effect of having 6 more or less addressable clusters, it is "philosophically" wrong to perpetuate a mistake.

By the same metrics, using ONLY 1.2, 1.44 or 2.88 images in El_Torito emulation CD's would be "safer", and making several passes to wipe a HD (all 35 of them) would be "failproof", and then I suppose we could all go home and start gardening as a hobby instead of this.....

When (and IF) you (or someone else) will produce an image that gives problems under a "used" (in the sense of common) "recent" (in the sense of NOT a 1990 fork/rewrite of CP/M or SVR4) OS I will gladly modify those two values or provide a "switch" to toggle between 4084/4078 and 65526/65518. :)

2) Well, it's a "temporary sheet anyway, but thanks.

3) Sure, those are just 5 lines with the formulas to experiment a bit, those entered are just "random examples"....

4) This "max 512" or "max 32 sectors" for root entries may be interesting in the "future" main sheet, as a consequence of a switch like:

format behaving as:

  1. DOS x.xx to x.xxx
  2. DOS y.yy to y.yy
  3. Windows 9x ...
  4. Windows NT/2K/XP/2003
  5. Vista :ph34r:
  6. etc.

0x(F)FF6 is truly dangerous to allow, as you just pointed out.

FF6/FFF6 was never obiect of any doubt, it cannot be used. (last character in the previous sentence is a dot or full stop or "period" ;))

I don't get this :unsure::

However, there's still another thing to be considered, that's not on the current worksheet. Whether we agree to 4084 or 4078 as the maximum number of sector, adress of the last cluster will be 4085 or 4079, because we are counting from 2. When one counts from zero, the maximum address will be the total number minus one, but when the counting starts with 2, the maximum address is the total number *plus* one! The same considerations also apply to FAT-16, of course.

The temporary "clusters" sheet has been made in that form EXACTLY to avoid issues with "counting from" as it calculates ALL possible values and subtracts from them those that - for one reason or the other - cannot be used.

As I see it, the next step (the one for which I need some help) would be testing a few "queer" sizes/combinatons on a "real" system and verify that the spreadsheet "simulation" is accurate.

Comeon guys, use your fantasy, think about values that may create an issue, and test them... :)

jaclaz

Link to comment
Share on other sites

BTW, interest in this is because I have two Iomega Zip-100 (IDE-cable type) and a single (apparently foobared by a shop magnet) disk and it would be interesting in "resurrecting" it
Low-level formatting a de-magnetized Iomega zip disk would be a major project, and I have no idea whether it can be done. If your zip disk is not completely bad, you might try to low-level format it with the Iomega SCSI Utilities for DOS (Tools for DOS) [scsiutil.exe] under pure DOS. If that doesn't work, I would buy a new zip disk. Edited by Multibooter
Link to comment
Share on other sites

4) Although the BPB allows it, since the Root Directory Entries is two bytes long, more than 255 Root Directory Entries can cause problems, as described in KB120138.

Precisely. And 16,384 bytes / 32 bytes per dir entry = 512 entries. The just didn't spell it, but iths there all right. Of course, the entries I've mentioned are short filenames... otherwise, less than 512 files are possible becaus LFNs use more than one 32 byte entry, or, put in a differnt way, they use multiple entries for each file.

Your reply doesn't match my question about your earlier statement.

The BPB refers to Root Directory Entries not full Filenames. An entry can contain a Short File Name, or a Long File Name Component, or Volume Label. The maximum number of Files can be anywhere from 24 to 512 depending upon File Name Length with a 512 Entry Root Directory. Your original statement implied that the number of Root Directory "Entries" was limited to 255 (effectively one byte in the BPB).

In my large Sector experiments with 32KB Sectors, I024 Root Directory Entries was the Minimum.

Link to comment
Share on other sites

I never meant to say there were any problems from the POV of the standard. The "Number of Directory Entries" is two bytes, of course, so (if unsigned) 65,525 entries are allowed for. I just wished to point out that MS says there can be compatibility problems (most probably just with deprecated versions of some MS applications) when more than 512 entries are used. Then, I went ahead and typoed, and you cached my typo, as usual. And I was so certain of what I thought I had written, that only at this moment it dawned on me I had written "255" instead of "512". I'm sorry, I really do try to be as clear as best as I can, but more than once my typos conspire against me (and, BTW, that's why works meant for publication must have someone other than the authors revising them before going to press, although, nowadays, it doesn't always happen anymore). Thanks for the heads up! You rock! :thumbup

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