Jump to content

Welcome to MSFN Forum
Register now to gain access to all of our features. Once registered and logged in, you will be able to create topics, post replies to existing threads, give reputation to your fellow members, get your own private messenger, post status updates, manage your profile and so much more. This message will be removed once you have signed in.
Login to Account Create an Account



Photo

On Superfloppies and their Images

- - - - -

  • Please log in to reply
161 replies to this topic

#26
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,109 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

OK. Except for formats having their own 0xFX code, 0xF0 for what will become A: or B: and 0xF8 for all other cases is a rule-of-thumb that makes sense to me.
However, 1966080 Bytes is 1.88 MiB, which is still < 3.5 MiB... and I don't think Amigas can use a "2.88 MB" drive.
Or are you suggesting we should put the floppy/superfloppy frontier at 4 MiB GiB? What is a superfloppy for you?
Please elaborate.

There never was a "2.88 MB" drive for the Amiga, but the principles used can be applied to the PC. I'm not sure that you can put three 8KiB Sectors in a single track but I think you probably can put one 16KiB Sector and one 8KiB Sector on a track. It is possible to put one 24KiB Sector on a track but you would need to do Error Detection in software.
Even putting 11 1KiB Sectors per track would achieve 3.52MB.

I never thought about the distinction between floppies and superfloppies. I always treated standard floppy formats as "floppies", anything else as "superfloppies", or I suppose possibly "subfloppies". I have never used a superfloppy. I called the up to 36MB El-Torito Images "extended floppies" as they use the standard floppy Geometry except for the number of Cylinders.
Only the A:/B: vs. C: distinction is really important.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.


How to remove advertisement from MSFN

#27
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

To me, common floppies formatted to 32 MB by LS-240 drives and those 40 MB click! from Iomega are superfloppies already. So the 36 MiB FAT-12 image we are discussing from the start of this thread *is* a supperfloppy image, not a floppy image. And it'll get A: on boot, and it has a single logical device starting in a boot sector, so it has all the characteristics of a floppy (or superfloppy). And that's why the original thread had superfloppies in the name, which ended up causing the split of the original thread into two threads. But then it dawned on me that it's not at all clear what idea each of the participants in this discussion has about what is a superfloppy. And I realized that not even to me it's actually clear how big a floppy may become, before starting to be a superfloppy. So I posted about reaching a consensus about it. It was relevant enough to cause a thread split, even if it may be irrelevant for practical purposes (I mean: actual usage or the way they are seen by any given OS).

#28
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
If we have to draw a line somewhere, I would draw it, as hinted, right after the 2M 4003.9 Kb size, since that is "the biggest floppy you can have on actually largely mass produced hardware using standard floppy media" (a bit lousy as definition :ph34r:, but not worse than many others :whistle: ).

While the LS-120 did have some diffusion, the LS-240 had so short a lifetime that the actual numbers are really low AFAIK (and only the LS-240 could make the 32 Mb floppy).

But I am with rloew, to me *anything* which first sector is a MBR and holds a partition table is a "HD-like device" and *anything* which first sector is a bootsector is a "floppy-like device".

jaclaz

#29
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

OK. But the table you provided is for 82 tracks. And almost all FDD made after 2000, including my quite unremarkable Samsung SFD-321B Rev. T4 (manufactured in Feb 2002), and the Mitsumi D359T7 I've just decomissioned, are capable of formatting/writing/reading 83 tracks reliably. This pushes up the max capacity on ED disks to ~4,150,000. Then I think 4.0 MiB as a round-number limit is a good number, after all. Can we agree on using it to define the frontier between floppy and superfloppy?

Attached Files



#30
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,109 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

To me, common floppies formatted to 32 MB by LS-240 drives and those 40 MB click! from Iomega are superfloppies already. So the 36 MiB FAT-12 image we are discussing from the start of this thread *is* a supperfloppy image, not a floppy image. And it'll get A: on boot, and it has a single logical device starting in a boot sector, so it has all the characteristics of a floppy (or superfloppy). And that's why the original thread had superfloppies in the name, which ended up causing the split of the original thread into two threads. But then it dawned on me that it's not at all clear what idea each of the participants in this discussion has about what is a superfloppy. And I realized that not even to me it's actually clear how big a floppy may become, before starting to be a superfloppy. So I posted about reaching a consensus about it. It was relevant enough to cause a thread split, even if it may be irrelevant for practical purposes (I mean: actual usage or the way they are seen by any given OS).

I wanted the CD Floppy Emulation thread to be distinct from the SuperFloppy thread because it is about El-Torito Floppy Emulation on Optical Media. There are different considerations for these than there are for other Floppy-Like Devices such as the LS-120, LS-240, Clik etc. It was not about size. I pushed the El-Torito limit in Post #1. Now I have determined that there is no real limit.

But I am with rloew, to me *anything* which first sector is a MBR and holds a partition table is a "HD-like device" and *anything* which first sector is a bootsector is a "floppy-like device".

