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

Not started:

• New errors codes related to OSS BASIC A+, XL and XE

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.

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. 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. 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 programme 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

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

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

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 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 used by the operating system (for the editor) and, thus, it is not free for users.
• IOCB #6 is used by GRAPHICS instructions.
• IOCB #7 might be used by the operating system, for LPRINT instructions for instance.

To play it safe, in Atari BASIC programs, only use IOCB #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)