Jump to content

On Superfloppies and their Images


dencorso

Recommended Posts

Some BIOSes (and the one for the Asus A7V600-X is a case-in-point) when set to boot an "USB ZipDisk" will boot a pendrive having an MBR and exactly one partition, regardless of if that partition is active or not, as A: (and, of course, will do so also with a real USB ZipDisk). After the device is booted all sectors preceeding the Partition Boot Record (PBR = the Boot Sector of the given Partition) will be unaccessible. It seems that those BIOSes use the MBR to locate the PBR and then will set it as LBA 0, thus rendering the preceeding sectors unavailable.

So this creates problems to use how a device mounts at boot as a criterion to define floppy-like and HDD-like. I prefer the presence of the MBR makes a device HDD-like and its absence makes it floppy-like, regardless of the way it can boot, for the above reason.

Link to comment
Share on other sites


The "2.88 MB" floppy uses a special FDD, which can create twice the sectors the normal one can.
A 2.88MB floppy belongs rather to the category "superfloppies" than "floppies". Like an LS-120 diskette, an unmodified 2.88MB floppy cannot be read, written to or formatted by a regular floppy drive, and the magnetic media used (Barium ferrite) is different from regular floppies. A 2.88MB floppy disk is similar to an LS-120 diskette: you can stick both into a regular floppy drive, but the regular floppy drive will not be able to do anything useful with it.

I don't like the term "superfloppy", it was probably used more by advertising folks. Here an ad in InfoWorld, of 21-Oct-1991, by Toshiba about their 2.88MB superfloppy http://books.google.de/books?id=2j0EAAAAMBAJ&pg=PA53&lpg=PA53&dq=superfloppy+trademark&source=bl&ots=aAxn4jY2CY&sig=eD7Cyt2GS689rZRr-Apf2n44vUc&hl=de [it's on p.53] The 2.88MB floppy was perhaps the first superfloppy. The term "super floppy" is ambiguous http://www.pcmag.com/encyclopedia_term/0,2542,t=super+floppy&i=52221,00.asp

Imation trademarked "SuperDisk" for their LS-120 diskettes in March 1997 http://electronics.zibb.com/trademark/superdisk/29599892 perhaps because it sounded like the term "super floppy", used by the other companies advertising their wares. BTW, my own memory somehow associates the term superfloppy with Iomega, maybe Iomega used it most effectively in their advertising, e.g. "Check out the new Zip® 250MB USB drive, the latest SuperFloppy solution from Iomega®." http://www.iomega.com/anz/zip_usb250.html

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.
In my ongoing search :( for a software tool to low-level format a bulk-erased LS-120 diskette I checked out a formatting tool called Media Preparation (by Shuttle Technology, Nov.1997, can supposedly low-level format Flopticals http://en.wikipedia.org/wiki/Floptical ), which in the help file contained the following text, not sure whether it helps: "Large Floppy format is a single non-bootable partition. This formatting standard is the de facto Windows 95 standard for removable media and was originally called "Large Floppy" by IBM. The operation involves creating a fresh boot record, root directory and File Allocation Table (FAT). Large formatted media can be read by all operating systems that support FAT file system". Edited by Multibooter
Link to comment
Share on other sites

Wow! :blink:

:huh:

Now, using your common garden-variety FDD as the criterion is something that sure hadn't crossed my mind at all.

Which, BTW, also puts the frontier at 2.0 MiB, the maximum the common drive can format/write/read...

It does make sense, however, I guess. dubbio.gif

Link to comment
Share on other sites

Some BIOSes (and the one for the Asus A7V600-X is a case-in-point) when set to boot an "USB ZipDisk" will boot a pendrive having an MBR and exactly one partition, regardless of if that partition is active or not, as A: (and, of course, will do so also with a real USB ZipDisk). After the device is booted all sectors preceeding the Partition Boot Record (PBR = the Boot Sector of the given Partition) will be unaccessible. It seems that those BIOSes use the MBR to locate the PBR and then will set it as LBA 0, thus rendering the preceeding sectors unavailable.

Yes this is perfectly consistent with "2nd" version of the ZIP, with the ARMD jumper set, see here:

@rloew

Yes, I know what you mean, but the fact a device is mounted a A: or B: may depend on several factors, like BIOS (or bootmanager) and/or actual OS drivers (if any), so it is not an "objective" way unless you actually tried the device on a given machine and you see which letter it gets under a given OS. :unsure:

@Multibooter

Since the ED 3840K floppy (as image) is inside the El-Torito specs, I doubt you can consider it a "super-floppy", after all:

  • it is is inside the specs
  • it is supported by most CD burning or .iso making application
  • the actual hardware "existed" and was produced in great quanitites, I remember a period when ALL original IBM's, desktop and laptop had an ED floppy drive.

As a (completely void of any relevance :ph34r: , but interesting as a reference :thumbup ) example the known bootmanager Syslinux/Isolinux considers these as "normal" floppies, and all the rest as "super" or "queer" ;):

B) If the disk image is less than 4,194,304 bytes (4096K, 4 MB) it is

