Feedback & feature requests

[LordCrass]

When writing an image file to disk, it seems the start/end track and head settings are ignored and the entire image file is written out.

I suppose the way the process currently works causes a bit of an issue writing out partial tracks, however. Since you don't choose an image file until right before it's written out, you can't see how many tracks are in the image.

Ideally, you'd choose the image file and the information about that image would populate into the copier window (start/end/type/etc), then you could adjust settings before clicking "Make Image" (which should probably be labelled as "Write Image" at this point).

Or, if the ability to write out partial images is prohibited, just gray-out the track settings as soon as the user chooses the Image File option from the source device drop-down.

[admin]

If you click on the "override file" option when writing a flux image back to disk, the start/end track on the display will be used instead of the start/end track in the file. So, you could do something like take a C64 disk image that has tracks 1-38 in it, and write back only tracks 1-19.

I do plan to populate the source window showing the tracks that are in the image. I guess maybe I should look at changing this to LOAD image where you could see all of the info about the disk image, and also have a WRITE image button.

[admin]

I am going to go ahead and change the Copier/Imager function so that flux images have to be LOADed and then disks created. This lets the user see the disk type for the image, and see the start/end track, blind mode, half tracks, etc.

[longbow75]

Are you planning to add flippy disk support for C64? I haven't seen it on your to-do list.

[admin]

Yes, the support is already built in, just not yet fully debugged (so not yet available). Look in the pull down menu under DRIVE SETTINGS/BACKSIDE CONTROL.

You can already write to the backside of a disk that has been flipped over, even without a second index hole. You just set: INDEX SENSOR/WRITES/IGNORE.

[longbow75]

Duh! I wasn't paying attention. Thanks.

[LordCrass]

Any plans for a track length matching feature in the writing routines? Sncboom2k and I were comparing notes and a few C64 images, and I found that I was unable to write back one of his images on my drive as the start of track was being overwritten by the gap data, meaning my drive must be a bit faster than his.

I could compensate by using the analyzer to mark start/end of track to eliminate most of the gap, but it should be possible to subtly alter the flux timings on the track to make it all fit properly.

[admin]

Yes, it's on the to-do list. The verify option will write to the track and check the duration and adjust the source track's flux timings so that the length matches the target drive's speed.

[LordCrass]

Fat tracks on c64 disks require a two-pass approach currently, where you copy or image the regular data tracks without half-tracks enabled, and then the fat track with half-track feature enabled.

Could you add an option to the write routine to ignore the half-track data except for the one needed in the fat track? Not sure if this would require the user to specify that one half-track manually, or if you could just auto-detect it.

[LordCrass]

Matching the length will be tied to a verify option? Seems like it should be an "always-on" feature. Just check the index-to-index time on the destination disk, compare with the source image, and adjust all the timings that are written based on that.

It would probably only require checking the destination speed on one track as well, so it's only a single revolution added to the time.

How does a verify option work with a flux copier anyway? Are you verifying against the decoded mfm/gcr?