SECRETS OF THE ST by Wilfred Kilwinger and Richard Karsmakers
On May 23rd, on the PCM Show at Utrecht, Mr. Kilwinger ('chief'
at the Software department of Atari Benelux) gave me permission
to translate his articles that he had published in SAG's "Atari
Magazine". Since he also covers subjects in those articles that
are already discussed or that will be discussed a bit broader in
the near future, I have hereby included translations of all
relevant pieces of some of his articles that were published uptil
now. Some of you that are familiar with the SAG articles will
note that all articles that have to do with the disk drive are
not included - this is since I intend to write a full series of
articles about this subject in the near future.
This time something about System Errors, starting on the next
page.
Every computer owner will undoubtedly recognize the following
event: One is running a program and suddenly the whole thing
crashes - God knows why. And the worst thing about it all is that
the system has to be reset before you can go on. For a
programmer, this is even much more serious - he needs
information about the error through which he will then be able to
locate the error (and get rid of it, of course). We can thus
classify the errors in two, or rather, three categories: Error
messages for the user, errors for the programmer and error
messages about internal (hardware) system errors.
The ST also knows these kinds of errors. In this table you can
see the kinds of error messages the ST knows with information
about who made the erros, for whom it was meant and how they are
visualised.
Category: Caused by: Meant for: Display:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
BIOS User/hardware User By program
GEMDOS Program/user User/programmer TOS error..
SYSTEM Program Programmer Bombs
With BIOS error messages, one most of the time doesn't quite
realise that these belong to the system errors, since the errors
are displayed by the program itself (the way it is done can vary,
since each programmer chooses another way to display them). BIOS,
by the way, means Basic Input Output System and this is a part of
the Operating System of your computer. Examples of BIOS error
messages are those that have to do with disk drive and/or
printer, like "Write Protected" or "Paper Empty". These errors
are plainly caused by the user and are very easy to get rid of.
With GEMDOS errors this is totally different. These can, most of
the time, not be solved by the user and are meant for the
programmer. These errors are put together in the following list:
Number: Description: Possible Cause:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
-32 Invalid function Wrong GEMDOS function number
number
-33 File not found Wrong filename specified
-34 Path not found Wrong pathname (folder name) spec.
-35 Too many files open Too many files or records opened by
programmer or user
Number: Description: Possible Cause:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
-36 Access denied
-37 Invalid file File header damaged
descriptor
-39 Insufficient memory The program tries to use too much
memory
-40 Invalid memory block
address
-46 Invalid drive You tried to use an invalid drive
specified
-49 No more files
-64 Range error
-66 Invalid program load
format
-67 Setblock failure
GEMDOS errors are displayed to the user by means of the message
"TOS Error:..", or sometimes by means of used software. Every
experienced ST users knows TOS Error 35. What you'll notice
immediately is that this one isn't contained in the list on the
previous page, but that -35 in fact is included. Right. You have
to get rid of the minus sign in front of the error to get the
right number. Error number 35 and 37 are most frequently caused
by damage of the contents of a disk. This especially occurs when
one disk is written to by several disk drives. Sometimes, you can
get a TOS error that is far above 60000. At Atari the people
didn't bohter to document these errors, as they in fact should
not occur at all. A possible explanation might be the fact that
the bit that specifies the minus sign has dropped out. The
standard conversion routine doesn't detect this drop-out and
produces a wrong error number.
The BIOS-and GEMDOS errors that are already mentioned belong to
the category of the errors that genarally don't cause much damage
at that won't crash your system. With the bomb-messages, this is
totally different. These errors are per definition not caused by
the user, but caused by the programmer or maybe even system
applications like the desktop.
With a crash, the user principally doesn't get any info about the
error. The programmer still needs that information, and that's
why Atari wrote a so-called 'Bomb-handler', and why Motorola (the
manufacturer of our dear 68000 microprocessor, ED) designed the
processor so that it could recognize certain errors. These
specific routines can repair or 'trap' the errors. These errors
that are recognized by the processor are called exceptions and
the routines that are mentioned are called exception handlers. A
handler, thus, is a certain routine that handles an error that
has occured. The pointer to a handler is located on a specific
place somewhere in memory (have a look at the Memory Map, an
article elsewhere in this issue of ST NEWS). This piece of memory
is called LOW MEM (the lower 64 Kb of the machine). A reset also
leaves this LOW MEM intact.
If an exception has occured, the programmer first has to look at
address $380 and check of the longword $12345678 is located
there. In that case, the information happens to be intact. From
address $384 on, you can find all saved address-and data
registers: D0-D7, A0-A6 and the supervisor register, in this
order. A7 is the stackpoint register. A Stackpointer is a pointer
to the 'notebook' op the 68000 processor. De 68000 has two kinds
of 'notebooks' (one for supervisor mode and one for user mode).
Thus, two A7s are stored down there as well.
The following table comprises a look-up table of all bomb errors:
Number: Description: Cause:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
2 Bus error Program tried to write at LOW MEM,
ROM, or the I/O memory
3 Address error You tried to read/write a word or
longword from an odd address
4 Illegal instruction The processor encountered an
instruction unknown to him
5 Division by zero The processor was instructed to
perform a division by zero
6 Chk instruction This instruction is quite legal,
but the software will first have
to install a handler
7 Trapv instruction See at 'Chk instruction'
Number: Description: Cause:
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
8 Priviliged violation The processor was in user mode,
tried to write on a piece of
memory reserved for supervisor
mode
9 Trace Trace bit is set
10 Line A Unjust way to call the Line A
interface
11 Line F Unjust way to call the line F
interface
12-23 These errors should not occur.
Undefined
24 Spurious Interrupt Bus error during interrupt
processing
25-31 Autovector interrupt Odd numbers should not occur and
even numbers just don't occur
bacause of the interrupt routines
The exception number is stored on $3C4 and the user register is
stored at $3C8. Finally, from $3CC you can find 16 upper words
from the supervisor stack. The meaning of this information is
enabling the programmer to find back his error. The user doesn't
notice this safe-keeping of the information, and that's why the
ST shows that something went wrong. It does this by displaying
bombs or thunderclouds. By counting the bombs, the user can have
some insight in the kind of error that has occured, but he can
normally not do anything with the information.
Like it's said, the user normally has nothing to do with this
information, but maybe it can control your lust for information.
For programmers, however, this information is of great
importance.
Disclaimer
The text of the articles is identical to the originals like they appeared
in old ST NEWS issues. Please take into consideration that the author(s)
was (were) a lot younger and less responsible back then. So bad jokes,
bad English, youthful arrogance, insults, bravura, over-crediting and
tastelessness should be taken with at least a grain of salt. Any contact
and/or payment information, as well as deadlines/release dates of any
kind should be regarded as outdated. Due to the fact that these pages are
not actually contained in an Atari executable here, references to scroll
texts, featured demo screens and hidden articles may also be irrelevant.