Error messages

This section is currently still in "Work in Progress" status.

Finished:

• The Atari BASIC errors (#1 - #21) are fully detailed:
• #1 - #18 for BASIC usage in general
• #19 - #21 for errors related to LOAD/SAVE program operations
• The Turbo-BASIC XL specific errors #22 - 30 are fully detailed

Pending:

• Errors from #128 onwards, related to the use of external devices like floppy drives, printers, modems, etc

To be continued...

The following user's manuals were used directly as inspiration for the explanations that illustrate the errors:

• Atari US - 1981 - CO16347 REV. 1 - Atari Disk Operating System II Reference manual
• Atari US - 1983 - CO61456 REV. A BX4211 - BASIC Reference manual
• Expanded Turbo-BASIC XL documentation by Ron Fetzer

The following books were used directly as inspiration for the explanations and/or programs that illustrate the errors:

• Atari BASIC Faster and Better (1983) (IJG)
• Inside Atari BASIC (1983) (Reston Publishing Company)
• Your Atari Computer (1982 second xl edition) (1982) (McGraw-Hill)
• Page 6 magazine, issues #21 & #22

Disambiguation:

• GOTO instructions can take any of these forms: GOTO, GO TO, ON [...] GOTO & IF [...] THEN (implicit GOTO).
  The GOTO instructions described below refer to and apply to all these forms. Check them all.
• GOSUB instructions can take any of these forms: GOSUB & ON [...] GOSUB.
  The GOSUB instructions described below refer to and apply to all these forms. Check them all.

The all-purpose BASIC XIO instruction:

BASIC instructions for performing operations on IOCBs (device communication channels) have fairly self-explanatory names: OPEN, CLOSE, STATUS, INPUT, etc... But BASIC also contains a very generic additional instruction, called XIO. It's the first parameter of the XIO instruction — a number between 0 and 255 — that determines what this XIO instruction will be used for.

For example, XIO 3 is equivalent to OPEN; XIO 12 is equivalent to CLOSE, and so on.

The following two lines are therefore strictly equivalent:

Some XIO instructions have a BASIC equivalent — XIO 3 = OPEN — but others do not. For example, XIO 18 fills the screen, providing the equivalent of a FILL instruction not implemented in Atari BASIC.

When your BASIC program contains XIO instructions, check the Atari BASIC documentation to understand the action performed by this specific XIO instruction.

This is the code that you get when whatever you were trying do was executed successfully without any error detectable by the Operating System.
This code is not normally displayed and is usually of interest only to machine language programmers.

Details & probable cause:

• There is not enough RAM memory:
• To store the statement of your program
• To store the new variable
• To dimension (DIM) a new simple numeric array, matrice numeric array or string variable
• To use this graphic (GRAPHICS) mode
• There are too many levels of:
• FOR-NEXT loops nesting
• GOSUB subroutines nesting

Possible recovery:

• Add more RAM memory in your computer
• Check the values in your DIM instructions
• Check the syntax of all mathematical functions used in this program line in DIM instructions
• Check the current value of all variables used in this program line in DIM instructions
• Use graphics modes that consume less RAM memory
• Rewrite, optimise and shorten your long Atari BASIC program. In particular, delete any unused RAM-consuming variables, simplify FOR-NEXT loops nesting and GOSUB subroutines nesting
• Break down your long Atari BASIC program into smaller modules to be loaded one after the other
• Learn Assembly language or Action! to get the same result with more compact programs

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 2 AT LINE 10" during execution, because the size of this string — althought not illegal — exceeds the maximum size that can be stored in RAM memory

"ERROR- 2 AT LINE 10" during execution, because the program is trapped in an endless loop of calls to GOSUBs, which will saturate the execution stack that will eventually run out of memory

Details & probable cause:

• A value expected to be a positive integer is negative
• A value expected to be within a specific range is not

Possible recovery:

• Check the syntax of all mathematical functions used in this program line
• Check the current value of all variables used in this program line and see what they are used for
• Check the values used in DIM instructions
• Check your GOTO, GOSUB and RESTORE instructions

Note #1:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

• GOTO 40000, GOSUB 40000 and RESTORE 40000 will produce an error 7
• TRAP 40000 is a valid instruction that will disable this error-catching fall-back mechanism
• GOTO -1, GOSUB -1 and RESTORE -1 will produce an error 3

Note #2:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

will produce an error 3 whilst

will not produce any error

Note #3:

• Using PEEK or POKE instructions in addressable memory space without RAM — for instance, with an Atari 400 with 16 KiB of RAM, trying to explore in Atari BASIC the 16-40 KiB region? — will not produce any error
• Using POKE instructions in ROM (read-only) addressable memory space will not produce any error

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 3 AT LINE 10" during execution, because the size of this string exceeds the maximum size defined in the Atari BASIC language syntax

"ERROR- 3 AT LINE 10" during execution, because the addressable memory space with a MOS 6502 CPU/microprocessor is between $0 (decimal 0) and $FFFF (decimal 65,535). Therefore, the PEEK and POKE instructions must remain between these limits 0-65,535 — a check made in the Atari BASIC language syntax

"ERROR- 3 AT LINE 10" during execution, because the line number referenced in a RESTORE instruction cannot be negative

Details & probable cause:

• You have exceeded the maximum number (128) of possible variable names in an Atari BASIC program. Variable names once used but now absent may still count toward this limit

Possible recovery:

• Cut down on variables in your Atari BASIC program
• Use numeric arrays instead of individual variables
• Some variables may still be stored in RAM memory even though they are no longer used. Indeed, when you save your program with SAVE "D1:MYPROG.BAS", the file contains both the variables of your program and those that were also in memory at the time of saving, even if they were not used in your program. This garbage therefore comes back into RAM memory during a LOAD. It is time to delete these unnecessary variables:
• Save your current program twice
• Once with SAVE "D1:MYPROG.BAS" for double safety, but we won't use it
• A second time with LIST "D1:MYPROG.LST", to save it as a "plain English text listing" (ATASCII)
• If these two operations are successful, then restart the computer completely
• Turn it back on and load your program with NEW then ENTER "D1:MYPROG.LST"
• Retry the operation that caused the error

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 4 AT LINE 1280" while trying to enter the line in the Atari BASIC editor: the limit of the maximum number of variables has been reached

Details & probable cause:

• Reference was made to an un-dimensioned string
• You have attempted to read from or write into:
• A location past the dimensioned string size
• Location 0 of your dimensioned string

Possible recovery:

• Enlarge the DIM size of your string variable
• Do not use 0 as index of your string variable
• Check the syntax of all functions used in this program line in string handling instructions
• Check the current value of all variables used in this program line in string handling instructions
• Check the names of your variables. A typo might have created two different variables

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 5 AT LINE 30" during execution, because the string COMPUTER$ has not been dimensioned (DIM)

"ERROR- 5 AT LINE 30" during execution, because the string has a size of 10 characters and therefore, it is impossible to display the 20th

"ERROR- 5 AT LINE 30" during execution, because the string has a size of 10 characters numbered from 1 to 10 and not from 0 to 10

Note:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

will produce an error 9 whilst

will produce an error 5

Details & probable cause:

• If you were given a line number with this error, then you do not have enough data in your DATA statements for the READ instructions
• If you were not given a line number with this error, then it occurred simply because you pressed the [RETURN] key while the cursor was on the READY prompt in the Atari BASIC editor

Possible recovery:

• If this error occurred because your cursor was on the READY prompt, then simply ignore it. There are no consequences
• Check the amount of data in your actual DATA statements and compare this number with your expectations in the various READ instructions
• If you use simple or nested FOR-NEXT loops for the READ operations, check the number of resulting iterations
• If needed, add a "data end flag" in your DATA statements such as -1 for numerical values or $END for string values. After each READ, check that you have not reached this "data end flag". If you did, don’t use that special value and stop reading data.

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 6 AT LINE 20" during execution, because the DATA statement contains 3 different values, whilst the READ instruction attempts to read 4

Details & probable cause:

• Value is not a positive integer, or is greater than 32,767 in a situation where such a value is not allowed

Possible recovery:

• Check the value of the line numbers used in this program line, especially in GOTO, GOSUB and RESTORE instructions
• Check the syntax of all mathematical functions used in this program line, especially in GOTO, GOSUB and RESTORE instructions
• Check the current value of all variables used in this program line, especially in GOTO, GOSUB and RESTORE instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 7 AT LINE 10" during execution, because the lines in an Atari BASIC program are numbered from 0 to 32,767 ($0 - $7FFF). Therefore, the line number referenced in GOTO, GOSUB and RESTORE instructions must remain within these limits

"ERROR- 7 AT LINE 10" during execution, because the lines in an Atari BASIC program are numbered from 0 to 32,767 ($0 - $7FFF). Therefore, the line number referenced in GOTO, GOSUB and RESTORE instructions cannot be negative

Note:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

• GOTO 40000, GOSUB 40000 and RESTORE 40000 will produce an error 7
• TRAP 40000 is a valid instruction that will disable this error-catching fall-back mechanism
• GOTO -1, GOSUB -1 and RESTORE -1 will produce an error 3

Details & probable cause:

• Attempted to INPUT a non-numeric value into a numeric variable

Possible recovery:

• Check your variable types and/or input data in READ and INPUT instructions. Numeric value cannot contain letters, punctuation, graphic characters, etc

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 8 AT LINE 20" during execution, because the two variables PRICE and TOTAL are numeric, whilst the READ instruction accesses the DATA line 10 which contains two strings of characters, "TWO" and "TEN"

"ERROR- 8 AT LINE 10" during execution, because the INPUT VALUE instruction expects a numeric variable, whilst the user has typed the string "SEVEN"

Details & probable cause:

• The DIM size exceeds 5,460 for simple numeric arrays
• The DIM total size exceeds 5,460 for matrices numeric arrays
• The DIM size exceeds 32,767 for strings
• A numeric array or string that was already dimensioned (DIM) was dimensioned again
• Reference was made to an un-dimensioned numeric array or string

Possible recovery:

• Check the values in your DIM instructions
• Check the syntax of all mathematical functions used in this program line in DIM instructions
• Check the current value of all variables used in this program line in DIM instructions
• Check the names of your variables. A typo might have created two different variables
• Whenever possible, dimension (DIM) your numeric arrays, matrices and strings in the beginning of your program, and make sure you don’t loop back over them with a GOTO or GOSUB instruction

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 9 AT LINE 10" during execution, because the size limit of 32,767 characters was exceeded in the definition (DIM) of the ATARI$ string

"ERROR- 9 AT LINE 20" during execution, because the string COMPUTER$ has not been dimensioned (DIM)

"ERROR- 9 AT LINE 20" during execution, because the program contains a blunder: the ARRAY numeric array has been dimensioned (DIM) but the ARRAIE numeric array — probably a typo — has not been dimensioned (DIM)

"ERROR- 9 AT LINE 20" during execution, because the string ATARI$ has already been dimensioned (DIM) on line 10, so it is impossible to dimension it again on line 20. If it is absolutely necessary, a CLR instruction must be executed before re-defining ALL numeric arrays, matrices and strings, at the expense of losing the current value of ALL variables

"ERROR- 9 AT LINE 10" during execution, but the error originates from line 40: if the user does not answer ATARI, the user must return to line 20 which will ask the question again, and not to line 10 which will try to dimension (DIM) the string COMPUTER$ which has already been dimensioned during the first execution of line 10

Note #1:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

• DIM ARRAY(1) to DIM ARRAY(5375) will not produce any error
• DIM ARRAY(5376) to DIM ARRAY(5460) will produce an error 2
• DIM ARRAY(5461) and beyond will produce an error 9

Note #2:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

• DIM ATARI$(1) to DIM ATARI$(32257) will not produce any error
• DIM ATARI$(32258) to DIM ATARI$(32767) will produce an error 2
• DIM ATARI$(32768) and beyond will produce an error 9

Note #3:

It may seem strange that it is impossible to store very large numeric arrays, whilst it is possible to store much larger strings of characters.
The explanation is simple:

• 1 character of a string occupies 1 byte in RAM memory
• 1 number, necessarily encoded in BCD, occupies 6 bytes in RAM memory

If you need to store large amounts of numbers, use a string instead. If the numbers are all less than 256, use the ASC() and CHR$() functions to store your numbers into characters and retrieve them. If your numbers are all less than 65,536, start by breaking them into two numbers with the formula MyNumber = Part 1 + (256 * Part2), then use the ASC() and CHR$() functions to store your numbers into two characters and retrieve them

Note #4:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

will produce an error 9 whilst

will produce an error 5

This rare error is caused by an expression that overflows the argument stack. Strangely, this error is only listed in some Atari BASIC manuals (1200XL era), but absent in other editions.

Details & probable cause:

• There are too many GOSUBs
• An expression is too large to be evaluated
• An expression has too many levels of parenthesis or function nesting

Possible recovery:

• Check the number of GOSUBs that accumulate in the program flow, without ever doing a RETURN. Simplify the structure and flow of your program, with fewer GOSUBs.
• Check the expressions evaluated on the line of the program that causes the error. Simplify and decompose into a series of simpler expressions, which follow on from each other.

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

I have not been able to create a program that causes this error.

Details & probable cause:

• You have attempted to divide by zero
• The Floating Point Package (FPP) has produced a number which is either too small or too large
• You refer to a number with an absolute value less than 1x10^-99 or greater or equal to 1x10⁹⁸

Possible recovery:

• Check that you do not have a division by zero on the program line
• Check the current value of all variables used in this program line and see what they are used for

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 11 AT LINE 10" during execution, because division by zero is meaningless and therefore prohibited

"10 ERROR- OVERTHETOP=1.0E+99" while trying to enter the line in the Atari BASIC editor, because the numeric value 1x10⁹⁹ has exceeded the permitted threshold of 1x10⁹⁸

"ERROR- 11 AT LINE 20" during execution, because the value of the numerical variable NUMBER has now exceeded the permitted threshold of 1x10⁹⁸

Details & probable cause:

• A GOTO or GOSUB referenced a non-existing line number
• You deleted a few lines from the program used in GOTO or GOSUB instructions
• You re-numbered a few lines from the program used in GOTO or GOSUB instructions

Possible recovery:

• Check the value of the line numbers used in this program line, especially in GOTO or GOSUB instructions
• Check the syntax of all mathematical functions used in this program line in GOTO or GOSUB instructions
• Check the current value of all variables used in this program line in GOTO or GOSUB instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 12 AT LINE 10" during execution, because the program contains only 2 lines: line 10 and line 20. The GOTO 50 instruction refers to a line 50 that does not exist

Details & probable cause:

• A NEXT was encountered without a previous FOR
• You have deleted a few lines from the program and left a NEXT instruction lying around
• You have re-numbered a few lines from the program but you have not re-numbered the FOR-NEXT loop properly
• If you use GOTO or GOSUB instructions, check the exact path that is followed when the program is executed
• Nested FOR-NEXT instructions do not match properly
• A POP instruction was in the middle of a FOR-NEXT loop, which effectively disabled the most recently executed FOR instruction

Possible recovery:

• Check the names of your variables in FOR-NEXT instructions. A typo might have created two different variables
• Check that all FOR instructions have a matching NEXT instruction (using the same variable)
• Check that the multiple nested FOR and NEXT instructions are correctly nested within each other and none are intertwined
• Look for POP instructions in FOR-NEXT loops
• Look for GOTO or GOSUB instructions in FOR-NEXT loops

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 13 AT LINE 20" during execution, because when the NEXT VARIABLE instruction is executed, the program must return to the FOR VARIABLE=... instruction, but the line containing this instruction does not exist

"ERROR- 13 AT LINE 20" during execution, because it is a NEXT VALUE instruction that is expected, not a NEXT VALUES with an "S", surely a typo. VALUE and VALUES are two different variables

"ERROR- 13 AT LINE 20" during execution, because it is a NEXT VALUE instruction that is expected, not a NEXT PRICE

"ERROR- 13 AT LINE 30" during execution, because the POP instruction on line 20 has removed the reference to the loop initiated by FOR ITEM=... from the execution stack, so the NEXT ITEM instruction can no longer return to the corresponding FOR ITEM=... instruction

"ERROR- 13 AT LINE 40" during execution, because the VALUE and PRICE loops are incorrectly intertwined. Lines 30 and 40 must be swapped

Note:

This error is reported at the NEXT instruction, not at FOR

Details & probable cause:

• The line or statement is too complex or too long for Atari BASIC to handle

Possible recovery:

• Break down this line into several lines
• Rewrite, optimise and shorten your long Atari BASIC statements, lines and program
• Break down your long Atari BASIC program into smaller modules to be loaded one after the other
• Learn Assembly language or Action! to get the same result with more compact programs

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 14" while trying to enter the line in the Atari BASIC editor, because the line cannot be processed

Note:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

This error is not related to the use of abbreviations when entering a line in the Atari BASIC editor.
Be careful however: a line which contains too many abbreviations cannot be edited afterwards. It will be necessary to re-enter it entirely (with abbreviations) to make the least change. This line is valid and will be accepted by the editor without error:

Listing the program, we get this:

But it's now too long to be edited. The Atari BASIC editor accepts 3 lines, that is 114 characters with a margin of 2 characters on the left. This one doesn't fit anymore

A NEXT or RETURN instruction was encountered and the corresponding FOR or GOSUB has been deleted since the last RUN. That is quite unusual, since a NEXT instruction without FOR usually causes an error 13, whilst a RETURN instruction without GOSUB usually causes an error 16. So, this error 15 is very uncommon. The FOR or GOSUB instructions were present at the beginning of the execution, but were removed shortly afterwards

Details & probable cause:

• You interrupted the program with the [BREAK] key, while it was in the execution of a:
• FOR-NEXT loop. You deleted the line containing the FOR instruction, and then resumed execution where it left off (on the next line) with the CONT instruction
• GOSUB-RETURN section. You deleted the line containing the GOSUB instruction, and then resumed execution where it left off (on the next line) with the CONT instruction
• Your program is self-modifying (maybe with the ENTER instruction?) and deleted crucial FOR or GOSUB instructions
• You have tried a few POKEs which have modified the RAM memory area containing the tokenized BASIC program or the execution stack
• You have executed a machine language routine that has modified the RAM memory area containing the tokenized BASIC program or the execution stack

Possible recovery:

• If you interrupted the program with the [BREAK] key, restart it properly with RUN
• List the program and try to locate where the lines containing the missing FOR or GOSUB instructions should be. Re-type them
• If your program is self-modifying, carefully check which lines have actually been created, deleted or modified "on the fly"
• If your program contains POKE instructions, check that they do not modify the RAM memory area containing the tokenized BASIC program or the execution stack
• If your program calls machine language routines, check that they do not modify the RAM memory area containing the tokenized BASIC program or the execution stack

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

Pressing [BREAK]

"STOPPED AT LINE 20"

"ERROR- 15 AT LINE 30" during execution, because after interrupting the execution of the program with the [BREAK]; key, line 10 containing the FOR ANGLE=... instruction was replaced by a comment. So, the NEXT ANGLE instruction can no longer return to the corresponding FOR ANGLE=... instruction

Details & probable cause:

• Atari BASIC error 15 has been expanded to include an UNTIL — which is a REPEAT-UNTIL loop.
  This UNTIL has been deleted since the last RUN

Possible recovery:

• (Same as Atari BASIC Error 15 above, except that you should carefully scrutinise the FOR, GOSUB and UNTIL instructions)

Details & probable cause:

• A RETURN was encountered without a previous GOSUB
• Your GOSUB called routines are at the end of the program, but you forgot to explicitly end your program — before this section — with an END instruction. As a result, the execution of the program continued beyond the theoretical end of the program, entered in this section dedicated to GOSUB called routines, and then a RETURN instruction was encountered
• You have deleted a few lines from the program and left a RETURN instruction lying around
• You have re-numbered a few lines from the program but you have not re-numbered these GOSUB and RETURN sections properly
• If you use GOTO or GOSUB instructions, check the exact path that is followed when the program is executed
• A POP instruction was encountered before the RETURN instruction, which effectively disabled the most recently executed GOSUB instruction

Possible recovery:

• Check that all RETURN instructions have a matching GOSUB instruction
• Make sure that an END instruction is present before the program lines dedicated to the GOSUB called routines that might be present at the end of the program
• Look for POP instructions before RETURN instructions
• Look for GOTO or GOSUB instructions before RETURN instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 16 AT LINE 20" during execution, because the RETURN instruction tells the Atari BASIC to return after the last GOSUB instruction that was executed. But NO GOSUB instruction has ever been executed

"ERROR- 16 AT LINE 1020" during execution, because a 50 END line is probably missing. As a result, the program continues to run in a section without really being planned

"ERROR- 16 AT LINE 1030" during execution, because the POP instruction on line 1010 has removed the reference to the jump initiated by GOSUB 1000 from the execution stack, so the RETURN instruction can no longer return to the corresponding GOSUB 1000 instruction

Execution of "garbage" was attempted

Details & probable cause:

• A program line containing an error has not been corrected. It is present in the program listing. Its execution causes an error
• Faulty RAM components (hardware problem), leading to incorrect values stored in RAM memory
• You have tried a few POKEs which have modified the RAM memory area containing the tokenized BASIC program or the execution stack
• You have executed a machine language routine that has modified the RAM memory area containing the tokenized BASIC program or the execution stack

Possible recovery:

• Check the line that caused this error 17. If it is an error line, correct it and run the program again
• Turn off the computer, turn it back on and run the "Self-Test" program (XL/XE) to check the RAM memory
• Turn off the computer, turn it back on and re-enter the program
• If your program contains POKE instructions, check that they do not modify the RAM memory area containing the tokenized BASIC program or the execution stack
• If your program calls machine language routines, check that they do not modify the RAM memory area containing the tokenized BASIC program or the execution stack

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 17 AT LINE 10" during execution, because this line is an error line (stored in the program as a special type of comment). So line 10 makes no sense and cannot be executed

Details & probable cause:

• A VAL function was used with a string whose first character is not a number

Possible recovery:

• Check the string values used in VAL instructions
• Check the syntax of all functions used in this program line in VAL instructions
• Check the current value of all variables used in this program line in VAL instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 18 AT LINE 10" during execution, because the string in the VAL function must be convertible to a number. But the string "ATARI" cannot be converted into a number

"ERROR- 18 AT LINE 30" during execution, because the string in the VAL function must be convertible to a number. But the string "SEVEN" cannot be converted into a number. Line 20 should read STRING$="7"

Insufficient memory remains to complete LOAD or CLOAD of a program

Details & probable cause:

• There is not enough RAM memory fitted in this computer to load the program
• There is not enough free RAM memory left to load the program:
• Maybe you have loaded a DOS or other RAM memory-resident programs/handlers/drivers, which consume RAM memory while the program to be loaded with LOAD or CLOAD really needs all the RAM memory available in this computer
• Maybe you have reserved too much RAM memory yourself by moving the LOMEM pointer, for machine language routines, for storing variables that you manage yourself, for alternative character sets, for graphic displays, etc. And this is a problem because the program to be loaded with LOAD or CLOAD really needs all the RAM memory available in this computer

Possible recovery:

• Add more RAM memory in your computer
• Turn off the computer, turn it back on, then:
• Do not load any DOS or load other RAM memory-resident programs/handlers/drivers. Try to LOAD your program again
• Reconsider how much RAM memory you are reserving by moving the LOMEM pointer. Try to LOAD your program again

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

I have not been able to create a program that causes this error.

Note:

Reading the first 14 bytes of the file allows the Atari BASIC LOAD instruction to determine that the program is too long. In details, the computed end address of the program to be loaded is larger than the limit of the last RAM memory address available for programs. The LOAD instruction immediately cancels the loading operation, with the following benefits:

• A long reading operation, which would be doomed to failure anyway, is not even undertaken
• The program currently in memory is not destroyed
• The user regains control very quickly

Details & probable cause:

• IOCB number (device communication channel) not in the range #1-#7

Possible recovery:

• Check the device number values used in OPEN, CLOSE, GET, PUT, PRINT #, INPUT #, NOTE, POINT, STATUS, XIO instructions
• Check the syntax of all mathematical functions used in this program line in OPEN, CLOSE, GET, PUT, PRINT #, INPUT #, NOTE, POINT, STATUS, XIO instructions
• Check the current value of all variables used in this program line in OPEN, CLOSE, GET, PUT, PRINT #, INPUT #, NOTE, POINT, STATUS, XIO instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 20 AT LINE 10" during execution, because the (existing) IOCB #0 is used by the operating system (for the editor) and, thus, it is not free for users

"ERROR- 20 AT LINE 20" during execution, because the GET #9 instruction is attempting to use IOCB #9, a value outside the range of #1-#7. Plus, this IOCB channel is not even opened...

"ERROR- 20 AT LINE 20" during execution, because the OPEN #11 instruction is attempting to use IOCB #11, a value outside the range of #1-#7

Note #1:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

After an

The instruction

will produce an error 20 (Device number error) whilst the instruction

will produce an error 133 (Device/File not opened, should be PUT #1,VALUE)

Note #2:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

• OPEN #-1,4,0,"D1:FILE.DAT" will produce an error 3
• OPEN #1.33,4,0,"D1:FILE.DAT" will be rounded to #1 and will not produce an error
• OPEN #0,4,0,"D1:FILE.DAT" will produce an error 20, but strangely not an error 129 — see below
• OPEN #9,4,0,"D1:FILE.DAT" will produce an error 20, as #0 and #9-#15
• OPEN #16,4,0,"D1:FILE.DAT" will produce an error 129: IOCB channel already open (IOCB #16 = 1x16 + 0 == IOCB #0)
• OPEN #17,4,0,"D1:FILE.DAT" will be considered as #1 and will not produce an error (IOCB #17 = 1x16 + 1 == IOCB #1)
• OPEN #33,4,0,"D1:FILE.DAT" will be considered as #1 and will not produce an error (IOCB #33 = 2x16 + 1 == IOCB #1)
• OPEN #18,4,0,"D1:FILE.DAT" will be considered as #2 and will not produce an error (IOCB #18 = 1x16 + 2 == IOCB #2)
• OPEN #34,4,0,"D1:FILE.DAT" will be considered as #2 and will not produce an error (IOCB #34 = 2x16 + 2 == IOCB #2)
• OPEN #9999,4,0,"D1:FILE.DAT" will produce an error 20
• etc...

Details & probable cause:

• Attempted to LOAD a program that was not saved with the Atari BASIC SAVE instruction, or a file that is not an Atari BASIC program at all
• Attempted to CLOAD from cassette tape a program that was not saved with the Atari BASIC CSAVE instruction, or a file that is not an Atari BASIC program at all
• Attempted to LOAD a program from an unexpected device such as LOAD "E:" or LOAD "S:"

Possible recovery:

• If the program is on cassette tape, try both LOAD "C:" and CLOAD
• If the program is on diskette, go to DOS, and try loading the program as a machine language executable (with "L. BINARY LOAD" in Atari DOS 2.5)
• If the program is really an Atari BASIC program, it may have been saved with the LIST instruction. Try loading it with ENTER instead of LOAD or CLOAD
• Check the name (the letter) of your device in the LOAD instruction. Most of the time you should expect a C: (cassette) or D: (diskette)

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 21" during execution, because the file "DOS.SYS" is most probably a Atari DOS 2.5 machine language program, and absolutely not an Atari BASIC program

Note #1:
By obligation, an Atari BASIC program saved with the SAVE or CSAVEinstruction (in tokenized form) must begin with the signature $00 $00 (0, 0 in decimal). This is mandatory. The LOAD or CLOADinstruction will fail if these two $00 $00 are not present at the beginning of the file.

Note #2:
Reading the two first bytes of the file allows the LOAD or CLOADinstruction to determine if the program is an Atari BASIC program saved with the SAVE or CSAVE instruction or not. In details, the $00 $00 (0, 0 in decimal) signature is the deal breaker. If missing, the LOAD or CLOAD instruction immediately cancels the loading operation, with the following benefits:

• The program currently in memory is not destroyed
• The user regains control very quickly

Note #3:
Trying to load a program from a printer with LOAD "P:" will return an Error 146 — Function non implemented in handler
Trying to load a program from a device unknown in the HATABS table with LOAD "A:" for instance, will return an Error 130 — Non-existent device

Details & probable cause:

• Some loops created by FOR-NEXT, GOSUB-RETURN, REPEAT-UNTIL, WHILE-WEND or DO-LOOP are not properly nested

Possible recovery:

• With the help of the listing indentation provided by Turbo-BASIC XL, check that all loops are correctly matched and none are intertwined

Details & probable cause:

• A WHILE-WEND loop with no corresponding WHILE

Possible recovery:

• With the help of the listing indentation provided by Turbo-BASIC XL, check that all WHILE instructions have a matching WEND and the other way around

Details & probable cause:

• A REPEAT-UNTIL loop with no corresponding REPEAT

Possible recovery:

• With the help of the listing indentation provided by Turbo-BASIC XL, check that all REPEAT instructions have a matching UNTIL and the other way around

Details & probable cause:

• A DO-LOOP loop with no corresponding DO

Possible recovery:

• With the help of the listing indentation provided by Turbo-BASIC XL, check that all DO instructions have a matching LOOP and the other way around

Details & probable cause:

• An EXIT instruction was found outside the context of a loop. An EXIT instruction can only make sense inside a loop, precisely to get out of it. In the normal flow of a program, an EXIT instruction has no sense
• You have deleted a few lines from the program and left a EXIT instruction lying around

Possible recovery:

• Find out where the loop is in which this EXIT instruction is supposed to be

Details & probable cause:

• A PROC-ENDPROC procedure must be called by an EXEC instruction. In the program execution flow, a PROC instruction was encountered directly, that is without being called by an EXEC instruction

Possible recovery:

• Make sure that an END instruction is present before the program lines dedicated to the PROC-ENDPROC procedures that might be present at the end of the program

Details & probable cause:

• An ENDPROC instruction was found outside the context of a procedure. An ENDPROC instruction can only make sense as the end marker of a PROC-ENDPROC procedure, precisely to define where it ends. In the normal flow of a program, an ENDPROC instruction has no sense
• You have deleted a few lines from the program and left a ENDPROC instruction lying around

Possible recovery:

• Find where the PROC procedure begins, whose ENDPROC instruction is supposed to delimit the end

Details & probable cause:

• You are attempting to call with EXEC a PROC procedure that does not exist

Possible recovery:

• Check the names of all your procedures defined by PROC. And then check all the names called by EXEC. There is a typo on a procedure name somewhere.

With the # instruction, Turbo-BASIC XL allows to give names to lines of the program.
Instead of making a 10 GOTO 5000, we can write 10 GO# END_OF_PRG, provided that a 5000 # END_OF_PRG line exists.

Details & probable cause:

• You are attempting to jump/branch to a # line label that does not exist

Possible recovery:

• Check the names of all your # line labels. And then check all the line labels names branched to from GO# or TRAP instructions. There is a typo on a line label name somewhere.

Details & probable cause:

• You pressed the [Break] key during an input/output operation, which aborted this operation.

Possible recovery:

• Restart only the input/output operation that was aborted (if possible).
• Restart the whole program.

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

This error can only be triggered by the [Break] key.

Note #1:

• Never press the [Break] key during an input/output operation, unless you explicitly want to abort this operation, if it is no longer desired or necessary.
• If you have done this intentionally while running a BASIC program, it might be a good idea to type the END instruction in the editor (immediate execution mode) to close any IOCBs (device communication channels) that may still be open.

Note #2:
On Atari 400/800 equipped with the REV. A OS, the computer would often go to sleep during input/output. Hitting the [Break] key is a non-fatal cure for this symptom.

Details & probable cause:

• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) that was already open by you or by the operating system
• In a BASIC program, you ignored the advice to use only IOCB #1 to #5

Possible recovery:

• Check every XIO instructions (see "Read me first", above)
• Check the values in your OPEN instructions
• Check the syntax of all mathematical functions used in this program line in OPEN instructions
• Check the current value of all variables used in this program line in OPEN instructions
• Check that each OPEN instruction is followed by a CLOSE instruction after all the operations performed on this IOCB have been executed.
• Extra safety: Add a CLOSE instruction before each OPEN instruction
• Extra safety: Add a TRAP instruction before each OPEN instruction to handle possible errors
• Check that there are no OPEN instructions typically in FOR ... NEXT loops, but also in any other type of loops (non-Atari BASIC).
  If there is one OPEN instruction, use the extra safety measures listed above
• Check that there are no OPEN instructions in a procedure called several times with a GOSUB.
  If there is one OPEN instruction, use the extra safety measures listed above
• Check the path followed by the execution of a program, in particular with GOTO or GOSUB instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 129 AT LINE 30", because the lines 20 and 30 should be swapped: the OPEN instruction should appear before the loop and not inside it, so as not to be executed several times.

"ERROR- 129 AT LINE 20", because IOCB #1 is already used in the previous line.

"ERROR- 129 AT LINE 20", because IOCB #1 is already used in the previous line. It's the same file, the same floppy disk drive D1:, the same request (8 - open for writing) as in the previous line, but it doesn't change anything.

Note #1:
In Atari BASIC

• IOCB #0 is permanently open for the E: editor, and is therefore never available to the user.
• IOCB #6 can be used for the S: screen, and is used in particular with instructions relating to graphics.
• IOCB #7 can be used for input/output commands such as LPRINT, SAVE, LOAD, CSAVE, CLOAD, ENTER and LIST.

In short, to be on the safe side, use the IOCB communication channels numbered #1 to #5.

Note #2:
Trying to close an IOCB that was not open will not trigger an error message.

Note #3:
In BASIC, an END instruction typed in the editor (immediate execution mode) closes all IOCB channels.

Note #4:

will produce an error 20, even though the IOCB #0 is already open by the operating system; one would have expected an error 129 instead

will produce an error 129, as expected. IOCB #16 = 1x16 + 0 == IOCB #0

See "Error 20 — Atari BASIC — Device number error" (above)

Details & probable cause:

• You attempted to use a floppy disk drive but you turned on drive #1 after the computer. So, you failed to load and initialize the required D: non-resident device
• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) and you forgot to include the name (the letter of) this device
• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) using a non-existing device

