Greaseweazle confusion

[Rissy]

Hey all.

I'm hoping someone knows the answer to this one.

I've now got myself armed with a GW. I've had some great success with it over the past two nights, but i've also had some failures too. I'm running at about 50% success rate.

Some of the disk content i'm scraping seems to be good. It works on Amiga Forever emulator on the laptop from the .scp file. But if i try to write that back to disk using GW, the result is unreadable by my Amiga. Why is this?

Is there some special settings within GW you need to set for certain content to be successfully read on the real machine again?

I've already tried many permutations of settings (not really understanding what they all mean of course, and can't seem to find an explanation on all the settings anywhere?!)

[dlfrsilver]

Why ? Very possibly because either the source you made the file from had errors, or simply because the disk you write on is bad, crap or inadequate.

[Rissy]

Originally Posted by dlfrsilver

Why ? Very possibly because either the source you made the file from had errors, or simply because the disk you write on is bad, crap or inadequate.

So to squash those suggestions, I can advise that I'd considered these things myself already. None are true.

The original disks which i'm trying to backup, still work. So no question on the original integrity of the files i'm trying to backup.

The copy procedure seems to work in the fact that the result of the copying, works in Amiga Forever Emulator just fine. Again, this would suggest that the files on the original disk(s) are good.

Trying to write this back to a floppy is where it seems to falls over.

I've tried writing the same problematic .scp file(s) to various different disks and none of them would work in the Amiga.

Just to rule out the disks being at fault, I then wrote a known good copy of a different file to the same disks, and in each case, the disks would work fine in the Amiga with the other file written to them.

So the fault seems to come from the writing of some files, but not others.

Is there some settings which people have HAD to use to get success with otherwise problematic software backups?

[dlfrsilver]

which firmware of GW are you using ?

[Rissy]

Originally Posted by dlfrsilver

which firmware of GW are you using ?

I'm using the latest (0.26) on windows and using the appropriate GUI interface with it (v2.66)

[Rissy]

really? nobody else got any help? I'm sure there are lots of you out there using a GW...

[Devlin]

If writing back to the disk is unreadable, do you have the scp format set correctly?
It may be that the write-back interprets the data as a ms-dos/mac/etc disk - winuae/AF will read it fine as it ignores that particular part of the definition - There's a tool to change the scp metadata with the gui interface - (if you're using the mikerochip one)

[Rissy]

Thanks for your reply. This is the GUI i'm using:

https://desertsagesolutions.com/greaseweazlegui/

I've been having the setting for writing back set to .scp: Amiga format (or something - i'm not in front of it right now)

I've played around with some of the other settings. According to changing some of the other settings when making it, i can get the Amiga to make different sounds and clicks etc as it tries to read the burned disk after i insert it into the Amiga drive. But the disk always fails to load. I've even had it spit back out a guru meditation at me from attempting to read it.

Considering the file plays fine in AF on my laptop, i've got to consider that the file must require a specific way of being burned back to disk for it to be readable by the Amiga.

[Rissy]

I was wondering whether it was something to do with some games being written to 82 tracks rather than 80. I think i remember reading somewhere that the Amiga can read 82 tracks, but only write 80. So some games made use of this, by having data on the other two tracks, meaning it was impossible for an Amiga to reproduce this within its own hardware....?

[solarmon]

Are the disks you are using OK?

You need to make sure that the written disk is clean and has no errors.

Always read the image back and check in HxC Floppy Emulator Software to see if there are any errors. Show the read back image here.

Also, I find that wiping the disk with a strong neodynium magnet before writing the image can help shift some stubborn magnetic media issues, if any.

Share your SCP image so that I can try writing them to disk and see if it works for me.

[Rissy]

Originally Posted by solarmon

Are the disks you are using OK?

You need to make sure that the written disk is clean and has no errors.

I'm pretty sure. I'm limiting myself now to just concentrating my results on the one disk. I've successfully used this disk with quite a few scrapings of other disks, and they work with that disk in the Amiga no problem. I've also tried formatting this same disk with the "initialise" function in WB and it reprorted no problems with the disk either.