assumed to be a floppy image and MEMDISK will try to guess its

geometry based on the size of the file. MEMDISK recognizes all the

standard floppy sizes as well as common extended formats:

163,840 bytes (160K) c=40 h=1 s=8 5.25" SSSD

184,320 bytes (180K) c=40 h=1 s=9 5.25" SSSD

327,680 bytes (320K) c=40 h=2 s=8 5.25" DSDD

368,640 bytes (360K) c=40 h=2 s=9 5.25" DSDD

655,360 bytes (640K) c=80 h=2 s=8 3.5" DSDD

737,280 bytes (720K) c=80 h=2 s=9 3.5" DSDD

1,222,800 bytes (1200K) c=80 h=2 s=15 5.25" DSHD

1,474,560 bytes (1440K) c=80 h=2 s=18 3.5" DSHD

1,638,400 bytes (1600K) c=80 h=2 s=20 3.5" DSHD (extended)

1,720,320 bytes (1680K) c=80 h=2 s=21 3.5" DSHD (extended)

1,763,328 bytes (1722K) c=82 h=2 s=21 3.5" DSHD (extended)

1,784,832 bytes (1743K) c=83 h=2 s=21 3.5" DSHD (extended)

1,802,240 bytes (1760K) c=80 h=2 s=22 3.5" DSHD (extended)

1,884,160 bytes (1840K) c=80 h=2 s=23 3.5" DSHD (extended)

1,966,080 bytes (1920K) c=80 h=2 s=24 3.5" DSHD (extended)

2,949,120 bytes (2880K) c=80 h=2 s=36 3.5" DSED

3,194,880 bytes (3120K) c=80 h=2 s=39 3.5" DSED (extended)

3,276,800 bytes (3200K) c=80 h=2 s=40 3.5" DSED (extended)

3,604,480 bytes (3520K) c=80 h=2 s=44 3.5" DSED (extended)

3,932,160 bytes (3840K) c=80 h=2 s=48 3.5" DSED (extended)

Anyway, as said, no problem whatsoever, we can draw "the line" (if needed) wherever you prefer. :)

jaclaz

Link to comment
Share on other sites

I think a line should be drawn, and fast, because it's been too much talk about sticking "this" or "that" format into one standard or another. Is anyone here member of a Standards Association of some sort?! Personally I'm getting more and more confused by all this information which deviates the course of the initial topic: "bootable CD floppy emulation". Since it should be about booting, why don't we focus on BIOS capabilities instead? I've read about some old Dell BIOS versions that wouldn't clear a carry flag, thus malfunctioning in certain situations and there may be other issues that need dealt with. If the purpose of the current topic is still making the largest possible floppy emulation image, then first find a common denominator for BIOS capabilities. I've had machines that wouldn't boot a ISOLINUX CD but would gladly accept Windows 9x or XP install CD. I've had machines that wouldn't boot any Linux flavor. How exactly does BIOS makes the difference between Floppy and HDD (image): is it the media descriptor (IBM's 11111RED byte)? Does it have any internal limitation on the number of C/H/S recognized for a certain media type (aside from or along with LBA/LBA48)?

More questons I have not yet found a definite answers for:

- why, exactly, choose floppy emulation over HDD emulation?

- why, exactly, make a single huge image instead of the classical 1.44/2.88 image plus creating a RAM drive, when the superfloppy wouldn't be writable anyway?

- what file system would be best for such boot image, considering all capabilities as well as limitations of different file systems?

There's probably more questions waiting for an answer, but that's all that came to my mind, for now. As for BootMaker, it'll still take a few days before I can release a safe version, after the changes I've made. That is, if it's still needed, because I haven't yet heard any constructive criticism about it, other than the labeling issue.

