[dencorso]

I have images of them all, by now! Most were created with WinImage v. 8.10.8100 (or the previous version of it). Some, like the formats used by DOS 1.x, WinImage cannot handle, because it needs a BPB (which hadn't been invented yet, in DOS 1.x times!) to find out what the floppy format is. For those I used the excellent freeware DiskImage, by Mike Brutman (the whole of his PC Jr site is worthy of a visit too...). In all cases, I've favoured raw images (.IMA files), which I can browse with WinHex and boot from with grub4dos if I'm in the mood. After I learned how to boot from raw images, I have had little use for my oddly formatted diskettes, but I decided to keep them, just to see how long they would hold their strange formats. I have one MD2HD (5.25") formatted to 160 kB and 20+ MF2HD (3.5") formatted strangely, and they are now 2 years old or more and counting, and remain perfect. Isn't that great? I had always read everywhere that high-density floppies formatted to low density formats wouldn't hold the format for long... Now, these floppies were, all of them, new media, never used before. With used media I've had mixed results: they do not necessarily format perfectly, and bad sectors are a common finding.
Later edit: for what it's worth, here's also a working direct download link to the trusty old Rundegren's Freeware Floppy Image 1.5.2.0 for Win (which, however, only supports 3.5" floppies).

[Multibooter]

Problem converting boot sectors to a different floppy format
I have come across a little monster among the floppies to be archived:
It is a 5.25" 360kB bootable floppy which boots into IBM DOS 2.00 (German) of 9-Aug-1983. I can create a 5.25" floppy image from it Ok, the 5.25" floppy re-created from the image file boots fine into IBM DOS 2.00 (German).

But I cannot convert this 5.25" 360kB floppy image correctly to 3.5" 720kB format, so that I can boot into IBM DOS 2.00 (German) on my Inspiron 7500 laptop, which has only a 3.5" floppy drive (laptops don't come with 5.25" floppy drives). I have tried both WinImage under Win98 and the "Convert" selection of Disk Copy Plus under DOS 6.22. The converted 3.5" 720kB floppy does NOT boot anymore. When booting from the "converted" 3.5" floppy, I get the error message:
" Falscher/fehl.Befehlsinterpreter" = "wrong/missing command interpreter".

During the conversion of the floppy format, DCP displays that the orignal 5.25" 360kB floppy had 12 sectors used by the system, while the resulting 3.5" 720kB floppy has 14 sectors used by the system. WinImage does not display any conversion information.

When I compared with Anadisk the original 5.25" floppy and the "converted" 3.5" floppy, there were 2 changes:
- the media byte changed from "fd" to "f9"
- the original 5.25" floppy had 2 sectors/FAT, while the "converted" 3.5" floppy had 3 sectors/FAT, which may explain why command.com could not be found.

This little monster shows that one cannot trust the converted image files of bootable floppies created by WinImage or DCP. After conversion one should always test: does the converted floppy really boot?

Both WinImage and DCF can write Ok without format conversion the 5.25" floppy onto a 3.5" floppy, but the trouble is that this non-standard floppy (i.e. a 3.5" floppy pretending to be a 5.25" floppy) boots fine on a Toshiba T3200 (80286), but when trying to boot from it on an Inspiron 7500 (Pentium 3), the system hangs during the boot process.

Is there a tool which can properly convert the boot sector from a 5.25" floppy to a standard 3.5" floppy?

P.S.:
Same problem when booting with a 3.5" 720kB "IBM PC-DOS v2.10 (German)" floppy converted from 5.25" 360kB format
(err msg: Fehler:DSKT,Platte/Kein System)
Same problem when booting with a 3.5" 720kB "IBM PC-DOS v2.10 (US)" floppy converted from a 5.25" 180kB format
(err msg: Non-System disk or disk error)

This post has been edited by Multibooter: 31 August 2009 - 06:26 AM

[dencorso]

Support for 1.2 MB MD2HD (5.25") floppies was added with PC-DOS 3.00 and support for 720 kB MF2HD (3.5") floppies arrived only with PC-DOS/MS-DOS 3.20. Older versions will refuse to boot from these formats, no matter what. Thus PC-DOS 2.xx will boot at most from 360 KB floppies (or images), PC-DOS 1.10 and MS-DOS 1.25 will boot at most from 320 KB floppies (or images) and PC-DOS 1.00 will only boot from 160 KB floppies (or images).

