#ADPro Problem
8 messages in this thread
Perry,
I recieved my copy of ADPro today(Friday), and while I haven't sent in my
registration card yet, I'm hoping I can get some support early.
I installed ADPro using the included instalation program. When I clicked
on the Workbench Icon for the first time, the screen turned grey and
dropped down for the Alert box. After several (about 15) seconds, the
alert popped up and I got a visit from the guru. Upon reboot, clicking on
the ADPro icon froze the machine. Since I am stubborn this happened
repeatedly. After several attempts, I rebooted into 68000 mode, and
everything seemed to be fine. (I say seemed because I did not do any
exhastive tests at this time, but everything I tried worked, and the
program exited gracefully.)
My system configuration is: A2500/20, 1M Chip ram, 4M Fast ram on A8620
board, and 4M 8UP board, etc. Booting into the 68000 mode costs me 1/2 of
my Fast ram.
I am not positive, but I believe (from memory) that the guru # was
8400000B.00000000. Although I am hoping that you will tell me that this is
a programming problem, I find that hard to believe. TAD never had any
problems with the excellerator board.
I wish I could say that my system has been stable for years and that your
product is the only recent change, but bunches of companies have diluged me
with products in the past few weeks- that time of year ;-). The 8UP board
is less than a week old, and it is the only thing I would think might
effect this problem, though I don't really see how.
Any ideas? Anything I left out? Any help on where I should start looking
to track this problem down will be greatly appreciated.
ADPro was developed on both a 68020 and a 68030 and was tested on a 68000.
All sorts of memory configurations and stresses were applied. There is no
possibility that your configuration represents a generic problem. What may
be the cause is a loose or faulty RAM chip or other hardware problem. As
far as contributary software causes, ADPro installed the latest
req.library. Try running TAD again in 68020 mode. Since TAD will also use
the library, (and it will probably) work there will be someother root
cause.
(1) check your memory both physically (by pushing on the chips and making
sure they are seated well) and by memory test.
(2) look through your startup-sequence for any recently added system hacks.
(3) ensure that TAD still runs on your machine.
pk
Perry,
I tries TAD, and it still works like a champ. Luckily I had not removed it
from my hard disk yet.
I had presumed that you all had used ADPro on excellerated machines, but
was soooooo hoping that the problem would be in the software. So much
easier for me.
As soon as I get back from my Christmas trip I will open her up and start
playing with the memory boards and chips. I had hoped to avoid that, but a
solution there will be better than being without while Ami is in the shop.
I will keep you posted when I know more. I am real dissapointed that
ADPro turned out to be the program which reacted to whatever the problem
is. TAD was such a joy to use that I have been eagerly looking foreward to
experiencing the pro.
Thanks again for the quick help.
Homer
I'm sorry too as I was looking forward to feedback on a program that we
poured so much heart and soul into. But these things happen, for example,
when a memory chip isn't kosher. One program might put a non-critical
variable in the bad location, another might put some very critical
instruction.
Have a good trip and holiday anyway – we'll pick this up again when you
return.
pk
Hey Perry – does ADPro require more stack than TAD, by any chance, and
perhaps he's starting it at shell level? Just a thought.
Ben
Amateur Radio Callsign is A A 7 A S
Our programs should not require any additional stack beyond the default 4K.
Thanks for the thought, but its probably not a stack overrun.
pk
Ok – just a thought. Weird problem – good luck.
Ben
Amateur Radio Callsign is A A 7 A S