Read Errors handling

All questions about how to use KryoFlux go here.
tect
Posts: 33
Joined: Thu Nov 04, 2010 7:58 pm

Re: Read Errors handling

Post by tect »

Great! I'm looking forward to testing this feature!
hawui1
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am

Re: Read Errors handling

Post by hawui1 »

I'm pretty sure this will help with the "stubborn" disks..

regarding instead the issue of the "missing density switch" I was able to get another confirmation..

I was able to put my hands on an ALPS DF354H911C, also this one has the "density switch" and also this one (like the SFD-321B /LEB that has the density switch) work like a charm with the AMIGA disks..
SFD-321B /LEFB instead is missing the density switch and doesn't work..
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Read Errors handling

Post by IFW »

Nice findings :)
I think it would be useful to update the drive thread with this information, if you could post there.
hawui1
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am

Re: Read Errors handling

Post by hawui1 »

I created a small xls with the info (to be reviewed) and posted it at the end of that 3d
hawui1
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am

Re: Read Errors handling

Post by hawui1 »

I checked how the "repositioning" works and I would say it's half/half working/not working..
In other words.. repositioning improves tracks readability and this can be easily seen on floppies that before I could not read successfully even trying multiple read scans.. however..

1. the stepping out/back in, in my opinion should move more tracks ahead (or backward) before coming back in place to retry to read.. it could be for example 10 tracks.. if you are a track number that is too high to step higher 10 tracks than you could step lower tracks and vice versa.. e.g. if you are at track 76 and you detect a read error you could step to track 66 and then back to 76..if you are at track 5, you could step at track 15 and then back in place on track 5 before trying to re-read. If you've room to step at higher track numbers that is always to be preferred.

2. the number of retries should be customizable.. and there should be the possibility to manually retry. In other words.. you could step 10 tracks, come back, try to read.. if it doesn't work you retry the process again and again a certain number of times (say 3 by default) but it should be possible to specify more times or less times in the command line or in the gui (say 0=no retries to 10). Furthermore, after the amount of retries is exhausted, a prompt should popup asking: read error! Would you like to retry read?
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Read Errors handling

Post by IFW »

If there was a slight problem with track positioning/stepper stepping one track will have exactly the same effect as stepping 10 tracks... see e.g. Panasonic drive service manuals describing how to correct a soft error. This might be different for other drive types, but anything reliable (as far as 5.25 drives are reliable anyway...) should work like that.

The number of retries can be set by using the -t paramater, you can set it as high as you like and it does what you describe.

There shouldn't be any popup etc coming from a console application, as things like those would disrupt the work of any frontend application such as the GUI that many people use.
hawui1
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am

Re: Read Errors handling

Post by hawui1 »

Sorry if I highlight this.. but it looks like whatever one suggests is always somewhat incorrect.. :roll:

regarding the track steps.. I don't know where you read your specs but, I'm wondering why both Amiga and PC are stepping far more tracks before retrying to read than what you do.. hear what happens when an Amiga or a PC are detecting a read error on a floppy and then hear what happens in Kryoflux with the current firmware.. the difference is a bit strange isn't it? Maybe I'm totally wrong but I have the strange sensation that if you could step some more tracks more and more errors would be corrected.. probably moving the head a bit more ahead stabilizes the rotation of the disk (that tends always to "bend" a little.. have you have heard that click clik that some disks are doing and goes away when the head moves to outer cylinders?) or maybe the stepper could recover some precision.. If I were you I would do some tests with "stubborn" disks.. in my opinion you would notice the difference..
Regarding the reliability, with disks that are 20 years old and more, you could have the best floppy drive in the world.. but you would still need/want more.. I have pack of disks where is hard to find one that doesn't have at least one broken cylinder.. (and I tried with SIX different floppy drives) despite they were kept protected..

Regarding the "disruption", I would prefer by far a disruption than an operation that goes to the end and then the disk image is USELESS.. I could appreciate a beep so that if I'm doing anything else while I'm dumping the disks the PC is attracting my attention to the fact the operation was interrupted but it seems a nonsense to me to have the PC go ahead and then have an ADF file I have just to delete to begin from scratch.. maybe that retrying some more times, even insisting, resolves the situation and allows to save the dump work done so far..
On a console application you can simply beep and display a warning line waiting for user input like plain old DOS did.. "Would you like to retry or cancel?"

lastly Thanks for pointing out -t
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Read Errors handling

Post by IFW »

The reason you hear PC and Amiga OSes seeking to track 0 and back is that they notice that the current track number recorded on the disk does not match the one they think the head is on.
You have two choices from there:
- Use the new track number and correct the stepping based on that
- Seek to track 0 (the only thing that can be verified from most disk drives using the sensor) then seek to the desired track
The latter is the preferred way as that relies on a hardware sensor rather than a software method.

Afaik the only thing that does both is the Commodore 1541 firmware, mostly because it does not have a track 0 sensor anyway on the original hardware, so it can only bang the head against the hard stop and get it misaligned eventually - seeking to track 0 must be a last resort.

When any OS seeks to track 0 and back for a simple read error, rather than a wrong track number, that is pointless - probably they just use the existing track 0 calibration routine regardless of the error type, but that's not what you need to correct the problem, it's just a very cheap programming solution using the exact same function.

KryoFlux actually moves the stepper in both directions (unlike any OS!) to try to nudge the motor to settle correctly. Exactly what the service manual recommends.
Either the drive manufacturer is wrong about this or the OS writers used the same track 0 calibration to resolve any kind of read error - make your pick ;)

I don't really think that the number of steps make any difference for a stepper - it either works and fully settles on the right track or not, as it has the use pre-defined positions.
However, I think you are right about some disks being totally unbalanced during rotation - I have noticed that myself with 5.25 disks used by Domark for C64 duplication being extremely poor quality -, a little nudge could help those, but that has nothing to do with stepper problems for real, it's just the poor quality of the disk in the first place.

I think that gradually increasing/descreasing the step distance could help to rebalance the disk a bit - but that is not based on any fact, so... we'll see... :roll:

Note, that DTC is a console application that cannot possibly take user input - apart from a break signal - via user interaction as front-ends such as the already available GUI would break if that ever happened.

As for disruption: you have the choice to stop the operation.
If you set your parameters to whatever you think is the highest number of retries that would ever yield a result, stopping the imaging is pointless - the disk is beyond repair, you couldn't salvage the data there, however you do need whatever you can get off the disk.

I am willing to bet that most people here would prefer to have a broken image rather than no image at all, especially those who work on archiving old disks.

Having said that, I can see the value of your suggestion for specific use cases.
I think having a command line option to stop imaging on an unrecoverable read error would make both parties happy.
Would that be something that works for you?
Are you using the GUI or DTC?
hawui1
Posts: 27
Joined: Sun Aug 14, 2011 9:40 am

Re: Read Errors handling

Post by hawui1 »

I think having a command line option to stop imaging on an unrecoverable read error would make both parties happy.
Would that be something that works for you?
yep, it would do the job.. it should say "Unrecoverable error found track = XX head = YY" and stop (a beep while the message is displayed would help as well, as I said)
Are you using the GUI or DTC?
most of times GUI.. but also DTC..
User avatar
IFW
Posts: 3080
Joined: Mon Nov 08, 2010 2:42 pm

Re: Read Errors handling

Post by IFW »

In that case stop on error should be supported by both.
Which one is preferred first?
Post Reply