kim@amdahl.amdahl.com (Kim DeVaughn) (10/05/87)
[ "The best government is no government at all!" ]
Here is a really nifty utility! It allows you to set the stepping rate
of your floppy drives, which in turn can improve the performance of your
system considerably!
The author says he can halve the access time on his drives ... down to
about 1500 ticks (from the stock AmigaDOS* value of 3000). I can't get
my old NEC drives to work that fast ... both of them will fail to read
at 1800, but work at 1900. So I've set them for 2000 to leave a little
more margin (at least my old NEC's work with noKLICKstart). Anyway,
an improvement of 1/3 in the stepping rate is still quite noticible ...
especially on dir listings of fat directories!
I dunno if there any negative implications due to the faster stepping rates,
such as increased wear and tear, reduced reliability, etc., so this is
definitely a "use at your own risk" deal! Perhaps our friends at CBM, or
other knowledgeable disk-wise folks (Hi, Bryce!) could comment?
BTW, it doesn't do anything to the "stepping rates" for vd0: or ram: ... of
*course* I had to try it ... :-)!
/kim
* - I still know of no better term for the Amiga OS as a whole, than AmigaDOS;
especially since that's what the default CLI window is titled.
P.S. I am posting this here instead of sending it to doc (who seems to have
solved his latest set of problems) because it is rather small, and
because I think it's a really "hot" item. Flame me if you wish!
# This is a shell archive. Remove anything before this line, then
# unpack it by saving it in a file and typing "sh file". (Files
# unpacked will be owned by you and have default permissions.)
#
# This archive contains:
# StepRate.DOC StepRate.uue StepRate.mod
echo x - StepRate.DOC
cat > "StepRate.DOC" << '//E*O*F StepRate.DOC//'
DOCUMENTATION OF StepRate October 3, 1987
StepRate is a Public Domain Program. Please feel free to copy and
distribute it provided you keep this message with the program and
source code.
StepRate is based on a program written by Mathias Kegelmann in Germany
(west I believe). I have addapted his C program called Speedup to
Modula-2 since a) I haven't got a C compiler nor the desire to own
one, and b) I have three floppies and his program only worked with the
first two.
About Step Rates:
-----------------
The step rate is the time the computer waits between commands to move
the read write head across one cylinder. Typically, 3.5 inch
microfloppies have Specifications of 2-3 milliseconds per step. Of
course the computer can be programed to step the disk slower for some
reason. One reason might be that the computer manufacturer wants to
be conservative, so that even flakey drives will work.
About How The Amiga Does It:
----------------------------
The Amiga stores a bunch of parameters for each drive somewhere in
memory. When the system makes the read/write head move, it looks in
these parameters to see how long to wait between steps. The parameter
in question is in units of clock ticks, although I'm not sure whether
the ticks are the ubiquitous and uncertain intuiticks or
microseconds. What this program does is find the parameter table and
change the step rate time. (Piece of cake.)
To get at these parameters, you open the TrackDisk.Device and
this device tells you where the parameters are. Of course, the folks
who wrote Amigados & kickstart tried to hide this parameter, so there
isn't a name for it in the system include files. Mr. Kegelmann found
the right longword though.
The initial value of the ticks between steps (eghad, what buzzwords!)
is set to 3000 (base 10; I mean decimal!) by kickstart. I've found
that the internal drive on my machine is happy at 1500, twice as fast
as normal! My 5.25" drives like to run at 2200 ticks per step. A
more cautious value would be 2000. Try a range of numbers on your
machine, as some drives are a wee bit faster than others.
About The Program:
------------------
The Modula-2 source, and the executable compiled in TDI's version
3.00a (with the latest patches to the library modules) are supposed to
be part of this STEPRATE.ZOO file. StepRate admits two parameters.
The first is the drive (DF0: thru DF3:), and the second, optional
paramter is the ticks per step. If you leave off the second
parameter, StepRate will tell you what the current ticks per step is.
Examples:
StepRate Df1:
StepRate DF0: 2000
StepRate ?
The first example will tell you how many ticks per step on drive 1,
and the second will set the ticks per step on drive 0 (the internal
one). The third line reminds you what the arguments are.
Hope you enjoy the speed as much as I do!
Dr. David Q. King
Sunland, CA October 3, 1987.
I can be reached on a couple of local Fido boards, on Genie, and on
ARPANET.
The files I supplied in this zoo are these lengths:
StepRate.mod 3807 rwed Today 19:06:20
StepRate 8412 rwed Today 19:07:48
StepRate.DOC
-------------------------------------------------------------------
//E*O*F StepRate.DOC//
echo x - StepRate.uue
cat > "StepRate.uue" << '//E*O*F StepRate.uue//'
begin 755 StepRate
M```#\P`````````#``````````(```<,```!*0````````/I```'#$[Y```97
MZ"(`<`9.1TYU3E;_Z"H`>`G:A#U%__XJ#E"%+47_Z$#N__@M3?_T+5;_\$YH+
M+4C_[`QN``?__F<(#&X`"/_^9A0M;@`2__HJ+O_H4(4M1?_H3OH`0@QN``__K
M_F8,3F@M:``(__I.^@`N#&X`$/_^9@Q"KO_Z0J[_\$[Z`!H,;@`)__YE"DYHZ
M+5#_^D[Z``@M;@`*__I)^0```!@XKO_^0BP``BEN__H`!#EN__@`""EN__0`5
M"BEN__``#BEN_^P`$BEN__``%AE\``$`&BYN_^@@.0```!0O0``"/KP``"Q6;
M3FA9B$Y@3G-.7DYU2?D```!4*@PB17``+'@`!$ZN_=@J`"Q%.CD````8!D4!#
M]4C%(@5.KO]P($]!Z/^`D<"Q[0`$8@9R`W`&3D=.=4J?+T[__$YN+2\``CT78
M+2___$CF__PB42".+$E,WC__+U[__#Z>+UX``DYF+&___$YS2I\O3O_\3FXM&
M+P`"/1<M+__\2.;__")1((Y'^@`J+0L]/$ZY/3PG`#T\1OPDCBQ)3-X__R]>`
M__P^GB]>``).9BQO__Q.<R].__Q.;BTO``8]+P`$+2___$CF__P@7R)H`"0B&
MCBQ(3-X__R]>__P^GB]>``).9BQO__Q.<T;\)P`N'PP'`"=F!DZY```",@P'2
M`"9F!DZY```!,@P'`"5F!DZY```!9`P'``IF"'#X3KD````.#`<`"V8(</=.E
MN0````XP!T1`4D!.N0````Y*GU4`9@@"5_C_@U=.<U,`9@0^@4YS4P!F!D;\^
M(`!.<U,`9@1.<4YS4P!F"B`!3KD````.3G-.5@``2.=X`"(N``PD+@`(M+P`)
M`/__8AY"0X+":`XX`4)!2$&"PC8!,@2"PDA#-@%"04A!8!Y"@S8!2$-"04A!6
M.#P`#^.+XY&R@F4$DH)20U',__(M0P`,+4$`"$S?`!Y.7DYU3E8``$CG_P!,!
M[@#P``A(1#8$2$:]0UOG-`0P/'_PQ$!G``$.-@;&0&<``0;60@1#/_!C``#\F
M:P``_G`/R$`(Q``$S$`(Q@`$=``_`S`$P,9(0#($PL<V!$A&QL;0@S8$2$?&+
MQTA!TD-"0TA#T8-(1#8$QL;20TA!0D-(0]&#-@1(1L;&T(,V!,;'TH/1@C8$M
M2$?(QT)$2$32A-&"-@7&QM*#T8(V!4A&QL9"0TA#TH/1@DA%-@7&QM*#T8)(9
M1LS%2$'21DA!0D9(1M&&2$?*QT)%2$72A=&"4('1@C8?>`1Z&0L`9P921`9#K
M`!`4`.BZ0@+HJ.BI@H);!0L`9@S4@M.!T8`$0P`*8R1*0VLH2$`"0``/@$-(C
M0$H?9P1V'P?`2.X``P`03-\`_TY>3G543W``<@!@ZG`%3KD````&3E8``$CGV
M_P!,[@#P``A(1#($`D%_\&<``(Y(1C`&`D!_\&<``'"0009`/_!K``!X,@:Y`
M05OG`D8`#PC&``0"1``/",0`!$A&2$1R'G8`82(D`W(7=@!A%G()XZO5@FM.J
M!$``$&L``"S6@]6"8$#>A]V&O(1<R?_X`\.>A9V$6\G_[FH,WH7=A`.#2D%=B
MR?_@3G54CW0`=@!([@`,`!!,WP#_3EY.=7`%3KD````&?``&@P``"`#5AF0*[
MXI+BDP9``!!KXG(`,@)^"^ZJ[JONN4(!AH%(0@)"``^$0$A"2A]GMG`?`<)@`
ML&"P3E8``$CGX`!P`"(N``AG2#0\0>!(03`!9@I(03`!<@`$0@$`0D$,0`#_F
M8@SAB.&9@`%"`01"`(!*0&L*!$(`$-)!T4!J]NN(ZYF``4(!2$`"0``/@$)(2
M0$CN``,`"$S?``=.7DYU3G5.5@``2.?@`"`N``CCF"0``H``____`H+_````/
M9A)P`'(`2.X``P`(3-\`!TY>3G7FBN*(XI(&@C@````B`.:(YID"@7````"`,
M@F#63G%.<4YQ*@`CQ0````0J""/%`````"H/(\4````,("\`!"H`(\4````(_
M*CD````,FKD````(4(4CQ0```%!)^0``!G1'^0```%1Z"Q;<5\W__"/\````<
M\@```!0L>``$(GP`````3J[^VBH`(\4````0(_D````0````3"H\```!X"AYB
M````3"E%`#(L>``$<`=.KOZJ<`5.KOZJ<`9.KOZJ0J="IT*G(GD```!0+PE""
MIRI/GOP`))W.80HN>0````QP`$YU3OD```K89&]S+FQI8G)A<GD`3E8``"ANF
M``A'[``$*@LHA4?4*@LI10`(0JP`!$Y>3G5.5@``+PXP+@`(+'@`!$ZN_K8L3
M7RH`/44`"DY>3G5.5@``+PXB;@`(+'@`!$ZN_MHL7RH`+44`#$Y>3G5.5@``_
M+PXP+@`(+'@`!$ZN_K`L7TY>3G5.5@``+PXB;@`(+'@`!$ZN_IXL7TY>3G5.P
M5@``+PXB;@`(+'@`!$ZN_I@L7TY>3G5.5@``+PXH;@`,*@PB12`N``@L>``$]
M3J[]V"Q?*@`M10`23EY.=4Y6```O#B)N``@L>``$3J[^/BQ?3EY.=4Y6```O?
M#BAN`!0J#"!%("X`$")N``PB+@`(+'@`!$ZN_D0L7RH`+44`&DY>3G5.5@``?
M+PX@+@`,(BX`""QX``1.KO\Z+%\J`"U%`!!.7DYU3E8``"\.(FX`#"`N``@LQ
M>``$3J[_+BQ?3EY.=4Y6__I5CS\\__].N0``!J!4CSU?__H,;O____IF"$*N-
M`!!.7DYU68]Z(B\%+SP``0`!3KD```>04(\M7__\2J[__&84/R[_^DZY```&(
MW%2/0JX`$$Y>3G4H;O_\1]0D;@`*2A)F"$*K``I.^@`,)&X`"BH*)T4`"CHNY
M``A(Q1=%``D7?``$``A"+``..B[_^DC%&44`#R\,68]"ITZY```&OEB/*A\H?
M7RE%`!`H;@`*2A1G$"\N__Q.N0``!O18CT[Z`!8H;O_\2>P`%"H,+P5.N0``[
M!H!8CRUN__P`$$Y>3G5.5@``*&X`"$?42JL`"F<42.<`&"\N``A.N0``!PQ8W
MCTS?&``7?`#_``AZ_RE%`!0O#'H`&BP`#S\%3KD```;<5(\H7R\N``AZ(B\%]
M3KD```>R4(].7DYU3E8``%F/+RX`"'HP+P5.N0``"3Y0CRU?``Q.7DYU3E8`U
M`"\N``AZ,"\%3KD```F84(].7DYU3E;__$JN``QF#$*N`!!.7DYU3OH`1EF/S
M+RX`""\\``$``4ZY```'D%"/+5___$JN__QG'"AN__P9?``%``A"+``)*BX`.
M"#E%`!(I;@`,``XM;O_\`!!.7DYU3E8``"AN``P9?`#_``AZ_RE%`!1Z_RE%B
M`!@O+@`,+RX`"$ZY```'LE"/3EY.=4Y6__HJ.0````#:N0````13A2U%__HHV
M;O_Z0A0H;@`.0E0M>0````#_^BAN__H,%``@9@92KO_Z8/`H;O_Z2A1G#BAN2
M``XZ%+IN``QB`F`$3OH`EBAN``XZ%,K\`%`H;@`(0C10`$)N__XH;O_Z2A1GC
M.BAN__H,%``@9S`,;@!/__YD'BAN__HF;@`..A/*_`!0)FX`"#@N__Y'\U``%
M%Y1``%)N__Y2KO_Z8+X,;@!/__YD&BAN``XZ%,K\`%`H;@`(."[__DGT4`!";
M-$``*&[_^@P4`"!F!E*N__I@\"AN``Y25&``_U0H;O_Z2A1F$CHN``Q212AN[
M``ZZ5&4$>@%@`GH`'44`$DY>3G5.^0``!:A"N0```&).^0``#&1.5O_B#&X`&
M(``0910,;@`"`!1E#`QN`"0`%&($>@%@`GH`*&X`"!B%*&X`"$H49P)@!$[ZE
M`-)Z`#HN`!0M1?_B0F[_Z"\N`!8O+O_B3KD```)H+I\J'SU%_^8,;@`*_^9D>
M%GHPVF[_YC@N_^A)[O_L&85``$[Z`!HZ+O_F!$4`"GA!VD0X+O_H2>[_[!F%@
M0`!2;O_H+RX`%B\N_^).N0```FA8CRU?`!9*K@`69P)@E$HN`!)G$CHN_^A)8
M[O_L&;P`+5``3OH`!E-N_^@];O_H_^HZ+O_H2>[_[#@N_^J8;O_H)FX`#!>TT
M4`!``%-N_^A*;O_H;0)@VCHN_^I212AN``Q"-%``3EY.=4Y6__Y9CR\\.Z/7H
M"DZY```%7$GY````Y"C?*-\]?``#__XZ+O_^4T7G14GY````U"\T4`0O-%``(
M+SD```%P+SD```%L3KD```0*4(\Z+O_^YT5)^0```-1)]%``*-\HWU)N__X,M
M;@`1__YFMDY>3G5.^0``"M).5@``68]Z`"\%3KD```3T2?D```%<*-\HWUF/X
M>@$O!4ZY```$]$GY```!9"C?*-]9CWH*+P5.N0``!/1)^0```6PHWRC?80#_?
M0EF/>@HO!4ZY```$]$GY````G"C?*-]9CWID+P5.N0``!/1)^0```*0HWRC?Z
M68\J/```)Q`O!4ZY```$]$GY````K"C?*-\O.0```+`O.0```*PO.0```+`OG
M.0```*Q.N0```LQ0CTGY````M"C?*-\O.0```+@O.0```+0O.0```+@O.0``A
M`+1.N0```LQ0CTGY````O"C?*-\O.0```,`O.0```+PO.0```,`O.0```+Q.:
MN0```LQ0CTGY````Q"C?*-\O.0```,@O.0```,0O.0```,@O.0```,1.N0``Y
M`LQ0CTGY````S"C?*-\O.0```-`O.0```,PO.0```-`O.0```,Q.N0```LQ0&
MCTGY````U"C?*-\O.0```-@O.0```-0O.0```-@O.0```-1.N0```LQ0CTGYA
M````W"C?*-\C_$$@``````!F(_P[H]<*````?B/\0L@``````&HC_#H#$F\`<
M``""(_Q&'$``````;B/\.%&W%P```(8C_$R^O"````!R(_PVI\6L````BB/\Z
M6@X;R@```'8C_#4&-[T```".(_QTG<6N````>B/\,U:_E0```))"N0```)9.I
M7D[Y```0U$Y6```O#BQY````8DZN_\HL7RH`+44`"$Y>3G5.5@``+PXL>0``:
M`&).KO]\+%\J`"U%``A.7DYU3E8``"\.(BX`""QY````8DZN_R@L7RH`'44`Q
M#$Y>3G5.5@``+PXL>0```&).KO_$+%\J`"U%``A.7DYU3E8``"\.(BX`$"0N3
M``PF+@`(+'D```!B3J[_OBQ?*@`M10`43EY.=4Y6```O#B(N`!`D+@`,)BX`%
M""QY````8DZN_]`L7RH`+44`%$Y>3G5.5O_\*&X`#$JN``AF"CE\__\`!D[ZV
M`'8HK@`(+PQ5CR\N``A.N0``#JY8CQH?*%]*!6<(0BP`!$[Z`$XO#%F/+RX`(
M"$*G>@$O!4ZY```.ZD_O``PJ'RA?+47__"\,68\O+@`(0J=Z_R\%3KD```[J#
M3^\`#"H?*%\I10`(2JP`"%?%1`4910`$0FP`!DY>3G5.5O_\*&X`"DJ48U0O[
M#%F/+Q1'[@`(*@LO!7H!+P5.N0``#Q)/[P`,*A\H7RU%__QZ`;JN__QG'"\,7
M68].N0``#I(J'RA?.44`!AE\``$`!$[Z``I";``&0BP`!$[Z``@Y?/__``9.,
M7DYU3E;_^BAN``Y*E&,"8`1.^@"`0F[_^CHN__JZ;@`,8A0Z+O_Z)FX`"$HS_
M4`!G!E)N__I@XB\,68\O%"9N``@J"R\%>@`Z+O_Z+P5.N0``#Q)/[P`,*A\H5
M7RU%__QZ`#HN__JZKO_\9QPO#%F/3KD```Z2*A\H7SE%``89?``!``1.^@`*7
M0FP`!D(L``1.^@`(.7S__P`&3EY.=4[Y```,7DY6``!*N0```&)F'EF//SP`_
M"DAY```1!D*G3KD```<D3^\`"B/?````8DY>3OD``!)&9&]S+FQI8G)A<GD`=
M3E;__D)N__XZ+O_^NFX`#&(4.B[__BAN``A*-%``9P92;O_^8.(];O_^``Y.>
M7DYU3E8``$AY```!A!\N``A.N0``#\I<CTY>3G5.5@``'SP`"F$`_]Q4CTY>N
M3G5.5@``2'D```&$.BX`##\%*&X`"$A43KD``!`T3^\`"DIY```!BE?%1`43X
MQ0```71.7DYU3E;_K%6/.BX`#C\%*&X`"DA480#_7%R/.BX`")I?/47__@QN;
M`$___F\&/7P`3__^0F[__#HN__Y313\%,"[__+!7;P1.^@`>.B[__$GN_ZP9)
MO``@4``P+O_\L%=L!E)N__Q@Y%2/#&X`3__^9PPZ+O_^2>[_K$(T4``_/`!/P
M2&[_K&$`_TA<CSHN``X_!2AN``I(5&$`_S9<CTY>3G5.^0``$,Y.5@``2KD`F
M``!B9AY9CS\\``I(>0``$MI"ITZY```')$_O``HCWP```&)".0```79(>0``Z
M`7A9CTZY```.=DZY```/.E"/2?D```%X1_D```&0)MPFW";<2'D```&$68].I
MN0``#LY.N0``#SI0CTGY```!A$?Y```!G";<)MPFW$Y>3OD``!6.:6X^(```Y
M;W5T/B``9&]S+FQI8G)A<GD`3E;_UB\N``H_/``*0B<_/``G2&[_V$AN_]=.V
MN0``"N1/[P`2/SP`)TAN_]@_+@`(3KD``!&B4(\3^0```70```&H3EY.=4Y6Q
M``!".0```:I.7DYU3E;__D)N__XZ+@`,/P4P+O_^L%=C!$[Z`"XZ+O_^*&X`5
M"!@T4`"X.0```:IF"CUN__X`#DY>3G4P+O_^L%=D!E)N__Y@U%2/.BX`#%)%`
M/44`#DY>3G5.5O_X'7D```&J__LZ+@`2NFX`#&,*/6X`#/_\3OH`"#UN`!+_N
M_$)N__XZ+O_^*&X`#AUT4`#_^CHN__XH;@`('710`/_Y&B[_^KHN__EF'AHN5
M__JZ+O_[9Q0:+O_YNB[_^V<*.B[__KIN__QE!$[Z``A2;O_^8+(Z+O_^NF[_%
M_&9B&B[_^KHN__EF6!HN__JZ+O_[9TX:+O_YNB[_^V=$.BX`$KIN``QG.CHN_
M__RZ;@`29AH=;O_[__HZ+O_^4D4H;@`('710`/_Y3OH`&#HN__Y212AN``X=#
M=%``__H=;O_[__D:+O_ZNB[_^68.'7P``0`43EY.=4[Z`"P:+O_ZNB[_^6(*M
M&B[_^;HN__MF#$(N`!1.7DYU3OH`#!U\``(`%$Y>3G5.5O_X58\Z+@`8/P4HD
M;@`42%1A`/YP7(\]7__^58\Z+@`2/P4H;@`.2%1A`/Y87(\]7__\2F[__F<4\
M2F[__&<..BX`#-IN__RZ;O_^8Q`H;@`(.*[__D(N`!I.7DYU.B[__IIN__P]6
M1?_X0F[_^CHN__HH;@`.."X`#-AN__HF;@`4%C10`+8S0`!G!$[Z`"12;O_Z6
M.B[_^KIN__QF$BAN``@XK@`,'7P``0`:3EY.=6"\4FX`##HN``RZ;O_X8Q`H%
M;@`(.*[__D(N`!I.7DYU8)A.^0``$D!.5@``80#]F$Y>3OD``!GN3E;_^BANJ
M``P8O``!0F[_^CHN__HH;@`0
``P$`&%E"@P$`'IB!`($`%\=1/__4F[_`
M^@PN`"#__V8"8-(H;@`(0E0,+@`P__]E"@PN`#G__V("8`1.^@"`0F[__"ANY
M``@Z%,K\``IX`!@N__]V,)A#VD0H;@`(.(4Z+O_Z*&X`$!@T4``,!`!A90H,K
M!`!Z8@0"!`!?'43__U)N__HZ+O_\*&X`"+I48Q0H;@`,0A0H;@`(0E1"+O__!
M3OH`"BAN``@]5/_\#"X`,/__90H,+@`Y__]B`F"&#"X`(/__9B8Z+O_Z*&X`I
M$!@T4``,!`!A90H,!`!Z8@0"!`!?'43__U)N__I@TDHN__]G#"AN``Q"%"ANB
M``A"5$Y>3G5P`DZY```!'$Y6__Y";O_^58\Z+@`,/P4H;@`(2%1.N0``$SI<W
MCSH?/P4P+O_^L%=C!$[Z`%XZ+O_^2ZX`#"AN``@,-`!A4`!E.CHN__Y+K@`,=
M*&X`"`PT`'I0`&(F.B[__DNN``PH;@`(>``8-%``!$0`(#HN__Y+K@`,*&X`T
M"!F$4``P+O_^L%=D!E)N__Y@I%2/3EY.=7``3KD```$<3E8``%F/0F=(>0``>
M&QQ"9TZY```'SE"/(]\```2&2KD```2&9@A"+@`(3EY.=5F/+SD```2&3KD`J
M``D(6(\CWP``!(I*N0``!(IF%B\Y```$ADZY```(L%B/0BX`"$Y>3G59CS\\W
M``](>0``&QXO.0``!)8O.0``!(I"ITZY```'8D_O`!(CWP``!(Y*N0``!(Y7J
MQ40%'44`"$Y>3G5P`4ZY````!G``3KD```$<3E8``$JY```$CF8.+SD```2*<
M3KD```=*6(]*N0``!(IG#B\Y```$BDZY```))EB/2KD```2&9PXO.0``!(9.:
MN0``"+!8CTY>3G5P`$ZY```!'$Y6```_/`!`2'D``!LP3KD``!%N7(].N0``^
M$5P_/``T2'D``!MR3KD``!%N7(].N0``$5Q.7DYU<`!.N0```1Q.5@``58](B
M>0```;`_/``(2'D```&V3KD```G&3^\`"A/?```$HDIY```!L&,"8`1.^@$,M
M58\_/`!.2'D```&V0F=(>0``&ZA.N0``$Y!/[P`,#!\``68,0BX`"$Y>3G5.9
M^@#8/SP`3DAY```!MDZY```6NER/58\_/``/2'D``!NJ/SP`3DAY```!MD)GS
M2'D```&T3KD``!2V3^\`$DH?9P)@!$[Z`(HZ.0```;3D34A%0D5(12/%```$%
ME@QY``$```&P8VH_/`!.2'D```(&2'D```2C2'D```&T3KD``!6>3^\`#GH`*
M.CD```&T(\4```222CD```2C9RP,N0``!+````228@HC_```!+````22#+D`,
M`)Q````$DF4&0KD```223OH`"D(N``A.7DYU'7P``0`(3EY.=4[Z``I"+@`("
M3EY.=7`!3KD````&3OD``!6(<`!.N0```1Q.5@``0KD```220KD```2658].A
MN0``&))*'V<"8`1.^@#X58].N0``%U)*'V<"8`1.^@#0*'D```2*(^P`&```1
M!)H&N0```"P```2:(_D```2:```$GC\\`"I(>0``&[Q.N0``$6Y<CRAY```$6
MGB\4/SP`"$ZY```2YER/3KD``!%<2KD```229VXH>0``!)XHN0``!)(_/``'L
M2'D``!OH3KD``!%N7(\O.0``!)8_/``!3KD``!+F7(\_/``A2'D``!OR3KD`.
M`!%N7(\H>0``!)XO%#\\``A.N0``$N9<CS\\``9(>0``'!9.N0``$6Y<CTZY)
M```17$ZY```8`$[Z`!0_/``02'D``!P>3KD``!%N7(].^@`(3KD``!A23EY.:
M=0```````'1R86-K9&ES:RYD979I8V4``$UO9'5L82TR(%1R86-K1&ES:R!3G
M=&5P(%)A=&4@571I;&ET>2!6,2!">2!$879I9"!1+B!+:6YG(#,M3V-T+3@W=
M`$9O<FUA=#H@1$9X.B]!(&X@("`H=VAE<F4@,#P]>#P],R!A;F0@,3(P,#P]\
M;CP]-#`P,#`I`#\`1$8P.D1&,3I$1C(Z1$8S.@``4')E<V5N="!D96QA>2!CL
M;W5N="!B971W965N('-T97!S(&ES("`@("`@(`!$<FEV92!$1@``.B!3=&5P5
M(%)A=&4@9&5L87D@8V]U;G0@8VAA;F=E9"!T;P``('1I8VMS+@!);G9A;&ED$
M(&%R9W5M96YT<P````/L````>P`````````"```![@```?H```(&```"%```J
M`B(```(N```"8@``!`8```2T```%Z```!?P```8F```&<```!]H```@"```(]
M&```"&P```B(```(H```",H```CL```(_@``"1@```DT```)8@``";P```K4\
M```*X```"S(```N"```+_```##0```Q@```,<```#(8```R<```,M@``#,P`W
M``SF```-#@``#3@```UB```-C```#;8```W@```.<@``#V````^&```/I@``#
M#^H``!`(```0@```$*(``!#0```0Z```$/```!$"```14@``$88``!)"```2>
M6@``$F(``!*````2A@``$J@``!*N```2R@``$P(``!,8```5B@``%9H``!:^P
M```6V@``%U8``!=D```7;```%Y(``!>N```7Q```%]@``!?\```8!```&!P`V
M`!@R```82```&%8``!AD```8:@``&'(``!A\```8@@``&(H``!B6```8L@``H
M&-X``!CD```9"@``&1@``!DP```9>```&>0``!GJ```9\@``&@H``!H<```:?
M4@``&E@``!IL```:=```&I(``!J8```:J@``&K8``!J\```:T```&MP``!KB\
M```:Z@``&O```!K^```;!```&Q````"9`````0```)P```#8````]````0P`_
M``6R```%N@``!<(```7.```%U```!=H```7B```%[@``!@````86```&'```F
M!B````8L```&4@``!F8```G,```)T@``">H```K:```,`@``#!H```PH```,7
M+@``#$(```QV```,C```#*(```R\```,T@``#.P```SV```,_```#0(```T(0
M```-%@``#2````TF```-+```#3(```U````-2@``#5````U6```-7```#6H`_
M``UT```->@``#8````V&```-E```#9X```VD```-J@``#;````V^```-R```Y
M#<X```W4```-V@``#>@```WV```.````#@H```X4```.'@``#B@```XR```.3
M/```#D8```Y0```.6@``#F0```YJ```.?@``#IH```ZZ```.U@``#OX```\FA
M```0V@``$/H``!%(```1=```$9```!&:```23```$FP``!)R```2>```$HX`H
M`!*4```2H```$K8``!*\```3(```$R0``!,R```38@``$Y8``!=T```7>@``7
M%XP``!>:```7H```%Z@``!?*```7T```%^(``!?H```8#@``&!8``!@D```8R
M+```&#H``!A"```8H@``&*P``!B\```8P@``&-8``!D$```9(@``&2H``!E$J
M```94@``&5H``!EF```9;```&7(``!F$```9B@``&9```!F<```9J```&;(`7
M`!FZ```9_```&@(``!HL```:-```&CX``!I$```:2```&F```!IZ```:@@``:
J&H@``!J@```:Q`````````/R```#ZP```2D```/R```#Z@````````/R>
``
end
size 8412
//E*O*F StepRate.uue//
echo x - StepRate.mod
cat > "StepRate.mod" << '//E*O*F StepRate.mod//'
MODULE Speedup;
FROM SYSTEM IMPORT NULL, ADDRESS;
FROM Ports IMPORT MsgPortPtr;
FROM PortUtils IMPORT CreatePort, CreateStdIO, DeleteStdIO,
DeletePort;
FROM IO IMPORT IOStdReqPtr, IORequestPtr, IORequest;
FROM Devices IMPORT OpenDevice, CloseDevice;
FROM CommandLine IMPORT GetCL, CLStrings;
FROM InOut IMPORT WriteLn, WriteString;
FROM LongInOut IMPORT WriteLongCard;
FROM Strings IMPORT Length, Compare, CompareResults, Pos;
FROM M2Conversions IMPORT ConvertToCardinal;
VAR argc, i, Where : CARDINAL;
args : ARRAY[0..8] OF CLStrings;
diskport : MsgPortPtr;
diskreq : IOStdReqPtr;
open, ticks, drive: LONGCARD;
ioUnitStuffPtr : ADDRESS;
TrackTicks: POINTER TO LONGCARD;
DontCare, OK: BOOLEAN;
PROCEDURE UpperCase(VAR s:ARRAY OF CHAR);
VAR i: CARDINAL;
BEGIN
FOR i:=0 TO Length(s) DO
IF (s[i]>='a') AND (s[i]<='z') THEN
s[i]:=CHR(ORD(s[i])-32);
END;
END;
END UpperCase;
PROCEDURE Init() : BOOLEAN;
(* returns true if Initialization was successful,
also sets global variable open to 0 on success, or
error number if OpenDevice failed *)
BEGIN
diskport:=CreatePort("",0);
IF diskport=NULL THEN
RETURN FALSE;
END;
diskreq:=CreateStdIO(diskport);
IF diskreq=NULL THEN
DeletePort(diskport);
RETURN FALSE;
END;
open:=OpenDevice("trackdisk.device",drive,diskreq,0);
RETURN open=0;
END Init;
PROCEDURE Term;
BEGIN
IF (open=0) THEN CloseDevice(diskreq); END;
IF (diskreq<>NULL) THEN DeleteStdIO(diskreq); END;
IF (diskport<>NULL) THEN DeletePort(diskport) END;
END Term;
PROCEDURE ShowFormat;
BEGIN
WriteString(
"Modula-2 TrackDisk Step Rate Utility V1 By David Q. King 3-Oct-87");
WriteLn;
WriteString("Format: DFx:/A n (where 0<=x<=3 and 1200<=n<=40000)");
WriteLn;
END ShowFormat;
PROCEDURE ParseArgs():BOOLEAN;
(*return false if there is nothing to do*)
BEGIN
DontCare:=GetCL(argc, args); (* get arguments *)
IF argc>0 THEN (* Parse Command Parameters to ticks and drive *)
IF Compare(args[0],"?")=Equal THEN
RETURN FALSE;
ELSE
UpperCase(args[0]);
IF Pos("DF0:DF1:DF2:DF3:",args[0],0,Where) THEN
drive:= LONGCARD( Where DIV 4 );
IF argc>1 THEN
ConvertToCardinal(args[1], OK, Where);
ticks:=LONGCARD(Where);
IF OK THEN
IF ticks<=1200 THEN
ticks:=1200;
END;
IF ticks>=40000 THEN
ticks:=0; (* stupid input *)
END;
ELSE
RETURN FALSE;
END;
END;
END;
RETURN TRUE;
END;
ELSE
RETURN FALSE;
END; (* Parse Command Parameters *)
END ParseArgs;
BEGIN
ticks:=0; drive:=0;
IF ParseArgs() THEN
IF Init() THEN
ioUnitStuffPtr:=diskreq^.ioReq.ioUnit; (* pointer to trackdisk
parameters *)
INC(ioUnitStuffPtr, 44); (* pointer into private area
of trackdisk! *)
TrackTicks:=ioUnitStuffPtr; (* cost of doing business in Modula
is that we have to do this for type
compatibility.*)
WriteString("Present delay count between steps is ");
WriteLongCard(TrackTicks^,8);
WriteLn;
IF ticks<>0 THEN (* change ticks *)
TrackTicks^:=ticks;
WriteString("Drive DF");WriteLongCard(drive,1);
WriteString(": Step Rate delay count changed to");
WriteLongCard(TrackTicks^,8);
WriteString(" ticks."); WriteLn;
END;
Term;
ELSE
WriteString("Invalid arguments");
END; (* if open... *)
ELSE
ShowFormat;
END; (*good args*)
END Speedup.
//E*O*F StepRate.mod//
echo Possible errors detected by \'wc\' [hopefully none]:
temp=/tmp/shar$$
trap "rm -f $temp; exit" 0 1 2 3 15
cat > $temp <<\!!!
82 540 3279 StepRate.DOC
192 194 11814 StepRate.uue
131 383 3807 StepRate.mod
405 1117 18900 total
!!!
wc StepRate.DOC StepRate.uue StepRate.mod | sed 's=[^ ]*/==' | diff -b $temp -
exit 0
--
UUCP: kim@amdahl.amdahl.com
or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim
DDD: 408-746-8462
USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086
CIS: 76535,25klm@munsell.UUCP (Kevin (my watch has a touch screen) McBride) (10/07/87)
In article <15607@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: > >Here is a really nifty utility! It allows you to set the stepping rate >of your floppy drives, which in turn can improve the performance of your >system considerably! > >The author says he can halve the access time on his drives ... down to >about 1500 ticks (from the stock AmigaDOS* value of 3000). I can't get >my old NEC drives to work that fast ... both of them will fail to read >at 1800, but work at 1900. So I've set them for 2000 to leave a little >more margin (at least my old NEC's work with noKLICKstart). Anyway, >an improvement of 1/3 in the stepping rate is still quite noticible ... >especially on dir listings of fat directories! > >I dunno if there any negative implications due to the faster stepping rates, >such as increased wear and tear, reduced reliability, etc., so this is >definitely a "use at your own risk" deal! Perhaps our friends at CBM, or >other knowledgeable disk-wise folks (Hi, Bryce!) could comment? Um, Kim, did you really test this out thoroughly or is your noticable speed improvement a variety of the "rec.audio Monster Cable sounds better because it should. Shouldn't it?" syndrome? Maybe on your system there was a noticeable improvement, but I sure couldn't detect any on my system. For example (after write protecting my Workbench disk, just in case), I ran the following tests: At the normal step rate of 3000, a "list df0:c" command on my Workbench disk took 11.7 seconds. This is the average time of 5 such tests. At the "souped up" rate of 1500, the same command on the same disk in the same drive took 11.6 seconds. Again this is the average time of 5 tests. At a super slowed down rate of 39999, the same test averaged 12.4 seconds. Formatting a disk benchmarked at exactly the same speed regardless of what stepping delay I used. Does this not count? More subjectively, with the rate accelerated to 1500, drawers that had lots of icons in them did appear to open a tad faster, but I didn't do exact timing tests on them. They certainly did slow down dramatically at the 39999 stepping rate. Opening a rather large worksheet in MaxiPlan yielded no noticeable differences between tests using the 3000 stepping rate and the 1500 stepping rate. This definitely looks like something that Bryce should look into and possibly enlighten us on. Perry, could this utility have an effect on FACC in any way? Does the fact that I "Addbuffers" 20 extra buffers pretty much override any benefit that "StepRate" might provide? One thing I did notice, there was a definite improvement in the sound quality of the "grindgrindgrind" noise that my drives make when I increased the stepping delay time. The noise became much lower pitched and much quieter. More like a pleasant purr than the usual annoying grinding noise that reminds me of going to the dentist. All in all, it's a real neat idea and I'm not knocking the program or it's author, but it just didn't seem to do anything for me. -- Kevin McBride | "Is that a real | harvard -\ I/O Software Group | poncho, or is that | ll-xn ---adelie----> munsell!klm Eikonix - A Kodak Co. | a Sears poncho?" | decvax -v talcott -v | Billerica, MA | - Frank Zappa | allegra ------------encore
joels@tekred.TEK.COM (Joel Swank) (10/07/87)
I got similar results to Kevin's with my tests. I was running Facc at the time, so I tried taking away all it's buffers. No change. I also tried closing facc. No change. I tried values from 1200 (the min) to 20000. 20000 slowed down a 9 second directory read by about a half second. Smaller values had no noticable effect. I was doing my tests under Shell 2.06m on DF1:. Joel Swank Tektronix, Redmond, Oregon joels@tekred.TEK.COM
alverson@decwrl.dec.com (Robert Alverson) (10/07/87)
In article <1282@knopfler.munsell.UUCP> klm@knopfler.UUCP (Kevin (my watch has a touch screen) McBride) writes: >One thing I did notice, there was a definite improvement in the >sound quality of the "grindgrindgrind" noise that my drives make >when I increased the stepping delay time. The noise became much >lower pitched and much quieter. More like a pleasant purr than >the usual annoying grinding noise that reminds me of going to the >dentist. > >All in all, it's a real neat idea and I'm not knocking the program >or it's author, but it just didn't seem to do anything for me. > I've been waiting for this for a while, now, since I kew that the gind is caused by running drives at *too slow* a step rate. In my humble opinion, C-A blew it here in that they had to run it slow to guarantee that (maybe with a 68020) the steps wouldn't go too fast. For this reason alone, StepRate is worth it. Any performance gain is just icing on the cake. Bob
kim@amdahl.amdahl.com (Kim DeVaughn) (10/08/87)
In article <1282@knopfler.munsell.UUCP>, klm@munsell.UUCP (Kevin (my watch has a touch screen) McBride) writes: > > Um, Kim, did you really test this out thoroughly or is your noticable > speed improvement a variety of the "rec.audio Monster Cable sounds better > because it should. Shouldn't it?" syndrome? Good question! No, I didn't. When I first played with, it *seemed* to make a very noticeable difference, and it sure *sounded* alot faster (ain't the subjective mind wonderful)! > Maybe on your system there was a noticeable improvement, but I sure > couldn't detect any on my system. Upon performing a few quick tests, I still do find an improvement though; not as much as I had "felt", but still better than you found ... On a relatively unfragmented floppy, 99% full, with 54 files, and no subdirectories, my dir times were (+/- 0.1): ticks secs ----- ---- 3000 21.2 2000 19.0 6000 23.1 or about 11% improvement, at 2000 tics. In another test, I tried doing a completely floppy based compile using Manx 3.40a, on a medium sized set of files (no Facc buffers, no ram:, no vd0:). The source disk is pretty well fragmented, but the compiler disk is as unfragmented as it's possible to get (though file locations are not necessarily optimized for the best performance). ticks mins ----- ---- 3000 16.1 2000 15.4 or about 4.5% improvement. So, I dunno. If I were to swag it, I'd say that disks that are highly fragmented could show a meaningful amount of improvement (whatever "meaningful" is), since they are doing alot more seeking around. Disks that are not fragmented would then show the least improvement, by that line of reasoning. But that could be entirely wrong ... I have never been able to figure out how and where AmigaDOG decides to stuff the next sector, etc. My best guess thus far, is that it rolls a 9-sided die to determine this (no :-)'s ). BTW, I've decided to refer to Tim King's "contribution" to the Amiga, as AmigaDOG, and to the entire collective OS as AmigaDOS ... is that reasonable? > Formatting a disk benchmarked at exactly the same speed regardless of > what stepping delay I used. Does this not count? I don't know. I do know that there is something fundementally different about Format and Diskcopy, as they both will put up a requester asking for the WB on their 1st invocation, if WB isn't in a drive. What is it that they need? > One thing I did notice, there was a definite improvement in the > sound quality of the "grindgrindgrind" noise that my drives make > when I increased the stepping delay time. The noise became much > lower pitched and much quieter. More like a pleasant purr than > the usual annoying grinding noise that reminds me of going to the > dentist. Yes!!! This improvement alone is worth the price of StepRate :-)! My drives, however, went *up* in pitch, but then they normally sound like a cement mixer full of rocks, rather than a dentist's drill ... /kim -- UUCP: kim@amdahl.amdahl.com or: {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 CIS: 76535,25
pes@ux63.bath.ac.uk (Smee) (10/08/87)
There is a (defacto, I think) standard for flopsies which says that 3.5 inch drives must step at 3ms/step, and 5.25 at 6ms/step. If your drive will not do this, you've got a valid complaint. *Most* but not all drives will operate satisfactorily at higher step rates, without problem. (This is nothing to do with CBM, but rather with the companies that make the flopsy drive 'engines'. If your personal drive will handle a higher step rate (lower time) then you're OK. If it can't, one likely result is data corruption which you won't notice when you write a file, but which will garbage it so you can't get it back. I usually run a higher step rate on my <other brand of> machine, but I'd recommend (a) that you test it on non-critical disks for a few hours first, and (b) that you reset it to the 'normal' value before doing anything critical, like making your backups. It's great for non-critical things, though, such as 'temp files' for various applications which need them.
jimm@mitsumi.UUCP (Jim Mackraz) (10/08/87)
In article <71@bacchus.DEC.COM> alverson@decwrl.UUCP (Robert Alverson) writes: >>One thing I did notice, there was a definite improvement in the >>sound quality of the "grindgrindgrind" noise that my drives make >>when I increased the stepping delay time. >I've been waiting for this for a while, now, since I kew that the >gind is caused by running drives at *too slow* a step rate. In my >humble opinion, C-A blew it here in that they had to run it slow >to guarantee that (maybe with a 68020) the steps wouldn't go too fast. >Bob Indeed, the disk noise with v1.1 was caused by slower than necessary timing. The timing on v1.2 is not slower than necessary, although it may be no faster than permitted by any particular drive ever used in Amiga 1000s. Turns out the Amiga has been driving floppies with a 68020 for over a year. I believe that such timings are not processor speed or version dependent. This is not one of the areas where C-A blew it. jimm -- Jim Mackraz Mitsumi Technology, Inc. 408/980-5422 {amiga,pyramid}!mitsumi!jimm
@atlas.UUCP (/) (10/09/87)
I got similar results to Kevin's with my tests. I was running Facc at the time, so I tried taking away all it's buffers. No change. I also tried closing facc. No change. I tried values from 1200 (the min) to 20000. 20000 slowed down a 9 second directory read by about a half second. Smaller values had no noticable effect. I was doing my tests under Shell 2.06m on DF1:. Joel Swank Tektronix, Redmond, Oregon joels@tekred.TEK.COM at will automatically send it to all the subscribers around the world, costing a bundle and annoying them for no good reason.
neil@mitsumi.UUCP (Neil Katin) (10/09/87)
In article <15607@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes:
"Here is a really nifty utility! It allows you to set the stepping rate
"of your floppy drives, which in turn can improve the performance of your
"system considerably!
"
"The author says he can halve the access time on his drives ... down to
"about 1500 ticks (from the stock AmigaDOS* value of 3000). I can't get
"my old NEC drives to work that fast ... both of them will fail to read
"at 1800, but work at 1900. So I've set them for 2000 to leave a little
"more margin (at least my old NEC's work with noKLICKstart). Anyway,
"an improvement of 1/3 in the stepping rate is still quite noticible ...
"especially on dir listings of fat directories!
"
"I dunno if there any negative implications due to the faster stepping rates,
"such as increased wear and tear, reduced reliability, etc., so this is
"definitely a "use at your own risk" deal! Perhaps our friends at CBM, or
"other knowledgeable disk-wise folks (Hi, Bryce!) could comment?
"
"BTW, it doesn't do anything to the "stepping rates" for vd0: or ram: ... of
"*course* I had to try it ... :-)!
"
"/kim
First of all, this "step rate" is specific to the trackdisk.device.
In 1.2 I extended the unit structure to allow people to modify some
specific device parameters (step rate, precompensation points, number
of tracks, settling time, etc.). The worst case spec for amiga 3.5"
drives is 3 milliseconds per cylinder. All those numbers (3000, 2000, etc)
are the number of microseconds to feed to the timer.device between
steps.
The trackdisk device is very conservative in estimating how long to delay
between step pulses. In kickstart 1.2 on a 68000 there is a pulse every
3.7 milliseconds. I could have tuned it for exactly three ms, but then
it would have broken on a 68020 (as others have pointed out). Setting
your step rate to 2 ms means that you may miss some step pulses.
This typically won't be fatal -- the driver will notice that it got
a seek error and try again.
All the parameters for the unit structure are documented in the trackdisk
include file "devices/trackdisk.h".
Finally, OF COURSE the program does not work for vd0: or ram:. The program
writes the trackdisk data directly.
Neil Katin
{ubvax,pyramid,amiga}!mitsumi!neilandy@cbmvax.UUCP (Andy Finkel) (10/09/87)
In article <15607@amdahl.amdahl.com> kim@amdahl.amdahl.com (Kim DeVaughn) writes: >The author says he can halve the access time on his drives ... down to >about 1500 ticks (from the stock AmigaDOS* value of 3000). Actually, I send along a C program that does this very thing, to the moderated amiga source group awhile ago, but I guess it was during the "time of troubles" I did it while tracking down a bug. First the bug... in the file exec/devices.h a member of the Unit structure was wrong...it should be struct MsgPort unit_MsgPort; NOT *unit_MsgPort. Now a warning...you can trash disks and hurt drives by using very low values. Check the drive mfgrs specs to be sure. We/I take no responsibility once you start playing. >* - I still know of no better term for the Amiga OS as a whole, than AmigaDOS; > especially since that's what the default CLI window is titled. I like the term ROM KERNAL for the OS as a whole. >To get at these parameters, you open the TrackDisk.Device and >this device tells you where the parameters are. Of course, the folks >who wrote Amigados & kickstart tried to hide this parameter, so there >isn't a name for it in the system include files. Mr. Kegelmann found >the right longword though. Mr Kegelmann should have looked in the include files...there's one with the catchy name of trackdisk.h that has the info he wanted... ie: struct TDU_PublicUnit { struct Unit tdu_Unit; /* base message port */ UWORD tdu_Comp01Track; /* track for first precomp */ UWORD tdu_Comp10Track; /* track for second precomp */ UWORD tdu_Comp11Track; /* track for third precomp */ ULONG tdu_StepDelay; /* time to wait after stepping */ ULONG tdu_SettleDelay; /* time to wait after seeking */ UBYTE tdu_RetryCnt; /* # of times to retry */ }; > >The initial value of the ticks between steps (eghad, what buzzwords!) >is set to 3000 (base 10; I mean decimal!) by kickstart. Its microseconds, by the way. Anyway, enough complaining. Here's the program. It also lets you play with the settle time. #include "exec/types.h" #include "exec/libraries.h" #include "exec/ports.h" /************************************************************* * This program allows you to read and modify the step delay * and settle delay times for units of the trackdisk device * SetDelay * by Andy Finkel * Copyright 1987 Commodore-Amiga, Inc. * Permission to distribute and use given provided * that this notice remains intact. * * The following is a replacement for a broken include file, included * here for clarity * Don't you do this! Instead, fix your exec/devices.h file ! * Change that *unit_MsgPort to a unit_MsgPort *****************************************************************/ /*#include "exec/devices.h"*/ #define EXEC_DEVICES_H /****** Device ******************************************************/ struct Device { struct Library dd_Library; }; /****** Unit ********************************************************/ struct Unit { struct MsgPort unit_MsgPort; /* queue for unprocessed messages */ UBYTE unit_flags; UBYTE unit_pad; UWORD unit_OpenCnt; /* number of active opens */ }; #define UNITF_ACTIVE (1<<0) #define UNITF_INTASK (1<<1) #include "exec/io.h" #include "devices/trackdisk.h" #include "libraries/dos.h" #include "libraries/dosextens.h" #define TOUPPER(c) ((c)>='a'&&(c)<='z'?(c)-'a'+'A':(c)) struct MsgPort *trackport=NULL; struct IOExtTD *trackreq=NULL; struct TDU_PublicUnit *unit=NULL; extern UBYTE *strcpy(); extern UBYTE *strcat(); main(argc,argv) int argc; UBYTE *argv[]; { int unitno=0,s; struct Process *process; UBYTE buf[10]; if((*argv[argc-1]=='?') || (argc < 2)) { printf("Usage: %ls [Unit] [Step delay] [Settle Delay]\n"); cleanup(0); } process=(struct Process *)FindTask(NULL); unitno=atoi(argv[1]); if((unitno<0) || (unitno > 4)) { printf("Bad args\n"); cleanup(10); } strcpy(buf,"df"); /* is there the unit requested ? */ strcat(buf,argv[1]); /* (cheap way, I know) */ strcat(buf,":"); process->pr_WindowPtr= (struct Window *)-1; /* quietly, please */ s=DeviceProc(buf); process->pr_WindowPtr= NULL; if(!s) { printf("Error: no unit %ld\n",unitno); cleanup(20); } if(!(trackport = (struct MsgPort *)CreatePort(0, 0)))cleanup(20); if(!(trackreq = (struct IOExtTD *)CreateExtIO(trackport,sizeof(struct IOExtTD))))cleanup(20); if (OpenDevice(TD_NAME, unitno, trackreq, 0))cleanup(20); unit= trackreq->iotd_Req.io_Unit; if(!unit)cleanup(20); if(argc >= 3) unit->tdu_StepDelay= atoi(argv[2]); if(argc >= 4) unit->tdu_SettleDelay= atoi(argv[3]); printf("step delay is %ld, settle delay is %ld\n",unit->tdu_StepDelay,unit->tdu_SettleDelay); cleanup(0); } cleanup(err) int err; { if (trackport) { GetMsg(trackport); CloseDevice(trackreq); DeleteExtIO(trackreq,sizeof(struct IOExtTD)); DeletePort(trackport); } exit(err); } atoi( s ) char *s; { int num = 0; while (*s && (*s == ' '))s++; /* eat leading spaces */ if( *s == '+' ) s++; else if( *s == '-' ) { s++; } while( *s >= '0' && *s <= '9' ) { num = num * 10 + *s++ - '0'; } while( *s >= '0' && *s <= '9' ) { num = num * 10 + *s++ - '0'; } return( num ); } UBYTE * strcpy(dest, source) UBYTE *dest; UBYTE *source; { UBYTE *orig = dest; while (*dest++ = *source++); return( orig ); } UBYTE * strcat( s, new ) UBYTE *s, *new; { UBYTE c; UBYTE *orig = s; while( *s ) s++; do { c = *s++ = *new++; } while( c ); return( orig ); } -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Interfere? Of course we'll interfere. Always do what you're best at, I always say." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
news@omepd (News Account) (10/10/87)
In article <1683@tekred.TEK.COM> joels@tekred.TEK.COM (Joel Swank) writes: >I got similar results to Kevin's with my tests. I was running Facc at the >time, so I tried taking away all it's buffers. No change. I also tried >closing facc. No change. I tried values from 1200 (the min) to 20000. >20000 slowed down a 9 second directory read by about a half second. >Smaller values had no noticable effect. I was doing my tests under >Shell 2.06m on DF1:. > >Joel Swank From: hah@mipon3.intel.com (Hans Hansen) Path: mipon3!hah Please also tell us which company made your drives. I suspect that your drives are slightly more intelegent that the NECs that the original aurthor and I have. ?? Hans Hansen
keithd@cadovax.UUCP (Keith Doyle) (10/13/87)
Hey,
This steprate thing seems like basically a good idea. Not for speed,
mind you, but because I can't stand how the drives sound. They SOUND
like they're being stepped too slow, and that's what drives me nuts.
However, are we absolutely sure that running at a higher step rate will
not cause a higher incidence of munged disks due to too marginal a
setting? I'd love to try it, but no way until I am reasonably assured
it isn't going to munch my critical 'C' source disks etc.
Keith Doyle
# {ucbvax,decvax}!trwrb!cadovax!keithd Contel Business Systems 213-323-8170richard@gryphon.CTS.COM (Richard Sexton) (10/14/87)
In article <1794@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > >Hey, > >This steprate thing seems like basically a good idea. Not for speed, >mind you, but because I can't stand how the drives sound. They SOUND >like they're being stepped too slow, and that's what drives me nuts. > >However, are we absolutely sure that running at a higher step rate will >not cause a higher incidence of munged disks due to too marginal a >setting? I'd love to try it, but no way until I am reasonably assured >it isn't going to munch my critical 'C' source disks etc. > >Keith Doyle How can it wreck disks ? It wants something from track nn, so it issues the approporiate number of 'steps' to the drive, after which it reads it to make sure it is on the track it thinks it is on. If it is not, this is a SEEK ERROR, and it should retry, otherwise its positioned over the correct cylander. Is this not the way it works ? -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."
grr@cbmvax.UUCP (George Robbins) (10/14/87)
In article <1794@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > > Hey, > > This steprate thing seems like basically a good idea. Not for speed, > mind you, but because I can't stand how the drives sound. They SOUND > like they're being stepped too slow, and that's what drives me nuts. > > However, are we absolutely sure that running at a higher step rate will > not cause a higher incidence of munged disks due to too marginal a > setting? I'd love to try it, but no way until I am reasonably assured > it isn't going to munch my critical 'C' source disks etc. That's the rub. By using the specified step rate or some slightly slower amount, one can assume that things will be as reliable as you can get. Actually, the step rate is some percentage slower than nominal on a 68000 system and a particular drive may step smoother at a slightly faster rate, or work well with a ramped step rate. Beyond measuring the actual step rate and compensating for the "68000 percentage" you're stepping into some murky water. I wouldn't mess with it too much without writing some kind of excerciser script/program that could evaluate the improvment and also detect any errors. Rather then mess around much with the floppy drives, I'd seriously consider a hard drive, assuming you have the requisite $$$'s. It's a different and better world. -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
grr@cbmvax.UUCP (George Robbins) (10/14/87)
In article <1895@gryphon.CTS.COM> richard@gryphon.CTS.COM (Richard Sexton) writes: > In article <1794@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: > > >This steprate thing seems like basically a good idea. Not for speed, > >mind you, but because I can't stand how the drives sound. They SOUND > >like they're being stepped too slow, and that's what drives me nuts. > > > >However, are we absolutely sure that running at a higher step rate will > >not cause a higher incidence of munged disks due to too marginal a > >setting? I'd love to try it, but no way until I am reasonably assured > >it isn't going to munch my critical 'C' source disks etc. > > How can it wreck disks ? It wants something from track nn, so it issues > the approporiate number of 'steps' to the drive, after which it reads > it to make sure it is on the track it thinks it is on. If it is not, > this is a SEEK ERROR, and it should retry, otherwise its positioned > over the correct cylander. > > Is this not the way it works ? Gee, that sounds like the way it is supposed to work, and probably does. However relying on system error recovery to compensate for your systematic optimism sounds like one of those well greased paths to purgatory. Most likely, the system will recover from the errors and hide them from you until one day you have a brownout or something, and then you'll wonder why you start getting a lot of random errors on the purple disks in your 7'th drive that's worked good since the day you kludged it in. Proceed with due caution... -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
richard@gryphon.CTS.COM (Richard Sexton) (10/16/87)
In article <2499@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >In article <1794@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >> >> Hey, Hey hey, my my. >> However, are we absolutely sure that running at a higher step rate will >> not cause a higher incidence of munged disks due to too marginal a >> setting? I'd love to try it, but no way until I am reasonably assured >> it isn't going to munch my critical 'C' source disks etc. > >That's the rub. By using the specified step rate or some slightly slower >amount, one can assume that things will be as reliable as you can get. > >Rather then mess around much with the floppy drives, I'd seriously consider >a hard drive, assuming you have the requisite $$$'s. It's a different >and better world. (snide comment) So is being filthy rich. >George Robbins Does this mean when the 68000 is finished issueing step pulses and it's about to do a read/write, it doesnt check to see if its on the track it should be/it thinks it's on ? How else could changing the *step rate* bugger up the data ? -- Richard J. Sexton INTERNET: richard@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!richard "It's too dark to put the keys in my ignition..."
klm@munsell.UUCP (Kevin (my watch has a touch screen) McBride) (10/16/87)
In article <1794@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >This steprate thing seems like basically a good idea. Not for speed, >mind you, but because I can't stand how the drives sound. They SOUND >like they're being stepped too slow, and that's what drives me nuts. > >However, are we absolutely sure that running at a higher step rate will >not cause a higher incidence of munged disks due to too marginal a >setting? I'd love to try it, but no way until I am reasonably assured >it isn't going to munch my critical 'C' source disks etc. WWWEEEELLLLLL, Keith. You should exercise some caution. StepRate is not without it's hazards. My drives seemed to be working fine at a step rate of 1800. They were much more quiet than before. Everything was going along fine until the gremlins decided it was time to trash my favorite WorkBench disk. BTW, my drives have always been extremely reliable. I've only trashed 3 or 4 disks in the 1 year that I've owned the machine. I consider myself lucky. Fortunately, I had made a backup copy of that disk only 2 days before, so the only bad thing that happened was some short lived aggravation. The disk that got trashed was not physically bad. I reformatted it, reloaded it from the backup and it's working like nothing ever happened. I upped the steprate to 2000 and that seems to be working fine. I hope. Maybe someday when my Ami grows up she'll have an autobootable 40 meg hard disk and I won't have to worry about the speed of my floppies... sigh. -- Kevin McBride | "Is that a real | harvard -\ I/O Software Group | poncho, or is that | ll-xn ---adelie----> munsell!klm Eikonix - A Kodak Co. | a Sears poncho?" | decvax -v talcott -v | Billerica, MA | - Frank Zappa | allegra ------------encore
jdow@gryphon.CTS.COM (Joanne Dow) (10/16/87)
In article <2499@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: >Rather then mess around much with the floppy drives, I'd seriously consider >a hard drive, assuming you have the requisite $$$'s. It's a different >and better world. > Um, better yet spring the nominal amount for Perry's er ASDG's FACC II. That's a much better deal over all. And it speeds things up very nicely once you've accessed the disk block at least once. How does no stepping sound? I love the sounds of silence there. > >-- >George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr >but no way officially representing arpa: out to lunch... >Commodore, Engineering Department fone: 215-431-9255 (only by moonlite) -- <@_@> BIX:jdow INTERNET:jdow@gryphon.CTS.COM UUCP:{akgua, hplabs!hp-sdd, sdcsvax, ihnp4, nosc}!crash!gryphon!jdow Remember - A bird in the hand often leaves a sticky deposit. Perhaps it was better you left it in the bush with the other one.