Here’s an update on the flippy disk problem for this week. In retrospect, that the reed switch was operating correctly was obvious: since wiring to the photo sensor was cut and rerouted to the reed switch and the regular side of the disks were being imaged, clearly the switch is operating correctly. Otherwise, the drive would error out for lack of a pulse for the index hole. (Slapping forehead.)
Instead the problem likely lays in the second, user-created write-unprotect notch. For the set of C64 disks at hand, these are circular and probably dealt with a hole punch. Using a disk with a larger unprotect notch (a straight-edged cut more similar to the manufacturer’s) did allow the FC5025 to read the flip side.
It seems then that the drive must detect a write-unprotect notch, or it will not be able to read any tracks. I have not located anything in the Fc5025 documentation indicating that it is unable to image write-protected disks, so it may be that rewiring the drive has introduced some logic which insists that an undetected write-unprotect notch prevent track reads.
There is also a collection of Loadstar disks here. For the disks that have a second write-unprotect notch (all but a few out of about fifty disks), both sides have been imaged fine by the FC5025 in D64 image format. However, we are considering taking G64 images of these disks as well. This format may allow the transfer of data used in copy-protected schemes which would otherwise be overlooked by the D64 format. As I’ve been learning at the C64 Preservation Project and ShadowM’s Commodore 64 site, the Commodore 1541 drive has an I/O, ROM, RAM and CPU. Code can therefore be sent to the drive and this is the basis of very wide variety of copy-protection schemes embedded in the Group Code Recording encoding of the disks. These may range from data stored in the unused upper five tracks of C64 disks (tracks 35-40) to strange header and gap data and custom formats.
Walker Sampson 