Side note — Background information about Atari computer devices:

On start-up these 5 resident devices are directly available and ready for use, as they are defined in the Operating System and present in the HATABS table (Handler Address Table) — the official listing in RAM of all usable devices of the computer:

1. P:, printer
2. C:, cassette tape player/recorder
3. E:, editor
4. S:, screen output
5. K:, keyboard

These 2 classic additional non-resident devices can be easily added in the HATABS table:

6. D:, floppy disk drive
   This device is fully loaded and initialised when you follow this sequence: floppy disk drive "#1" must be powered on before the computer, and ready for use in the SIO chain with a bootable diskette inserted before the computer is powered on
7. R:, RS232, Atari 850 parallel communication ports — typically, for modems
   This device is loaded and initialised when you follow this sequence: turn on the Atari 850 interface. Floppy disk drive "#1" must be powered on before the computer, and ready for use in the SIO chain with a classic Atari DOS diskette (DOS 2, DOS 2.5, DOS 3, DOS XE, etc) inserted before the computer is powered on.
   Alternatively, if you don't need to use floppy disk drives, you can just turn on the Atari 850, turn off any floppy disk drive and power on the computer

Apart from these 5+2 well-known devices, any other device unknown to the system must be initialised correctly according to the procedure defined by the manufacturer. This device must be added in the HATABS table in RAM, and a driver/handler must be loaded and correctly initialised. The HATABS table can hold a grand total of 12 devices (including the 5 resident devices defined in the OS).

