ST CRASH CLUES

Count the bomb icons

by Patrick Bass, Antic ST Program Editor

The Program Crash. It's something everyone who programs a computer experiences at one time or another. On the Atari 8-bit computers, a system crash is usually accompanied by complete lockup of the machine – not even the reset key works. To recover you need to turn the power off, then back on.

Why did the system crash? Computers have the horrifying habit of doing exactly what you tell them, not what you want them to do. This can lead the computer to jump into a sequence of unknown instructions, or trap itself in an endless loop.

Each program leaves a trail that can be followed to determine the cause of the crash. Unfortunately, you destroy that trail when you turn off the power. It would be nice to somehow be able to recover that information.

The people who built the "brain" of the 520ST, the Motorola 68000, decided that the MC68000 should be smart enough to determine when a catastrophic crash is about to happen – then try to recover from it, if at all possible.

Events that cause the 68000 to start the recovery sequence are called "exceptions" and the whole ball of wax is known as "exception processing." Events that cause exception processing to occur can range from encountering an illegal instruction, to dividing by zero (since the 68000 has a "divide" instruction).

When an exception occurs, the MC68000 determines what type it is, and uses this as an index into a table of addresses in low memory, which point to routines that handle each exception.

As an example, whenever the machine tries to divide a number by zero, an exception occurs. The 68000 says to itself, "An exception! Trying to divide by zero, eh? Well, instead of trying to do that I shall go down to memory locations $14, $15, $16, and $17 and in there I shall find the address of the routine to perform instead of trying to divide by zero." And the machine jumps to wherever the address at $14(long) points to. Most of the time the program may resume operation. But in some cases this is not possible, and here is where Atari got helpful.

BOMBING OUT

Suppose the 520ST determines that it's about to suffer a bad crash from which it might not be able to recover. Before losing control, it writes a copy of the value in each of its address and data registers to a section in low memory that is not erased when you press the [RESET] button in the back of the 520ST.

It then displays the same number of small icons near the center of the screen as the number of the exception that occurred. Have you seen the little "nuclear bombs" (spy bombs in the newest version of TOS) on screen after a crash? Count them, and that's the number of the exception that happened. Reset the machine, and after powerup go down to low memory and look for the crash information in the format that follows:

If the longword at $0380 is $12345678, then the crash information is valid, unless stepped on by another crash.

The Data registers D0-D7 are saved beginning at $0384.

The Address registers A0-A6 and Supervisor A7 are saved beginning at $03A4.

The exception number is stored at $03C4 (long). (See Figure 1.)

The user A7 register is stored at location $03C8 (long).

				  Figure 1
			     ST EXCEPTIONS
			# of Bombs  Exception
			2	    Bus Error
			3	    Address Error
			4	    Illegal Instruction
			5	    Divide by Zero
			6	    CHK Instruction
			7	    TRAPV Instruction
			8	    Privilege Instruction
			9	    Trace

Finally, starting at $03CC there are sixteen words pulled from where the Supervisor Stack was pointing.

The information found down in low memory should help greatly in reconstructing why the 520ST crashed. This should, in turn, give a hint as to where in your program the problem occurred.

Program crashes can be useful. I used to get mad whenever a long string of crashes would occur. But I started looking at the problem as if the machine was trying to help, rather than hinder. Indeed, the machine would not crash if I had just given it the correct instructions in the correct order. Every crash should teach you a little bit more about the limits of the machine and the limits of your own programming ability.

For more detail on exception processing, read 68000 ASSEMBLY LANGUAGE PROGRAMMING, by Kane, Hawkins & Leventhal, Osborne/McGraw-Hill, 2600 Tenth Street, Berkeley, CA 94710. $18.95