So I suggest you:
1)Use FDFormat to format a common MF2HD (3.5") to 360 kB (with the high-density tab taped)!
2)Use DiskImage or WinImage to collect a raw image from the 5.25" floppy.
3)Use WinImage to transfer without formatting the raw image to the 360 kB 3.5" floppy you've just prepared!
This works in my machine, so it's worth giving it a shot on yours. Good luck!

Now, in case your hardware does not accept the MF2HD (3.5") 360 kB created with FDFormat (which lets you produce a floppy perfectly within the original specs), then the best ideia is to boot MS-DOS 7.10 from a floppy, run Grub4DOS and boot the image of the PC-DOS 2.00 from it. In case you decide to go this way I can provide you a more detailed how to (and so can jaclaz who first interested me on the *fantastic* Grub4DOS ).

@jaclaz: DCOPY seems interesting, no doubt, and I shall give it some testing shortly. The programs I'm talking about, however, are those that, at lest for me, are proven to work well with those really old versions of DOS, which are very picky as to formatting detail, although they may be tricked into using 3.5" floppies, as long as the FDD plays along.

This post has been edited by dencorso: 31 August 2009 - 01:57 PM
Reason for edit: Added a lot of info

[jaclaz]

@dencorso

I'll try again re-submitting (pushing ) DCOPY:
http://users.telenet...plications.html

Quote

DCOPY is a single pass floppy disk copy program. It makes use of
extended memory, hard disk, or conventional memory. It is capable of
making more copies of the same disk, without re-reading the disk. It
can copy a variety of floppy formats, including those formatted with
FDFORMAT. It can copy non-DOS disks, sush as Linux disks, thanks to
an autodetect function. It's also possible to make/restore disk
images to/from a file. Another possibility is to format a disk, verify
and compare a disk.

 
You must use DCOPY as follows:
     DCOPY source target [options]

source: This can be a drive (A: or B:) or a file (a disk image)
target: This can be a drive (A: or B:) or a file (a disk image)

      - You cannot specify a disk image for both source as target.
      - You can specify wildcards with source disk image names.
      - When you create a disk image with .ZIP extension,
        the disk image is automatically compressed with PKZIP.
      - When you restore a disk image with .ZIP extension,
        the disk image is automatically uncompressed with PKUNZIP.
        The zip file must contain a file with the same name, but
        with extension .IMG

options:
  /s   : Use a swap file instead of extended memory.
  /c   : Use conventional memory instead of extended memory or swap
	 file.
	 With this options enabled, the copy process must be done  in
	 multiple passes.
  /v   : Verify if data is written correctly. The data is read again
	 and compared with the original data.
  /f   : Always format target disk the same as the source disk.
  /vo  : Verify only a disk, do not copy. A target drive is not
	 necessary.
  /fo  : Format only a disk, do not copy. A target drive is not
	 necessary.
  /f:x : Use a predefined disk format, this can be
	    160,180,320,360,720,800,1200,1440,1600,1722
	 Every format indicates the capacity of the disk in Kbytes.
  /a   : Autodetect the disk format, this is done automatically  if
	 the disk is a non-DOS disk. When used with the /fo option,
	 the disk is formatted at the highest possible capacity.
	 (You will need a TSR like FDREAD that enables you  to  read
	  the disk)
  /a1  : Autodetect the number of sectors per track at every track.
	 This is usefull for some forms of copy protection, where
	 the disk is formatted with a different number of sectors at
	 some tracks.
  /a:x : Retry to read/write a track x times in case of a read/write
	 error.
  /sk  : Skip all read/write errors.
  /t:x : Use x tracks.
  /n:x : Use x sectors per track.
  /s:x : Use x sides.
  /qm  : Quiet mode, does not make the silly beeps.
  /i:x : Use an interleave of x.
  /ss:c: Use Sector Spinning of x. Changing this number may speed up/slow down
	 the copy process.
  /hs:x: Use a head settle time of x. If your drive reports read errors, you
	 can try setting this value to at least 25.
  /fs  : Do not use FAT selection.
  /x:n : Make/Restore n disk images. Dcopy will create or restore n disk
	 images from/to disk. The images have the name you specified as
	 first or second argument with the extension .001 to .n
  /co  : Compare two disks. Reads the first disk and compares it with a
	 second disk. You can also compare disks with a disk image.
  /fdr : Creates an executable called fdread.exe on the target disk.
	 This program allows you to read the extra high density diskettes.
	 This option is only used with the /fo option.
  /q   : Does a quick format. Writes only the logical information, does not
	 really format the disk. This option is only used with the /fo 
	 option. 

jaclaz

[Multibooter]

dencorso, on Aug 31 2009, 09:01 AM, said:

So I suggest you:
1)Use FDFormat to format a common MF2HD (3.5") to 360 kB (with the high-density tab taped)!
2)Use DiskImage or WinImage to collect a raw image from the 5.25" floppy.
3)Use WinImage to transfer without formatting the raw image to the 360 kB 3.5" floppy you've just prepared!
This works in my machine, so it's worth giving it a shot on yours. Good luck!