Notice how modern all this is for a computer of this era. At the same time, competing computers had peripheral numbers, with fixed numbers. On Atari, peripherals have names that are also easy to remember.

The icing on the cake is total flexibility:

• A new device can be added with a name chosen by the user: just add it to the 1^st free location in the HATABS table.
• It is possible to replace a resident device with a new version: just add it to the 1^st free location in the HATABS table — since the Operating System reads this table from the end, and not from the beginning

Details & probable cause: (rewritten and expanded)

• You attempted to use a floppy disk drive but you turned on drive #1 after the computer. So, you failed to load and initialize the required D: non-resident device
• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) and you forgot to include the name (the letter of) this device
• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) and you used a letter corresponding to a device NOT defined in the HATABS table. Maybe a non-resident device you forgot to load and initialise?
• With the BASIC OPEN instruction, you tried to open an IOCB (device communication channel) and you used a letter corresponding to a device defined in HATABS but NOT correctly initialised

Possible recovery:

• Check every XIO instructions (see "Read me first", above)
• Make sure your OPEN instruction does mention a device letter, followed by a colon
• If you want to use a D: device, make sure this D: device is properly loaded and initialised
  (see above, Side note — Background information about Atari computer devices)
• If you want to use a R: device, make sure this R: device is properly loaded and initialised
  (see above, Side note — Background information about Atari computer devices)