Edited by Drugwash
Link to comment
Share on other sites

More questons I have not yet found a definite answers for:

- why, exactly, choose floppy emulation over HDD emulation?

- why, exactly, make a single huge image instead of the classical 1.44/2.88 image plus creating a RAM drive, when the superfloppy wouldn't be writable anyway?

- what file system would be best for such boot image, considering all capabilities as well as limitations of different file systems?

  1. Historically, there have been a number of BIOSes that did have problems with Hard disk emulation. An example is (was? :unsure:) the BOCHS (read Qemu) one:
    http://reboot.pro/3890/
    http://reboot.pro/3890/page__st__46
    but similar issues are more common that you may think, of course mostly on very dated BIOSes.
    DELL's are notoriously a PITA in about everything concerning booting them but also Acer and other makers have their own "queer" things, examples (not directly related, though):
    http://reboot.pro/10503/
    http://reboot.pro/12942/
  2. Because its fun? Because it can be done? :yes: If you mean an actual *need* there isn't any AFAIK, nowadays you can boot a grldr no-emulation CD or a 1.44 floppy emulation one booting grub4dos and you can map almost *anything* to *anything* else. If you want an example of a project that may make use of this, it's here:
    http://reboot.pro/10373/

  3. Given the anyway limited size of the possible image with 2/18 or 2/36 geometry, FAT16 is iMHO a good choice, FAT12 is, as seen, a bit stretched out and FAT32 is pointless (besides not being NT 3.5/4.0 and DOS <=6.22 compatible), whilst NTFS sounds "looking for troubles" (unneededly).

As for BootMaker, it'll still take a few days before I can release a safe version, after the changes I've made.

Take all the time you need (and even more :)) there is no pressure.

That is, if it's still needed, because I haven't yet heard any constructive criticism about it, other than the labeling issue.

Well, right now (I mean the preliminary version you posted) doesn't do much, so it's hard to say how what you added to it in the meantime can be bettered or enhanced.

The posted version, besides Writing capabilities, is missing IMHO what I tried (and still try) to add to the worksheet:

  • a set of pre-configured settings for most (if not all) floppy and "super-floppy" formats
  • a set of suggested settings for the "FREE" formats

Your nice app, unless you add these features (and/or other ones) won't have much more practical functionalities (exception made for a nicer interface :thumbup ) than an existing app, such as Roadkil's BootBuilder:

http://www.roadkil.net/program.php/P3/Boot%20Builder

BTW, your nice program is not necesarily connected to the use of a floppy or super-floppy image on a CD, it could (and should) be IMHO a "general" tool to experiment with floppies and super-floppies.

jaclaz

P.S.: I am attaching last version of the spreadsheet and a small batch that may possible be useful :unsure: (needs dsfo and dumphex)

FAT_make_06.zip

getFAT1xBS.zip

Edited by jaclaz
Link to comment
Share on other sites

I'm getting old and productivity is not that high now so development is slow. However, here's a glimpse of what will be:

post-99477-0-55380700-1312573777_thumb.p

Obviously, I will try my best to create a good editor. All formats in the drop-down list will automatically yield the proper values and the File system dropdown will add the corresponding boot code and - when possible and allowed by the license - also the required files or otherwise prompt for manual addition by the user. At some point I thought of adding a disassembler, but that's still far from becoming a certainty.

I also plan on reading/editing available HDD/FDD/USB boot sectors but that's also far from implementation.

For now it can edit and save .ima images of either floppy or hard disks. Currently, editing can be done at bit and byte level (hex), since I haven't yet found a reliable way for ASCII editing. String editing is also available but it doesn't update the editor window, that's why I haven't released it yet, since it could create big problems.

If anyone has other suggestions, please speak up; I'd be glad to comply, if and when possible.

Link to comment
Share on other sites

@rloew

Yes, I know what you mean, but the fact a device is mounted a A: or B: may depend on several factors, like BIOS (or bootmanager) and/or actual OS drivers (if any), so it is not an "objective" way unless you actually tried the device on a given machine and you see which letter it gets under a given OS. :unsure:

True.

I define Floppy-Like and HD-like based on the way they are handled by DOS and possibly by Windows 9X.

At the Media end, Floppy = Soft, Flexible Media, Hard = Rigid, Non-Flexible Media.

As for Drives and Controllers, I leave it up to the rest of you to fight over definitions.

