• Announcements

    • xper

      MSFN Sponsorship and AdBlockers!   07/10/2016

      Dear members, MSFN is made available via subscriptions, donations and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. Alternatively, become a site sponsor and ads will be disabled automatically and by subscribing you get other sponsor benefits.
dencorso

On Superfloppies and their Images

162 posts in this topic

Wow! Does it require a DDO, or just modding the bootstrap loader and IO.SYS can get it to boot?

0

Share this post


Link to post
Share on other sites

I had not quite grasped it was a single sided format (silly me!), but the 0xFA format is also in Thom Hogan's handbook, which relevant table I reproduced here. I think no format can be more officially recognized by MS than one which has its own Media Type Byte, so for me that's more than settled.

0

Share this post


Link to post
Share on other sites

Wow! Does it require a DDO, or just modding the bootstrap loader and IO.SYS can get it to boot?

To read or Write a 1K Sector Disk only requires a TBPLUS IO.SYS with one small Mod and a tiny Startup Program.

I have not yet succeeded in booting yet. A DDO probably will be required as the BIOS reports incorrect Geometry, and the BIOS is not correctly handling DMA wrap.

A 512B Bootstrap Sector is needed to switch the Disk Controller as the BIOS will not read 1K Sectors during Boot. I made a custom Format by adding one 512B Sector to the nine 1K Sectors on Track 0 Head 0. This creates 2 separate #1 Sectors, one 512B and one 1K. The DDO will go into the Bootstrap Sector.

0

Share this post


Link to post
Share on other sites

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.

Edited by rloew
0

Share this post


Link to post
Share on other sites

Not-necessarily OT...

...The MS standard (fatgen.pdf v. 1.03) has BPB_TotSec16 for BPB+0x10 and BPB_TotSec32 for BPB+0x1D...
I've beat my brains out over the Dell Utility/Recovery partitions MBR/PBR (using goodell's info). A worthy note is a "Sector 18" copy of some of the MBR (the Partition Table). Amazingly, the sectors AFTER the first Sector of the Partition (those "reserved" -NOT HIDDEN- sectors) is NOT 32, but rather 38!!!

If you search on "fatgen102" as opposed to using the kind-of CURRENT "fatgen103" the information, albeit a slight older, kind of helped me figure it out. They have many a warning about "false assumptions" (e.g. "how to REALLY identify fat12-fat16/fat32). Of course, you all may already know this...

edit - durr!!!

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 since the dang things are hard to find and rather expensive. :(

Thread subscribed...

Edited by submix8c
0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
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
0

Share this post


Link to post
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
0

Share this post


Link to post
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.

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
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

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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.

0

Share this post


Link to post
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

0

Share this post


Link to post
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
0

Share this post


Link to post
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.

0

Share this post


Link to post
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

0

Share this post


Link to post
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

Actually they don't say there is a problem having more than 512 Entries, at least in this particular Article. They just assume that only 512 Entries are allocated, which obviously limits the number of files. I would not be surprised if many applications exist that would choke on more than 512 since all standard Formatters set 512 or less. It might be interesting to determine the absolute limit. it is easy for me to setup any limit I choose.

You are not the only one who has reviewed his writing multiple times and missed the same typo every time. I have done it too. As more and more Authors self-publish, there is going to be less and less review.

EDIT: The absolute limit appears to be 4096 Root Directory Entries. I have seen evidence that the Sector Offset into the Root Directory is limited to a Byte.

Edited by rloew
0

Share this post


Link to post
Share on other sites

OT :ph34r:, but just to keep things together as possible, the opposites of superfloppies (would they be "underfloppies"? :unsure::w00t: )

http://reboot.pro/8752/page__st__59

(I just happened to get by chance on that thread again, that I had completely forgotten)

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Not underfloppies, no. :)

Subfloppies, of course! :P

But... that'd mean something with a total space less than 160 KB...

0

Share this post


Link to post
Share on other sites

But... that'd mean something with a total space less than 160 KB...

Exactlly, the "smallest" subfloppy (but with "large" capacity) I managed to produce has only 2560 bytes free, but is pretty FAST ;) in loading to --mem with grub4dos....

4096 bytes total size, gzips in 246 bytes. :thumbup

I might review it at the light of the new findings on this thread an maybe I can find a way to make it even smaller. :unsure:

jaclaz

Edited by jaclaz
0

Share this post


Link to post
Share on other sites

Hey, kids, noone wanting to play with me anymore? :(

I am almost finished with the spreadsheet :whistle: , but I just got a doubt. :unsure:

The three bytes jump code is actually part of the CODE and NOT of the BPB, right?

I mean, if I want to make a non-bootable bootsector :w00t: those three bytes should be 00 00 00, and ONLY when I decide to apply the bootsector CODE, then they will get (examples):

EB 3C 90 (MS)

EB 3C 90 (FREEdos)

EB 58 90 (some other bootsectors)

etc.

Or do you think that by default (if NO code is chosen) I should put a non-bootable bootsector code?

Same question goes for the "Magic Bytes" 55 AA:

http://linuxgazette.net/issue84/dashti.html

are they used only if the bootsector is bootable (thus CODE) or they define the sector as a bootsector (and thus they should also be 00 00 by default)?

Suggestions for a Public Domain or however freely redistributable bootsector code that can print a message (or display an image) welcome.

JFYI, I have also started working on a few batches, and then stopped and then started again....., and again, and again....

....I will do such things, ....

....What they are, yet I know not: but they shall be

The terrors of the bootsectors :ph34r:

jaclaz

0

Share this post


Link to post
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.