• Read the manual of the specific device you wish to use. You need to follow the correct procedure to load and initialise its driver in the HATABS table

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 130 AT LINE 10", because no device is mentioned, only the file name "DATA.1". It should probably read "D1:DATA.1".

"ERROR- 130 AT LINE 10", because no "X:" device is defined in the HATABS table, unless you explicitly run a program that will add it.

"ERROR- 130 AT LINE 10", if you forgot to properly load and initialise the "D:" device.
Typically, this happens when you switch on the floppy disk drive "#1" after the computer.
(see above, Side note — Background information about Atari computer devices)

Details & probable cause:

• You tried to read something from a printer
• You tried to read from a file that was opened in write-only mode
• To generalise the problem: with the BASIC GET or INPUT instructions, you tried to read from an IOCB (device communication channel) that was open for write-only

Possible recovery:

The problem arises from the inconsistency between the OPEN instruction, used with parameters to open a write-only communication channel, and the GET or INPUT instruction — sometimes a long way from the original OPEN instruction — which asks to read from this communication channel. Although this error occurs on the line containing the GET or INPUT instruction, the line containing the original OPEN instruction must be found and examined.

If it's related to a printer, the error is in the GET or INPUT instruction. It makes no sense to read from a printer.

If it's related to the keyboard, the error is found in the OPEN instruction. It makes no sense to open the keyboard for writing.

