saj@chinet.chi.il.us (Stephen Jacobs) (07/22/89)
Lately I've been unable to execute a certain large (about 600 K text+data+bss)
program on my 1040 ST. It used to work fine. The symptoms were as follows:
first when I tried to run it from msh I'd get the error message "fundamental
error", and return to msh. There'd be less than 1 K free memory left, so I'd
have to reboot. I could, at that time, still run it bu loading it into the
Mark Williams debugger and typing :e, or from either Gulam or the desktop.
As of yesterday, the debugger trick either generates the message "child
process terminated (0)", or crashes the debugger back to msh (with about 10 K
of free memory). Running from the desktop gives 2 bombs; Gulam crashes trying
to run it.
Again, this behavior is recent. The program (moria, if you must know) used
to run just fine. I have remade it from sources and compared the result with a
backup copy (Mark Williams cmp utility): no differences. I reloaded msh from
the distribution disk. This behavior occurs with from 0-4 desk accessories
(accessory 1 is the control panel, the others are well behaved too: the idea
was to move the load point around in memory). I use deskmanager 2 to control
bootup, and also have foldr050.prg and fatspeed.prg (and a clock setter)
resident.
Does this paint a consistent picture of anything to any of you out there?
If it doesn't give enough information for a diagnosis, where do I look next?
Do I take my ST to the shop? My hard drive? Trade the ST in?
All answers (even character assassination) appreciated.
Steve J. saj@chinet.chi.il.us
or maybe chinet.uucpsaj@chinet.chi.il.us (Stephen Jacobs) (07/26/89)
In article <9040@chinet.chi.il.us>, saj@chinet.chi.il.us (Stephen Jacobs) writes: > Lately I've been unable to execute a certain large (about 600 K text+data+bss) > program on my 1040 ST. It used to work fine. The symptoms were as follows: > first when I tried to run it from msh I'd get the error message "fundamental > error", and return to msh. There'd be less than 1 K free memory left, so I'd > have to reboot. I could, at that time, still run it bu loading it into the > Mark Williams debugger and typing :e, or from either Gulam or the desktop. > As of yesterday, the debugger trick either generates the message "child > process terminated (0)", or crashes the debugger back to msh (with about 10 K > of free memory). Running from the desktop gives 2 bombs; Gulam crashes trying > to run it. .... > Does this paint a consistent picture of anything to any of you out there? > If it doesn't give enough information for a diagnosis, where do I look next? > Do I take my ST to the shop? My hard drive? Trade the ST in? > Steve J. saj@chinet.chi.il.us > or maybe chinet.uucp The situation hasn't gotten worse, but it hasn't gotten better either. I got one reply so far, suggesting a virus. This seems unlikely because all my floppies have completely clean boot sectors (according to a sector editor). I have the following new information: The large 'erik' demo and the even larger 'California Raisins with music' demo run fine, so the memory takes data ok. I openned the box in case a chip is loose: I have a rev D motherboard with 6 ROM chips (TOS 1.0) and 2 banks of 256K RAM: the front row is 150 nSec NEC chips; the back row appears to be Micron Technology chips. The Atari db debugger refuses to load the problem program (too little memory) and thus doesn't force me to reboot. Again, according to the program header I should have at least 100 k to spare. I sincerely hope some hardware wizard out there can diagnose this. Right now I'm not at all sure I have enough information to take the machine to the local repair shop. I'm leaning toward the idea (since 150 nSec memory chips are out of their guaranteed performance range in the ST architecture) that this is a consequence of marginal memory behavior. Any recommendations for a memory test program? I'm new at using Atari's debugger. Can I trace through the attempt to load a program using it? Apologies to those I have bored. Steve J.
saj@chinet.chi.il.us (Stephen Jacobs) (07/27/89)
Intensive testing of everything I could test intensively (I could still use
an industrial strength RAM test program) really didn't turn anything up. So
in desperation, I re-copied the hard disk driver into the auto folder on my
boot-up disk. No more problem. Go figure.
Steve J.