search

keirf / greaseweazle

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

Option for marking of the BAD sectors or leaving bad data. #273

Open kaunomedis opened 1 year ago

kaunomedis commented 1 year ago

By default, when reading with new disk format option to HFE format, bad sectors are filled with "-=[BAD SECTOR]=-". Is it possible not to fill it with text, but leave salvaged data. Just another option please :)

For CP/M it will save 1K of data... request

We can see that there is some readable data in bad sector... Meanwhile: T9.0: IBM MFM (4/5 sectors) from Raw Flux (10794155 flux in 43071.99ms) (Retry #6.6) T9.0: Giving up: 1 sectors missing Even after 6x6 retries the sector is filled with "bad block text".

I don't know, maybe there is such option?

keirf commented 1 year ago

I will have a look how easy this is to implement. I fear the danger with this behaviour by default would be that it would be too easy to "launder" bad sectors to appear good, and this would risk proliferation of subtly broken image files. But as a recovery option I can see the sense in it.

Telev78 commented 1 year ago

See this today when i dump a floppy with one bad sector ... Now the problem is that the raw flux is marked as 100% valid. HxC does not mark the sector as bad, and the same when using gw convert. Is it possible, for example, to put a bad CRC? Thus the sector will always be indicated as bad. image

keirf commented 1 year ago

What was your gw read command line? If you only wanted verification checks and not for the flux file to be "recreated" by the Greaseweazle IBM codec, you could have passed --raw to gw read. But the point about trying to keep data but mark a bad CRC, where possible, is a good one. It is on the to-do with plenty of other stuff.

Telev78 commented 1 year ago

ho yes forget the --raw parameter in my command line

edit : now HxC report the bad sector and the gw convert report also the bad sector. Simply forget the parameter ...

Telev78 commented 1 year ago

So, to understand well, there is a difference between gw read --format ibm.1440 track00.0.raw and gw read --format ibm.1440 --raw track00.0.raw

The two commands write in the same output format, but the raw data is different ?

keirf commented 1 year ago

That is correct. The former regenerates the track based on sector data decoded from the original flux. The latter writes the original flux, however it does use the ibm.1440 codec to check for missing sectors so that the usual retry logic works.

Telev78 commented 1 year ago

ok now it's make sense. i'm not aware of this difference before.

keirf commented 1 year ago

Your original comment about writing an incorrect CRC in the regenerated track still stands, though. That could still be a good idea. I'm not sure.

keirf commented 1 year ago

Your original comment about writing an incorrect CRC in the regenerated track still stands, though. That could still be a good idea. I'm not sure. It's probably better than trashing the data completely, and writing a good CRC.

Telev78 commented 1 year ago

to me, that makes sense. So we realize during the conversion or with other software like HxC that the image has bad sectors.

kaunomedis commented 1 year ago

I like the idea of bad CRC value to mark bad sector, but only AS OPTION. And I don't know, but some "original" games in 8bit Atari and in Amiga used some "bad sector" trick as copy protection. So, sometimes it is useful to leave CRC and data mismatched.

I not very deep in this- I used gw to salvage some text documents and I was in need to get sector data. Because 1K sector is one page of text and even half page of text is better than full page of dummy text.