.adf to .scp to real disk
#1
Hi All,

I'm having real trouble converting a .adf to a real disk, once I have tried to recover files.
I use the SCP > ADF mode to do recovery and set reties to 13 however, it normally only tries 5 or so times.
Anyway, I use WinUAE to read the image and get my files off it.
If I then use HxCFloppyEmulator_soft to convert .adf to .scp file.
Then I use the SCP v2.10 to Override File and pop on INDEX mode, Select Amiga and write the image back to a real disk.
It seems to be doing the correct thing and I have a nice blue two-tone image to say all is well, however, if I then try to re-image that disk as INDEX or SPLICE to an .adf file again, it fails every time and gives only read errors on every track.

This is the same drive I used to recover in the first place.
Does anyone have any ideas on what could be going wrong? or Is there any way to just dump from .adf image to the physical disk from the SCP hardware?
I cannot get this HxCFloppyEmulator software to work properly

A second question.
If I attach a .scp file to WinUAE and get the data off it and then format that image to create a new structure for writing without errors and copy my files back over, the .scp file is "unknown" to SCP v2.10 and unable to be used. Works fine in WinUAE though.


Thanks, everyone :-)
Reply
#2
Make sure you are cleaning the heads frequently.

HxC has no problems (at least the latest beta doesn't) converting .adf to .scp. Doing the override is the correct way. Does that disk work in a real Amiga after writing it back? I don't support writing anything except .scp image format. HxC, Aufit, SamDisk, Keir's Disk Utils, PCE Tools, etc. all support creating .scp images from various disk formats.

WinUAE does not support writing to .scp images.
Reply
#3
(05-18-2020, 03:02 AM)admin Wrote: Make sure you are cleaning the heads frequently.

HxC has no problems (at least the latest beta doesn't) converting .adf to .scp.  Doing the override is the correct way.  Does that disk work in a real Amiga after writing it back?  I don't support writing anything except .scp image format.  HxC, Aufit, SamDisk, Keir's Disk Utils, PCE Tools, etc. all support creating .scp images from various disk formats.

WinUAE does not support writing to .scp images.
Hi Jim!,

Hope everything is well with you and yours during this trying time.

The disks don't read in a normal Ami, no. It's the exact same drive I "rip" the flux image from, all on my PC, the rips are perfect though.
Converting to .adf to get some error recovery works well. Mind you, WinUAE doesn't seem to write to .scp images correctly, only read.
If I format the .scp image inside WinUAE, SCP no longer recognises the image after. I don't know if Tony will look at that though. lol

I'll go try the beta HxCFloppyEmulator as i'm not using that, i'm using the new v2.2.2.1.
I just Load a .adf and then Export a .scp image.
Maybe I should just go try some of those others.

Just FYI, thanks for doing this. You've made a fantastic product here and your support is just amazing.
I love the SCP.
Reply
#4
(05-18-2020, 03:02 AM)admin Wrote: Make sure you are cleaning the heads frequently.

HxC has no problems (at least the latest beta doesn't) converting .adf to .scp.  Doing the override is the correct way.  Does that disk work in a real Amiga after writing it back?  I don't support writing anything except .scp image format.  HxC, Aufit, SamDisk, Keir's Disk Utils, PCE Tools, etc. all support creating .scp images from various disk formats.

WinUAE does not support writing to .scp images.
Yep, cleaning after every disk pass with isopropyl and cotton tip.
Ok, Beta HxC wasn't much better although it was somewhat improved with less red sections.
I'll try another disk drive.
Ok, I've swapped from the Sony to a Panasonic and it's no different.

*edit - I did a double disk write, 1 pass after another to see if that made the pattern any stronger. It made a little difference, most tracks are now mostly yellow instead of red.

Maybe this floppy media is too old for writes now?
*noted - no WinUAE support for .scp writes.
Reply
#5
Can you convert/export the .adf image to .scp and re-import that into HxC and see a good disk?  I will take a look.  There is nothing really magical about this.  It's worked for years this way, so I wold be surprised if something really has changed.

Toni has never supported the write option.  In fact, the .scp images should be automatically write protected within the emulation when they are loaded (to prevent the Amiga from attempting to write to them).  It sounds like the automatic write protect is not happening.  I will let Toni know.
Reply
#6
(05-19-2020, 12:53 AM)admin Wrote: Can you convert/export the .adf image to .scp and re-import that into HxC and see a good disk?  I will take a look.  There is nothing really magical about this.  It's worked for years this way, so I wold be surprised if something really has changed.

Toni has never supported the write option.  In fact, the .scp images should be automatically write protected within the emulation when they are loaded (to prevent the Amiga from attempting to write to them).  It sounds like the automatic write protect is not happening.  I will let Toni know.
Yep.
I "rip" the original test.adf image using the SCP, tracks set to 79 . There is only one yellow recovery block, the rest as green as the Irish hills.
I check it in WinUAE, lovely. I get most files back that I was hoping to.

Next, I load the test.adf into HxC.
It seems to think it has 0/84 track length even though SCP did an Index dump to 79 only. I ignore this.

If I then export it to .scf, it's a much larger dump than I expected, however, it works.
SCP when dumping to flux is half the size.

I get test_adf.scp 40,879 KB in size.

The .scp image loads into SCP all orange so, I assume it's ok.

If I then write it to a new blank disk, it writes all blue however, I force it to INDEX mode to do the write first as discussed in the forums.

Without taking out the disk, I change the options to SPC (Drive0) and Target ADF Image.

I set my SCP to Amiga and tracks to 79, just because I know it's supposed to be a 79 track length image and I press Make Image.

Right away, I get yellows on the first reads. Closer to the end of the newly written disk, I start to get some greens.
I did the same with a second disk drive (Panasonic) as well. I have a similar result.

I ran a speed test and I get a range of 299.642 to 299.672
Reply
#7
(05-19-2020, 12:53 AM)admin Wrote: Can you convert/export the .adf image to .scp and re-import that into HxC and see a good disk?  I will take a look.  There is nothing really magical about this.  It's worked for years this way, so I wold be surprised if something really has changed.

Toni has never supported the write option.  In fact, the .scp images should be automatically write protected within the emulation when they are loaded (to prevent the Amiga from attempting to write to them).  It sounds like the automatic write protect is not happening.  I will let Toni know.
Just to add to this, I have now tried this with 6 different disks, out of the packet and I have also checked this against my 2nd, spare SCP.

Also, when trying to recover the boot block, I find SCP doesn't try stepping the head up and back. The stepper motor isn't moving not even like a nibble half-step.
Is there a setting to make it try to do this?
I have the retries set to 99 but it makes no difference.
Reply
#8
You can't make the head move "half of a step". It's a full step per track for the Amiga. You don't really need to move the head. I will probably end up removing that "feature" as it really doesn't seem to do anything. Cleaning your heads (and the disk when necessary) is the only thing that is going to help recover a disk.

I will look into the HxC thing. I am testing a new beta version right now. The only odd thing I have seen it do is double the size of the image because it converts an .ADF to .SCP as 2 revolutions sometimes.
Reply
#9
(05-20-2020, 11:59 PM)admin Wrote: You can't make the head move "half of a step".  It's a full step per track for the Amiga.  You don't really need to move the head.  I will probably end up removing  that "feature" as it really doesn't seem to do anything.  Cleaning your heads (and the disk when necessary) is the only thing that is going to help recover a disk.

I will look into the HxC thing. I am testing a new beta version right now.  The only odd thing I have seen it do is double the size of the image because it converts an .ADF to .SCP as 2 revolutions sometimes.
Really? I mean the head step thing has really helped on the stuff over track zero for me. I'm almost sure of it.

I watched it do it yesterday while testing. It seems to be enough to rattle the head to grab a weak bit on my disks, especially for the older disks.

I have even resorted to manually tapping the head gently with a plastic fork on the error to grab a recovery as a last resort attempt (It honestly has helped) for the upper head reads. Can't do that to the bottom head though. I think that my Panasonic drive is less aligned to the Sony, however, I think it's a really useful feature, anyway, you're the boss, I am grateful for your time and efforts as a user no matter what.

I actually wish it would retry more to get a "green" read though. I have found that yellow doesn't always mean ok.



Ahhh, that makes more sense on the HxC program.

I tried a new batch of floppies today. I just don't understand why I have errors. I have 2 SCP devices, both are doing the same thing.
I have some other drives I salvaged at work from old servers as well, they are all doing the same thing, so that's 4 drives now, 2 of which I haven't opened or tapped with a fork

Maybe because the disks were pre-formatted IBM 1.44 ?
Reply
#10
What exact "errors" are you referring to, the media test, or the process with HxC that you are trying?

I have found that about 5% of my brand new in the box 3.5" disks are still good.  Something about the passage of time with 3.5" disks.  I see errors starting around track 72 during a media test.  When looking at the flux data visually using the editor/analyzer's flux display option, it's clear that there is in fact a problem because the flux data is wildly distorted.  I can take the same disk and it fails formatting with a USB floppy drive plugged into my PC, so it really is a disk issue.

Any previous format won't matter.  The head assembly has an erase head that sits before the actual write head and that wipes out the data before an actual write occurs.

If you can simply tap the head and pickup data that would indicate an alignment issue between the disk and the drive.  This is not that uncommon, but usually far more common with 5.25" drives.  If a drive is slightly out of alignment from factory spec any disk formatted using that drive will read just fine in that drive, but may not read in any other drive that is in factory spec.  The only thing that shuffling the head can do really is to move the read head slightly off center of the track if the drive head stepping assembly is worn out (sloppy) and the head doesn't quite move the same each time.  In reality you shouldn't be using that drive at all for archiving disks if that actually works as it will be unreliable.

91% IPA with a fiber cleaning disk is the only thing I recommend for cleaning a disk drive.  You can't "scrub" the heads near well enough with just a cotton swab.  I also usually have to clean the surface of 3.5" disks using a microfiber and 91% IPA.  For whatever reason, 3.5" disks did not stand the test of time.  I have 5.25" disks from the late 70's that were stored in horrible conditions that still read/write perfectly today, and I have boxes of brand new disks that were stored in a climate controlled environment that won't format.

Yellow means that one or more sectors were not able to be recovered.
Reply




Users browsing this thread: 1 Guest(s)