gw seems to ignore rpm= when writing to 5.25HD diskette

[jgeorge44]

I have a 5.25" 1.2MB diskette (standard 1.2MB PC/AT drive, and standard DSHD diskette) which is written for an IBM midrange machine (a System/36 PC, machine type 5364). It has an unusual, but not overly complex format.

I can read diskettes into flux (scp) and in to IMD formats reliably, and I can write flux/SCP images properly. However, when I write the IMD image, gw seems to write the tracks at 300 RPM, and I can't read back the data I wrote to the diskette.

Here's my diskdef for the format:

    cyls = 77
    heads = 2
    tracks 0   ibm.mfm
        secs = 26
        bps = 256
        rpm = 360
    end
    tracks * ibm.mfm
        secs = 15
        bps = 512
        rpm = 360
    end
end

If I write the IMD file with this def, gw writes tracks at 200ms (300rpm) instead of 167ms (360rpm):

*** TEST/PRE-RELEASE: 1.16.4.dev0+g2978619.d20240425
*** Use these tools ONLY for test and development!!
Writing c=0-76:h=0-1
Format ibm.p36.diag
T0.0: Writing Track (Flux: 200.0ms period, 220.0 ms total, Terminate at index)
T0.1: Writing Track (Flux: 200.0ms period, 220.0 ms total, Terminate at index)
.....

If I write back the SCP file, it writes tracks at 167ms and the diskette image looks correct.

Also, i'm running freshly built and checked out v1.16.3 gw from the repo, but for some reason it's reporting a prerelease version above. I don know if that's my problem but I'll try to whack everything and reinstall to make sure i'm running released code.

My problem is that I have MANY (~100) diskette images from another source that are IMD only and no flux images, so I need to be able to write an IMD and have it work, but it doesn't. Can anyone else try to write this image and tell me what I'm doing wrong?

DSKT11.IMD.gz

Thank you!

[keirf]

This was actually fixed about a week ago but not yet in a release. If you build the tip of master you should find the IMD writes correctly.

Specifying a --format for an IMD is pointless. The IMD is self describing so the format will be ignored; the fact this happens silently isn't great though. Probably should at least warn.

The weird version number for your build appears to be because setuptools_scm thinks your tree is dirty. I don't know why that is.

[jgeorge44]

Hmm. Running the tip of tree master gives me the same result. I don't see any recent commits that would be related to it?

I know --format on write is redundant, it's a force of habit because i usually just recall my "gw read --format..." command and turn it back into a write. :-)

Thank you for the super fast response!!

[keirf]

Tip of master is 154cb9d3404675ddd128cec444c2b706bfab37b9 "imd: fix import..."

This should correctly deduce 360 rpm when first track is 26 sector FM.

[keirf]

Oh I see but track 0 here is MFM. Well the heuristic could be extended fairly safely I suspect. I'm away for a few days but we could try this when I'm back.

The IMD file you linked in the original post -- is that one of the third party image files you need to be able to write? Ie not one created by gw?

[jgeorge44]

Yessir, the attached IMD is the one I need to be able to write and can't. I managed to get a copy that seems to work (though I haven't tested it much yet) with the command "gw write --drive 0 --fake-index 167ms DSKT11.IMD" - I tried "360rpm" instead of "167ms" first, and that didn't work (still wrote sectors at 200ms).

If you think it's the same logic as the last checking with FM track 0 I can try to make that change locally and see if it works. I should be able to try that in the next day or so.

[keirf]

Fake index of 167ms should be equivalent to 360rpm of course. And I would expect neither to work.

Here's why. Tracks recorded at 300 vs 360rpm generally have the same bitrate at their respective spin speeds; 360rpm tracks are therefore simply 5/6 the length of 300rpm (in terms of number of bitcells). So when gw gets the rpm wrong it is creating a track that has 20% too many bitcells and an enormous track gap (because the sectors don't fully fill a 300rpm track). If this gets written and then read back by a 360rpm drive the bitrate will be 20% too fast!

With your fake index parameter, the whole 300rpm/200ms track will get squeezed again to 167ms. So now this would be 40% too fast on a 360rpm drive.

What might work (but I don't recommend as a real long term solution) is a fake index of 240ms.

Of course the real fix is to generate a 360rpm track in the first place. As you suspect the fix would be similar to the FM fix at tip of master. I will supply a candidate fix on Sunday.

[jgeorge44]

I think I was more surprised that 360rpm and 167ms didn't do the same thing, even if it was wrong :)

I'm pretty sure that's what I did, but your explanation makes me question my memory. My short term memory is a sieve lately, so honestly, I can't be sure that's what I did, sorry.

[keirf]

Please test latest tip of master, you should find this is now fixed.

I also confirmed that --fake-index=360rpm and --fake-index=167ms are equivalent.