phils@tekigm2.TEK.COM (Philip E Staub) (05/07/87)
------------------------------------ Has anyone played around with the step times on the 3.5" drives? I seem to recall reading somewhere that it was possible to do, but I can't remember where I've seen it. My objective is to attempt to find a step rate which will quiet down the drives while seeking. On other machines, I've seen dramatic changes in the volume of the drive noise by just altering the step rate. In the event that anyone else has experimented with this, I'd be interested to know what rates give the quietest operation on various brand drives. Thanks, -- ------------------------------------------------------------------------------- Phil Staub tektronix!tekigm!phils (206) 253-5634 Tektronix, Inc., ISI Engineering P.O.Box 3500, M/S C1-904, Vancouver, Washington 98668
dillon@CORY.BERKELEY.EDU.UUCP (05/07/87)
You can change the drive step rates by looking at the TDU_PublicUnit (I think that is what it is called). from the Unit structure pointer extracted from a trackdisk.device request. The numbers don't make much sense though, and there is no documentation on their format. (Anybody at Commodore care to enlighten us?) -Matt
andy@cbmvax.UUCP (05/08/87)
In article <8705071902.AA08439@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > You can change the drive step rates by looking at the TDU_PublicUnit > The numbers don't make much sense though, and there is no documentation >on their format. (Anybody at Commodore care to enlighten us?) The number is in microseconds. The field name is TDU_STEPDELAY in the TDU_PUBLICUNIT structure. (tdu_StepDelay in the TDU_PublicUnit structure for the C crowd) > -Matt -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore/Amiga /or/ pyramid!amiga!andy } "Do not meddle with the affairs of wizards, for it makes them soggy and hard to light." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
dillon@CORY.BERKELEY.EDU (Matt Dillon) (05/08/87)
>andy finkel {ihnp4|seismo|allegra}!cbmvax!andy >Commodore/Amiga /or/ pyramid!amiga!andy } > >"Do not meddle with the affairs of wizards, for it makes them soggy and hard >to light." Quoting from the gamma release notes: ******** trackdisk: actual step rate now down to 3.6msec. The specs for fine tuning this are in this directory. look at trackdisk.h. See tdu_StepDelay and tdu_SettleDelay. These parameters are extremely hardware dependant! This means the values that may work for a 68000 may not work with a 68010 as well as a 68020 with a faster clock, etc. ******** Ok, I've looked in trackdisk.h, found tdu_StepDelay, And absolutely no information whatsoever on how to use it. 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. -Matt
billk@pnet01.CTS.COM (Bill Kelly) (05/09/87)
>Has anyone played around with the step times on the 3.5" drives? I seem to >recall reading somewhere that it was possible to do, but I can't remember >where I've seen it. My objective is to attempt to find a step rate which >will quiet down the drives while seeking. On other machines, I've seen >dramatic changes in the volume of the drive noise by just altering the >step rate. No problem. Just grab the screen title bar and vigorously shake the screen up and down while your drives are stepping. The stepping rate gets noticably slower, lower in pitch, and lower in volume... Well, it *does* work... :-) Bill Kelly -- Bill Kelly {akgua, hplabs!hp-sdd, sdcsvax}!crash!pnet01!billk Try this: BltClear(0,524288,1) ;-)
scotty@l5comp.UUCP (Scott Turner) (05/10/87)
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)