 |
If you are still tearing your
hair out because that error was not covered in the first part
of Steve Pedler's article, fear not, the concluding part of
this article brings you all the other error codes you are
likely to encounter on your Atari.
|
Part 2 - Operating System Errors
Error codes from 128 onwards are not specific to
any one language, since they are codes generated by the Operating
System (O.S.) following an input/output (I/O) operation. To fully
understand these codes, a working knowledge of the I/O subsystem is
necessary. There is insufficient space in an article intended to be
a reference guide to go into this in detail, but further information
can be obtained from the sources listed at the beginning of part 1
of this article. I have however found it necessary to review certain
aspects of the I/O system when discussing the various error codes
and I hope that more experienced programmers will forgive any
generalisations I have made in the interests of clarity and
simplicity.
Beginners should remember that most of the work in
setting up IOCBs and calling the OS is done for you by BASIC. Many
of these errors will not be seen until you try to access peripherals
directly by using BASIC's file handling commands (OPEN, CLOSE, PUT,
GET, XIO, etc.), or by setting up the IOCB and calling the operating
system routines directly.
Error-128 BREAK abort.
If you press the BREAK key during an I/O
procedure, the operation is aborted and this status code returned.
Therefore, never press BREAK during I/O unless you mean to stop the
operation.
Error-129 IOCB already open.
See error 134 for a brief explanation of the
IOCBs. Any given IOCB can only be open for one purpose at any time.
If you try to open an IOCB that is already in use, this error code
is returned, even if the second operation is identical to the first.
Always CLOSE an IOCB before using it again. (Note that trying to
CLOSE an already closed IOCB does not generate an error.)
Error-130 Nonexistent device.
After setting up an IOCB (see error 134) the
Central Input/Output utility (CIO) determines from the data in the
IOCB the nature of the device you wish to use. It then looks up the
address of the device handler (the software which actually performs
the operation) in an area of RAM called the Handler Table (38 bytes
starting at location 794). Each entry in the table consists of three
bytes (two additional bytes are unused), the identifier code for the
device concerned (C for cassette, E for screen editor etc.) plus the
address in low and high byte format of the handler software.
On power up five handlers (the 'resident'
handlers) are specified in the table (Cassette, Editor, Screen,
Keyboard and Printer). These handlers are located in the OS ROM.
Others (the non-resident handlers) are either booted in (such as
Disk or RS232-C handlers) or can be added later. CIO searches the
table for the appropriate device, but if the handler is not present
in the table error 130 is returned. To see
this, try the following. POKE 797,65 will replace the identifier for
the cassette handler with the ATASCII value for the letter A. Now
try a CLOAD. Error 130 will be displayed as CIO thinks the cassette
handler is not present in memory.
Error-131 IOCB write only.
Before you can do anything with a peripheral, you
must first OPEN a channel (IOCB) to it. The OPEN command will
specify whether data is to be read from or sent to the device. (This
is of course done automatically with certain BASIC commands such as
SAVE, LOAD, LPRINT etc.) If you OPEN a device to send data to it and
then try to read data from it, this error results. You will then
have to CLOSE the channel, and reOPEN it for read or read write
(update).
Error-132 Invalid command.
On setting up an IOCB, one of the necessary pieces
of information you must supply is a command code which indicates the
type of action yon wish CIO to take. All peripherals share a series
of common codes for open, close, put, get bytes, etc. (although not
all functions are available for each device - see error 146). In
addition, there are a number of 'special' codes which are specific
to certain devices, such as the disk drive and screen handler. Error
132 occurs when either the common code is incorrect, or you have
issued a 'special' command to a device which doesn't have any
special commands. If this error occurs from BASIC, you should check
the command POKEd into the IOCB, or the XIO command number (the
number immediately following the XIO statement).
Error-133 Device or file not open.
This error occurs when truing to access a file or
device that has not been OPENed. A common cause of this is a mistake
in your file specification, either on OPEN or when trying to access
the device.
Error-134 Bad IOCB number.
The Atari maintains a series of eight Input/Output
Control Blocks (IOCBs) in RAM, commencing at location 832. Each IOCB
(numbered from 0 to 7) is 16 bytes long, and into this area is
placed the information needed by the O.S. to perform the required
action. This includes a command code indicating the operation that
is required, the source, or destination of the data to be
transferred, how much data to transfer, and any information that may
be specific to the device concerned. BASIC sets up an IOCB
automatically when performing I/0 operations, but you can also set
them up yourself from BASIC or assembly language. Once the IOCB is
ready, a single machine language call to the Central Input/Output
Utility (CIO) will pass control to the O.S. for the procedure to be
carried out. CIO will in turn call the specific device handler. If
the I/O procedure uses the serial bus (cassette, printer, etc.) the
handler will set up another area of RAM called the Device Control
Block (DCB) and will then call
the Serial Input/Output Utility (SI0) to do the actual data
transfer.
When performing I/O operations therefore you must
specify the IOCB to be used. BASIC always uses IOCB 6 for the screen
handler, IOCB 0 for the screen editor and IOCB 7 for LPRINT. When
using OPEN, CLOSE, PUT, GET etc. you specify the IOCB in the number
immediately following the command (e.g. OPEN #1, CLOSE #4). With
XIO, the first number is the command, the second is the IOCB to be
used (e.g. XIO 18 #6).
Since BASIC reserves IOCB 0 for the screen editor,
you cannot use this from a BASIC program, error 20 (not error 134)
occurs if you try. You can however use IOCB 0 from machine code.
In assembly language, the IOCB number is placed in
the X-register for use as an index. Because each IOCB is 16 bytes
long, the IOCB number must be an exact multiple of 16 (including 0)
and not be greater than 128. If this is not adhered to, the IOCB
number is wrong and error 134 is the result.
Error-135 IOCB read only error.
This is the exact opposite of error 131. It means
that you have attempted to read from a device opened only for write.
You will have to CLOSE the device and reOPEN it for read or read
write (update).
Error-136 End of file.
Not so much an error as a status code indicating
that when reading data from a device you have come to the end of the
file.
It can be useful to check for this code when you
don't know precisely how much data is present in the input file. You
could then instruct CIO to read a block of data you know is larger
than is actually present in the file and check for this error code
(using TRAP in BASIC to prevent the program from stopping). The
actual amount of data transferred is recorded in the ninth and tenth
bytes of the IOCB used (see Mapping the Atari pp. 82-89).
Error-137 Truncated record.
The Atari O.S. supports two main types of I/O
procedure - byte oriented and record oriented.
With byte oriented transfer, you simply specify
the memory location where the data to be transferred is located
(output) or where it is to be stored (input), and the number of
bytes to be transferred. The, operation continues until the
specified number of bytes is moved, or the end of the file is
reached, regardless of the nature of the data. If you are inputting
data and you have not reserved a large enough area (buffer) of RAM
for the incoming data, then data input is not halted - it just
overwrites whatever follows the buffer (program lines, screen memory
etc.).
In record oriented transfer, input or output only
continues until an ATASCII end-of-line (EOL) character is reached.
If on input your allocated buffer size is exceeded before an-EOL is
reached, then only part of the data is input and this error is
returned, indicating that the record is truncated.
The BASIC command for record oriented input is
INPUT . When using this command, BASIC allocates a
maximum buffer of 119 bytes (according to the DOS 3 reference
manual). If you use INPUT to read a file created
using byte oriented transfer (PUT in BASIC) you may run into this
error.
Error-138 Device timeout
This is an error generated by SIO following I/O
which uses the serial bus (e.g. printer, disk, cassette). For each
device the device handler sets a finite amount of time by which the
device must respond to the command sent - the device 'timeout'.
'Intelligent' peripherals such as the printer or disk drive can
actively acknowledge the command and so the timeout value is short.
If this error occurs with these devices the usual cause is that the
device is not connected or switched on, or the printer is not
switched to on-line.
Unfortunately, the cassette recorder is not an
'intelligent' device and cannot respond in this way. If you try to
output to the cassette and it is not connected, or Play and Record
have not been depressed, then the Atari has no way of knowing this
and continues to send data regardless until it is all sent. This is
the reason for the audio prompts when using the cassette recorder.
When inputting from cassette, the Atari waits until the recorder
starts to send data. If it does not do so within the timeout period
(about 37 seconds according to Mapping the Atari) then this error is
generated and the cassette motor is stopped. Potential causes for
this (other than the obvious ones) include excessively long tape
leaders or incorrect measurement of the baud rate (sometimes seen
when trying to load programs recorded on another recorder to your
own). If this persists in happening with programs recorded on your
own system, then have your recorder checked.
Error-139 Device NAK.
There are a number of possible causes of this
error which is, to a certain extent, dependent on the device. One
possibility is that an, illegal command was sent to the device such
as trying to access a bad disk sector or one not present on the disk
(e.g. a sector number greater than 720 on a single density disk).
Check the syntax of the command passed to the device.
This error may also occur during the use of the
850 interface module, see the 850 Manual for further details. The
error may be returned when using the printer if the printer is not
switched to on-line.
Error-140 Serial bus error.
The ROM location 53775 (SKSTAT - D20F hex) holds
the current status of the serial I/0 port and keyboard. If bit 7 of
this register is set it means that data received from the peripheral
has become scrambled, e.g. data bits are missing or unwanted ones
added. This error is then returned to the user.
According to the DOS 3 reference manual, this is a
rare error. I have only seen it once, when first adding a printer to
my system, and it occurred due to a bad cable connection
at the printer end. If this error persists, then Atari suggest
having the offending peripheral or computer checked.
Error-141 Cursor out of range.
Each graphics mode has its own particular
resolution (the number of points which can be plotted on the screen
. You must stay within the limits of resolution for the mode you are
using, and if you exceed the limits for that mode then error 141 is
the result.
It this seems an unusual error to find amongst the
I/O error codes, remember that the Atari treats the screen and
keyboard just as any other peripheral. PRINT and PLOT operations are
considered to be I/O procedures, and when you change graphics modes
you are in fact OPENing a channel to the screen handler.
Error-142 Serial bus data frame overrun.
The Atari serial port receives data one byte at a
time, with the eight bits of that byte arriving one after the other
(i.e. in serial fashion rather than parallel fashion, when all eight
bits arrive together). The incoming byte must be processed before
the next can be dealt with, but the peripheral doesn't wait for the
computer it sends the next byte regardless. If the next byte arrives
while the computer is still processing the first, then the data is
said to have 'overrun', and error 142 results.
Note that SKSTAT (see error 140 above) contains
the serial port status, and if data overrun occurs then bit 6 is
set, not bit 5 as stated in the DOS 3 reference manual (see the
hardware manual p. III.18). Once again, Atari suggest that if this
error occurs more than once the computer should be checked.
Error-143 Serial bus data frame checksum error.
When data is sent to the computer from the
peripheral, a checksum byte is also sent at the end of each block of
data. This is a single byte consisting of the sure of all the other
bytes in the data frame. On receipt of the data SI0 calculates its
own checksum and compares it with that sent by the peripheral. This
procedure is intended as a check of the accuracy of the data being
sent compared with when it was recorded. If the checksums don't
match, then this error is returned.
There are a number of potential causes. The
initial recording of the data may have been fault; due to a
defective disk or cassette, or the peripheral itself or the I/O
connections may be faulty. This error is usually seen with the
cassette recorder due to the inherently unreliable nature of
cassette storage. If it persists with data recorded and played back
on your own system, then have the recorder and or computer checked.
Error-144 Device done error.
This error occurs when you have issued a valid
command to the peripheral but the device is unable to carry it out.
For example, you may have tried to write to a disk that is
write-protected, or there may be no disk at all in the drive. 'Your
Atari Computer' implies that this error might also occur if the disk
directory was damaged in some way.
The cause of the error depends on the device, so
check the command given and whether the device is prevented in some
way from executing it.
Error-145 Read after write compare error or bad
screen mode.
This error has two potential meanings. When the
disk handler writes a file to the disk, it reads the file after
writing it as a check of the accuracy of the recording. If there is
a difference between the tile as written and what should have been
written this error is returned. Possible causes would include a
defective disk or faulty drive, although write errors do occur on
occasion for no apparent reason. Try resaving the tile onto another
disk to see if the error recurs.
The second cause of this error is if you try to
choose a graphics mode not implemented in your computer. For
example, the original 400/800 machines have no graphics modes from
12 to 15. Selecting one of these modes on a 400/800 will result in
error 145.
Error-146 Function not implemented.
As indicated in the explanation of error 132, all
device handlers share common command codes for a series of
operations. These include the commands to OPEN, CLOSE, get STATUS,
PUT/GET RECORD, and PUT/GET BYTE. Clearly, not all of these
operations are possible with all peripherals, so that (for example)
you cannot send data to the keyboard or get data from the printer.
Attempting to do one of these impossible operations will generate
error 146.
Error-147 Insufficient RAM
This error code is very similar to BASIC's error 2
(see this error for a brief explanation of how the Atari keeps track
of memory usage). Whenever you change graphics modes, the value in
MEMTOP (741,742) is changed accordingly, being either increased or
decreased depending on the memory requirements of the mode selected.
If the change of mode would lower the value in MEMTOP so much that
it would be lower than that in APPMHI(14,15) then the screen is
returned to graphics 0 and error 147 is returned.
This error is not likely to occur in machines of
48K or more, but certainly could occur in 16K machines with a large
program using high resolution modes such as graphics 8-11-and 15.
There is only one solution - add more memory.
Errors 150-154 are devoted to the use of the
RS232-C serial ports. I have not included explanations for these
errors here (mainly because I don't fully understand them) but also
because anyone using these ports would presumably have access to the
850 Interface Manual or equivalent. These error codes are fully
documented in that manual, to which reference should be made.
Error-160 Drive number error.
You can attach up to four disk drives (numbered 1
to 4) to your Atari, but with standard DOS 2.5 the default number
that can be hooked up is two. This is because each drive in the
system needs a 128-byte buffer reserved for it. Since the majority
of users are unlikely to want (or need) more than two drives, the
default is two to conserve memory. With standard DOS 2.5 then,
attempting to access a disk file with a drive number that is neither
1 nor 2 will result in error 160. If you wish to connect up more
drives, a simple modification to your DOS will be needed.
Under certain circumstances however, you can use
drive numbers between 1 and 8 without error. For example, if you own
a 130XE, you can use the RAMDISK utility of DOS 2.5 to set up the
extra 64K of RAM for use as a virtual disk drive, in which case the
'drive' takes on the number 8. The point at which this error is
generated therefore, will to a certain extent depend on your system;
however, the drive numbers must always be in the range 1 to 8.
Error-161 Too many OPEN files.
DOS 2.5 allows you to have a maximum of three open
disk files at any one time (although you can have files open to
other devices as well). This is because each open tile has a
128-byte buffer associated with it, and DOS only provides for three
such system buffers. I am not sure whether it is possible to modify
DOS to allow more open files than this. If this error occurs, you
should check for the presence of any file(s) opened unnecessarily,
and close them to free them for further use.
Error-162 Disk full.
This means that there is no further free space on
the disk for saving programs or data. If this occurs and you don't
have another formatted disk with enough free space available, the
only way out is to use the cassette recorder to save your program,
format a new disk, then reload the program and put it onto the empty
disk.. Moral: always have a ready formatted spare disk or two to
hand.
Error-163 Unrecoverable system data I/O error.
This error appears to act a, a catch-all for any
I/O error not covered by the other I/O error codes, and for which
the cause cannot be determined. It appears to be a very rare error.
Suggested causes are malfunctioning equipment, corrupted DOS, and
damaged disks (though there are presumably others).
Error-164 File number mismatch.
There are two possible causes of this error. The
first relates to the use of the POINT statement. Having OPENed a
disk file, you can refer to any byte within that file by moving an
internal pointer with the POINT command. To do this you must
specify: the channel number on which the file
is open, the sector number and the byte number within that sector.
If the sector specified by you does not form part of the OPEN file,
this error is returned to you. POINT can also generate other errors
- see errors 166 and 171.
The second cause of this error will hopefully
never be seen with today's reliable disk drives. Disk files are
stored on the disk as sectors of data, each sector holding 128
bytes. Of these, only 125 bytes are program data, the other three
hold information needed by the disk drive. This includes the file
number as present in the directory, and the number of the sector
holding the next part of the file (i.e. the next sector to be read
or written to). When moving to the next sector, the drive checks
that the sector does indeed belong to the correct file. If the file
number does not match, then error 164 is returned. This shouldn't be
seen with present day drives, but was apparently a fairly common
problem with the early 810s. If it occurs and you haven't been
tampering with the disk structure, your drive may need servicing.
Error-165 File name error.
The Atari only allows the use of the letters A-Z
(uppercase) and numbers 0-9 in disk filenames, plus the wildcard
characters "*" and '?'. Any other character in a filename
will cause this error.
Although the wildcard characters are legal, they
are not so when creating a file, only when reading from an already
existing one. The reason is fairly obvious, you shouldn't create
ambiguous file names, and attempting to do so will return this
error.
Error-166 Point data length error.
See error 164 for a description of the POINT
statement. When using POINT, you must specify the byte number within
the indicated sector. This number must be in the range 0-125
inclusive. If it is not, then this error is the result. See also
errors 164 and 171.
Error-167 File locked.
Once a disk file is locked, the only thing you can
do with it is read it. You cannot write to it in any was, delete it
or change its name. Trying to do any of these things to a locked
file generates error 167. You will have to unlock the file using DOS
2.5 option G or XIO 36 from BASIC.
Error-168 Command invalid.
Take a look first at error 132. What is the
difference, you might ask, between these two errors? Certain device
handlers, notably the disk drive, RS232-C and screen support
'special' command codes in addition to the common codes used by all
devices. These are device specific commands, and for the screen
handler are draw and fill. The disk handler has seven special
commands: rename, delete, lock, unlock, point, note and format.
Error 132 will occur if you issue a special command to a device
which doesn't have any special commands associated with it. Error
168 occurs if the device concerned does have special command codes,
but the code you used is not recognised by the handler. You should
check the command issued to the device (e.g. via a XIO statement).
Error-169 Directory full.
The 810 and 1050 disk drives from Atari only
allocate 8 sectors on the disk for the directory. These 8 sectors
allow you to make a total of 64 directory entries (i.e. 64 separate
files on the disk). In practice, this should be enough for anything,
and you are much more likely to fill the rest of the disk before you
exceed this limit. If you do exceed it, error 169 is generated and
you will have to use another disk.
Error-170 File not found.
The file name you use for any operation must match
exactly one of the file names on the disk. Even if it differs by
only one character, if it doesn't match an entry in the directory
the disk handler will be unable to find the file and will return
this error. The usual cause is inserting the wrong disk in the
drive or a typing error when entering the file name.
Error-171 Point invalid.
The next step after a POINT (see errors 164 and
166 for further details) is usually to read (using INPUT or GET) the
byte pointed to, or write to it using PRINT or PUT. It is clearly
not possible to read past the end of the file, and attempting to do
so will cause error 136 (end of file). (There is a mistake in the
first edition of Your Atari Computer p. 262, where attempting to
read past the end of the file is given as error 170.) It is quite
undesirable to write past the end of the file, since you might
overwrite part of another file. If you try to do this, then error
171 is returned.
Users of DOS 3 should be aware that NOTE and POINT
are treated differently by this version of DOS, since they return a
pointer Offset from the start of the file rather than an absolute
location in terms of sector and byte numbers. The meaning of the
error codes related to POINT is however the same.
CONCLUSION
There are in addition to the errors listed so far
six errors identified in the DOS 3 Manual but not in earlier Atari
publications. I presume that these are errors specific to DOS 3. I
do not intend to deal further with these error codes since Atari
owners should no longer be using this version of DOS. ln any case,
they are fully documented in the above manual.
I hope you have found this guide useful in
interpreting the sometimes obscure error codes produced by the Atari
computers. I would be very interested to hear any comments, further
information or corrections (I hope there won't be too many of
those!) that you may have. Further information on the inner workings
of the Atari resulting in these codes can be obtained from the
sources listed at the start of this article.
top
