#GVP '030 Troubles?
19 messages in this thread
Recently I was loaned a GVP A3001 board, 33 mhz, 4 megs static. I know,
life is hard. I've been experiencing random gurus, and I'd like to find
out if others are having the same problems… I've tried to contact GVP,
but their techs were quite busy today. I'm running the GVP hard disk
controller, with two megs of RAM on it, plus an ASDG-designed 2 meg board,
and an internal Supra modem. It's guru'd just sitting at a CLI prompt,
straight out of a cold boot. It's also guru'd while running Turbo Silver
'020, CED II, Comm, you name it. I was running SetCPU FASTROM NOPATCH in
the startup. Does the version of SetCPU matter to this board? It's gonna
kill me, but I think I'm going to need to remove it until the problem's
solved. I've tried removing the 2 meg board, and it still crashes. Also,
sometimes it won't reboot, it starts the reboot cycle and just flickers the
LED, over and over. Typical guru numbers are 81000005.00235858 and
B.00235910. Any ideas?
When it won't reboot and the LED is just flashing (I assume that is what
you mean by flickering, a nice steady beat, not random), what color is the
screen?
Chris
Dark grey or light grey, as I recall. Nothing special, right?
Oh well, I'm afraid that I can't help then. The reason that I asked is
that I had a similar problem with my LUCAS board in my A1000, the LED would
just keep flashing, but I had an aqua screen. It appeared to be a timing
problem getting to the chip RAM, if I remember correctly.
Chris
I had similar problems long ago with an Alegra board for my 1000, as well
as recently with a Hurricane '020 board. This type of GURU can usually
tracked down to a bad ram chip or two. The Alegra problem was due to DRAMS
that weren't fast enough for it's critical timing-related circuitry. Hand
picking the DRAMS solved the problem. The Hurricane problem was due to
either some sort of intermittant connection on the 32-bit RAM board, or
static build up somewhere in the system. After I removed the RAM board,
cleaned it off, and re-installed it everything has been just fine since.
You might check all your connectors and wiggle them around to make sure a
good connection is being made. Do the same for all your socketed (if any)
ram chips.
-Reid.. M.V. Micro –
If it helps any, my trusty Guru list shows the 81000005 as a corrupted
memory list, and 0000000B as a CPU Exception/Op code 1111. Don't ask me
what they mean … 8^).
Harry
John,
My experience was like Reid's. With the a Commodore 2 meg ram card in my
Amiga 2000 with Hurricane 68020 card, it would GURU frequently. With that
Ram card OUT of the system, everything was fine. Now I have 4 megs of 32
bit ram (plus the 1 meg of CHIP), and things are still O.K. A friend with
a similar system found one 16 bit ram card that was O.K., but I don't
remember which one. For now, you might try removing your 16 bit ram and see
if that solves the problem.
Lloyd
John:
We've got a 33mhz A3501 around, and it does the same thing. I believe I'm
going to send ours back. It's really too bad, but since most of our
"standard" A3001's are running at 32mhz (with appropriate crystal upgrades)
and have been for some time, we won't be missing it too much.
Ariel
So you're saying your out-of-the-box 33 mhz boards are sick, but the
upgraded 25 mhz boards to 32 mhz are OK?
What I'm saying is that the single 33mhz board we got in for evaluation
exhibits the same, random (albeit frequent) GURU behavior that you
described in your message. Of the 4-5 "standard" boards that we have
upgraded to 32mhz operation, only 1 has eventually developed problems. The
one that did is now tooling along just fine at 28mhz. The small number of
32mhz upgrades was drawn fairly randomly from a group of about 50 boards
ordered over the last year or so.
I guess I should mention that when I said "most" of our boards, I really
meant "most of our IN-HOUSE" boards. In that context, quantity four WOULD
be "most". The rest of the 50 or so were used in systems shipped to end
users.
Ariel
Try removing the 2 Mb board. My CBM board didn't like my 3001, and my
random errors disappeared after I removed it. Switching slots might also
work, I havent tried that yet.
John,
Your problems sound similar to the ones I'm experiencing with the
Imtronics '030 board I have installed. I experience complete system
freezes more often than GURUs thou. My system configuration is pretty
similar to yours — GVP controller with 2MB installed and a CBM 2MB (2052)
card. Lots and lots of experimenting and I was able to determine the
problem is associated with the memory attached to the '030 board. The
Imtronics does not auto-configure the '030 memory (one has to run a add
memory program to let Ami get access to it) and so I was able to test the
'030 memory with a utility provided by Imtronics. I do not know if GVP
provides a similar utility, but give it a try if possible. At the least
you will eliminate one of the variables.
J
There's a nifty little progam called ARTM (Amiga Real Time Monitor) here in
the libs some where. Since the addresses are same for each typ of error, it
appears there are two problems you are having. If you boot, run ARTM (or
another PD program called EXEC) you can find out which routines are
resident at the addresses of the guru messages. It may not fix the problem
but could point to the source.
Also (and be careful of me here as I have a stock A2000 with HD and 2 meg)
I thought the '030 required setCPU with a -r.
wmc
What's the "-r" option? When I do "SetCPU ?", it give me a very
AmigaDOS-style options list, not a Unix-style list.
J
I don't know for sure, just recall some people saying it solved someof
their problems. I think it might be 68020/030 with 1 meg chip?
wmc
John,
I suspect the "r" option (no dash) goes with Set_Patch_, not SetCPU.
It's for Super Agnus compatability (as you no doubt already know).
-Dave
Actually, I didn't know – I tend to install things in my startup, then
throw away the docs. You better be right, I just added '-r' to SetPatch's
options, because I added a 1 meg chip a while back.
John,
I just have "setpatch r"…no dash before the r (and the r must be
lowercase). I think the purpose of this particular patch is to keep things
like RAD: (which I don't use, much preferring VD0:) from losing their
contents every time you reboot. There may be other factors involved as
well.
-Dave