That is not what I said. I said Devices that Mount as A: or B: are Floppy-Like. Devices that Mount as C: or above are HD-Like.
USB Drives generally Mount as C: or above, so are HD-Like, but they can use a MBR or not use a MBR.
I will agree that a Drive that uses a MBR is HD-Like because it cannot be Mounted as A: or B:, but the Converse is not necessarily true.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#31
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#32
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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....pf2n44vUc&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...&i=52221,00.asp

Imation trademarked "SuperDisk" for their LS-120 diskettes in March 1997 http://electronics.z...erdisk/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.co...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, 05 August 2011 - 01:12 AM.


#33
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

#34
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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:
http://www.msfn.org/...et-of-floppies/

@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

#35
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,262 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag
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, 05 August 2011 - 10:33 AM.


#36
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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?


  • 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/
  • 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/
    http://www.msfn.org/...project-update/
  • 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.n...P3/Boot Builder

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)

Attached Files


Edited by jaclaz, 05 August 2011 - 11:52 AM.


#37
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,262 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag
I'm getting old and productivity is not that high now so development is slow. However, here's a glimpse of what will be:
Attached File  v5_preview.PNG   96.37KB   13 downloads
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.

#38
rloew

rloew

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,109 posts
  • Joined 30-May 05
  • OS:98SE
  • Country: Country Flag

@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.
Ye who enter my domain. Beware! Lest you become educated in the mysteries of the universe and suffer forever from the desire to know more.

#39
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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, 05 August 2011 - 04:04 PM.


#40
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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

#41
Drugwash

Drugwash

    MSFN Expert

  • Member
  • PipPipPipPipPipPip
  • 1,262 posts
  • Joined 21-June 06
  • OS:98SE
  • Country: Country Flag

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.

#42
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

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 http://www.msfn.org/...post__p__973019 so that postings stay focused.

Edited by Multibooter, 05 August 2011 - 06:42 PM.


#43
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

Attached Files



#44
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag

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:
http://www.msfn.org/...98/page__st__60
and:
http://alter.org.ua/...oft/win/floppy/
JFYI.

jaclaz

Edited by jaclaz, 06 August 2011 - 01:45 AM.


#45
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

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.

#46
jaclaz

jaclaz

    The Finder

  • Developer
  • 14,675 posts
  • Joined 23-July 04
  • OS:none specified
  • Country: Country Flag
@all
Can you please review the attached version of the spreadsheet?
I added a tentative way of "classification" and naming and an example .ini, as I am thinking we can use a .ini file to create a "database" of known formats and/or let the user choose only a subset of the available and/or have a common "interchange" format between different utilities/scripts.

Please do review the "known" values and the "ranges" besides the actual "naming proposal", and let me know of any mistake, missing piece or whatever you think about the idea. :angel

Please :), no comment/proposal involving directly or indirectly any of:
  • access (or any other database format)
  • xml :w00t:
  • java
  • .net :ph34r:

jaclaz

Attachment removed, see a few posts below.

Edited by jaclaz, 08 August 2011 - 02:41 AM.


#47
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

There are too many utilities that deal with reading/writing the first sector of physical devices.

For regular floppies and hard disks, yes. For removable media of the "SuperFloppy" type, >2.88MB, NO. Their drives, when used internally, use the hard disk controller, not the onboard floppy disk controller.

How about experimenting with bulk-erased Iomega zip disks, to see whether any of these floppy disk utilities can write track 0 on a bulk-erased/de-gaussed Iomega zip disk? I just bulk-erased an Iomega zip disk, to see what happens. In My Computer, on the context menu of the Iomega removable drive, the selections of Iomega Format, Iomega Protect and Iomega Eject were greyed out. And the Iomega tab in the drive properties sheet displayed: Disk Type: No disk inserted, even if the de-gaussed zip disk was in the Iomega zip drive. Perhaps the de-gaussed zip disk can be revived with the manufacturer-specific Iomega SCSI Utilities under DOS. Good luck.

The Iomega zip 100 drive is single-format only, i.e. it accepts only 100MB zip disks, the drive doesn't have to decide on which type of media is inserted. On dual-format drives ( e.g. LS-120 for 1.44MB/120MB diskettes, or Caleb drives for 1.44MB/144MB diskettes) writing track 0 onto a de-gaussed diskette may be even trickier, and there are no manufacturer-provided utilties for re-initialization of diskettes, at least as far as I know.

A track-0-writer should be able to write on degaussed removable media, so that eventually any super disk image, even with changes in media type and other info on track 0, can be written back to the physical media of the appropriate capacity. If I have an image, I want to be able to write it back to the media.

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.

GRDuw can create image files of probably most removable media, but can only restore a few image types, if it likes track 0 of the image and track 0 on the target media. GRDuw, for example, cannot write back the image of a 100MB zip disk to a de-gaussed 100MB zip disk, err msg: "Checking disk media ... Please insert a disk", even if the de-gaussed zip disk was inserted.