Converting DOS 2 boot floppies from 5.25" -> 3.5" media
Thanks, dencorso, it worked fine on my old Inspiron 7500 laptop. I used DCF instead of DiskImage or WinImage.

Under DOS 6.22 I pre-formatted a taped 1.44MB floppy disk with FDFormat: "FDFormat A: /4"
Then, in a DOS window under Win98, I extracted with DCF on top of this pre-formatted floppy a .dcf image of the DOS 2.10 boot floppy, with the options: Format=OFF and Fast=ON.

I was able to boot from this special 3.5" floppy into DOS 2.10, both with my Inspiron 7500 laptop (2000) and with an older Toshiba T3200 (1987)

Under Win98 the files on this specially-formatted 3.5" floppy displayed Ok, but I was not able to read from or to write to it without a blue screen + disk error msg. In any case, it's nice to know that one could boot into DOS 2.1 on a laptop without a 5.25" floppy drive, if ever the need came up.

This post has been edited by Multibooter: 16 September 2009 - 03:17 AM

[CharlotteTheHarlot]

@Multibooter ...

FYI, Svend Olaf Mikkelsen also developed a method for live booting from floppy images a few years back. I won't bother explaining it since he has it pretty thoroughly documented on this page The Boot Floppy.

It is 9x based (well, FATxx actually).

I meant to mention this a while ago, sorry I got busy elsewhere!

[jaclaz]

CharlotteTheHarlot, on Sep 9 2009, 10:06 AM, said:

FYI, Svend Olaf Mikkelsen also developed a method for live booting from floppy images a few years back. I won't bother explaining it since he has it pretty thoroughly documented on this page The Boot Floppy.

Nice.

Just for the record, grub4dos or Syslinux/memdisk can map a floppy image to (fd0) (please read as A:\) allright.
As long as the OS inside the floppy is a "protected mode" one and there are no programs that use undocumented ways to access the floppy, it will work allright.

jaclaz

[dencorso]

For what's worth, here is my MENU.LST for loading the good old classics with Grub4DOS:

Quote

default 2
timeout 3

title CP/M-86 1.1 (1983)
map --mem /CPM86_11.IMA (fd0)
map --hook
rootnoverify (fd0)
chainloader --force (fd0)+1

title PC-DOS 1.00 (1981)
#image is 160kB
map --mem --heads=1 --sectors-per-track=8 /PCD100.IMA (fd0)
map --hook
rootnoverify (fd0)
chainloader --force (fd0)+1

title PC-DOS 1.10 (1982)
#image is 320kB
map --mem --heads=2 --sectors-per-track=8 /PCD110.IMA (fd0)
map --hook
rootnoverify (fd0)
chainloader --force (fd0)+1

This runs OK from a common 1.44 MB bootable MS-DOS 7.10 floppy.
Besides the usual DOS files, grub.exe, menu.lst and the raw floppy images, of course, are needed.
DRVSPACE.BIN can be removed, and a one line CONFIG.SYS, containing just "INSTALL=GRUB.EXE" should be added.

[Multibooter]

