On Tuesday, March 9, 2010 at 9:05:41 PM UTC-5, Michael J. Mahon wrote:
> Dave Rawson wrote:
> > Michael J. Mahon wrote:
> >
> >> Next step--the two-sided index pulse mod... ;-)
> >
> >
> > I'm happy to report (with long and tortuous detours of heroic
> > proportion) that I've ported the oldest of my Apple sides over to PC as
> > proof-of-concept. I purchased the FC5025 and the Teac FD55GFR and the
> > combination worked. I took note of Mike's notes about ProDos being
> > faster and it worked as well as ".dsk", so why not.
> >
> > CiderPress recognizes the disks as MagicWindow files and will
> > automatically extract them to PC readable ".txt" files when requested!
> >
> > There are some eccentricities that I don't have the time or coherence
> > enough to describe right now, but I can already imagine some possible
> > approaches to dealing with them.
> >
> > So, I've read about 30 front sides and ache to read the backs. I've
> > jumped the E2 to no avail. All the floppies are already punched for
> > both sides since that's the way I used them.
> >
> > Has anyone been able to read the backs, punched and jumpered, yet?
> >
> > If so, is there any way to predict which of the FD55s allow this?
> Unfortunately, none. ;-(
> There are two ways to read the back sides:
> 1) Cut out or punch two new "index access" holes in the jacket on
> the other side (laterally, not up/down) of the jacket. It should
> be in an angular position symmetric with the existing pair. This
> set of holes will allow the FD-55 index sensor to "see" the existing
> index hole in the disk media when the disk is upside down in the
> drive.
> 2) Modify the FD-55 to either allow it to sense the index hold from
> either side (laterally, again) of the drive, or modify it to see
> "fake" index pulsed generated from the rotation of the spindle motor.
> (I'm still looking for the web article that described making these
> modifications.)
> > As an incidental approach to bad sector reads, has anyone tried the
> > "browse" option which allows working file by file, if necessary, so that
> > a whole ".dsk" image isn't 'bad' or necessary?
> I haven't tried any disks with bad sectors, but a quick perusal of
> the code of the host program suggests that all the good sectors are
> copied to the image, with only the bad sectors represented as either
> zeroes or some random data (I don't know which, and haven't done the
> experiment).
> If this is the case, even a "bummer" image will have all that the
> program could recover in "file mode".
> BTW, in my experience, the vast majority of disks with "bad sectors"
> are ultimately recoverable with unusual means, so don't throw them
> out if you might want the contents!
> > Thanks again to everyone for their encouragement and help!
> I'm very happy to hear that you are recovering your data. ;-)
> -michael
> NadaNet and AppleCrate II: parallel computing for Apple II computers!
> Home page: http://home.comcast.net/~mjmahon
> "The wastebasket is our most important design
> tool--and it's seriously underused."