My roommate was having trouble copying 360k disks and came to me for help. I took a look
In the current SCP release 2.40, it seems 96-TPI drives are not being double-stepped when dealing with IBM 360k formats during some operations.
This occurs when reading using the analyzer/editor (every other track is showing random flux.) The analyzer shows a track range of 41 so it should know to double-step when the drive type is properly specified as 96 TPI.
This also occurs when writing 360k SCP images back to disk using copier. It writes 96-TPI, covering only half the disk. No workaround for this!
READING a disk to create a 360k image is not affected. These create fine and are readable in HxC and similar.
Of course we're verifying that the setting for drive type is 96-TPI and read/write density is low. Drives tested were a TEAC and a Panasonic JU-475-4.
In the current SCP release 2.40, it seems 96-TPI drives are not being double-stepped when dealing with IBM 360k formats during some operations.
This occurs when reading using the analyzer/editor (every other track is showing random flux.) The analyzer shows a track range of 41 so it should know to double-step when the drive type is properly specified as 96 TPI.
This also occurs when writing 360k SCP images back to disk using copier. It writes 96-TPI, covering only half the disk. No workaround for this!
READING a disk to create a 360k image is not affected. These create fine and are readable in HxC and similar.
Of course we're verifying that the setting for drive type is 96-TPI and read/write density is low. Drives tested were a TEAC and a Panasonic JU-475-4.