[Coco] Re: Help with ms-dos DSKINI please
Rodney V Hamilton
rodney_hamilton at gbronline.com
Tue Jul 20 07:05:12 EDT 2004
In article <cdhsgf$cph$1 at sea.gmane.org>, robert.gault at worldnet.att.net says...
>Robert Gault wrote:
>><snip> The main problem is why won't DSKINI.EXE convert this image to a
>> real floppy. I don't have the answer for that.
>I have tried several methods for making a real disk of this image with
>no success. The direct method with "dskini /t40 /d a: lsl.dsk" fails at
>track 11. A copy of the disk made with an emulator fails in the same
>manner. OS9.EXE a: -w lsl.dsk will not work either.
The OS9.EXE util worked fine for me, using the same lsl.dsk image that
DSKINI.EXE cannot handle. I pre-formatted the target disk on my CoCo3
before writing the lsl image to avoid possible problems, since I don't
think OS9.EXE auto-pads its disk writes. Either way, OS9.EXE gave me
no problems while writing the image file to floppy. (on a 386 AT box
running MS-DOS 6.2 to a 1.2M drive with "os9 b: -w lsl.dsk")
I was actually a bit surprised (and pleased) that OS9.EXE handled the
double-sided image_file -to- floppy disk write properly, since I had
mostly been making my floppies with dskini before now.
>It makes no sense that a program like dskini.exe, which works perfectly
>for all other images I've tried, would fail on any specific image. My
>guess is that some combination of data bytes is being interpreted by
>dskini as a specific dskini instruction. Clearly this should be
>impossible but I can't think of any other possibility.
Definitely a head scratcher!
BTW, I did notice a buglet in DSKINI.EXE's format-length padding code:
It only auto-pads 40-track disks! The padding test it uses compares
the track number to 40 instead of the user-specified value, so it only
pads for files with 40 or fewer tracks of data. FYI.
More information about the Coco