Conference hydra::amiga_v1

2566.0. "Pacific Peripherals and ASDG" by TLE::RMEYERS (Randy Meyers) Tue May 16 1989 21:23

Readers of this notesfile may remember that I had problems last
November getting my Pacific Peripherals "Overdrive" disk controller
to work with the fast file system.  (The original series of notes on
this subject was 1890.*.)

To summarize the problem I had:  My disk controller worked fine under
the old file system, but my system repeatedly crashed under the fast
file system.  The typical Gurus were Guru 3 (odd address trap) and
Guru 4 (illegal instruction).

I eventually began to suspect that there an interaction between the
disk controller and my ASDG 8 meg (2 meg installed) memory board.
Testing the memory board showed no problems, and I discovered that
my system began to work after I reseated the memory board.

The problem (before it disappeared) seemed to be heat related:
The system would work fine from power on, but after it had been on
a while (anywhere from 15 minutes to 2 hours), the Gurus would appear
(usually during hard disk I/O).

Well my system worked fine until last month, and then the Gurus
began to appear.  They first showed up as mysterious Gurus after
the system had been on awhile.  Lately, the problem had become so
severe that I could not accomplish anything.

I reseated the memory board; the problem still existed.  I jumpered
the memory board to put it in diagnostic mode and ran diagnostics on
the it for a couple of days.  The diagnostics reported no problems
(even when I heated the memory board with a hair dryer).

Back last November, I talked to Pacific Peripherals a few times on
the phone, and they could offer no advice.  I decided to call ASDG
(they have always struck me as far more technically competent anyway).

The fellow I first talked to at ASDG told me that there was an
incompatibility between the two boards, and that if I called back
I could talk to a technical person that could explain the problem.

I called back, and although I didn't get the engineer who researched
the problem, I did get someone who knew the technical causes of the
problem.  According to ASDG, the Pacific Peripherals controller does
not obey proper buss protocol.   The Pacific Peripheral feeds the wrong
signal to the Motorola DMA controller used on the Overdrive.  Thus,
the Overdrive's conception of the buss signals is 180 degrees out
of phase.  When the buss signal goes from low to high, the overdrive
thinks it has gone high to low (the expansion buss is driven by
signal transitions, not the level of the signal itself).  Because
of this, the Overdrive does not respect the ASDG board's occasional
wait state to do memory refresh, and memory gets corrupted.  (The
ASDG board has no forced wait states, but does introduce a wait
state about 3% of the time.)

ASDG knew of no way of fixing the problem: their memory board and
Pacific Peripherals' disk controller just could not coexist.  They
said that the Commodore memory board did seem to work with the
Overdrive (Commodore's board uses a different refresh technique).
Other disk controllers worked with the ASDG board (ASDG recommended
the Commodore controller and the Hardframe from Microbiotics).

ASDG said that they had informed Pacific Peripherals of the problem,
but that Pacific Peripherals refused to acknowledge it.  "They'll
say that there is a problem, but they'll say that no one knows
what causes it."

I asked about this problem being heat related.  I got the impression
that this problem was not usually though of as heat related, but
it sounded plausible that it might be.  The guy from ASDG said that
the problem depended on razor edge timing, and that heat definitely
affected the dynamics of the system.

(I am sure now that the problem is heat related, and that the problem
starting showing back up when the temperature starting rising due to the
approaching warm weather here in northern Massachusetts.  Lately,
my system would not work during the day when it was warm, but would
function fine at night when it was cool.  If it was cool enough that
I had to wear a sweater when sitting in front of the Amiga, the
system would have no problems for hours on end!  In cause you are
wondering, my Amiga is in a room with lots of windows, and so stays
several degrees cooler than the rest of the house during cold
weather.)

I decided to call up Pacific Peripherals, and I talked to Lee Adams.  He
said there definitely was a problem in using their controller and the
ASDG board.  He said that ASDG "had an opinion" as to what the problem
was, but that Pacific Peripherals did not share it.   (At no time did
he mention that ASDG felt that it was a problem with the Overdrive,
and he would not speculate as to what might cause the problem.)

He did say there is a work around.  In the C directory of the Pacific
Peripherals software disk, there is a command DMAoff.  That command
causes the disk driver not to use DMA, and allows the ASDG memory
board to coexist with the Overdrive.  (Early versions of the
Overdrive software did not contain the DMAoff command.  Updated
floppies can be obtained from Pacific Peripherals for free, I
believe.)  DMAoff should be given in the Startup-Sequence right
after Mounting the first hard disk partition.

I tried DMAoff.  It fixed the problem.

I asked Lee about the performance impact.  He guessed it would be
about 25%.  I timed my Startup-Sequence, and Lee's estimate seemed
to be correct.

I am not thrilled about this solution, but I am glad that I don't have
to buy a new disk controller (in the near future anyway).

I am inclined to believe ASDG's version of the story.  The fix given
by Pacific Peripherals is consistent with ASDG's claim that the problem
is cause by the Overdrive doing DMA to the memory board during refresh
time.

Would any hardware types like to comment?

It sure SOUNDS like ASDG knows what they are talking about.  Thanks for 
sharing the info, Randy.  I'm going to be in the market for a hard disk
real soon and me thinks I'll opt for the HardFrame.

...richard