Fix writing to non-existent tracks

[OyyoDams]

Hi,

When using a software such as Discology on Amstrad CPC 6128, copy from a physical disk to a virtual floppy only works if both are in "data" format. That's not possible to format the virtual disk as "system", or copy non standard sectors.

Thanks

[keirf]

This is using DSK (EDSK) images right? They are effectively pre-formatted and you cannot change their sector ids. Writes to non-matching sector ids (such as when trying to format to a different disk type) get dropped. I suppose theoretically FlashFloppy could get into re-creating EDSK images but it's a small-enough demand thing that I don't envisage it happening.

[OyyoDams]

Ok, so any idea how I can achieve it ? Maybe using another format than EDSK

[keirf]

Use HFE if you want this flexibility. Or if you have an EDSK of the correct existing format, you can use / 'reformat' that and it will work.

[OyyoDams]

Ok I'll try with HFE, thanks!

[f1ac0]

Hello,
Seeing your questions and replies, I went to try it to backup my old 3inch disks :) 👍
I also used Discology which is configured by default to copy from track 0 to 41 : 42 tracks
My blank HFE images for CPC were 40 tracks only (0 to 39), however.

After discovering some errors on my files, at first I thought they were due to the old and rusty hardware : after few hours of gently waking and warming it it now seems to be completely fine.

But I believe I found an issue with the latest 3.11a firmware : writing the "unformatted" 40 and 41th tracks to the 40 tracks HFE does erase track 39 ! Maybe FF does not like "overtracks" ?

I tried with a 42 tracks HFE and after the copy, track 39 is OK.

As a work-around solution, since it was quite common to have 42 tracks discs on CPC, I suggest to use 42 tracks HFE. I guess it also works to copy only 40 tracks if you use 40 tracks HFE.

I believe FF should just drop the "overflowing" tracks instead of writing them to the last track of the HFE, or better if possible : expand the number of tracks in the HFE ?

[keirf]

Extending an image during use is a bit tricky as that's a potentially relatively slow operation. Not mapping overtracks to the last available track does make sense though, especially for writes!

Possibly writes to non-existent tracks should flag a warning/error on the display, for a second?

[f1ac0]

Personaly I would say :
-Not writing overtracks to the last available track is necessary to reduce risk of data loss
-It might be a good idea to add that information in the wiki (Image formats and host platforms pages) : about formats that do and do not support "write ID"/formatting operations (the original question of this post) ; then adding there and info about the number of tracks in the images and what FF does when the host is asking for cylinders that are not in the image.
-A warning on the display could be OK too since users don't read manuals... But if you do that, you might as well inform the user when an unsupported "write ID"/formatting operations occurs. You would also have to find a way for this warning to be persistent until the user notices it. This could be a lot of work ! Maybe not worth it if the info is in the wiki...

[keirf]

All good points, except the last I think it is fine for the error to be non-persistent on the display:

1. It is better than no error at all
2. In fact it will be printed more as a minor point of information, probably turning the 'W' character into a '!' or 'X' for a couple seconds.

There is no proper documentation on image formats at the moment and that's probably a good idea to be fixed in the wiki.

[keirf]

Ok the primary issue of this ticket (avoiding writing non-existent tracks to last available track) is fixed. It will be in next release v3.14a, which I hope to then make the next stable series starting with v3.15.

[keirf]

Now released as v3.14a. Please reopen if this does not resolve the ticket issue.