koreth@ssyx.ucsc.edu (Steven Grimm) (04/19/88)
Here's a list of what the various numbers of bombs mean...
1 - Impossible. If you get 1 bomb, take your ST to a repair shop.
2 - Bus error. This means you have tried to access memory outside the
computer's valid address space (or tried to access a protected area
in user mode).
3 - Address error. This usually results from doing a word or long
operation on an odd byte boundary.
4 - Illegal instruction. You figure it out.
5 - Divide by 0. Usually generated by the divs and divu instructions,
though if I recall correctly some others can cause it as well.
6 - CHK instruction trap. If a chk instruction returns an illegal value,
this trap is executed. Chk is actually pretty dumb, in my opinion,
unless you're using Pascal.
7 - TRAPV instruction. You get this by executing a trapv instruction
when the overflow bit is set. Most programs don't use trapv, so this
one shouldn't pop up much.
8 - Privilege violation. This one appears when a supervisor-only instruction
is encountered in user mode.
9 - Trace. If you've got the trace bit set, this trap will occur after
each instruction. Great for debuggers.
10 - Line-A. You shouldn't get this, as it's the interface Atari uses to get
to graphics routines.
11 - Line-F. This is supposed to be a hook for math coprocessors, but Atari
(DRI?) used it for GEM instead. I would have preferred a coprocessor.
The others are pretty much undefined; if you get one, something weird is
going on. From 32 to 47 bombs mean that you made a trap call whose vector
wasn't set.
Note that the number of bombs is equivalent to the 68000 exception number.
Hope this helps people.
-Stevebraner@batcomputer.tn.cornell.edu (braner) (04/20/88)
[] When debugging AL programs I sometimes generate a bad CHK on purpose at a point in the program that should not be reached. The six bombs stand out on the screen... Another trick is to use -1 (rather than 0) as the "invalid" pointer-offset value in variables. Then if you use an uninitialized such variable you get a tell-tale 3-bombs. Note though that sometimes you'll get 2 or 3 crashes together, and the number of bombs on the screen when the smoke clears will be the sum of the numbers output by each crash. SO if you get, say, 8 bombs it _could_ really be 3+3+2. A good debugger beats all of the above... - Moshe Braner
hase@netmbx.UUCP (Hartmut Semken) (04/27/88)
In article <2905@saturn.ucsc.edu> koreth@ssyx.ucsc.edu (Steven Grimm) writes: >Here's a list of what the various numbers of bombs mean... > > 1 - Impossible. If you get 1 bomb, take your ST to a repair shop. Possible but not very probable. I got one bomb some day; the ST hang while drawing the bomb. [...] >10 - Line-A. You shouldn't get this, as it's the interface Atari uses to get > to graphics routines. Same as above: if some error occures while drawing the bombs, the Xbios will draw too many bombs (?). >11 - Line-F. This is supposed to be a hook for math coprocessors, but Atari > (DRI?) used it for GEM instead. I would have preferred a coprocessor. So do I. A Trap is alittle faster and smaller than a JSR. I think it helped to put GEM into the ROM. A Freak here in Germany removed the F-Line Traps from the Rom and substituted them with new A-Line Traps (to work with a PAK68 board containing a 68020). hase -- Hartmut Semken, Lupsteiner Weg 67, 1000 Berlin 37 hase@netmbx.UUCP I think, you may be right in what I think you're thinking. (Douglas Adams)
leo@philmds.UUCP (Leo de Wit) (04/28/88)
In article <4481@batcomputer.tn.cornell.edu> braner@tcgould.tn.cornell.edu (braner) writes: >[... story about bombs, rest deleted ...] >- Moshe Braner Apart from throwing bombs, the bios also saves the registers in a specific area in Ram. In case of Bus or Address error (2, resp. 3 bombs) some more info is saved. I wrote a (C) program to read and display this information; if there is enough interest I will forward it to this newsgroup (the program is small enough). Please use e-mail. Leo.
leo@philmds.UUCP (Leo de Wit) (05/03/88)
Having recieved a few enthousiastic reactions for the Bomb detector program,
here is it. You can run it afterwards whenever a bombing has taken place.
The main pre is that it does not have to be resident and that it is an
ordinary C program (what is ordinary C? :=).
The program is called LASTERR and compiles succesfull on a Lattice-C compiler,
so note that int == 4 bytes, and short == 2 bytes!
It could be cleaned up a bit, replacing the 'magic numbers' by macro's etc.
It is mainly self-explainatory; the data referenced (addresses 0x380 etc.)
have already been filled in by the standard error routine (the one that also
throws bombs).
------------------------------- CUT HERE --------------------------------------
/* lasterr.c: report last occured error and stack dump.
* Copyright L.J.M. de Wit, 1988.
* This source and the generated code may be freely distributed, if not used
* commercially.
*/
#define PEEKB(a) (*(unsigned char *)(a))
#define PEEKW(a) (*(unsigned short *)(a))
#define PEEKL(a) (*(unsigned long *)(a))
main()
{
int ssp, i;
ssp = gemdos(0x20,0); /* switch to supervisor mode, save stack pointer */
if (PEEKL(0x380) != 0x12345678) { /* magic marker */
printf("No error occured since last reset\n");
} else {
static char *errmsg[] = {
"Reset", "Reset",
"Bus error",
"Address error",
"Illegal instruction",
"Division by zero",
"CHK",
"TRAPV",
"Privilege violation",
"Trace"
};
short excepno, offset;
excepno = PEEKB(0x3c4);
offset = ((excepno == 2) || (excepno == 3)) ? 8 : 0;
printf("Exception no. %d (%s)\n",excepno,
(excepno >= sizeof(errmsg)/sizeof(errmsg[0]))
? "Unassigned" : errmsg[excepno]);
for (i = 0; i < 8; i++) {
printf(D%d : %8x\tA%d : %8x\n",
i, PEEKL(0x384 + 4 * i), i, PEEKL(0x3a4 + 4 * i));
}
printf(PC : %8x\tUSP: %8x\nSR : %8x\n",
PEEKL(0x3ce + offset), PEEKL(0x3c8), PEEKW(0x3cc + offset));
if (offset == 8) { /* exceptions 2 and 3 */
short status = PEEKW(0x3cc);
static char *accmode[] = {
"unassigned",
"user mode data reference",
"user mode program reference",
"unassigned",
"unassigned",
"supervisor mode data reference",
"supervisor mode program reference",
"interrupt acknowledge"
};
printf("\nRead/Write : %s\n",
(status & 16) ? "read" : "write");
printf("In-/Extern : %s\n",
(status & 8) ? "extern" : "intern");
printf("Access mode : %s\n",accmode[status & 7]);
printf("Address : %8x\n", PEEKL(0x3ce));
printf("Instruction : %8x\n", PEEKW(0x3d2));
}
}
gemdos(0x20,ssp);
}
------------------------------- CUT HERE --------------------------------------
I hope no errors have crept into the source while I was typing it over; but
then, you could use this program to see what bomb was produced ( :=)).
Have fun!
leo. (What you C is what you get).weaver@tut.cis.ohio-state.edu (Andrew Weaver) (05/05/88)
Here is a question I don't think I have ever heard hashed around on here before. Is there a way to intercept the 'bombs' that come onto the screen with some sort of dialog like on the Mac: "Sorry, a system error has occureed [Restart|Resume]" or on the Amiga: "System Error: Guru Meditiation xxx:xxxxxxx [Continue]" so that one can better diagnose problems with one's own (or someone else's) program? It seems to me that having a number of non-descript cherry bombs (or mushroom clouds, which I am told appeared on earlier STs) is not a very good way of represent- ing an error, but I guess that's just me. On a similar note, has anyone purchased and/or received the "NeoDesk" program that was announced in this group last week? It sounds as if it promises a lot, (but at what return?) I'd be interested in whether or not this would be a 'wise' purchase. -- Andrew Weaver weaver@tut.cis.ohio-state.edu Soon to be a 'Zip' at the University of Akron ...ihnp4!cbosgd!osu-cis!weaver (does anyone know of a Usenet site at the University of Akron? ...akw)
ahinds@hvrunix.UUCP (Alexander Hinds) (05/08/88)
In article <12463@tut.cis.ohio-state.edu>, weaver@tut.cis.ohio-state.edu (Andrew Weaver) writes: > > Here is a question I don't think I have ever heard hashed around > on here before. Is there a way to intercept the 'bombs' that come onto > the screen with some sort of dialog like on the Mac: "Sorry, > a system error has occureed [Restart|Resume]" or on the Amiga: "System > Error: Guru Meditiation xxx:xxxxxxx [Continue]" so that one can better > diagnose problems with one's own (or someone else's) program? It seems > to me that having a number of non-descript cherry bombs (or mushroom clouds, > which I am told appeared on earlier STs) is not a very good way of represent- > ing an error, but I guess that's just me. > > -- > Andrew Weaver weaver@tut.cis.ohio-state.edu > Soon to be a 'Zip' at the University of Akron ...ihnp4!cbosgd!osu-cis!weaver What follows is somewhat long and technical in nature... Well, I hacked up something in 'C' on my Amiga, similar to what you're attempting. I didn't like my machine going down on things like divide by zero, opcode A emulation, and things like that. So, I wrote a little ( actually not that little) that runs in the background to catch cpu traps like those mentioned above. I don't know if you'll be able to do it, since you don't have a multitasking environment. Maybe a desk top accessory? I'm not too familiar with the ST, so I can tell you what I did on my Amiga as generically as possible, and maybe you can go from there. This discussion presumes some knowledge of 68000 assembly and 'C'. O.k. What I did was get a list of the 68000 trap vectors, and I reset them to point to my code. It went something like this: void (*ptr()); /*For a pointer to a function that returns void. I actually just used an unsigned long*/ void MyTrapCode() { /*Stuff. See below*/ } main() { ptr = 0000014; /*Some thing like this for divide by zero. I don't have my source in front of me right now!*/ *ptr = &MyTrapCode; } Voila! Now any program that would divide by zero executed my function! Unfortunately, where you want to go from there can get very tricky indeed. For me, I didn't want the machine to pop up a task failed requester and crash. Do accomplish that, (This is greatly simplified, but communicates the essence of what I did), MyTrapCode() looked like: void MyTrapCode() { #asm /*This will differ for your compiler!*/ move -(sp),d2/d4 unlk a5; #endasm /*The above lines undo the default startup code for a function*/ #asm /*Here's where I removed all the things pushed onto the stack because of a trap*/ #endasm Wait(-1); /*Stupid, but effective. Task was held until I pressed ctrl-c in it's window*/ } I know this was kind of general, but if you use your imagination, I think you can take it from there. You can learn alot about your compiler and machine in so doing. There are alot of subtelties to watch out for, some I didn't really discuss. So, be careful, and happy hacking! Well, I hope this helps. If you have any specific questions, I'd be glad to try and help you out. Just send me mail... Alexander Hinds ahinds@hvrford
c162-br@zooey.Berkeley.EDU (Warner Young) (05/10/88)
In article <12463@tut.cis.ohio-state.edu>, weaver@tut.cis.ohio-state.edu (Andrew Weaver) writes: > Here is a question I don't think I have ever heard hashed around > on here before. Is there a way to intercept the 'bombs' that come onto > the screen with some sort of dialog like on the Mac: "Sorry, > a system error has occureed [Restart|Resume]" or on the Amiga: "System > Error: Guru Meditiation xxx:xxxxxxx [Continue]" so that one can better > diagnose problems with one's own (or someone else's) program? It seems > to me that having a number of non-descript cherry bombs (or mushroom clouds, > which I am told appeared on earlier STs) is not a very good way of represent- > ing an error, but I guess that's just me. > Andrew Weaver weaver@tut.cis.ohio-state.edu As a matter of fact, it is possible to "trap" the exception vectors to run your own routines. Compute!'s book on C Programming on the ST has a program that does just this, called Bombsite (or something like that). I have no permission to post the program here, and it's written in a format that would be rather unwieldy to post, but I suggest you check out this book; it's quite good. \ /arner - Writer of the dreaded Safety Seal Reviews \ / / - Owner of the vaporware group Safety Seal Software \/ \_/oung | - Disclaimer: I'm not associated with any of the companies \_| above, in any way except (possibly) as a customer.
wes@obie.UUCP (05/11/88)
In article <12463@tut.cis.ohio-state.edu>, weaver@tut.cis.ohio-state.edu (Andrew Weaver) writes: > Is there a way to intercept the 'bombs' that come onto > the screen with some sort of dialog like on the Mac [...] > or on the Amiga: [...] Sure. The bombs are drawn on the screen by the default handler for the following processor exceptions: 2 Bus error 3 Address error 4 Illegal instruction 5 Zero divide 6 CHK instruction 7 TRAPV instruction 8 Priviledge violation 9 Trace trap A Line A emulator B Line F emulator C Reserved D Reserved E Reserved You could simply write a Ptermres program that points the vectors for these exceptions (except Line A and Line F) to your code, and have the code pop up an alert with some useful information. The bombs tell you which exception you got, however, and the information about the processor's context at the time of the crash is stored in a buffer in low memory so you can access after a crash, even after a warm boot.