search

keirf / greaseweazle

Tools for accessing a floppy drive at the raw flux level
The Unlicense
983 stars 97 forks source link

Solved fluxmap support for IBM PC (upd765a) formats #229

Open tdaede opened 2 years ago

tdaede commented 2 years ago

A2R has a concept of a "solved fluxmap" - e.g. a flux map that has been machine generated to be perfect, not a raw read from a disk.

These can be created with gw indirectly right now, by reading to an image format and then writing back to a flux image. However, doing so loses some data that can be seen by the upd765a's Read Track command.

There are several ways to fix this. One method that I'd like to try is doing a full decode of the track (and multiple retries, if needed, to get the best possible read) but then extracting the post-PLL-recovery bitstream and encoding that to the solved fluxmap, possibly with a small amount of rotation around the index.

keirf commented 2 years ago

To preserve gap protections etc?

tdaede commented 2 years ago

Yes. This isn't the only way to do it, of course. This method has some downsides, too - it can't combine good sectors from separate reads, it preserves potentially useless data between sectors, etc.

keirf commented 1 year ago

We now have raw.* formats which simply convert a raw track to bitcells at a specified clock rate, index-to-index. Also in next release I plan to implement a generic IBM track resolver which will scrape FM/MFM sectors at a range of usual clock rates (say, 125, 250, 500kbps at 300, 360rpm). Between these two will we have enough to call this feature done? I will also be implementing write support for D88 and IMD files so that resolved IBM tracks can be written to these image types.

tdaede commented 1 year ago

Yeah the raw.* formats should be enough, I'll try them out and see what happens.

I was thinking that it would also be good to run the decode in this case so that the "best" of multiple tracks can be used, but I'll have to play around and figure out how much of an actual problem that is first.

tdaede commented 1 year ago

FWIW I've been testing the raw.* formats with HFE and it's worked great so far. My current workflow then involves checking that the result is reasonable with HxCTools, but of course having a generic IBM track resolver could avoid that step (and potentially allow rereads during dumping). That would be enough to close this.

I've run into a couple of other minor issues but I'll file them separately.

keirf commented 1 year ago

You should try the new format ibm.scan