Originally Posted by solarmon

Always read the image back and check in HxC Floppy Emulator Software to see if there are any errors. Show the read back image here.

I've been using the emulator which is part of Amiga Forever. I think it's this one?: https://www.winuae.net/ Which is also accessible separately on my laptop without going through AF, although it appears differently. I've found both to work the same, except for the front end being different, and ive tried the same scraping files on each and both behave the same.

Originally Posted by solarmon

Also, I find that wiping the disk with a strong neodynium magnet before writing the image can help shift some stubborn magnetic media issues, if any.

I've got some here, a stack of them, and ive tried this too before writing to the disk.

Originally Posted by solarmon

Share your SCP image so that I can try writing them to disk and see if it works for me.

I'll set up a drop box folder and put stuff in there and send you the link privately.

Thank you.

[solarmon]

@Rissy,

Thanks for the SCP dump images.

I've taken a look and can see that, firstly, these are not original game images but cracked game images.

Your first image "Silly Putty d1.scp" seem to have an error in it that probably explains why it does not work in emulation:



The fact that these are cracked game disk images is important when talking about Greaseweazle. You can't write these images back as they are. They need to be converted to a format that Greaseweazle can use.

You will find that if you convert your SCP images to ADF, using HxC Floppy Emulator software, you can then use Greaseweazle to write the ADF file to disk, and if the image and the disk are OK then it should work:



Having said that, you might as well use the already available ADF images of these cracked games in the first place, rather than taking an SCP dump of your disks.

Note also that you can use Greaseweazle to dump straight to ADF for any AmigaDOS based disks - just make sure the filename ends in .adf rather than .scp.

[r.cade]

It's all about index alignment. The Amiga does not care about it, but it's important when you are writing disks. Without taking this into account, you will always get at least one bad sector on every track.

[Rissy]

Originally Posted by solarmon

@Rissy,

Thanks for the SCP dump images.

I've taken a look and can see that, firstly, these are not original game images but cracked game images.

Your first image "Silly Putty d1.scp" seem to have an error in it that probably explains why it does not work in emulation:



The fact that these are cracked game disk images is important when talking about Greaseweazle. You can't write these images back as they are. They need to be converted to a format that Greaseweazle can use.

You will find that if you convert your SCP images to ADF, using HxC Floppy Emulator software, you can then use Greaseweazle to write the ADF file to disk, and if the image and the disk are OK then it should work:



Having said that, you might as well use the already available ADF images of these cracked games in the first place, rather than taking an SCP dump of your disks.

Note also that you can use Greaseweazle to dump straight to ADF for any AmigaDOS based disks - just make sure the filename ends in .adf rather than .scp.

