BRIGHT@AC.DAL.CA (BOB BRIGHT) (03/23/89)
I recently noticed some strange behaviour issuing from my ST. I have a 520STfm, one of the new ones with the built-in double-sided drive and the so-called "Mega" roms. Here's the strangeness: Cold boot the machine with a freshly-TOS-formatted disk in drive A:. Open a window for A: on the desktop, and create a folder (called "FOLDER", say) on the blank disk. Double click on FOLDER to get a subdirectory showing "0 bytes used in 0 items". Go ahead and hit the escape key a gazillion times. All that will happen is that the screen window updates; the drive never comes on, since the current subdirectory is cached, and no media change is detected. Now remove this disk from drive A: and insert another blank disk (or at least, one which doesn't have any folders at all on it). Hit <esc>; the drive spins, and the (non-existent) sub-directory on the new disk gets read. Now, the next few presses of the escape key won't do anything besides update the window on the screen, but every fourth press of escape _will_ force the disk to be re-read. I'm not sure why it's doing this, but for some reason every fourth press of escape is forcing a media change. Note that this doesn't happen under "normal" circumstances. I think I recall from somewhere that Alan Pratt said he was going to make <esc> force a media change in TOS 1.4, but the only way I can force a media change with my roms is if I hit <esc> four times and the window on my screen is showing a non-existent subdirectory on a disk which _doesn't have any other subdirectories_. What happens if the disk does have other subdirectories? Glad you asked; this is the really weird part. Remove the second disk from drive A: and insert a third disk, this one with a least one folder on it, but _without_ a folder called "FOLDER". Hit <esc>; the drive spins, and the (non-existent) sub-directory gets read. BUT...No matter how many times I hit <esc> from here on in, the drive light never comes on and the disk never gets read. In fact, my machine COMPLETELY REFUSES TO RECOGNIZE A MEDIA CHANGE. I can take out the third disk and insert any disk whatsoever, but no amount of standing on the escape key will read the new disk. The only way that I can force a read is to back out of the FOLDER subdirectory to the root. What's the explanation for all this strangeness? Should I worry about it? I'm fairly sure that my other ST (a 1040 with the old roms) doesn't exhibit this behaviour (though I haven't actually gotten around to verifying it). Ever since I started using the 520 at work (my 1040 is now at home), I've noticed that WordPerfect has been trashing a lot of files. The only explanation I could get out of WordPerfectCorp is that WP doesn't live very happily on small machines. But now I'm wondering if WP's internal directory caching isn't running headlong into this strange little "feature" of TOS that I've located. Comments? BBB Bob Bright <BRIGHT@DALAC.BITNET> Philosophy Dept. Dalhousie University Halifax, NS B3H 3J5
clf3678@ultb.UUCP (C.L. Freemesser) (03/24/89)
The problem you are having with your drive is not uncommon. I am assuming you have the Chinon drive in your STFM (it has the eject button underneath the disk slot). First off, Chinon drives are the pits. Recent ST's have had HUGE problems with these drives. Atari wisely stopped using them and went to Sony drives. The actual problem is that the disk-eject device the drive has, which tells the computer that a new disk has been inserted), has failed. It is a very common problem. It can be fixed, but the easiest way to fix this is to replace the drive with a GOOD mech. The drive will probably fail on you soon. If your computer is still under warrantee, get a new drive. If it is the same model number (Chinon AA or something like that) as the one you have now, then you will be doing alot of replacing. The drives are just no damn good. If you want to get adventursome, put in your own mech. I suggest the following: Toshiba ND-354 Epson SMD-180 (discontinued model) Epson SMD-280/480 (I believe the 480 is made by Sony, and is what Atari now uses) Teac FD-135-01-U (something like that, this is what I use) You will have to do some hacking of the case (the face plates are different), but you will have a MUCH better drive. =cf=
ajy2208%ritcv@cs.rit.edu (03/24/89)
Chris, Chinon drives are not as bad as you make them out to be. My roommate's Mega has been performing flawlessly since August, and it has a Chinon DD/DS drive built in. Prior to that he had a 520ST with an external drive and that also had a Chinon mech. I know many people back home (in Connecticut) who have Chinon drives who have never had problems with them. I think you're blowing things a bit out of proportion. That's not to say I don't think Sony drive mechs aren't better. Albert Yarusso
BRIGHT@AC.DAL.CA (BOB BRIGHT) (03/25/89)
In reply to a posting of mine concerning strange TOS behaviour when attempting to read non-existent subdirectories, clf3678@ultb.UUCP (C.L. Freemesser) writes: >The problem you are having with your drive is not uncommon. >I am assuming you have the Chinon drive in your STFM (it has the eject >button underneath the disk slot). > >First off, Chinon drives are the pits. Recent ST's have had HUGE >problems with these drives. Atari wisely stopped using them and went to >Sony drives. > >The actual problem is that the disk-eject device the drive has, which >tells the computer that a new disk has been inserted), has failed. It >is a very common problem. It can be fixed, but the easiest way to fix >this is to replace the drive with a GOOD mech. The drive will probably >fail on you soon. If your computer is still under warrantee, get a new [...] I don't think that you read my posting very carefully. Yes, the drive in my 520STfm is a Chinon; and no, I don't think that the problem is with the drive's eject/write-protect detection. I've been reading this group for a while, so I've heard all about the problems with those insidious Chinon drives. (I was under the impression, though, that the problem with media change recognition when Atari started using the Chinon drives was due to the way the Chinon's write-protect mechanism was wired up. Is _failure_ of the write-protect mechanism, rather than a wiring glitch, really all that common?) As I noted in the original posting, my machine recognizes media changes just fine, _except_ when I try to read a non-existent subdirectory on a disk that has at least one other folder on it. When I do that, no amount of swapping disks in and out of the machine will cause <esc> to read a new directory. The symptoms are thoroughly replicable, and moreover this is the _only_ circumstance in which I've ever noticed a problem with media changes. And there's also that curious behaviour when I try to read a non-existent subdirectory on a disk that has no other folders: every fourth press of <esc> _forces_ a re-read of the disk, though I haven't taken it out of the drive. Correct me if I'm wrong, but this sure sounds like TOS-related behaviour to me. BBB Bob Bright <BRIGHT@DALAC.BITNET> Philosophy Dept. Dalhousie University Halifax, NS B3H 3J5 (902) 424-3810
clf3678@ultb.UUCP (C.L. Freemesser) (03/26/89)
So Chinon drives aren't as bad as you say, eh? I got a call from a member of our users group (ACORN) two days ago. His CHINON drive is giving him problems, and his computer is less than a year old. Seems that he got a copy of Regent Word II (PD program). For some reason, the disk threw his heads out of alignment. Gee, what a sturdy drive! I've also heard horror stories about people who take disks out of the drive before it stops spinning, and the heads get torn away. So they aren't that bad??? A friend of mine who runs a small computer store ONCE put in a Chinon 5.25 inch drive into a PC/XT unit. In the span of 2 months, he replaced the drive 6 times. SIX TIMES! Says alot about Chinon, doesn't it? I still stand behind what I said: if your Chinon drives goes on you, do NOT put another one in. =cf=
dlm@druwy.ATT.COM (Dan Moore) (03/28/89)
in article <493@ultb.UUCP>, clf3678@ultb.UUCP (C.L. Freemesser) says: > The actual problem is that the disk-eject device the drive has, which > tells the computer that a new disk has been inserted), has failed. The ST does not use the media change line from 3.5" drives. If they did there wouldn't be problems with the ST not detecting disk changes. Instead of using the media change signal that most 3.5" drive produce Atari checks the write protect line every vblank. If the status of that line changes the BIOS sets the drive status to "maybe changed". The next access to the drive will read the boot sector and compare the serial number on the disk to the one it thinks should be there. In order to check the write protect status of the drive the vblank code must select the drive, read the status and then deselect the drive. Unfortunately many drives do not return valid write protect status for several milliseconds after they are selected, which is many times longer than the vblank code takes. So these drives have problems on the ST since media changes aren't always detected. This has almost nothing to do with the quality of the drive, I've got some very good Epson drives that miss media changes on the ST and some garbage Chinons that do detect the media change. Dan Moore AT&T Bell Labs Denver dlm@druwy.ATT.COM
apratt@atari.UUCP (Allan Pratt) (03/29/89)
In article <3938@druwy.ATT.COM> dlm@druwy.ATT.COM (Dan Moore) writes: > Unfortunately many drives do not return valid write protect > status for several milliseconds after they are selected, which is many > times longer than the vblank code takes. So these drives have problems > on the ST since media changes aren't always detected. Another failure mode is that some drives don't give a valid write-protect signal when there is no disk present. This means you can take out one write-enabled disk and put in another, and the ST won't see a transition on the write-protect line. If you MUST use such a drive, have a write-protected disk handy. Whenever you remove a disk, place the write-protected disk in the drive for 1 second or so, then take it out again. In this time, the ST will detect the transition on write-protect and mark the media as "maybe changed." When you put in the next (write-enabled) disk, the serial number will be read, it won't be the same, and media change processing will commence. Note that going from one write-protected disk to another, the write-protect line often doesn't change. That's taken care of by the floppy code, too: if the line has not changed from the write-protect state and the last access was more than 1.5 seconds ago, the media's state is "maybe changed." These drives, and those mentioned by Mr. Moore, are out of spec for the ST: don't use them. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
laba-2he@web-3d.berkeley.edu (Oliver Juang) (04/03/89)
The floppy drive in my Mega 2 will not format past track 80. Is this normal? The one I have has a dust cover that folds down when the disk is ejected. If this is normal, can anyone tell me if this is a good mechanism? What mechanisms can I replace this with, without having to cut up the case to get a fit? Thanks. Lawrence Y. Chiu
laba-2he@web-3d.berkeley.edu (Oliver Juang) (04/03/89)
Albert, Chinon drives are the worst. Two models even run slower than the other drives Atari uses, at 6 ms. These use a board to convert the signal to 3 ms... Lawrence Chiu
clf3678@ultb.UUCP (C.L. Freemesser) (04/04/89)
The drive you have in your Mega is one of the new Sony drives Atari started using after the Chinon problem. It can't format more than 80 tracks because of its design, not a problem with the drive itself. I've also seen the Epson SMD-480 mech in there. I believe that Sony makes the drive for Epson, so don't be surprised if you open the computer and find Epson's name all over the drive. =cf= BTW, the Sony drive is a workhorse, and you shouldn't have any problems with it for a LONG time!
ralph@nastassia.laas.fr (Ralph P. Sobek) (04/06/89)
I often pop in and out floppy disks while running gulam. This media change problem does hit me from time to time when I want to access a sub directory on A:. Is there any way for to reread the disk? An 'ls -l' does correctly show the root directory. Is there any other solution to quitting gulam, clicking in GEM, and restarting gulam? Thanks a lot, Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU Ralph P. Sobek Disclaimer: The above ruminations are my own. ralph@laas.laas.fr Addresses are ordered by importance. ralph@laas.uucp, or ...!uunet!mcvax!laas!ralph If all else fails, try: SOBEK@FRMOP11.BITNET sobek@eclair.Berkeley.EDU
apratt@atari.UUCP (Allan Pratt) (04/08/89)
In article <330@laas.laas.fr> ralph@nastassia.laas.fr writes: > I often pop in and out floppy disks while running gulam. This media > change problem does hit me from time to time when I want to access a > sub directory on A:. Is there any way for to reread the disk? An > 'ls -l' does correctly show the root directory. Is there any other > solution to quitting gulam, clicking in GEM, and restarting gulam? Gulam has a feature whereby it caches directories. There should be validation of the directory cache via a Mediach() call on the pertinent device, but there isn't. This is strictly Gulam's fault. Gulam's directory handling is really bad: ever try "ls -lt" on a directory with, say, 100 files? It takes a LONG time. That time is not sorting; it's making two or three Fsfirst calls for each file. Fortunately, if you use TOS 1.4 and add directory buffers, it doesn't hit the disk 300+ times... The trouble is, the code is so convoluted I can't hope to improve it. I am really sorry Gulam is so good: it prevents me from writing a proper shell. Gulam's bugs are irritating, but the bulk of it is too good to junk. (Well, specifically, the code is badly unstructured and virtually impossible to analyze, troubleshoot, and improve.) ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt