Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!zaphod.mps.ohio-state.edu!mips!sjsca4!storkamp From: storkamp@sj.ate.slb.com (Mark Storkamp) Newsgroups: comp.sys.atari.st Subject: Re: Wanted: Chinon Floppy Drive Horror Stories Message-ID: <1990Aug30.155717.16384@sj.ate.slb.com> Date: 30 Aug 90 15:57:17 GMT References: <1990Aug29.100251.11916@gdr.bath.ac.uk> Reply-To: storkamp@sj.ate.slb.com (Mark Storkamp) Distribution: comp Organization: Schlumberger Technologies, San Jose, CA. Lines: 26 In article <1990Aug29.100251.11916@gdr.bath.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes: >In article ralph@laas.fr writes: >>Some time back there were numerous postings concerning the (in?)famous >>Chinon floppy drive. As I remember, many people had problems with its >>media change detection. >> >>Suggestions are also appreciated. Is there a good test program for >>this problem? Please try to reply to me directly and I'll summarize >>if anyone else is in the same boat, and interested. > >There's a simple test _procedure_. Put a write-enabled floppy (little >window closed) in the drive, and pop up a directory-listing window. >Take the floppy out, reinsert it (or any other write-enabled floppy) >and hit ESCape. If the drive spins, you're OK. If the drive does not >spin, you've got the problem. The problem mechs only do the wrong >thing with write-enabled disks. To be sure, try this several times . > One of the changes in TOS 1.4 is it now forces a re-read of the disk whenever you hit ESCape, even if a media change was not detected. This, unfortunatly, will not fix the problem if you change disks while inside of a program. It does make it much more difficult to tell if you have this problem. The procedure outlined above will work from Neodesk, since it does not force the re-read. Mark Storkamp