If it's related to a file on a floppy disk drive, think about what you really want to achieve with this file: read or write or update it?

For all other devices, think about the logic: is it normal to read from this device? Why isn't it open for reading or updating?

Check this:

• Check every XIO instructions (see "Read me first", above)
• Check the related OPEN instruction
• Check the values in your OPEN instructions
• Check the current value of all variables used in this program line in OPEN instructions
• Check the syntax of all mathematical functions used in this program line in OPEN instructions

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 131 AT LINE 20", because the IOCB channel #1 was open for writing (to a printer identified as P:) and yet you attempted to read from it. You don’t get this error message because reading from a printer is non-sense. You get this error message because, literally, you attempted to read from an IOCB channel open for write only.

"ERROR- 131 AT LINE 20", because the IOCB channel #1 was open for writing (to the keyboard) and yet you attempted to read from it. You don’t get this error message because opening the keyboard for writing is non-sense. You get this error message because, literally, you attempted to read from an IOCB channel open for write only.

"ERROR- 131 AT LINE 30", because the IOCB channel #4 was open for writing (to a file in the D1: floppy disk drive) and yet you attempted to read from it.

Details & probable cause:

• The error occurs when you have issued a valid command to the peripheral, but the device is unable to carry it out
• The latch/door of the floppy disk drive is open
• The diskette you're trying to write on is write-protected
• The diskette you're trying to write on is not formatted
• The diskette you're trying to write on was formatted for another brand of computers
• The diskette is spinning too fast (it should be spinning at 288 rpm)
• If using an Atari 810 floppy disk drive, model with a "data separator board", then this data separator board might have failed.