Data recovery problem
One of my 720kB floppies to be archived has a very nasty CRC error in track 0. WinImage reports "Disk Error on track 0, head 0. Floppy Error". DCF gives the msg "Diskette bad. CRC read error" on Track 0. BadCopy is of no help either ("No file found in rescue Mode #1, you may try Mode #2", and under Mode#2 it recovered garbage into File1.EXE ). Similar story with EaseUS Data Recovery Wizard under WinXP.

AnaDisk reports:
Track 0, Side 0: Sector 8 data error, Sector 9 ID but no data found
Track 0, Side 1: Sector 5 data error
all other tracks were Ok

Vga-Copy v5.3 was able to recover correctly, in a Win98 DOS window under SlowDown v1.01, with a regular 3.5" floppy disk drive, about 50% of the files on the floppy, with their correct file names and correct content. I had selected the maximum of 99 retries; Vga-Copy was then reading for about 45 minutes the bad and weak sectors of track 0.

LS-120 floppy drives are much better at reading bad floppies than regular floppy drives. Vga-Copy unfortunately does not work with LS-120 floppy drives, it accesses the floppy controller directly.

AnaDisk v2.10, DiskDupe v4.07, DCF v5.3, CopyQM v5 and WinDupe v1.02 don't work in a Win98 DOS window with an LS-120 floppy drive either. TeleDisk v2.23 allows to address the floppy controller either directly or via the BIOS, but TeleDisk doesn't work either in a Win98 DOS window.

I would like to continue my data recovery with an LS-120 floppy drive because of its superior error correction. Which Win98 recovery software or sector-copier works with an LS-120 floppy drive and is actually able to recover floppies with a bad track 0?

This post has been edited by Multibooter: 10 September 2009 - 06:24 PM

[dencorso]

Multibooter, on Sep 10 2009, 08:12 PM, said:

I would like to continue my data recovery with an LS-120 floppy drive because of its superior error correction. Which Win98 recovery software or sector-copier works with an LS-120 floppy drive and is actually able to recover floppies with a bad track 0?

None that I know of.
But, by all means, clone the disk with Anadisk to a good floppy, while you still can, before using Anadisk more extensively to try to salvage something from the bad sectors. And do clean the heads of your drive before proceeding, and after you're finished with the bad floppy.

[jaclaz]

dencorso, on Sep 11 2009, 07:30 AM, said:

But, by all means, clone the disk with Anadisk to a good floppy, while you still can, before using Anadisk more extensively to try to salvage something from the bad sectors. And do clean the heads of your drive before proceeding, and after you're finished with the bad floppy.

Also, take this advice from an old man , use an old floppy drive.

I don't trust "recent" floppy drive, something you bought new in the last 5 to 10 years and payed $5 to $7 apiece.

Ideally you should have a few floppy drives, possibly salvaged from old "brand" PC.

I have a 3.5" floppy salvaged from a Toshiba 5100 (a "portable" of the time) that weights a little more than 2 times one of the new ones, it's sturdy, and at least in my simple mind (and on field) more reliable than those cheap thingies.

Besides that, every floppy drive can (and is) slightly mis-aligned, let's say that you have a "left misaligned" floppy drive.
Anything you write on a floppy with it will be readable on the same drive and on all floppy drives that are perfactly "centered".
As soon as you put that floppy in a "right misaligned" drive, it won't be read properly anymore.

If you have a few floppy drives, it is probable that some will be misaligned the same way the one on which the floppy was originally written was.

Unfortunately, I think that the most you can try is cleaning the heads, without specific tools.

Some reference:
http://www.accurite....oppyPrimer.html

jaclaz

[Multibooter]

Data recovery problem nearly solved
I have achieved fantastic data recovery results using an LS-120 floppy drive together with GRDuw for Windows v4.1.14 (=GR Disk Utility, by Grosso, Roberto, for WinME/9x) to recover data from this bad floppy.

It took about 6 minutes to recover probably 90% or more of the bad 720kB floppy. The GR Disk Utility recovered 26 good files, totaling 513kB. VGA-Copy, using only a regular floppy drive, recovered 6 good files with 377kB, taking over an hour. VGA-Copy, however, recovered the last chunk of a text file, which GR Disk Utility couldn't, otherwise the files recovered by VGA-Copy and GR Disk Utility were identical.

With a regular floppy disk drive, however, GR Disk Utility is very slow and couldn't even recover a single sector of track 0 after my clicking for 10 minutes on Retry.

LS-120 drives differ in their data recovery performance. One drive recovered 26 good files, totaling 513kB, another drive recovered only 17 files with 502kB. This bad little floppy disk actually can help me identify which one of my LS-120 drives is a particularly good reader.

Using "AbsRW"as "Low level disk mode" gave much better results than using "BIOS"; I have not yet checked the IoCtrl mode.

There is one other feature which I particularly like: GR Disk Utility is the only Win98 GUI utility which can write .dcf floppy image format. (It can read and write 3 formats: .dim, .dcf and .ima). If you own an LS-120 drive, the GR Disk Utility is an absolute must-have.

I now appreciate my LS-120 floppy drives, which were sitting in a box for years, as magic data recovery drives for bad 3.5" floppies.

This post has been edited by Multibooter: 11 September 2009 - 12:08 PM

[Multibooter]

Remainder of bad floppy recovered with ScanDisk
GRDuw and the LS-120 floppy drive had recovered 26 good files with 513kB, but the 720kB floppy also contained files and directories with strange characters in their names and Windows Explorer reported using 10.9GB. I then:
- created with GRDuw a .dcf image of the recovered floppy
- created a work-copy of the recovered floppy (by writing the .dcf image to another floppy)
- ran ScanDisk on the work-copy with the options Make copies of cross-linked files and Convert lost fragments to files
- ScanDisk then recovered 9 more files from lost clusters, but they had filenames like "File0000.chk". I assume the lost clusters came about because parts of the control structures area, track 0, were bad. They were good data, but no index on track 0 was pointing to them.
- I assigned correct filenames to these lost clusters (= good, not yet recovered files plus junk) by comparing them with Beyond Compare to backup versions
- I manually removed with Beyond Compare the junk appended at the end of 7 ASCIIl files recovered by ScanDisk. The size of the recovered lost cluster files on the floppy, e.g. of File0000.chk, was a multiple of 1024 bytes. Anything between the last byte of the original file (e.g. byte 135.878 ) and the end of the lost cluster file (e.g. byte 136.192, a multiple of 1024) was junk to be removed. But you have to know where the original file ended. The ".chk" files recovered by ScanDisk did not have the original modifcation date of the file. The recovered and then cleaned files can be easily recognized by their much later modification dates.
- 2 of the 9 files recovered by ScanDisk as .chk lost cluster files were non-ASCII files (compiled .QLB and .LIB, both 25.600 bytes). Since I could NOT with certainty identify the last byte of the original file/the appended junk I left these 2 files unmodified, with a maximum of 1kB of junk at the end.

The recovered 720kB floppy has 35 files using 669kB. About 75% of the files (26 files using 513kB) were recovered by GRDuw. 1 file recovered by GRDuw had perfect content but had a modifcation date error ("4/11/90" instead of "4/11/91). The file modification date/time of all files recovered by GRDuw was increased by exactly 9 hours, e.g. "3/25/91 6:40:50 am" instead of "3/25/91 9:40:50 pm". This may be a bug of GRDuw, I have Pacific Time (GMT-8) on my laptop, or it may have something to do with the orignal files being created under DOS 5, but the recovery took place under Win98.

The remaining 25% of the files, for which the index on track 0 was damaged, were recovered by ScanDisk plus manual modification. Manual cleanup was feasible only for the ASCII files, not for the 2 compiled files.

I repeated the recovery altogether 7 times, on 2 different LS-120 drives, on a regular floppy drive, with and without the iosys98.exe unofficial Windows update, using AbsRW and BIOS as low-level disk modes, with basically identical results. I am confident that all files on the floppy were recovered and good (except for the junk at the end of the 2 compiled files) because the data area of the floppy was Ok, only track 0 was bad. I looked at all 33 ASCII files on the floppy, they all looked good. Thanks Grre-doff

This post has been edited by Multibooter: 12 September 2009 - 04:45 PM

[Multibooter]

Unofficial I/O Subsystem Drivers Fix
3 of my attempts to recover the bad floppy with CRC errors on track 0 were made on a plain-vanilla Win98SE system and 4 attempts on a plain-vanilla Win98SE system plus the Unofficial I/O Subsystem Drivers Fix (iosys98.exe)

GRDuw plus an LS-120 floppy disk drive could recover without the iosys98 update 2/4/5 files in 3 attempts.
With the iosys98 update they could recover 26/24/22/4 files in 4 attempts.
It might have been just coincidence, but it appears that the iosys98 update may improve the data recovery capability of GRDuw plus an LS-120 floppy drive as drive A:.

I have tested the iosys98 update quite a bit, it didn't cause any problems on my system. In any case it has a very good uninstall routine, in contrast for example to nusb.

BTW, when I had the internet connected, via a USB 2.0 WLAN PCcard in a PCMCIA-slot, during a further recovery attempt with the iosys98 update, only 3 files were recovered.

This post has been edited by Multibooter: 13 September 2009 - 10:42 AM

[dencorso]

Congratulations for the successful data recovery, Multibooter! That's not easy at all!
I'm happy to read IOSys98 did help. But I have a question for you, just for the record:
Were you using also the VFAT.VxD official update (Q277628) or it was all done with the original VFAT.VxD?

[Multibooter]

dencorso, on Sep 13 2009, 12:49 PM, said:

Were you using also the VFAT.VxD official update or it was all done with the original VFAT.VxD?

All floppy recovery efforts were done with the original VFAT, NOT with the VFAT update.

I had test-installed the VFAT.VxD official update after the iosys98 update and got a tremendous multiple-drive-letter problem: I had a SCSI Iomega Jaz drive connected via an Adaptec SlimSCSi 1460A PCCard in the PCMCIA slot. Instead of getting one icon in My Computer for the Jaz drive I got seven. A 2nd SCSI Jaz drive connected via a Jaz Traveller cable [= a SCSI to parallel converter] to the parallel port was unaffected and Ok, it showed up as an eighth icon.

Restoring clean \Windows\ and \Program Files\ directories didn't help, I kept on getting these multiple drive letters, somehow unexplainable. Maybe something got stored in a hidden area of the Jaz drive. When I changed the SCSI ID on the Jaz drive from 7 to 6 plus repeated restoring a clean Windows, the multiple-drive-letter problem was miraculously gone.

I never had seen 7 multiple Jaz icons before, and I prefer to stay away from this VFAT update. Windows is a huge pile of bugs: I installed this VFAT update, which was supposed to have something to do with the time-stamps of files, and I get a huge number of multiple jaz drive letters. Or, as I mentioned above, I connected to the internet with a WLAN PCCard, and the file-recovery with the floppy drive became poor. That's why I prefer a plain-vanilla Win98SE, with as few updates as possible.

[Multibooter]

Multibooter, on Sep 4 2009, 02:33 PM, said:

dencorso, on Aug 31 2009, 09:01 AM, said:

So I suggest you:
1)Use FDFormat to format a common MF2HD (3.5") to 360 kB (with the high-density tab taped)!
2)Use DiskImage or WinImage to collect a raw image from the 5.25" floppy.
3)Use WinImage to transfer without formatting the raw image to the 360 kB 3.5" floppy you've just prepared!
This works in my machine, so it's worth giving it a shot on yours. Good luck!

