ADF vs SCP read errors nDOS and bad sectors
#1
Hi

I bought a Supercard pro, and I love it! So happy to finally be able to recover these old Amiga disks, because the internal Amiga drive is broken and PC's can't read the disks.   

I'm currently salvaging badly damaged (moist & mold) Amiga disks, which I recovered from a basement.


I use a Supercard pro hardware v1.1 , Firmware v1.2 with two different floppy drives:
- Sony MPF920
- Samsung SFD-321J
Both drives work flawlessly (i think) 

I can't read the disks directly, because the dirt, mold and what not, will stick to the heads immediately. So I remove the disk from it's casing, and clean it with a solution based on alcohol and some detergent. Then I place it in an empty and clean casing and rip the disk. First I make an ADF. The (green/yellow/red) status of the tracks give me a quick impression of the disk's condition. When it's ok (all green or green with some yellow) I take a 5 revolutions SCP image.

What I found though is that all green tracks don't mean that they are 100% ok. In fact. When an image is all green, I still get many errors while reading the disk in WinUAE. When I replace the copy with the SCP image of the same disk, there are less erros (or none). Why does the Amiga OS complain about it when the Checksum is ok (all green)?

Does this mean that there is a bug in the recovery software? Or is the Amiga's OS using a different way of Checksum than Supercard Pro?
Reply
#2
All green means 100% checksum'd correctly.  Can you send me the .scp image file (that converts to all green) for verification?  Send it to [data @ cbmstuff.com].  I have never seen this happen, and nobody has reported this problem before.

A .adf image just contains sector data (no header or anything like that), so there should be no way that you are getting a checksum error with WinUAE when using an .adf image!
Reply
#3
(03-06-2016, 01:55 PM)admin Wrote: All green means 100% checksum'd correctly.  Can you send me the .scp image file (that converts to all green) for verification?  Send it to [data @ cbmstuff.com].  I have never seen this happen, and nobody has reported this problem before.

A .adf image just contains sector data (no header or anything like that), so there should be no way that you are getting a checksum error with WinUAE when using an .adf image!

Well , to clarify a bit. I'm getting a "read/write" error. 
[Image: Amiga1.JPG?raw=1]
I'm making an ADF , all green. But when I try to copy the files to HD ( using Disk Master 1.3 ) , a Amaga Dos Popup shows up " Volume OctaMED 2.0 has a read/write error [retry] [cancel]".
Right after making the ADF , I also make an SCP ( 2 revolutions ). When I try to copy files to HD using that images all goes well.
When I convert that SCP to ADF , all goes well too. 

So the only thing that's not going right is the ADF image straight from the disk. 

I send you a link to the files.
Reply
#4
I got the file but I have not checked it yet. You say that you can convert .scp to .adf without any problems, but the .adf created from disk has a read/write error (which is physically impossible with a .adf). Have you compared the .adf files created using both methods??
Reply
#5
(03-10-2016, 09:31 PM)admin Wrote: I got the file but I have not checked it yet.  You say that you can convert .scp to .adf without any problems, but the .adf created from disk has a read/write error (which is physically impossible with a .adf).  Have you compared the .adf files created using both methods??

I compared the two. You can see screenshots by downloading this link:
https://www.dropbox.com/s/5ekdlkf4bmlghr...n.rar?dl=0
009.png the first difference
[Image: 009.png?raw=1]
010.png the second difference
[Image: 010.png?raw=1]

Left is the working ADF, right is the one giving the read/write error.
Reply
#6
I see the difference but even there was complete junk in the file it can not generate a read/write error because .adf files contain just sector data, not header information, checksums, etc.  I don't see how it is physically possible to ever have a read/write error with an .adf image.

The code that pulls the image from disk and converts it to .adf is the very same code used to go from a .scp image to .adf image, which makes the issue of not getting the same data even more odd.  I suppose it is possible that just by chance the checksum passes with invalid data, but that would be the same on a real Amiga with a real disk.
Reply
#7
One thing for sure is that you have a problem with your disk drive. The screenshot of the flux data shows a "wave" instead of a flat line. That is cause by a drive speed variation, typically due to either a disk that is really tight in the plastic enclosure, or you are not powering the drive correctly.
Reply
#8
OK, I scanned both disk images with several Amiga copy programs, and even copied the disks just fine. There are no read/write errors in the images (because that is not possible). However, the problem you see (that shows a read/write error when it is actually not) has to do with the fact that file link data is invalid. It looks like this is a case where it just so happens that the Amiga sector data checksum'd correctly. The Amiga's checksum technique is not the most robust, so it's possible that you can have invalid data checksum correctly. The checksum is the only thing we have to go by for determining if the data is really good or not. This is the first time I have seen this since back in the 90's when I had a disk do the same thing.
Reply
#9
(03-11-2016, 09:45 AM)admin Wrote: OK, I scanned both disk images with several Amiga copy programs, and even copied the disks just fine.  There are no read/write errors in the images (because that is not possible).  However, the problem you see (that shows a read/write error when it is actually not) has to do with the fact that file link data is invalid.  It looks like this is a case where it just so happens that the Amiga sector data checksum'd correctly.  The Amiga's checksum technique is not the most robust, so it's possible that you can have invalid data checksum correctly.  The checksum is the only thing we have to go by for determining if the data is really good or not.  This is the first time I have seen this since back in the 90's when I had a disk do the same thing.

Hey Thanks for putting in your time.

The disks are old, badly kept and have visible dirt spots on the surface. After I clean them with a alcohol/detergent solution they are still barely readable. So I guess this is a situation where the check-sum is put to a test like never before. 

I also found out that X-copy and the likes are not showing errors at all. They copy even the most miserable images just fine, but the copy is broken. I looked for a chkdsk equivalent on Amiga OS, but it doesn't exist besides maybe Disksalv, which isn't what I need. I check if the disk is fine by doing a DOS copy to RAM (or HD for keeping), file by file.

I didn't notice any corruption in data files though (yet). If the check-sum was prone to so many mistakes, I guess it should show up there as well?

I'm trying to make sense of the ADF format and sector layout of Amiga disks so I can change things in a HEX editor, but I'm not quite there yet. ;-)
Reply
#10
The 'wave' in the flux data can only be caused by the rotational speed of the disk. Typically, this is almost always due to the drive itself and not the disk, but a disk with clumps of debris can cause this as well. You might want to change USB cables or ports to see if that makes a difference for powering the drive (unless you are using an external power source, in which case it is just flat bad). You could also try a different drive as well. Don't forget that you should be cleaning the disk heads every time you read a disk.
Reply




Users browsing this thread: 1 Guest(s)