[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