[dencorso]

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

[dencorso]

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.

[rloew]

dencorso, on 02 November 2011 - 12:01 AM, said:

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.

[rloew]

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.

This post has been edited by rloew: 02 November 2011 - 09:34 PM

[submix8c]

Not-necessarily OT...

dencorso, on 11 August 2011 - 04:55 PM, said:

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

This post has been edited by submix8c: 03 November 2011 - 05:52 PM

[rloew]

rloew, on 02 November 2011 - 09:33 PM, said:

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.

[pengo]

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.

This post has been edited by pengo: 09 November 2011 - 10:39 PM

[jaclaz]

pengo, on 09 November 2011 - 10:38 PM, said:

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

This thread has been split from the other one (on which you ALREADY posted and I just replied to you):
http://www.msfn.org/...oppy-emulation/
(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...topic=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 :
http://reboot.pro/15784/

This post has been edited by jaclaz: 10 November 2011 - 03:30 AM

[dencorso]

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.

dencorso, on 19 July 2011 - 05:13 PM, said:

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:

Quote

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.

[pengo]

hey guys, sorry i'm sure you can appreciate how frustrated i was and u get desperate et al... anyway i'm pursuing a solution via whats described here http://reboot.pro/13171/

[jaclaz]

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 ) is that with some patience (and a couple mindboggingly complex Excel Formula's ) I have (hopefully) transformed the table/list from "static" to "dynamic", in the sense that the three fields:

• Sector(s) per FAT
  
• Sector(s) per Cluster
  
• Root Entries

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

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" that perpetuated itself by cross-referencing sources (involving also the good Linux guys for some time ).
My choice is to use ECMA 107:

Quote

ECMA 107: 4,084/65,524

jaclaz

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

This post has been edited by jaclaz: 27 January 2012 - 03:08 AM

[dencorso]

Way to go, jaclaz!

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!

[rloew]

dencorso, on 26 November 2011 - 05:13 PM, said:

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.

Quote

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.

[dencorso]

rloew, on 26 November 2011 - 08:44 PM, 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.

[rloew]

dencorso, on 26 November 2011 - 10:38 PM, said:

rloew, on 26 November 2011 - 08:44 PM, 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.

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.

[dencorso]

Quote

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.

[jaclaz]

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

• Norton, Peter (1986). Inside the IBM PC, Revised and Enlarged, Brady. ISBN 0-89303-583-1, p. 157.
  
• 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....ns/cnix/FAT.pdf
but later, see here:
http://www.win.tue.n.../fat/fat-2.html
they decided to use the "right" value 4084.
I expected (and rloew quickly and kindly complied ) 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 ) 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:

• DOS x.xx to x.xxx
  
• DOS y.yy to y.yy
  
• Windows 9x ...
  
• Windows NT/2K/XP/2003
  
• Vista
  
• etc.

dencorso, on 26 November 2011 - 10:38 PM, said:

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 :

dencorso, on 26 November 2011 - 10:38 PM, said:

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

[Multibooter]

submix8c, on 03 November 2011 - 05:38 PM, said:

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.

This post has been edited by Multibooter: 27 November 2011 - 03:50 PM

[rloew]

dencorso, on 26 November 2011 - 05:13 PM, said:

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.

Quote

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.

[dencorso]

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!