Hi there, thanks for looking at those for me. It's much appreciated. I have other disks which i didn't present in front of you which include disks with save files on them from games like Cannon Fodder which i was also keen to back up (This is really an amazing nostaglia trip i'm taking right now). I'm presuming the same rule will apply to backing those up too, as GW hasn't been making a good job of those either.

So now on to the questions directly regarding quotes:

Originally Posted by solarmon

I've taken a look and can see that, firstly, these are not original game images but cracked game images.

Right enough, the games i've been having success with, are originally bought legitimate ones.

Originally Posted by solarmon

Your first image "Silly Putty d1.scp" seem to have an error in it that probably explains why it does not work in emulation:

Why is it that in this case, the "original" disks still work in the Amiga, but copies don't anywhere? For other "original" (by this i mean old copied, cracked games) games, I'm managing to get them copied and when testing them, they work in the emulator. It's just that they don't once i try to burn them to disk again. It's just that one you mentioned that wont even work in the emulator.

Originally Posted by solarmon

The fact that these are cracked game disk images is important when talking about Greaseweazle. You can't write these images back as they are. They need to be converted to a format that Greaseweazle can use.

You will find that if you convert your SCP images to ADF, using HxC Floppy Emulator software, you can then use Greaseweazle to write the ADF file to disk, and if the image and the disk are OK then it should work:

How do i do this? What is this HxC Floppy software? and where do i find it?

Is this what has produced your fancy images above? what is that if not?

Originally Posted by solarmon

Note also that you can use Greaseweazle to dump straight to ADF for any AmigaDOS based disks - just make sure the filename ends in .adf rather than .scp.

I've tried this with the GW GUI, but it seems to just get stuck always complaining and retrying over missing sectors or something. Maybe i'm still doing something wrong with that setting too? How can identify AmigaDOS based disks? Is it simply a case of them being read ok within WorkBench?

Again, thank you for your ongoing help, it's very much appreciated.

[solarmon]

Yes, HxC floppy Emulator Software is what produced the visual track view of the disk dumps. Download it from:

https://hxc2001.com/download/floppy_drive_emulator/

I recommend the beta version. You can use this HxC software to convert SCP to ADF. However, as stated you might as well download the the ADF file for the game.

Writing ADF files with Greaseweazle includes write verfication which will be sensitive to media issues - so you need really clean disks for that.

Writing SCP/IPF files does not have any verification - so it will blindly write to bad disks. This is why you should then read back the disk again and check with HxC that it does not have any errors. You should also use HxC to check any dumped SCP image for any errors.

You can see in the "Silly Putty d1.scp" image that there is an any of the disk that is has orange bits. I'm am assuming that this is what is causing it to stop loading.

[Rissy]

Originally Posted by solarmon

Yes, HxC floppy Emulator Software is what produced the visual track view of the disk dumps. Download it from:

https://hxc2001.com/download/floppy_drive_emulator/

I recommend the beta version. You can use this HxC software to convert SCP to ADF. However, as stated you might as well download the the ADF file for the game.

Writing ADF files with Greaseweazle includes write verfication which will be sensitive to media issues - so you need really clean disks for that.

Writing SCP/IPF files does not have any verification - so it will blindly write to bad disks. This is why you should then read back the disk again and check with HxC that it does not have any errors. You should also use HxC to check any dumped SCP image for any errors.

You can see in the "Silly Putty d1.scp" image that there is an any of the disk that is has orange bits. I'm am assuming that this is what is causing it to stop loading.

Again, thank you!

There are SOO many links to downloads on that page! How to know which one i need to use?

Is it this one?

HxCFloppyEmulator software:
HxCFloppyEmulator_soft_beta.zip (beta/snapshot version)

[solarmon]

Yes, those are the one.

Either:

* HxCFloppyEmulator_soft.zip (https://hxc2001.com/download/floppy_...lator_soft.zip)
* HxCFloppyEmulator_soft_beta.zip (beta/snapshot version) (https://hxc2001.com/download/floppy_..._soft_beta.zip)

[Rissy]

I have to say, after spending a little bit of time looking at disks with this tool, it's facsinating stuff!

When you look at a .adf file (your bottom picture), what does the blue section (sector?) represent over and above the green sectors? I have many questions, but lets start there! LOL!

Does the different shade of green represent different gradings of quality of the data? I'd have thought it was either there, or it wasn't.

If you have a bad .adf image, and then extract it as a .scp image, is there a chance for the data lost during copy of the .adf to be recovered by converting the .scp back into a .adf? I'm asking this question as I thought the GW read magnetic flux, so if the signal was still feint enough to be picked up when reading as a .scp, then it might be able to be translated back strong enough as good data again when making it back to .adf....?

Or am i living on hopes and dreams?

[solarmon]

Yes, the HxC tool is invaluable when trying to analyse the disks.

The different green colours represent the different data types and headers. The blue areas are the underlying MFM encoding used.

Typically, you would use Grreaseweazle to do a flux dump (either SCP or RAW) and then use other tools, like HxC, to analyse and process the disks. You can increase the revs per track read to increase the amount of data for that track to better analyse/process.