Out of curiosity, how bad are the disk? What steps have you tried to clean/recover them? I wouldn't mind taking a look at a SCP dump to see if there is anything that can be recovered.
@SomeGuy here are several dumps attemps using SCP and TransCopy. I also made physical copies of disks using SCP and ran Spinrite on the copy in order to try to recover bad sectors. Some sectors were recovered but not all. I also copied content of disk2 and it seems fine but I was not able to copy disk1 content. https://mega.nz/file/reIiSDbZ#YRJCnN5z94X-QLx4BcbzoHTubKm9V484jZmsrpl419w
1) 11.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25] raw weak bits) 2) 13.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25]1 3) 14.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25]2
*Bad (Broken) sector
450 <-- Recovered by spinrite recovered image or sector from version 3.31 (Fixed it easily) 558 <-- Recovered by spinrite recovered image or sector from version 3.31 (Fixed it easily) 637 <-- Memory Mapped Sector filled with all F6h (Fixed it easily) 648 <-- Recovered by your Track 36-37 image. 655 <-- Recovered by your Track 36-37 image. 669 <-- Recovered by your Track 36-37 image. 705 <-- Blank Sector filled with all F6h (Fixed it easily)
Thanks for checking on that ibmpc5150. I was fiddling around with that last night using a different method and got identical results.
I used a decoded MFM stream written to a text file with the PCE tools, and then merged good reads from other revolutions or used pattern matching to repair sectors. Most of the read errors were small, just a few bits or bytes, so there was little guesswork. The important thing is all sector CRCs were intact and unaltered, so the certainty the repairs are correct is basically 100%.
Now, lets talk about what was done right an wrong here.
callmejack, you did the right thing by saving flux images first, making several, and keeping multiple revolutions (SCP defaults to just one).
Based on how some of the errors seemed to move around in each revolution, I suspect the disk was just dirty.
Before ever inserting a disk in to a drive, I carefully inspect and clean it. At minimum, a wet (with water) q-tip to wipe up and then dry any dirty spots. In really filthy cases I rinse the 5.25" disk with hot water, optionally using a drop or two of dawn dish washing soap. (Water can damage labels, so always scan first) (rinsing does not work with 3.5" disk)
When I see there are still errors usually the first thing I do is go back and re-inspect and carefully re-clean the disk. Yes, this can be time consuming but usually it is either do that or watch the disk get ripped up.
If additional flux dumps fail and the disk is not getting ripped up then I may try other drives or, as you did, using a real FDC to read the disks.
Sometimes just copying the files from a disk using genuine MS-DOS (always make sure to write protect) and mashing "retry" will get the important stuff.
Never use a disk repair tool that writes back to the disk! Tools like spinrite were not designed to handle these kinds of degrading disks. Attempting to write back through a layer of grime or to a shedding surface will just make things worse. (Also, Kryoflux purists can tell when a sector has been re-written to a professionally mastered disk, they treat that as an "error" and it invalidates the disks authenticity). Looking at the "recovered" dump, it looks like spinrite "repaired" some sectors by writing gibberish back to the sector, destroying the original data.
It very rapidly retries sector reads and even shows you the contents. I strongly suspect that in this case, since the errors were small, it would have made quick work of these disks.
Like spinrite, it can optionally "reconstruct" sectors based on multiple bad reads - but I have encountered many, many, times where small damage results in the exact same bad pattern being read over and over, rather than random junk each time, which then gets translated as a good reconstruction. I believe that is what spinrite did. So don't use that kind of option unless the data is something you can manually reconstruct, like a text file.
Disk2img does not write back to the disk, it saves the image to a file and logs errors.
I should do a software spotlight on that sometime.
If you must write back to the disk to do thing like wipe user created private documents, remove viruses, or undelete things that should be there, only do so after reading all possible data.
Finally, that last read of disk 2.... ug. The last time I saw something like that was when I accidentally got glue residue all over a disk. Oops. I'd guess possibly an attempt to clean a disk with something harsh like Isopropyl alcohol? Yea, that stuff is great at removing that nasty brown rust filled paint from those nice transparent plastic sheets. A good quality disk that is not shedding should not be harmed, but you don't know until it is too late. That is why I normally recommend just water to start with.
Among the files that callmejack dumped, the most difficult part was sector 648 on track 36 and sector 669 on track 37.
By the way, I refer to the README.DOC included in version 3.31. I recovered sector 669, but the most difficult was sector 648.
So I asked callmejack to dump track 36-37 in 10-20 times for the partm unless it was impossible to recover. I converted to PSI and IMA, but unexpectedly there were a few dumps without bed. It was included and could be modified by editing it with a binary editor.
I'm very pleased to help preserve this precious software.
@SomeGuy Thanks for the comprehensive explanation. At first I heard some "hiss" sound when I started dumping so I stopped and inspected the disk but I did not see any sign of dirt or spots so I thought it was just the noise from the inner jacket touching the disk, I was very surprised when I saw the result and there was some kind of dirt that got stuck on the head and damaged the disk. Next time I will be more careful.
When you clean a disk surface with water, how do you dry it ? wouldn't the magnetic disk get stuck to the inner of the jacket ?
I have another floppy with just one spot of mold, what would you recommend that I do to remove it ?
As for Spinrite, I thought that using it's DynaStat recovery method would help. I didn't run it on the original but on a copy of the disk I made using the "weak bit Raw" scp dump image. If you think it's not worth it, then I will use disk2img next time, As for the DIsk2 spinrite recovered, I don't know what created this strange spot. I didn't try to clean the disk, it could be that the disk I used as a copy was already damaged. Anyway I'm glad the disk content was recovered, thanks again for your advices.
Right, the key to that one, (track 36 head 0 sector 1) the way I was doing it, was that the first revolution in the first dump and the last revolution in the last dump had the bad bits in slightly different places, so all of the data was there, just bitshifted after the damage. Spliced the two together in the middle of a run of spaces. Rather than manually bitshifting all of data bytes after that I just used a RAW directive to fill in a few bits. When it matched the CRC (which was also bitshifted), clearly it was correct.
Comments
https://mega.nz/file/reIiSDbZ#YRJCnN5z94X-QLx4BcbzoHTubKm9V484jZmsrpl419w
I hope you to dump it again with 10-20 times of disk 1
But I want to dump it as partially from Track 36-37 by SCP.
(You should check Override File to dump it with selected track range.)
Example :
Disk 1 (Track 36-37)-1.scp ~ Disk 1 (Track 36-37)-20.scp
--> The reason why I analyze and use different bad sectors for treatment.
The problem is that README.DOC is broken.
I recovered Disk 1 except sector (648 / 669)
Disk 2 is recovered (restored) perfectly.
I attached Disk 2 at first.
I hope you can dump it from Track 36 (with Override File option)
1) Raw Weak Bit (5~10 times)
2) Raw without Weak Bit (5~10 times)
I think spinnaker fix is not so good.
You can save the time to dump disk partially from 36 only.
Now I recovered Disk 1 perfectly.
https://mega.nz/file/GbQhzAhJ#3NDaTQpBXGcHak6dyxFPPmaMwQx_UFWuZe6Nxoi5SSY
Thanks again.
Now this is recovered (restored) perfectly!!
I attached the file with .PSI & .IMA format.
1) 11.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25] raw weak bits)
2) 13.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25]1
3) 14.IMA <-- Converted from Pascal Compiler 3.3 - Disk 1 [5.25]2
*Bad (Broken) sector
450 <-- Recovered by spinrite recovered image or sector from version 3.31 (Fixed it easily)
558 <-- Recovered by spinrite recovered image or sector from version 3.31 (Fixed it easily)
637 <-- Memory Mapped Sector filled with all F6h (Fixed it easily)
648 <-- Recovered by your Track 36-37 image.
655 <-- Recovered by your Track 36-37 image.
669 <-- Recovered by your Track 36-37 image.
705 <-- Blank Sector filled with all F6h (Fixed it easily)
Your disk is Not so broken.
Once again I really appreciate the help from this community. Now I can post the software will all materials.
No problem.
I'm very pleased to fix (recover) rare program.
I used a decoded MFM stream written to a text file with the PCE tools, and then merged good reads from other revolutions or used pattern matching to repair sectors. Most of the read errors were small, just a few bits or bytes, so there was little guesswork. The important thing is all sector CRCs were intact and unaltered, so the certainty the repairs are correct is basically 100%.
Now, lets talk about what was done right an wrong here.
callmejack, you did the right thing by saving flux images first, making several, and keeping multiple revolutions (SCP defaults to just one).
Based on how some of the errors seemed to move around in each revolution, I suspect the disk was just dirty.
Before ever inserting a disk in to a drive, I carefully inspect and clean it. At minimum, a wet (with water) q-tip to wipe up and then dry any dirty spots. In really filthy cases I rinse the 5.25" disk with hot water, optionally using a drop or two of dawn dish washing soap. (Water can damage labels, so always scan first) (rinsing does not work with 3.5" disk)
When I see there are still errors usually the first thing I do is go back and re-inspect and carefully re-clean the disk. Yes, this can be time consuming but usually it is either do that or watch the disk get ripped up.
If additional flux dumps fail and the disk is not getting ripped up then I may try other drives or, as you did, using a real FDC to read the disks.
Sometimes just copying the files from a disk using genuine MS-DOS (always make sure to write protect) and mashing "retry" will get the important stuff.
Never use a disk repair tool that writes back to the disk! Tools like spinrite were not designed to handle these kinds of degrading disks. Attempting to write back through a layer of grime or to a shedding surface will just make things worse. (Also, Kryoflux purists can tell when a sector has been re-written to a professionally mastered disk, they treat that as an "error" and it invalidates the disks authenticity). Looking at the "recovered" dump, it looks like spinrite "repaired" some sectors by writing gibberish back to the sector, destroying the original data.
For dumping disk images with a real FDC, I strongly recommend Trixer's Disk2img http://www.oldskool.org/pc/disk2img
It very rapidly retries sector reads and even shows you the contents. I strongly suspect that in this case, since the errors were small, it would have made quick work of these disks.
Like spinrite, it can optionally "reconstruct" sectors based on multiple bad reads - but I have encountered many, many, times where small damage results in the exact same bad pattern being read over and over, rather than random junk each time, which then gets translated as a good reconstruction. I believe that is what spinrite did. So don't use that kind of option unless the data is something you can manually reconstruct, like a text file.
Disk2img does not write back to the disk, it saves the image to a file and logs errors.
I should do a software spotlight on that sometime.
If you must write back to the disk to do thing like wipe user created private documents, remove viruses, or undelete things that should be there, only do so after reading all possible data.
Finally, that last read of disk 2.... ug. The last time I saw something like that was when I accidentally got glue residue all over a disk. Oops. I'd guess possibly an attempt to clean a disk with something harsh like Isopropyl alcohol? Yea, that stuff is great at removing that nasty brown rust filled paint from those nice transparent plastic sheets. A good quality disk that is not shedding should not be harmed, but you don't know until it is too late. That is why I normally recommend just water to start with.
Among the files that callmejack dumped, the most difficult part was
sector 648 on track 36 and sector 669 on track 37.
By the way, I refer to the README.DOC included in version 3.31.
I recovered sector 669, but the most difficult was sector 648.
So I asked callmejack to dump track 36-37 in 10-20 times for the partm unless it was impossible to recover.
I converted to PSI and IMA, but unexpectedly there were a few dumps without bed.
It was included and could be modified by editing it with a binary editor.
I'm very pleased to help preserve this precious software.
I was very surprised when I saw the result and there was some kind of dirt that got stuck on the head and damaged the disk. Next time I will be more careful.
When you clean a disk surface with water, how do you dry it ? wouldn't the magnetic disk get stuck to the inner of the jacket ?
I have another floppy with just one spot of mold, what would you recommend that I do to remove it ?
As for Spinrite, I thought that using it's DynaStat recovery method would help. I didn't run it on the original but on a copy of the disk I made using the "weak bit Raw" scp dump image. If you think it's not worth it, then I will use disk2img next time, As for the DIsk2 spinrite recovered, I don't know what created this strange spot. I didn't try to clean the disk, it could be that the disk I used as a copy was already damaged.
Anyway I'm glad the disk content was recovered, thanks again for your advices.