[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stepper Acceleration in RWTS



Michael J. Mahon wrote:
martin_haye wrote:

On Dec 28, 7:51 pm, Sheldon Simms <wsspa...@gmail.com> wrote:

... If that's the case, then the whole idea of
"accelerating" the motor is kind of silly even though the code may successfully
seek to the correct track.



I can add that my own experience developing NakedOS involved
empirically determining values that would work, and that I found
acceleration to be definitely necessary. If I started out stepping to
fast, the stepper wouldn't move at all.

There were some mentions in Beneath Apple DOS (I think) about Shugart
specs, and I suspect Woz actually had access to technical docs for the
stepper and used a table computation to arrive at the acceleration/
deceleration values.


While that may be so, acc/dec head movement was virtually unknown
in the floppy world at that time, since seeking was done with very
simple "step up/step down" logic.

I think that Woz, who was doing all the drive control in software,
simply saw an opportunity for speedup and persued it.  I'd bet that
the values he used were at least partially the result of experiment.

The Disk ][ was the fastest-seeking Shugart floppy drive on the
market because of his more sophisticated control (not to mention
the higher effective data rates from his use of GCR).

I'm fascinated to learn about POKEing new speed values in for newer
drives into DOS. That's so cool I have to try it with my IIc.


I suspect you'll find significant seek speedups!

Here's the delay routine used for seeking and motor control
in DOS 3.3:

39FD:                2 **************************
39FD:                3 *   MSWAIT SUBROUTINE    *
39FD:                4 **************************
39FD:                5 *                        *
39FD:                6 *  DELAYS A SPECIFIED    *
39FD:                7 *   NUMBER OF 100 USEC   *
39FD:                8 *   INTERVALS FOR MOTOR  *
39FD:                9 *   ON TIMING.           *
39FD:               10 *                        *
39FD:               11 *   ---- ON ENTRY ----   *
39FD:               12 *  A-REG: HOLDS NUMBER   *
39FD:               13 *        OF 100 USEC     *
39FD:               14 *        INTERVALS TO    *
39FD:               15 *        DELAY.          *
39FD:               16 *                        *
39FD:               17 *   ---- ON EXIT -----   *
39FD:               18 *  A-REG: HOLDS $00.     *
39FD:               19 *  X-REG: HOLDS $00.     *
39FD:               20 *  Y-REG: UNCHANGED.     *
39FD:               21 *  CARRY: SET.           *
39FD:               22 *                        *
39FD:               23 *  MONTIMEL, MONTIMEH    *
39FD:               24 *   ARE INCREMENTED ONCE *
39FD:               25 *   PER 100 USEC INTERVAL*
39FD:               26 *   FOR MOTON ON TIMING. *
39FD:               27 *   ---- ASSUMES ----    *
39FD:               28 *   1 USEC CYCLE TIME    *
39FD:               29 **************************
39FD: 0003 30 DS 3,0 ;AVOID PAGE BOUNDARY CROSSING...
3A00:A2 11          31 MSWAIT   LDX #$11
3A02:CA             32 MSW1     DEX             DELAY 86 USEC.
3A03:D0 FD   3A02   33          BNE MSW1
3A05:E6 46          34          INC MONTIMEL
3A07:D0 02   3A0B   35          BNE MSW2        DOUBLE-BYTE
3A09:E6 47          36          INC MONTIMEH      INCREMENT.
3A0B:38             37 MSW2     SEC
3A0C:E9 01          38          SBC #$1         DONE 'N' INTERVALS?
3A0E:D0 F0   3A00   39          BNE MSWAIT      (A-REG COUNTS)
3A10:60             40          RTS

This is the unrelocated "master" code, so $8000 should be added
to all addresses to correspond to a 48K "slave" DOS.

The location to patch to speed up all the mechanical delays is
$BA01, which has a standard value of 17 ($11).  With a fast (modern)
drive you can safely change it to 8 or so.  Just drop it until seek
errors start to occur, then bump it up a bit.  ;-)

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."