Possible recovery:

• Check that the floppy disk drive is still powered on, connected in the SIO chain, with a diskette properly inserted and the door/latch closed
• Check that the diskette is not write-protected:
• If the write-protect notch is covered, then this is the cause of the error.
  Remove the sticker that covers the notch or insert another more suitable formatted diskette with enough free space
• If the write-protect notch is uncut/non existing, then this is the cause of the error.
  This diskette is probably an original software that was write-protected for a good reason. Insert another more suitable formatted diskette with enough free space
• Check that the diskette is formatted in an Atari DOS compatible format. Reboot the computer with Atari DOS 2.5 for instance, and try to read the diskette directory from DOS 2.5. If it fails, retry with Atari DOS 3. The diskette may be brand new, completely unformatted. The diskette may have been formatted on a computer other than Atari, making it impossible for the Atari computer to understand its layout and structure
• Use a specific program to check the rotational speed of the diskette in the drive. Atari floppy disk drives don't use the classic 300 rpm rotational speed but use 288 rpm instead. Also check the appropriate field service manual:
• Atari US - 1980 - FS015854 REV. 1 - Atari 810 Disk drive field service manual
• Atari US - 1985 - FD100330 REV. 03 - Atari 1050 Disk drive field service manual
• If using an Atari 810 floppy disk drive, model with a "data separator board", then this data separator board might have failed:
• Check the following document: Tech tip #4 (17 Nov 1982) ~ Atari 810; Data separator board
• In a board is suspected, follow the standard troubleshooting procedure outlined in Atari 810 Disk Drive Field Service Manual (FD100003), to check circuitry and alignment. If circuitry and alignment check out but board has many 144 errors or many intermittent errors, swap the data separator board in the unit with a known good one. This procedure isolates the problem to a faulty data separator board or faulty side board.

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

