[Coco] Re: Help with ms-dos DSKINI please

[Rodney V Hamilton]

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.

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

-Rodney