Writing ADF

[LordCrass]

Using the HxC floppy emulator software, I converted an ADF file to a .scp file. This works, sort of, although two issues came up. One was that when saving the file to .scp using the HxC software, it always crashed when done. This left a 23MB scp file which I was able to load into the SCP software (it's funny looking at a perfectly timed track in the analyzer) and notice that it saved 2 rotations for each track for some reason.

So I tried writing this new scp file using the disk copier. Since it's got two rotations, I assume it's writing each track twice over, which sort of defeats the purpose of the "wipe tracks" option. Also, it wrote all the way out to track 82 and then errored out with the "Missing track identifier! - Image file is corrupted!" message and I had to end-task the app. Checking the image file with the analyzer did show that tracks 80-82 had indeed been created by HxC.

On the plus side, the copy worked! I booted it up on my A500 and ran an error check on the disk, and every track was ok.

[admin]

Interesting... I don't have a HxC - but I am ordering one. What version do you have (normal or FPGA version?). Jeff is still working on the support for it, and I just changed the format (again). We'll all get on the same page here shortly!

[LordCrass]

I don't have one either. Thinking of getting one, but for now I still like using real floppies/drives, despite their history of reliability.

You can still use the software though, as it will convert between many different types of image formats.

I haven't been able to get it to convert from .scp to .adf though. I always wind up with a damaged file that won't boot in WinUAE, even though these are AmigaDOS disks, and no matter if they are index or non-indexed images.

[admin]

Ah... I missed the fact that there is an emulator. I will grab it and check it out.

I know Jeff is working on the code for this, and I just posted the final change to the .scp file format - which shouldn't change compatibility, it didn't with my analyzer and copier - it just reduced the size of image files a bit now and allows for any number of revolutions to be stored instead of a maximum of 5.

[Jeff]

I don't have one either. Thinking of getting one, but for now I still like using real floppies/drives, despite their history of reliability.

You can still use the software though, as it will convert between many different types of image formats.

I haven't been able to get it to convert from .scp to .adf though. I always wind up with a damaged file that won't boot in WinUAE, even though these are AmigaDOS disks, and no matter if they are index or non-indexed images.

Use this one instead :

http://hxc2001.com/download/floppy_drive...t_beta.zip

i made some corrections not yet released in the non-beta version.

[admin]

Thanks Jeff!

[LordCrass]

Tried it again and this now works for converting an index-aligned ADOS .scp file to to ADF.

It doesn't work for a non-index aligned disk image, even when using the non-blind mode (2 revolutions). It seems to pull in the first revolution and convert that to ADF, which results in read errors on the disk since sectors have spanned across the index or otherwise only exist partially in the first rev and are incomplete. Basically, it's the same effect you'll get if you try to write these images back to disk.

Naturally, I had to try .ipf to .scp conversion . Unfortunately, it doesn't work, even for ipf images that contain only standard ADOS. It hangs after generating the image and the file contains bad data.

[Jeff]

Tried it again and this now works for converting an index-aligned ADOS .scp file to to ADF.

It doesn't work for a non-index aligned disk image, even when using the non-blind mode (2 revolutions). It seems to pull in the first revolution and convert that to ADF, which results in read errors on the disk since sectors have spanned across the index or otherwise only exist partially in the first rev and are incomplete. Basically, it's the same effect you'll get if you try to write these images back to disk.

mhh i suppose that this should work... can you send me the packed scp by email ?

Naturally, I had to try .ipf to .scp conversion . Unfortunately, it doesn't work, even for ipf images that contain only standard ADOS. It hangs after generating the image and the file contains bad data.

For sure this must work ! Please send me the ipf, i will correct this
(email on the hxc2001.free.fr site).

[admin]

Jeff, did you get the last version of the .scp file specification where I now allow for unlimited number of revolutions? It shouldn't break anything in your code if you are using the offsets. My code didnt break with the changes.

I would like to propose using .scp image files as a wrapper for all flux dumped images by making the reserved word in the header (0x00A-0B) the actual flux capture frequency (a base time, the minimum time per bit cell). This base time value would be multiplied by 100. So, SCP's 25ns flux times would give you a value of 2500. Kryoflux's 41.66ns flux times would give you a value of 4166. The Discovery Cartridge's 66.66ns flux times would give you a value of 6666. There are a couple of other flux copiers, one that is FPGA based and uses a 10ns capture, giving you a value of 1000. Using this method, ALL of the different flux copier's flux data could be stored in the .scp file format and then universally used. In your case, the only change you would make to your existing .scp support would be to look at the base time word and use that info as your multiplier for flux timing. To maintain backwards compatibility, any base time of 0x0000 would default to a value of 2500. It would be easy enough for me to convert any flux data contained within the image file to the proper timing for writing out to disk, no matter what flux device originally created the data. Your Thoughts?