Chybové kódy - neradi ich vidíme = niečo nefunguje. Ak ale poznáme čo ktorý chybový kód oznamuje sme schopní pochopiť kde je problém a následne ho vieme aj riešiť. Jedno také pekné komplexné zhrnutie chybových kódov pre malé Atari vyšlo v dávnych dobách v magazíne Page 6:
A Guide to Atari Error Codes
by Steve Pedler
As everyone should know, when an error occurs during the running of a BASIC program, a code is returned to the user indicating the type of error that has taken place. Unfortunately, you then have to look up the meaning of these codes in a manual, and the explanations are all too often very brief and written in a kind of Atarispeak which may be difficult if not impossible to interpret. A better explanation of these codes might not come amiss and I therefore present a guide to the meaning of ATARI Error codes, why they occur and how to avoid them.
In this guide I give the error codes followed by the 'official' name as found in the Atari BASIC Reference Manual appendix B). Note that error names may vary between different publications (even Atari publications!) as may the explanations given.
For further information, see the following sources:
Atari BASIC Reference Manual (Atari Inc.)
Technical Reference Notes (Atari Inc.)
DOS 3 Reference Manual (Atari Inc.)
Your Atari Computer (Osborne-McGraw Hill)
Revised Mapping the Atari (Compute! Books)
________________________________________________________________________________
Part 1 - Language specific errors.
Errors 2 - 21 only occur when a BASIC program is running. Other languages (e.g. the Assembler-Editor cartridge) also use these numbers, but have a completely different meaning. You should also note that errors occurring during the execution from BASIC of machine language subroutines may generate error codes which bear no relation to the error which actually occurred.
Error-1
There is in fact no 'error' 1 in Atari BASIC. The value is returned by the operating system on successful completion of an input-output (I/O) operation. Quite properly, BASIC doesn't bother telling you this, but just gets on with the job.
Error-2 Memory insufficient.
During the running of a program, BASIC maintains a series of pointers in RAM to keep track of memory usage. Two of these are MEMTOP (locations 741,742) and APPMHI (14,15). MEMTOP is a pointer to the top of free memory. Above the location found in MEMTOP is the display list, and following that the screen RAM. The value in MEMTOP is moved up or down depending on the graphics mode selected, the greater the memory requirement for any mode, the lower is the value contained here. APPMHI is a pointer to the top of your BASIC program. Whenever a new line is added to the program, or when space is reserved for a string or array by the DIM statement, the value in APPMHI is increased. If, either during the typing in of a program or during a run, the value in APPMHI is greater than that in MEMTOP, error 2 is the result. (There is an exception - see error 147).
This error may also occur if RAMTOP (106), the pointer to the top of available memory, is moved down
too far, since this will also cause MEMTOP to be lowered when the graphics mode is changed. This could occur during repeated runs of a program which deliberately lowers RAMTOP (e.g. during debugging). To avoid this, press Reset before re-running such a program.
Error-3 Value error.
This is a common error which can be surprisingly difficult to track down. It occurs when attempting to use a number whose value is in some way unacceptable to the computer. Trying to POKE a memory location with a negative number or one greater than 255 will cause this problem. So too will trying to access part of a string or array with a negative index value, or if the second index is smaller than the first. For example, the following lines would generate this error:
10 DIM A$(9):? A$(7,1)
20 END
On the face of it this should be easily avoidable. However, frequently a program first computes the value of a variable then uses the variable in a POKE statement or as a string or array index. It is all too easy during the initial computation to obtain a value that is not acceptable to the machine. If the cause of this error is not clear, check the actual value of your variables against what you think they should be.
Error-4 Too many variables.
Atari BASIC only allows you the use of 128 different variable names. In practice, this should be enough for most applications, so that you are unlikely to see this error. One point to beware of is that variables used during program development, but not in the final version, will remain in BASIC's variable name table even if no longer used in the program. If you are running short of variables, you can clear out the unwanted ones by LISTing your program to cassette or disk, typing NEW (which clears the variable name table) and ENTERing your program again.
Why does this limitation exist? When a BASIC program is present in memory (or SAVEd to cassette or disk) it is in tokenised form rather than full ATASCII format. Each BASIC keyword is stored as a one byte token, so that (for example) the word RESTORE is stored as one byte rather than seven (one for each character). Variables are also stored as tokens, so that no matter how long the variable name, it still only takes up one byte each time it occurs in the program. One byte can only contain 256 different numbers, the BASIC keywords are allocated numbers 0-127 (though not all are used) leaving the numbers 128-255 for the variables - giving 128 different names.
Should you need more than 128 variables, then you can store numeric variables as elements of an array. For example, the statement DIM ARRAY(99) will set up an array of 100 elements. Each of these elements can hold a different number, but the array still only takes up one variable name.
Error-5 String length error.
Whenever you use a string, you must first tell the machine how long you want the string to be, using the DIM statement. BASIC then reserves a section of memory to contain the contents of your string. The convention used is that the first character of the string is given the index value 1 (i.e. PRINT A$(1,1) would print the first character of A$). If you use zero as an index, then error 5 occurs. Incidentally, note that just to be confusing, the first element of an array is given an index of zero!
This error will also occur if you use an index value greater than the dimensioned string length. If you need a longer string, you will have to alter the original DIM statement. Once again, it is easy to cause this error when using variables as string indices. See also errors 3 and 9.
Error-6 Out of data error.
Whenever you use the READ statement, BASIC obediently tries to read as many items of DATA as you have instructed. Every time one piece of data is read, a pointer is updated to point to the next piece. If BASIC finds that there is no more data in the program, but it is still under orders to READ, then the run stops and error 6 is returned (but see below). This error is usually caused by miscounting the number of data items to be read (often by means of a FOR ... NEXT loop) or by missing out one or more pieces of data. A slightly more obscure cause is that the pointer is not moved during a GOSUB...RETURN loop. If your subroutine reads data contained in lines which are part of the subroutine itself, and control then returns to the main program, when you next try to read data the pointer will be pointing to data lines following the subroutine (if any). To avoid this, you should make appropriate use of the RESTORE statement.
You can make use of this error in your programs. If you have large amounts of data to read in, then rather than count them all up, you simply set a TRAP to the line where the program is to continue when all DATA is read. You then set up a simple loop which forces BASIC to read data until there is none left, at which point error 6 occurs but is caught by the TRAP and the program then continues as normal.
Error-7 Number greater than 32767.
Theoretically this error means that you have used a number greater than 32767 (hex $7FFF) where this is not acceptable to the machine. In practice, the only reason I know for this error is a line number larger than 32767 - and I'm not sure why this limit exists. Does anyone else have any further information?
If you try to type in a line with a line number of 32768 or more, you simply get a syntax error on pressing Return. However, Atari BASIC allows you to use variables as line numbers in statements such as GOTO, GOSUB etc. so look out for the possibility that the variable is larger than the allowed limit.
Error-8 Input statement error.
When you issue an INPUT statement, BASIC expects the program to enter an appropriate reply, (either via the keyboard or from cassette or disk) which will either be a number or a character string. While it is quite acceptable to enter numbers in response to a string input request (the characters making up the number are treated just like any other string) it is not acceptable to enter a string when BASIC expects a number. This is because BASIC will try to assign the number which is input to a variable (e.g. if you respond with '450' to the statement 'INPUT A', the variable A gets the value 450). It clearly can't do this with a string of characters, and so will generate this error. Pressing Return without entering any number at all will also cause the error.
You can prevent users crashing your programs in this manner by setting a TRAP so that any input which generates an error could print a message and a request to try again.
Error-9 Array or string DIM error.
There are three possible causes of this error.
i) As mentioned above, in Atari BASIC you must DIMension all strings or arrays before use. If this is not done, and you try to use an undimensioned string or array, this error results.
ii) You may also only dimension a string or array once per program run. A good practice would be to contain your initialization code (including setting up strings and arrays in a separate subroutine called only once at the start of the program. This will prevent accidental redimension of your strings. Should you for some reason need to redimension strings or arrays during a program you must use the CLR statement to undimension them first.
iii) There is an absolute limitation of dimension size of 32767 for strings, and 5460 for arrays. Exceeding this limit will generate error 9. Different strings or arrays when combined may however exceed this limit, providing you don't exceed available memory, in which case you will get error 2. (The odd looking figure of 5460 for array size comes about because DIMensioning an array to this size sets up the array to hold 5461 elements. Since each element takes up six bytes, and 5461 x 6 = 32766, one more element would exceed the 32767 limit
Error-10 Argument stack overflow.
As BASIC processes a program line, if it comes across an arithmetical expression it first places the various arithmetical operators it finds on an 'operator stack'. The order in which the operators go on the stack is of some importance, since it determines the order in which BASIC carries them out. In some cases the order depends on priority (multiplication has priority over addition, for example), otherwise on the order they occurred in the statement. This order can be specifically overridden by using parentheses. The size of the stack is limited. If the number of operators or the number of parentheses cause the stack size to be exceeded (stack overflow), error 10 is returned. If this occurs, you will have to simplify the offending expression.
Error-11 Floating point overflow/underflow error.
BASIC stores numbers in your program in a 'floating point' format, using six bytes every time a number occurs. (It is clearly more economical of memory to assign a variable to a number if you intend to use that number frequently, since this will only use one byte every time it occurs.) By using this format, BASIC can utilise numbers as large as 10 to the power 98, or as small as 1 divided by 10 to power 99 (should be a good enough range for most purposes!). If you exceed these limits, then BASIC can't handle it, and this error results. The usual cause of this is inadvertently dividing a number by zero (the theoretical result of which is infinity).
Error-12 Line not found.
Certain keywords in BASIC are followed by a line number, e.g. GOTO, GOSUB, etc. When such a statement is processed, BASIC attempts to find the indicated line. If it can't do so, then it literally has nowhere to go, so the run stops and this error is returned.
There is an interesting feature here to do with the TRAP statement. If you set a trap to a nonexistent line number, and an error occurs to spring the trap, then instead of error 12, as you might expect, you get the error which sprung the trap in the first place. You can use this to clear previously set traps which are no longer wanted, by setting the trap to a line known not to exist).
Error-13 No matching FOR statement.
On processing a FOR statement, BASIC puts 16 bytes into an area of memory called the run-time stack. This is in RAM, pointed to by locations 142 and 143, and is situated directly above the string/array area (itself just above the main body of the program). The first 12 bytes are the numerical limit the variable can reach then the step increase or decrease (six bytes per number in floating-point format). The remaining four bytes are the variable number as it occurs in the variable name table, the line number where the FOR occurs, and the offset into that line. When it reaches the corresponding NEXT, BASIC checks that the variable limit is not yet reached, and then returns to the line containing the FOR. Clearly, if BASIC finds a NEXT without a corresponding FOR, there is nothing on the run-time stack to indicate the point of return, and program execution must stop.
GOSUB statements also use the run-time stack, placing four bytes on it. These are an identifier byte to indicate a GOSUB, the line number to go back to on reaching the RETURN statement, and the offset into that line. See the description of error 16.
This error also occurs if your FOR ... NEXT loops have not been properly nested. If the variable in the NEXT statement is not the same as that in the FOR entry on the stack, then the same problem arises.
Error-14 Line too long error.
When you type in a line of code and press Return, your line goes into BASIC's input buffer, 128 bytes located from 1408 to 1535 (580-5FF hex). BASIC then proceeds to tokenise the line (see error 4 above for an explanation of tokenising) and puts the resulting tokens into its output buffer, 256 bytes of RAM located above the value contained in MEMLO (743, 744). If the length of the tokenised line exceeds 256 bytes during the tokenising process, error 14 occurs. It's not very likely, but if it does happen you will have to shorten the line.
Error-15 GOSUB or FOR line deleted.
This is a strange error which I have never actually seen m practice. You will remember (see error 13 above) that GOSUB and FOR statements use the run-time stack to indicate the line to which control should pass on reaching the RETURN or NEXT statement. This error means that on reaching a RETURN (or NEXT) BASIC fetches a line number from the run-time stack, but cannot then find that line. This in turn implies that the line was deleted between BASIC's encountering the GOSUB (or FOR) and the RETURN (or NEXT). It is difficult to think of circumstances in which this might occur, but it is possible that POKEing around in the area of RAM which contains the program might alter line numbers. Another possibility is faulty RAM, causing program lines to be lost.
Error-16 RETURN error.
This error is analogous to error 13 above. On reaching a RETURN, BASIC gets the line number to return to (and the offset into that line) from the run-time stack. If a RETURN is reached before a GOSUB, there won't be an entry on the stack and program execution will have to stop.
Error-17 Garbage error.
A very reassuring error message to get! What it means is that while executing the program, BASIC has come across a line which contains non-executable (garbage) code. There are several possible reasons. Although Atari BASIC performs syntax checking on entry of program lines, it is quite easy (especially if you are in a hurry) to miss the syntax error display you normally get. This erroneous line will however be entered into memory (at least in part), and when BASIC finds it again error 17 is the result. It is also likely that POKEing directly into the RAM containing your program would alter the code, causing havoc at run time. The third possibility (least likely of all) is that your RAM might be at fault.
Error-18 Invalid string character.
This error relates to the use of the VAL function. Although numbers are usually held as constants or as numeric variables, it is possible to store numbers as strings. To convert a number to a string, you use the STR$ function. You can then perform string handling operations on the result. To convert the string back into a number for arithmetical operations, VAL is used. VAL can only be used however if the string is composed of numbers, or (at the least) if the first character of the string is a number. If this condition is not met, this error is generated.
Error-19 LOAD program too long.
This error is a very simple, one: it means that the program you are trying to LOAD is too large to fit into the available RAM. This is not likely-to be seen with today's 48K-plus machines, but it must have been fairly common in the days of the 8K Ataris. There is no easy solution; if this happens, you will have to install some more memory in your computer. It is possible that this error might occur in a 48K machine with faulty RAM.
Error-20 Device number error.
This error occurs during input/output operations if you try to use an incorrect IOCB (channel) number. (See error 134 in the second part of this article for a brief explanation of IOCBs.) The Atari can use up to eight IOCBs (numbered 0-7) for communication with peripherals, but BASIC reserves IOCB zero for its own use. The IOCB number is the number following the 'hash' sign in statements such as PRINT #6, OPEN #1, CLOSE #7, etc. and must be numbered from one to seven inclusive. See also error 134.
Error-21 LOAD file error.
When you try to LOAD (or CLOAD) a program, the computer expects to receive a BASIC program in tokenised format (see error 4 for an explanation of tokenising). Tokenised BASIC programs are only stored on cassette or disk with the SAVE (or CSAVE) command, and files created by any other means will not be in this form. Trying to LOAD anything other than a tokenised BASIC program will produce error 21. Examples of such files would include any file LISTed to cassette or disk (full ATASCII format), machine language programs, screen memory dumps etc.
If this error occurs, you will have to use the correct command to reload your file. For example, this would be ENTER for LISTed files, the DOS binary load option L for machine code files, and so on
____________________________________________________________
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.
___________________________________________________________
Ak to niekomu pomôže pri riešení vzniknutých problémov budem len a len rád ..., nakoniec koho to zaujíma - link na prvý, pôvodný článok o chybových kódoch:
http://blog.3b2.sk/igi/post/Chybove-hlasenia-ATARI-ATARI-error-codes.aspx
___________________________________________________________
Vaše hodnotenie, Rate post: