Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: Drive Step times Message-ID: <118@l5comp.UUCP> Date: Sun, 10-May-87 09:42:46 EDT Article-I.D.: l5comp.118 Posted: Sun May 10 09:42:46 1987 Date-Received: Wed, 13-May-87 01:30:59 EDT References: <8705081659.AA02101@cory.Berkeley.EDU> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 53 Summary: One person's step rate is anothers hardware malfunction. In article <8705081659.AA02101@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > I wanna know! If these drives are rated at 3msec track to track, >then I'll be damned if I'm going to settle for 3.6msec, which is nearly >20% off the mark. Cool yer jets there Matt! A little investigation before leaping can yield excellent rewards, like preventing "How was I suposed to know I should set 8N1 automatically for XMO?" The routine used by trackdisk.device ain't all that precise to begin with. In a multi-tasking system like the Amiga it is very hard to get precise time intervals without choking the task switcher. The seeker is an excellent example of this. To keep the machine rolling smoothly the seeker must allow task switching inbetween step pulses. Otherwise it could lockup the task switcher/IRQ system for almost .25 sec worst case. This is clearly a bad thing to do. So it does a delay based on the value you want to fondle and gives the task switcher a shot. The time delay sets a minimum delay mark, the actual delay is going to be longer. If you tweak this value it may work for you one day, then the next day you remove some ram resident program and now your system isn't so loaded. BAM you start getting flakey seeks. Flakey seeks aren't fun. If you build this into your software (the major reason I write this is the fear that you would do so) then the seek value that works on your system may give me fits on my 68010 Amiga. The real solution to this would have been for Jay to build a seeker into the floppy controller, but hey the guy just plain ran out of pins. So we get to catch as catch can. Also, please note that lengthing the step pulse interval is bad news too. Drives like their pulses within a "narrow" range. If they come to fast they get pissed, if they come to slowly they get pissed. And before someone says how can they ever be too slow, just try it and find out :-). My system is all the time recalibrating the heads on DF0: when I have the system heavily loaded and then cp dh1:bigfile df0:. I can even visit Mr. Guru by issuing a loadwb with the floppy head off in the ozone someplace. Something to do with moving the floppy head to read info off the floppy while my winnie is still hogging the system. And another also, there are currently two groups of drives, the old one and the new ones. Each group acts differently about seeking. The older drives are more sensitive to slow step pulses than the newer drives. So please just leave it where it is, it's just barely functional for me as it is! Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)