gw seems to ignore rpm= when writing to 5.25HD diskette about greaseweazle HOT 8 CLOSED

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.

from greaseweazle.

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!!

from greaseweazle.

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

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

from greaseweazle.

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?

from greaseweazle.

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.

from greaseweazle.

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.

from greaseweazle.

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.

from greaseweazle.

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.

from greaseweazle.