I received my SCP yesterday and installed it today on a 32-bit XP SP3 machine w/ 3GB RAM (SOYO mobo, AMD Athlon CPU, no overclock). I installed the software as recommended before connecting the card to a USB port. From the SCP I am running a Panasonic 3.5-inch 1.4 MB drive which the software recognizes as drive 0. Windows recognized the device as USB / Serial device.
Selecting "Disk Copier" as the function and Amiga as the format, I created images of several disks known to operate with my Amiga 500 and which I had previously copied ON the Amiga using a software utility called Project D. I accepted all SCP defaults for these copies.
Copying indicated success (all green cells) creating an image (.scp, not .adf, with preservation) and after copying I made duplicate disks, again without errors, of three files that I knew had boot tracks on them and were therefore bootable on an Amiga. One of the three, a Workbench 1.3 disk copy, booted successfully; two others did not. The Amiga did not recognize the others as DOS disks.
I loaded the images into the analyzer and noticed that the WB disk started with "801555555..." while the other two started with "AAAAAAA..." Obviously there is a difference but what it signifies is lost on me. Could someone please suggest a direction for further research?
Thanks for your reply.
Charles Hudson
clh333
It could be that the other disks were not created with a mastering machine and so they will not work in index mode. You would need to use SPLiCE mode instead. GREEN only shows when you are making a .adf image, not when making .scp images or copying disks.
(04-14-2015, 05:02 PM)admin Wrote: [ -> ]It could be that the other disks were not created with a mastering machine and so they will not work in index mode. You would need to use SPLiCE mode instead. GREEN only shows when you are making a .adf image, not when making .scp images or copying disks.
Thank you for your reply.
Following your advice I made another copy of each of the two disks that were unsuccessful in INDEX mode. The titles were Supra Boot and Baud Bandit. I verified that the original distribution disk would boot on the Amiga. I verified the target disk was writable with the disk utility; I also tried pre-formatting the target disks on the Amiga and played with the "wipe track" switch.
Creating the copy in SPLICE mode resulted in copies that were at least recognizable to Amiga DOS, although the disks were either flagged as having an error or as needing a visit from DiskDoctor. The Amiga DiskDoctor utility noted "hard" errors on more than a dozen tracks across the Supra disk. It was able to "resurrect" the disk but noted that data was lost.
I am attaching JPEG screen shots of the Analyzer's read of the original Baud Bandit disk and the "spliced" copy as written back to disk. I can see differences between them, but don't know if the differences are significant. Can you help me understand what I am seeing?
Thanks again,
Charles Hudson
clh333
[
attachment=52][
attachment=53]
What you are seeing are Amiga MFM data. Depending on the how the bits are shifted, you will see AA or 55. This is normal.
Can you make a .adf image with all green boxes?
Yes, I can copy the original disk to an ADF image file and all 80 boxes are green. JPEG screen shot attached.
I can not write this ADF file back to disk, however, through the SCP disk copier interface. I get the checksum error message also illustrated in the attached JPEG.
The ADF file is 880K, and could be compressed using LHA or ARC, fit onto a 720K PC-formatted floppy and carried over to the Amiga, where I have a utility to read PC-formatted disks. From there it could be extracted and then written back to an Amiga-formatted floppy. A hard disk and a second (1010) floppy drive make the process simpler, of course.
Is this the recommended procedure, or is there a shortcut?
-CH-
[
attachment=54] [
attachment=55]
Yes, that could be. When a disk is not originally created using the index pulse to start/stop tracks, you need to use the SPLICE mode. It's not perfect for sure, which is why I made the .adf image file creation. I need to improve the SPLICE mode and also allow writing back .adf images. However, in the mean time, you can use the HxC Floppy Drive Emulator software to convert .adf to .scp (and vice-versa) and write the image to disk.
(04-16-2015, 12:44 PM)admin Wrote: [ -> ]Yes, that could be. When a disk is not originally created using the index pulse to start/stop tracks, you need to use the SPLICE mode. It's not perfect for sure, which is why I made the .adf image file creation. I need to improve the SPLICE mode and also allow writing back .adf images. However, in the mean time, you can use the HxC Floppy Drive Emulator software to convert .adf to .scp (and vice-versa) and write the image to disk.
Thank you for your reply. Following your suggestion I downloaded the HxC software and used it to convert the .ADF image created with the SuperCard Pro back to an .SCP image. I then opened this image in the SCP utility and wrote it to disk. The resulting disk booted successfully on the Amiga.
Interestingly, the ADF file converted by the HxC software into an SCP file gained an extra three tracks in the process. I am attaching JPEG images to show the following: The indexed SCP copy, made using the defaults, read tracks 0-79; the spliced SCP did the same; and the ADF copy, which was also made using the defaults, showed only 80 tracks as well. But the HxC conversion found 83 tracks, 0-82; and the new disk's Analyzer track display is quite different as well.
The Panasonic drive wrote to track 82 without complaint, to my surprise. Now I'm wondering whether my best practice would be to always follow this procedure: Create ADF copies of all disks as a matter of course and convert them to SCP when needed for writing? Or is the "blind copy" - which I assume means using indexed mode and tracks 0-79 as a default - still the best approach? or should I always read out to track 82 in any copy mode? What would be your suggestion?
Thanks again,
Charles Hudson
clh333
[
attachment=56] [
attachment=57] [
attachment=58] [
attachment=59]
AmigaDOS only used 80 tracks (0-79), so I am not sure why the .adf created with HxC would copy the extra tracks. Sometimes (rarely), those tracks are used by copy protection schemes, but since the .adf format itself does not handle copy protection at all it is odd that you would care about extra tracks. Maybe this is to handle a custom floppy format that is sector based (getting extra data on a floppy)?
Some floppy drives can not read/write the extra tracks. You can test your drive to see if it really does support up to track 83 by using the Maximum Track Test in the Utilities section.