SugarConvDsk's .IPF images do not report write splice

[Yserra]

Hi Keir, here is a strange case we experimented with the user Paco about writing Amstrad CPC disk images in .ipf format.

Paco retrieved some Amstrad CPC disk images in Kryoflux's CT-Raw format.

He converted them into .IPF format with the tool SugarConvDsk.

Here is an example of a resulted disk image: RIT.ipf.zip

The strange thing is that gw doesn't want to write that .IPF. The following commands fail after many (and random?) verification errors:

$ gw write RIT.ipf $ gw write RIT.ipf --tracks="c=0-39:h=0"

BUT. It appears that the following command writes a perfect working disk:

$ gw write RIT.ipf --tracks="c=0-39:h=0" --no-verify

Paco told me he can successfully write the same .IPF with a Kryoflux board. But I'm not sure if the Kryoflux' tool actually verifies the .IPF content when it writes it back to disk.

Here, the 'not verified' written floppy disk has then been checked with:

$ gw read --format=ibm.scan MyCPCtestIPF.edsk --tracks="c=0-39:h=0"

And I then successfully loaded the resultant MyCPCtestIPF.edsk into an Amstrad CPC emulator.

My Greaseweazle perfectly writes & verifies other .IPF files that I found on the web (actually I found Amiga's .IPF only, not Amstrad's .IPF)

The question is: why does gw fail to verify this particular .ipf when it (perfectly) writes it? And why the verification fails randomly?

[keirf]

Is this specific to the example IPF, or generally true for all IPF generated by SugarConvDsk?

Are the verification error(s) on specific track(s), or can errors occur randomly on any track?

[Yserra]

Actually, I can't produce myself other IPF with SugarConvDSK, since this software doesn't want to build on macOS. Paco didn't provide other examples...

The errors occur on random tracks. Example 1: gw write /Users/yserra/Downloads/RIT.ipf IPF Image File: SPS ID: 0000 (rev 1) Platform: Amstrad CPC Created: 0/0/0 00:00:00 Cyls: 0-41 Heads: 0-1 Writing c=0-81:h=0-1 T0.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T0.0: Writing Track (Verify Failure: Retry #1) T1.0: Writing Track (Flux: 200.0ms period, 220.0 ms total, Terminate at index) T2.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T3.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T3.0: Writing Track (Verify Failure: Retry #1) T3.0: Writing Track (Verify Failure: Retry #2) T3.0: Writing Track (Verify Failure: Retry #3) ** FATAL ERROR: Failed to verify Track 3.0

Example 2: gw write /Users/yserra/Downloads/RIT.ipf IPF Image File: SPS ID: 0000 (rev 1) Platform: Amstrad CPC Created: 0/0/0 00:00:00 Cyls: 0-41 Heads: 0-1 Writing c=0-81:h=0-1 T0.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T0.0: Writing Track (Verify Failure: Retry #1) T1.0: Writing Track (Flux: 200.0ms period, 220.0 ms total, Terminate at index) T2.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T2.0: Writing Track (Verify Failure: Retry #1) T2.0: Writing Track (Verify Failure: Retry #2) T3.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T4.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index) T4.0: Writing Track (Verify Failure: Retry #1) T4.0: Writing Track (Verify Failure: Retry #2) T4.0: Writing Track (Verify Failure: Retry #3) ** FATAL ERROR: Failed to verify Track 4.0

The above examples were tried with the same floppy disk, which works for any other writing. To rule out any possible problems with the 3" drive, these examples were carried out with a 3.5" drive, on a 3.5" floppy disk.

[keirf]

Similar to #358 the problem is that this IPF does not report the location of the write splice (reported as -1 which means unknown). Greaseweazle currently takes -1 literally, as one bitcell before the index. Unfortunately this IPF reports data across the index, so placing the write splice at the index places it in the middle of that data.

It would be nice if SugarConvDsk could tell us the write splice location but, in absence of that, heuristics similar to #358 will be required. That is, place the splice in a weak area, or end of an NFA, or in a sector gap. In that order.

[keirf]

Here's probably another one, from Paco Gonzalez, Knight Force:

Knighta.ipf.zip