Converting DOS 2 boot floppies from 5.25" -> 3.5" media
Thanks, dencorso, it worked fine on my old Inspiron 7500 laptop. I used DCF instead of DiskImage or WinImage.

Under DOS 6.22 I pre-formatted a taped 1.44MB floppy disk with FDFormat: "FDFormat A: /4"
Then, in a DOS window under Win98, I extracted with DCF on top of this pre-formatted floppy a .dcf image of the DOS 2.10 boot floppy, with the options: Format=OFF and Fast=ON.

I tried to create a 360kB 3.5" boot floppy into IBM PC-DOS 2.00 (US) with WinImage instead of DCF (in a Win98 DOS window), but on my floppy drive WinImage canNOT write the floppy image onto a 3.5" 720kB floppy pre-formatted to 360kB. WinImage gives me the error message "Error. Disk error on track 1, head 0. Floppy Error". Apparently your floppy drive works better with WinImage than mine.

GRDuw could not transfer the image onto preformatted 360kB 3.5" media either. GRDuw does not support the 360kB format, only 1.2MB for old 5.25" floppies. When I tried to transfer the 360kB image with GRDuw onto 3.5" media I get the error message: "The Disk Image file media type is not supported"

So the only software tool that works with my floppy drive and which can transfer under Win98 the image of a DOS 2.x boot floppy onto 3.5" media is DCF.