This is a purely hardware error that cannot be triggered by a program.

Details & probable cause:

• You tried to save a program, copy a file or store data on a diskette which does not contain enough free sectors to carry out this operation

Possible recovery:

• Retry the operation with another blank, formatted diskette
• Retry the operation with another formatted diskette that contains enough free sectors to carry out this operation
• If you are in Atari BASIC, don't use the DOS instruction to go to Atari DOS 2.5 to format a diskette.
  You might lose your program and/or data if you leave Atari BASIC for DOS.
  Instead, use the CLOSE #1:XIO 253,#1,0,0,"D1:" instructions to format in "90 KiB Single Sided/Single Density" the diskette in the floppy disk drive #1, or CLOSE #1:XIO 254,#1,0,0,"D1:" instructions to format in "130 KiB Single Sided/Enhanced Density" the diskette in the floppy disk drive #1
• If you can't get another formatted diskette immediately for any reason, save your program or data on a cassette tape instead — save to C: instead of D:. That way you won't lose anything, and you'll have extra time to get a formatted diskette
• Try to estimate the amount of data to be saved. Perhaps a unique formatted diskette can't hold that much information? If you are saving data, can you spread its contents over several diskettes?
• If you are trying to save an Atari BASIC program with the LIST instruction, use the SAVE instruction instead. The SAVE instruction will require less free sectors on a diskette, because the program will be tokenized

