Re: Drive Keeps Running...

[dempson@actrix.gen.nz (David Empson)]

Tony Cianfaglione <ab616@chebucto.ns.ca> wrote:

>> [Ctrl-Reset]
>   This is what is happening - it stops until the next command.

With the original Disk ][ controller card (and presumably the UniDisk
controller), pressing Ctrl-Reset while the drive is spinning causes it
to stop immediately, but when Ctrl-Reset is released, it starts up again
and spins for another second before stopping by itself.

After a little experimentation with the IIgs (which should be the same
as the IIc): it appears that Ctrl-Reset turns off the drive, and cancels
the one second timeout.

This seems to confirm my theory about the one second timeout not working
in your IIc (it never times out, but Ctrl-Reset cancels it).

>   If I start the IIc _without_ the external drive, the internal drive will
>run on and on.  Starting the IIc _with_ the external drive plugged in
>causes the internal drive to run momentarily and then stop with the
>external drive then starting up and running on and on.

But it stops running after you press Ctrl-Reset.  It then starts up
again next time any disk command is issued: if the command refers to
drive 1, then drive 1 (internal) is activated for the duration of the
command, followed by drive 2 going permanently active (until another
Ctrl-Reset, or temporarily during any other reference to drive 1).

Does this summary agree with your observed behaviour?


This behaviour sounds like something in the disk controller is causing
drive 2 to be selected at all times, except while drive 1 is active (as
I mentioned in my previous posting, a single soft-switch selects between
the two drives, and there is a separate drive enable output for each).

This does seem rather odd - why is it only happening with the second
drive plugged in?  The computer doesn't do anything special to detect
the second drive, so I'm still wondering whether there might be a
different fault.

It really boils down to one of three things:

1. An internal fault in the IWM disk controller chip.  This could only
be fixed by replacing the chip.  I still think this is the most likely
cause.

2. A motherboard or cable fault, e.g. a corroded or shorted track
somewhere.  I can't think of any specific combination of faults that
would produce these symptoms, however.

3. A fault with the internal drive which is inducing this behaviour.
This is the easiest one to eliminate.  If you know how to open up the
IIc, you can unplug the internal drive from the motherboard, and see
whether the external one behaves itself afterwards (might be tricky, as
you no longer have a drive 1).  


>A Control-Reset will stop it but probably breaks any program that has
>loaded into memory at the same time.  What does a Control-Reset
>do to a program?

Bad things.  It effectively yanks the rug out from under the feet of the
program, and causes the system to start running from a fixed location
(in the monitor firmware).  If you are running under BASIC, the firmware
eventually reinitializes DOS 3.3 or BASIC.SYSTEM and the BASIC firmware,
leaving you at the command prompt.

This is a much harder "break" than Ctrl-C, for example, which is
detected in an orderly fashion by the BASIC interpreter.

If you are running a ProDOS application (SYS file) other than
BASIC.SYSTEM, the application is responsible for hooking into the reset
sequence and starting itself up again after the reset.  Some programs
(e.g. AppleWorks) don't bother - they will drop you into the monitor, or
force the computer to restart.

It is an extremely bad idea to reset the computer while it is writing to
a disk drive, as you will almost certainly destroy the sector which the
computer is writing at that time.  The track may need to be reformatted
afterwards.

-- 
David Empson
dempson@actrix.gen.nz
Snail mail: P.O. Box 27-103, Wellington, New Zealand