Bad* + Modified, no retries?

All questions regarding the dumping of media go here.
Post Reply
hydr0x
Posts: 104
Joined: Wed Dec 29, 2010 4:01 pm

Bad* + Modified, no retries?

Post by hydr0x » Wed Oct 28, 2015 1:01 pm

I'm experiencing something I can't quite understand. I'm dumping through the GUI but I don't think that matters. The first track on this floppy shows up as Bad* + Modified. I wouldn't even have noticed this if the GUI hadn't shown "1 bad" in the status bar. There's two things that I can't understand here:

1) Why does the GUI show this as H (orange). It's more important to know it's bad than to know it is modified. Imho it should show this track red.

2) Why are there no retries? If the track is bad, dtc should retry. It seems the decision tree is wrong here. This might be related to the other retry bug I mentioned a while ago. Edit: Aha, reading that thread again, Istvan mentions "there is another recent thread with a request for optionally treating missing sectors as bad". The log shows these as missing indeed, so that might be the problem here too. It's definitely inconsistent either way though

Also, looking at the log, I wonder why max_track is shown as 83. I calibrated the drive and it's 81 and does show 81 in the GUI. It didn't try going beyond 81 either.

Code: Select all

00081be4: status=0
00081bf8: status=0
00081c0c: reset=0
0008205e: info=1, name=KryoFlux DiskSystem, version=2.20s, date=Dec 30 2012, time=02:33:19
00082072: info=2, hwid=1, hwrv=1, sck=24027428.5714285, ick=3003428.5714285625, wb=32768, wa=64, wq=8, wt=65535, wm=26
00082086: device=0
0008209a: density=0
000820ae: min_track=0
000820c2: max_track=83
KryoFlux DiskTool Console, v2.51_Win32, uiv.1, Oct 29 2014, 16:45:42
(c) 2009-2014 KryoFlux Products & Services Ltd.
Developed by The Software Preservation Society, www.softpres.org
Licensed for private, non-commercial use only.
000820d6: motor=1
00082457: side=0
0008246b: track=0
0008247f: stream=1
0008291b: stream=0
00.0    : frev: 45467, drift: 0.225 us, tfer: 217958 B/s, rpm: 300.055
00.0    : band: 1.575 us?, 1.975 us, 3.995 us, 5.955 us, 7.966 us
00.0    : base: 1.985 us [99.532%], band: 1.975 us, 3.995 us, 5.955 us
00.0    : MFM: <error>, trk: 000, sec: 9, mis: 4, *H +5
00082993: motor=1
000829a7: side=1
000829bc: track=0
000829d0: stream=1
00082eaf: stream=0
00.1    : frev: 43710, drift: 0.558 us, tfer: 210166 B/s, rpm: 300.036
00.1    : band: 3.993 us, 5.979 us, 7.983 us
00.1    : base: 1.993 us [99.749%], band: 3.993 us, 5.979 us, 7.983 us
00.1    : MFM: OK, trk: 000, sec: 9

User avatar
Mayhem
Posts: 229
Joined: Mon Apr 16, 2012 5:52 pm
Location: London, England
Contact:

Re: Bad* + Modified, no retries?

Post by Mayhem » Wed Oct 28, 2015 2:13 pm

I had a disk recently (would have to go back through the dumping thread to check which) with exactly the same thing, it was marked as bad, but didn't retry dumping it. G64 of the stream loaded fine in VICE.
Lie with passion and be forever damned...

anormal
Posts: 22
Joined: Sat Jul 19, 2014 1:44 pm

Re: Bad* + Modified, no retries?

Post by anormal » Wed Mar 02, 2016 1:21 pm

Any more information about this?

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Bad* + Modified, no retries?

Post by IFW » Wed Mar 02, 2016 1:35 pm

What exactly?

SomeGuy
Posts: 230
Joined: Wed Feb 18, 2015 8:18 pm

Re: Bad* + Modified, no retries?

Post by SomeGuy » Wed Mar 02, 2016 3:53 pm

The underlying issue is that the Kryoflux has no way to know for sure what your disk's sector geometry is supposed to look like. As such it make assumptions that some kinds of "errors" are part of copy protection schemes and are therefore normal.

Similarly, because the Kryoflux is geared more towards being a preservation tool for copy protected software rather than a tool for user data archival or system interoperability, they made the decision that detection of potentially "modified" sectors should take priority over these kinds of errors.

ZrX
Posts: 557
Joined: Tue Dec 06, 2011 9:09 pm

Re: Bad* + Modified, no retries?

Post by ZrX » Wed Mar 02, 2016 6:49 pm

I'm still hoping to see the option to force retrying in case of missing sectors as most often they're missing due to some disk error.

User avatar
mr.vince
Posts: 2120
Joined: Tue Oct 05, 2010 5:48 pm

Re: Bad* + Modified, no retries?

Post by mr.vince » Wed Mar 02, 2016 8:56 pm

We'll put this on the list.

User avatar
IFW
Posts: 3079
Joined: Mon Nov 08, 2010 2:42 pm

Re: Bad* + Modified, no retries?

Post by IFW » Thu Mar 03, 2016 5:34 pm

Starting with the next DTC release missing sectors will be treated as bad sectors and will be retried during read operations.
You will be able to disable this new behavior by specifying -tm0 as an additional parameter.

hydr0x
Posts: 104
Joined: Wed Dec 29, 2010 4:01 pm

Re: Bad* + Modified, no retries?

Post by hydr0x » Thu Mar 03, 2016 7:25 pm

Thanks a lot, much appreciated :)

Post Reply