How to avoid this in the future:

• Before you start any file copying, data copying or programming session, make sure you have one or more freshly formatted diskettes available at hand
• Use the Atari BASIC DOS instruction to go to Atari DOS 2.5 and format several diskettes before you need to create / copy new files

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 162 AT LINE 40" because this program fills up the "D1:FILL.UP" file with strings of 1024 stars until the disk is full. The error occurs during the last attempt to write to the diskette, on line 40.

Details & probable cause:

• You tried to save a program, copy a file or store data on a diskette which already contains the maximum number of files allowed on a diskette. For instance, Atari DOS 2.5 allows a maximum of 64 files per (side of a) diskette

Possible recovery:

• Retry the operation with another blank, formatted diskette
• Retry the operation with another formatted diskette that contains enough space in its directory for additional files
• If you are in Atari BASIC, don't use the DOS instruction to go to Atari DOS 2.5 to format a diskette.
  You might lose your program and/or data if you leave Atari BASIC for DOS.
  Instead, use the CLOSE #1:XIO 253,#1,0,0,"D1:" instructions to format in "90 KiB Single Sided/Single Density" the diskette in the floppy disk drive #1, or CLOSE #1:XIO 254,#1,0,0,"D1:" instructions to format in "130 KiB Single Sided/Enhanced Density" the diskette in the floppy disk drive #1
• If you are in Atari BASIC, don't use the DOS instruction to go to Atari DOS 2.5 to list the files on the diskette or delete existing files.
  You might lose your program and/or data if you leave Atari BASIC for DOS.
  Instead, use the following instructions to list the files on the diskette (it will end with an Error 136, ignore it):
  CLOSE #1:OPEN #1,6,0,"D1:*.*":FOR I=0 TO 65535:GET #1,CHAR:?CHR$(CHAR);:NEXT I
  or this alternative
  CLR:DIM ENTRY$(30):CL.#1:OP.#1,6,0,"D1:*.*":FOR I=1 TO 64:IN.#1;ENTRY$:?ENTRY$:N.I
  Then select a non-essential file and delete it (see next bullet point)
• If you know the name of a file that is not essential, delete it from the diskette to make room for the new one. For example, to delete file "D1:DELETE.ME" from Atari BASIC, use the instructions CLOSE #1:XIO 36,#1,0,0,"D1:DELETE.ME": XIO 33,#1,0,0,"D1:DELETE.ME" to unlock the file (if that was necessary) and then delete it
• If you can't get another formatted diskette immediately for any reason, save your program or data on a cassette tape instead — save to C: instead of D:. That way you won't lose anything, and you'll have extra time to get a formatted diskette that contains enough space for additional files

How to avoid this in the future:

• Before you start any file copying, data copying or programming session, make sure you have one or more freshly formatted diskettes available at hand
• Use the Atari BASIC DOS instruction to go to Atari DOS 2.5 and format several diskettes before you need to create / copy new files

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

"ERROR- 169 AT LINE 50", because this program creates files named "D1:FILE.1", "D1:FILE.2", "D1:FILE.3", etc until the directory of the diskette is full and can no longer host extra files. The error occurs during the last attempt to create an additional file on the diskette, on line 50.

Details & probable cause:

• You inserted the wrong diskette in the floppy disk drive
• You inserted the wrong side of the diskette in the floppy disk drive
• You have tried to access a file that is not on this diskette
• You have deleted a file that is now needed on this diskette
• You mistyped the name of a file you tried to access on this diskette

Possible recovery:

• Insert the correct side of the correct diskette in the floppy disk drive
• Check every XIO instructions (see "Read me first", above)
• Check the file names in all OPEN instructions
• Check the values in your OPEN instructions
• Check the syntax of all mathematical functions used in this program line in OPEN instructions
• Check the current value of all variables used in this program line in OPEN instructions
• Check that the floppy disk drive contains the diskette that holds the file you're trying to access
• Restore / Copy / Recreate the file you are trying to access on this diskette
• If you are in Atari BASIC, don't use the DOS instruction to go to Atari DOS 2.5 to list the files on the diskette or rename existing files.
  You might lose your program and/or data if you leave Atari BASIC for DOS.
  Instead, use the following instructions to list the files on the diskette (it will end with an Error 136, ignore it):
  CLOSE #1:OPEN #1,6,0,"D1:*.*":FOR I=0 TO 65535:GET #1,CHAR:?CHR$(CHAR);:NEXT I
  or this alternative
  CLR:DIM ENTRY$(30):CL.#1:OP.#1,6,0,"D1:*.*":FOR I=1 TO 64:IN.#1;ENTRY$:?ENTRY$:N.I
  Then use the following instructions to rename a file (if needed):
  CLOSE #1:XIO 36,#1,0,0,"D1:OLD.BAK": XIO 32,#1,0,0,"D1:OLD.BAK,NEW.BAS"
  The first XIO instruction will unlock the "D1:OLD.BAK" file (it that was necessary), and the second XIO instruction will rename "D1:OLD.BAK" into "D1:NEW.BAS"

How to avoid this in the future:

• From Atari DOS 2.5, you can lock an important file to prevent it being deleted, renamed or updated. Use the "F. LOCK FILE" command in the menu
• From Atari BASIC, you can lock an important file to prevent it being deleted, renamed or updated. Use the following instruction: CLOSE #1:XIO 35,#1,0,0,"D1:CRUCIAL.PRG" to lock the "D1:CRUCIAL.PRG" file
• If the content of an important diskette should not be altered, then cover the write-protect notch on this diskette, to prevent writing to it. It will be possible to read the diskette, but it will no longer be possible to format it or write anything to it

Sample program(s) that would trigger this error:
(Examples running on 800XL PAL OS, booted with Atari DOS 2.5)

(Using a newly formatted diskette in the floppy disk drive #1)

"ERROR- 170 AT LINE 20", because the diskette contains a file named "MYFILE" that was created on line 10, but we try to read a file named "WHATFILE" on line 20 and this file doesn't exist on this newly formatted diskette.