Flippy Disks, Continued

by wsampson


Loadstar magazine, Issue 142, Disk 1

Loadstar magazine, Issue 142, Disk 1

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.

Manufacturer's write-unprotect notch

Manufacturer's write-unprotect notch

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.

Custom hole-punched write-unprotect notch

Custom hole-punched write-unprotect notch

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.

A 1541 drive is required to create a G64 image. Since we have one here, it’s a possibility we’ll try to image the Loadstar, as well as other published Commodore software disks, with this method. It would be interesting to compare/contrast them with the D64 images. We are presently waiting for a required cable to be sent.

Finally, I’m going to check out MITH’s Deena Larsen Collection site in more detail, and begin to scope the vintage computing equipment which is MITH’s own. This will help get an idea for the organization, cataloging and metadata associated with vintage computing equipment, in preparation for an online catalog.