[dencorso]

No. You've got me wrong. In my machine, WinImage can transfer all but DOS 1.xx images to all odd-formats of floppies, provided I don't use it to actually format. That is to say, the "Write disk" works all right. Whenever I try to use either "Format and write disk" or "Format disk" with formats of 720 kB or less I also get an "Error. Disk error on track x, head y. Floppy Error". With the standard formats it works also for formatting and sometimes it is able to format a 3.5" floppy to 1.2 MB. FDFormat, in true DOS, is my preferred way to do all formatting. When it fails, the floppy actually is bad.
But I bet there is yet another utility that may transfer the images in your machine: DiskImage. Did you give it a try?

dencorso, on Aug 30 2009, 03:17 PM, said:

... the excellent freeware DiskImage, by Mike Brutman (the whole of his PC Jr site is worthy of a visit too...). ...

[jaclaz]

Ok, since noone AFAICR mentioned it:
http://www.fdos.org/ripcord/rawrite/

Have you tested FDimage?

jaclaz

[Multibooter]

Multibooter, on Sep 16 2009, 02:09 AM, said:

on my floppy drive WinImage canNOT write the floppy image onto a 3.5" 720kB floppy pre-formatted to 360kB.

dencorso, on Sep 16 2009, 07:26 AM, said:

No. You've got me wrong. In my machine, WinImage can transfer all but DOS 1.xx images to all odd-formats of floppies, provided I don't use it to actually format. That is to say, the "Write disk" works all right. Whenever I try to use either "Format and write disk" or "Format disk" with formats of 720 kB or less I also get an "Error...

