Oh, Those Bugs
After the publication of "Chicken" and "Attack on the Death Star" in ANTIC we received many calls from puzzled readers who were unable to make the programs run. Since both listings were correct, we know many of you need help finding errors. This article will give some elementary guidance in debugging BASIC programs. Also see and use TYPO, in this book, to help you find entry errors.
The most important advice we can give is: never attempt to RUN a program prior to saving a copy on disk or tape. Should your newly typed program contain a fatal error it may possibly cause the computer to fail to respond to the keyboard. This forces you to turn the power off and then on again in order to reset, erasing computer memory and your program.
We assume you've corrected your normal typing errors, those which generate an error message when you press [RETURN] after a line. The remaining errors are more subtle and are not reported until the computer tries to execute the program.
Such things as NEXT with no FOR, or a RETURN with no GOSUB, are generally the result of a missing line. Tracing back through the program to the line where the command should be is fairly straightforward. More difficult are the errors which are not actually in the line the computer indicates. You have to know where else to look for the error. Most notorious of these are errors which result from mistyping a DATA statement.
Most errors in typed computer programs stem from DATA statements. There are logical reasons for this. Human beings are not very good at duplicating long strings of numbers or letters separated by commas. Numbers get transposed or dropped, commas get left out, or periods are substituted for them. Secondly, the computer does not check DATA statements during input. You can put anything in a DATA statement and the computer won't protest--until you try to RUN the program.
A surprising variety of errors can be traced to DATA statements. There is, of course, "Out of Data" (Error 6), but often the following errors are due to DATA errors:
1. Value Error (outside a specified range; Error 3)
2. String length error (Error 5)
3. Number greater than 32767 (Error 7)
4. Input statement error (Error 8)
5. Cursor out of range (Error 141)
It is true that these error messages can also be caused by other mistakes besides DATA statements. Out of Data and Cursor Out of Range can be caused by an error in the parameters of a FOR-NEXT loop. Often there will be a series of FOR-NEXT loops in a program, and an error in typing the parameters of one FOR-NEXT loop won't be detected until one of the following loops is executed. A String Length error may be the result of mistyping the DIM statement. In general, this is not detected until you try to define or use a portion of the string past the dimensioned length.
Knowing that such a wide range of errors can indicate a mistyped DATA statement is half the battle. Finding out which DATA statement can be difficult because the computer reports the error as occurring in the line containing the READ statement. Thus, if line 10 says (in part), "READ X, Y: PLOT X, Y" followed by lines of DATA statements, any data error will be reported as occuring in line 10, even though line 10 is typed in perfectly! The problem of finding the erroneous DATA statement is somewhat simplified if each READ statement is followed by its DATA statements.
There are other ways to isolate the problems. One way is to check the line where the error is reported and ask the computer to print the value of the READ variable. Often the READ statement is executed in a FOR-NEXT loop, and you can ask the computer to print the value of the loop variable. For example, let's look at the following BASIC program:
10 DIM A$ (10)
20 FOR N = 1 to 10: READ Q: A$ (N,N) =Q: NEXT N
30 DATA 0,1,2,3,4,5,6,7,8,9
40 FOR M = 1 TO 5: READ X, Y, Z: PLOT X, Y:POKE 256 +M, Z: NEXT M
50 DATA 10, 20, 24, 30, 40, 24, 50, 60, 24, 70, 80, 24, 90, 100, 25
Suppose you accidentally typed A$(5) instead of A$ (10) in line 10. You'll get the error message "ERROR 5 on Line 20". This is an example of a "misleading" error message. Next, suppose you made "8, 9" into "8.9" in line 30, by substituting a period for a comma. You'll get the message "ERROR 6 on line 40" Line 40? What's going on here? When line 20 is trying to READ Q 10 times (N = 1 to 10), it runs out of data on line 30 because 8.9 is one data item, while 8,9 is two. The computer gets the first data item on line 50. When line 40 executes, it starts reading at the second data item on line 50 and, consequently, runs out of data.
The first thing to do is type (in direct mode) PRINT M. The computer responds with 5. You can tell that line 40 did not finish executing, because if it had, the computer would respond with 6--one more than the loop limits. Counting off the data items in line 50 reveals that the last values of X, Y, and Z should be 90, 100, and 25 respectively. Typing in PRINT X, Y, Z causes the computer to respond with 100, 25, and 90. Everything is off by one data item, but line 50 is typed in perfectly. Now go back to the READ statement executed on line 20 and type in PRINT Q. The computer responds with the last value of Q, which is 10. That's right, so you look at line 30 to find your error.
Leaving out commas is an easy way to get Cursor Out of Range, Value Error, and Input Statement Error. Leaving out the comma between 10 and 20 on line 50 would cause the computer to try to plot 1020, 24--a non-existent position off the screen. Leaving out the comma between 24 and 30 would cause the computer to try to POKE the number 2430 into memory. Since 255 is the largest number a memory location can contain, this will also generate an error.
Finally, make sure that after you have made corrections and deletions to your program that you press [System Reset]. Sometimes errors cause critical memory locations to change in such a way that even error-free programs cannot run. Prior to every test run, press [System Reset]. Of course once your program runs correctly this is not necessary.
by David Plotkin