I have uploaded an alternative superfloppy image.
Differences with your previous superfloppy geometry:
Your superfloppy (in UBCD52a3):
Heads_Amount: 2 (0-1)
Cylinders_Amount: 512 (0-511) <== (too big for floppies in MSDOS)
New superfloppy (linked to download, keep reading):
Heads_Amount: 16 (0-15)
Cylinders_Amount: 32 (0-31)
The new image is smaller and compatible with ATA and BIOS geometry standards. It should be (unnoticeable) more efficient (only one FAT copy) and it wastes less space (only one FAT copy, less unnecessary root entries, and smaller cluster size).
The amount of Root Directory Sectors currently really necessary is 1 (one), and one only. The reason to have more than one Root Sector is to complete the last cylinder of the image. Using complete cylinders helps reduce potential incompatibilities.
The new image was already tested (by me) to support the current requirements for size and amount of files, and its geometry is correctly identified by memdisk and by grub4dos.
I would also suggest to consider the potential “pros” and “cons” of changing the APPEND line in the syslinux menu for the memdisk fdubcd boot entry,
from the current:
APPEND raw floppy
APPEND raw floppy c=32 h=16 s=63
or even to:
APPEND raw floppy c=32 h=16 s=63 ro
I shall be clear; I am not convinced that adding all those parameters is really necessary. It may help in some case, but if the geometry is changed then the entry should be corrected accordingly (or if someone wants to use the image uncompressed and not read-only). In most systems, the additional APPEND parameters should not be necessary. The only reason I would consider them is for some (whether too old or too new) buggy BIOS, so probably the best compromise would be something like the following lines (one effective line, and two lines commented out):
APPEND raw floppy
# If the above fails, try adding some additional parameters
# APPEND raw floppy c=32 h=16 s=63 ro
In any case, this new image should be tested in as many systems as possible, from CD and from UFD.
Additionally, in my image:
Volume Label: FDUBCD_147 (The underscore is for aesthetic reasons for utilities that can display the volume label as file name and extension, "FDUBCD_1.47", instead of “FDUBCD14.7”.)
Boot code source: sys.com version 3.8pre2012MAY11
OEM String: FRDOS5.1 (as used in latest format.com and sys.com 3.8pre).
Serial Volume: all zeroes (It is a RAM read-only superfloppy. There is no utility to other serial volume values, and using all zeroes helps its compression).
Empty data clusters are filled with “F6” for better compatibility with floppy tools.
The initial (non-bootable) geometry of the FAT12 image can be achieved by several methods, including mtools version 4.0.17 (either under Linux, or using the Windows port from Icecube).
In this opportunity, I happened to use different tools, not mtools, but mtools is capable of building this exact CHS geometry and the FAT12 fs.
It should be noted that there are other alternative geometries that can successfully serve as superfloppy image for fdubcd; each with its own advantages and disadvantages.
The file name of the uncompressed image I have uploaded is already fdubcd.img. To avoid accidental overwriting, I changed the name of the compressed gzipped image, from "fdubcd.img.gz", to "FDUBCD_147-32256.img.gz". So after downloading the gzipped image, you can just change its name back to "fdubcd.img.gz" and build a new UBCD test for you.
The file will be available for the next 7 days at:
http://www.fileconvoy.com/dfl.php?id=g8 ... 82970ac679
SIZE: 14'187'395 bytes (13.53 MiB)
If you have any questions, please don't hesitate to ask.
I'll be posting any feedback / reports I may find in UBCD 52a3 in the public forum, specially if I find something about fdubcd.
EDIT / UPDATE:
I just tested the build of mtools 4.0.17 that Icecube made for Windows users, and for replicating my image (in fact, generating one image anew), a FAT12 image with the suggested geometry, it has some problems in the resulting image. I don't know if the Linux version has / generates those problems too.
On one side, it is a good thing that I used a different method for my image (the one I uploaded), because the result is a nice, clean, correct, valid, bootable FAT12 superfloppy image. On the other side, providing a simple mtools command is not enough to replicate this geometry accurately enough, so now I have to think of a simple step by step method for you to replicate it, unless you are able to do it by yourself with your own tools.