On my machine I had "pre-formatted" three 3.5" target floppies to 360kB (with the Win95 program SH-CopyStar v4.31b, with FDFormat under DOS and with VGA-Copy v5.3 plus SlowDown v1.01 in a Win98 DOS window). I then selected in WinImage "Write disk" (NOT "Format and write disk") to transfer an image of DOS 2.00, also of DOS 3.10, and got an error. WinImage worked in this case with your floppy drive, but not with mine.

dencorso, on Sep 16 2009, 07:26 AM, said:

But I bet there is yet another utility that may transfer the images in your machine: DiskImage. Did you give it a try?

DiskImage
DskImage v1.0 by M.Brutman is an excellent program. It does work with my LS-120 floppy drive.

Here is an illustration of the importance of using an LS-120 floppy drive for data recovery: when DskImage was used with a regular floppy drive on my bad floppy with track 0 CRC error, it reported 30 sectors were unrecoverable; when I used the LS-120 floppy drive, DskImage reported 1 sector was unrecoverable. Once DskImage actually reported, with the bad floppy in the LS-120 drive, a perfect read with 0 sectors unrecoverable, but the disk image still contained lost clusters and lots of huge directories with illegal characters, so I don't quite trust the message "0 sectors were unrecoverable".

Here a comparison between GRDuw v4.1.14 and DskImage v1.0:
- DskImage can only read thru the BIOS while GRDuw can also use Absolute RW, a method which in my tests has produced more recovered files than using BIOS
- DskImage can re-read a bad sector up to 10 times, while GRDUW seems to read a bad sector up to 15 times
- nevertheless both programs achieved roughly the same data recovery results

I tried DskImage under Windows XP SP2, because the docu file DskImage.txt states "DskImage works under DOS, Windows 9x, Windows 2000, and probably Windows XP". But what does "probably" mean?

When I tried to recover under WinXP this bad floppy with track 0 error, everything seemed to work fine. But I couldn't write under WinXP the recovered disk image onto a floppy. Under Win98 I was eventually able to write the image to a floppy, after several frozen or hung systems. In Windows Explorer this recovered floppy didn't show any files, although there was hardly any free space on it. When I ran ScanDisk on the recovered floppy, the system froze. I then compared with Beyond Compare/HexViewer the floppies recovered with DskImage under Win98 and under WinXP: they were nearly identical, except that the disk image obtained under WinXP had just blanks around the area of the FAT.

So "probably" could als be interpreted as "probably not". In any case, DskImage should be in the Win98 tool box for data recovery.

@jaclaz:
I have looked at FDImage, but it's for writing a floppy disk image, not for reading a bad floppy. Thanks anyway.

This post has been edited by Multibooter: 18 September 2009 - 03:47 PM