Official El-Torito Floppy Emulation Images top out at 2.88MB. Extending the Cylinder Count (unofficial, but common in BIOSes) gets you to 36MB.

I called these "Extended" Floppy Images.

So called SuperFloppy Drives typically use IDE or SCSI Interfaces and more resemble Hard Drives. Only by explicit inclusion in a BIOS's or Option ROMS's design can they be Booted as A: Drives. USB Drives are a similar story.

Link to comment
Share on other sites

Obviously, I will try my best to create a good editor... For now it can edit and save .ima images of either floppy or hard disks. ... If anyone has other suggestions, please speak up; I'd be glad to comply, if and when possible.

I like the screen shot of BootMaker. It is a little OT, but would it be possible to turn BootMaker into a track-0-writer for removable media, so that it could, for example, write/re-create track 0 on a bulk-erased/de-gaussed removable media disk, e.g. a bulk-erased LS-120 diskette? Such a tool could be very useful for re-initializing the rare special removable media of dual-format drives in general (e.g. also Floptical, Sony HiFD, Caleb UHD144).

Edited by Multibooter
Link to comment
Share on other sites

@Multibooter: Well, gdisk can do it, but it'll write an MBR there. So hexediting it subsequently would be in order, to create a floppy-like format. And WinHex template editing will let you do it relatively easily by hand. I think even when unregistered WinHex will allow you to do so, but of that I cannot be sure, since I'm a registered user for a real long time already.

Link to comment
Share on other sites

would it be possible to turn BootMaker into a track-0-writer for removable media

That'd be my intention but it'll take quite some time before I figure out all the tricks. The big problem is, I don't have access to any of those pieces of hardware you're talking about., so actual testing would have to be performed by people who do. All I have at hand is a floppy drive removed from an Atari before throwing it away; no idea about it since I never managed to properly connect it to a PC. The boot disk seems to be OK and I just made an image of it; it's in German though.

Don't hold your breath on the direct boot manipulation with BootMaker.

Link to comment
Share on other sites

would it be possible to turn BootMaker into a track-0-writer for removable media

That'd be my intention but it'll take quite some time before I figure out all the tricks. The big problem is, I don't have access to any of those pieces of hardware you're talking about., so actual testing would have to be performed by people who do.

I would be glad to do some testing on my old removable drives/media, just send me a PM.

@dencorso: I posted my 5 cents at so that postings stay focused.

Edited by Multibooter
Link to comment
Share on other sites

I think, with all that's been said about it, till now, that the best divide between floppy and superfloopy remains 4.0 MiB (and no MBR nor partitions, of course).

This little beauty arrived by snail-mail yesterday. Yay! :D

Its true size is 125,960,192 bytes, and it's not quite empty, as there are some patterns written to many sectors, besides the skeleton MBR, PBR and FATs (which are FAT-16). The attached .7z contains a full image of it (acquired with the write lock set, so forensically sound), and a fully blank image of the same size, to help finding fast the non-zero regions, for those using Beyond Compare or analogous utilities.

post-134642-0-34391900-1312611831_thumb.

20110805_128MB_SD_Card.7z

Link to comment
Share on other sites

Obviously, I will try my best to create a good editor... For now it can edit and save .ima images of either floppy or hard disks. ... If anyone has other suggestions, please speak up; I'd be glad to comply, if and when possible.

I like the screen shot of BootMaker. It is a little OT, but would it be possible to turn BootMaker into a track-0-writer for removable media, so that it could, for example, write/re-create track 0 on a bulk-erased/de-gaussed removable media disk, e.g. a bulk-erased LS-120 diskette? Such a tool could be very useful for re-initializing the rare special removable media of dual-format drives in general (e.g. also Floptical, Sony HiFD, Caleb UHD144).

Unless I am mistaken, we then need to draw another line. :w00t:

Are we talking of a DOS track-0-writer (which is doable) or of a Windows NT one (that will get us into the drivers trouble)?

@Drugwash:

and:

http://alter.org.ua/en/soft/win/floppy/

JFYI.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

There are too many utilities that deal with reading/writing the first sector of physical devices. It'd be much more useful to have one outstanding utility capable of writing/reading the first sector of an image and creating boot sectors and MBRs there at will. I would concentrate on that. The ability to create custom images from scratch, in a user-friendly way would also be welcome. Just my 2¢, of course. mkdosfs is limited in that it doesn't bother with creating bootable images.

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