Edited by Multibooter, 07 August 2011 - 02:55 PM.


#48
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

AFAIK, GDISK can do it on DOS, Win 9x/ME and Win XP. WinHex can do it on Win 9x/ME (sometimes) and Win XP.
Under DOS or Win 9x/ME, any fully zeroed/randomized device that Windows cannot mount but which respond to SCSI commands can be recovered by Adaptek's AFDISK 3.34. Both AFDISK and GDISK will create an MBR and a HDD structure, but that can be changed afterwards, when Windows is already capable of mounting the device, by using WinHex or any other sector editor. AFDISK 3.34 is free. Did you try it?

#49
dencorso

dencorso

    Iuvat plus qui nihil obstat

  • Supervisor
  • 6,026 posts
  • Joined 07-April 07
  • OS:98SE
  • Country: Country Flag

Donator

@all
Can you please review the attached version of the spreadsheet?

I've just given your spreadsheet a try:

I found two issues right away:
(i) [minor Bug?] the dropdown menu offers *two* "FREE" options... I picked the 1st, but I suppose the other would have worked equally (I didn't try it). If so, there's no reason for two identical entries. If not, there must be made more clear which is the difference between them.
(ii) [nomenclature issue] "Sectors per Head" everywhere shouldn't be rendered as the more usual "Sectors per Track"?

I liked the way it does not impose, but just suggests sensible values, and that it goes on with the red "Calculated image size from data:", until it considers the paramenters sensible.

Attached File  Clip2.jpg   60.97KB   6 downloads

I went on to create a 125,960,192 bytes, then copied the batch to notepad, saved it as batch.cmd and run it, and it gave me a perfectly sensible 42 kiB truncated image of the sought after 120 MiB FAT-12 superfloppy, named XLSimage.ima

Attached File  Clip1.jpg   40.7KB   5 downloads

The batch is quite clever, I liked it a lot! :thumbup
[Caveat:] But it should warn that anything on the same directory named *.bin wil be deleted by it, with no warning...
Moreover ".bin" is a too common extension... Perhaps ".tmp" or something like ".&#@" might be safer?

I noticed however, that the calculated BPB values are not automagically transfered to the other pages, which do contain the bootstraps. It would be handy, because, then, a simple copy of the whole sector could be used to enable bootability. As it was, I added the first two bytes (0x33 0xC0) of the bootstrap by hand to the image, to get to a paragraph boundary, then copied all the rest as suggested, but using WinHex, instead of TinyHexer.
I then extended the truncated image to full size using WinHex, but probably DCopyNT would also have worked well. I didn't try it here, though.

I liked very much the way the spreadsheet suggests the number of directory entries to be used. :D
I think it might also suggest a Volume Serial Number. Here's a suggestion of how to do it.
The quotation below is taken from Brian Carrier's "File System Forensic Analysys", Addison-Wesley, 2005 (ISBN 0-321-26817-2) Chapter 10, p. 258.

Attached File  Carrier258.jpg   63KB   9 downloads

Here's a link to the reference cited in the above quotation: [Wilson 2003].

Keep on the great work! :yes:
You do rock! :thumbup

#50
Multibooter

Multibooter

    Friend of MSFN

  • Member
  • PipPipPipPipPip
  • 896 posts
  • Joined 21-March 08
  • OS:98SE
  • Country: Country Flag

AFAIK, GDISK can do it on DOS, Win 9x/ME and Win XP. WinHex can do it on Win 9x/ME (sometimes) and Win XP.
Under DOS or Win 9x/ME, any fully zeroed/randomized device that Windows cannot mount but which respond to SCSI commands can be recovered by Adaptek's AFDISK 3.34. Both AFDISK and GDISK will create an MBR and a HDD structure, but that can be changed afterwards, when Windows is already capable of mounting the device, by using WinHex or any other sector editor. AFDISK 3.34 is free. Did you try it?

I had tried WinHex earlier and it couldn't write to a bulk-erased LS-120 diskette.

GDisk32 requires as parameter a physical fixed disk number (1-8) http://service1.syma...002112213111525 That sounds more like GDisk32 doesn't work with removable media/LS-120 drives, standalone Ghost 11.0.2, for example, doesn't display removable drives, or the type "3 1/2 Inch Floppy Disk", as indicated for the LS-120 drive in My Computer. I tried "gdisk /status" under MS-DOS 6.22, but the system just hung.

AFDISK v3.34 seems to hang on my Inspiron 7500 laptop under MS-DOS 6.22, the msg "Please wait" kept on flashing for about 20 mins, until I rebooted, although there was some HDD activity. Maybe AFDISK requires an Adaptec SCSI PCI card, or a line in config.sys, or I am missing a file, no idea. AFDISK seems to be the most promising of the three.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users