Skip to main content
? Vic

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 

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 

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
-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
-39      Insufficient memory The program tries to use too much
-40      Invalid memory block
-46      Invalid drive       You tried to use an invalid drive
-49      No more files
-64      Range error
-66      Invalid program load
-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
9         Trace                Trace bit is set
10        Line A               Unjust way to call the Line A
11        Line F               Unjust way to call the line F
12-23                          These errors should not occur.
24        Spurious Interrupt   Bus error during interrupt
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 

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.