This section is the section to read if all else fails; you have studied your program, and the rest of the manual, and you still cannot see anything wrong, but the program refuses to work.
There are two types of programming errors; errors of syntax, and errors of logic.
Syntax errors are caused by writing something in the program that is not legal, and that is therefore not understood by the BASIC interpreter. Usually this will give rise to an error, and reading the description of that error code in Chapter 27 should make the mistake obvious.
Typical causes of syntax errors are:
1. Mistyping a digit '0' for a letter 'O', and vice-versa. E.g.:
F0R N=1 T0 3
2. Mistyping a digit '1' for a letter 'I', and vice-versa. E.g.:
1F J=2 PR1NT "TWO"
3. Forgetting to enclose an expression in brackets when it is used as a parameter in a statement. E.g.:
MOVE X+32,Y
In some cases a syntax error is interpreted as legal by BASIC, but with a different meaning from that intended by the programmer, and no error message will be given. E.g.:
MOVE O,O
was intended to move to the origin, but in fact moves to some coordinates dependent on the value of the variable O.
Errors of logic arise when a program is perfectly legal, but does not do what the programmer intended, probably because the programmer misinterpreted something in this manual, or because a situation arose that was not forseen by the programmer. Common logical errors are:
l. Unitialised variables. Remember that the variables A-Z initially contain unpredictable values, and so all the variables used in a program should appear on the left hand side of an assignment statement, in an INPUT statement, dimensioned by a DIM statement, or as the control variable in a FOR...NEXT loop, at least once in the program. These are the only places where the values of variables are changed.
2. The same variable is used for two purposes. It is very easy to forget that a variable has been used for one purpose at one point in the program, and to use it for another purpose when it was intended to save the variable's original value. It is good practice to keep a list of the variables used in a program, similar to the list given after the application programs in this manual, to avoid this error.
3. Location counter P not set up when assembling. The value of P should be set before assembling a program to the address of an unused area of memory large enough to receive the machine code, and P should not be used for any other purpose in the program.
4. Graphics statements used without initialising graphics. The CLEAR statement must precede use of any graphics statements.
5. Assigning to a string variable and exceeding the allocated space. Care should be taken that enough space has been allocated to string variables, with DIM, to receive the strings allocated to them.
6. Assigning outside the bounds of an array or vector. Assigning to array or vector elements above the range dimensioned in the DIM statement will overwrite other arrays, vectors, or strings.
This section deals with faults on an ATOM which is substantially working, but which exhibits faults which are thought to be due to hardware faults rather than programming faults. Hardware fault-finding details are provided in the Technical Manual; this section describes only those hardware problems that can be tested by running software diagnostics.
The following BASIC program can be used to verify that the ATOM's memory is working correctly:
1 REM MEMORY TEST 10 INPUT"FROM"A," TO"B 20 DO ?12=0; R=!8 30 FOR N=A TO B STEP4;!N=RND; NEXT N 35 ?12=0; !8=R 40 FOR N=A TO B STEP4 50 IF !N<>RND PRINT'"FAIL AT "&N' 60 NEXT N 70 P." OK"; UNTIL 0
The first address entered should be the lowest address to be tested, and the second address entered should be four less than the highest address to be tested. For example, to test the screen memory enter:
>RUN FROM?#8000 TO?#81FC
The program stores random numbers in the memory locations, and then re-seeds the random-number generator and checks each location is correct.
The BASIC interpreter, operating system, and assembler, are all contained in a single 8K ROM, and as all ROMs are thoroughly tested before despatch it is very unlikely that a fault could be present. However, if a user suspects a ROM fault the following program should be entered and run; the program obtains a 'signature' for the whole ROM, this signature consistinq of a four-digit hexadecimal number. The program should be run for each 4K half of the ROM.
1 REM CRC Signature 10 INPUT "PROM ADDRESS", P 20 C=0;Z=#FFFF;Y=#2D 30 FOR Q=0 TO #FFF 35 A=P?Q 40 FOR B=l TO 8 60 C=C*2+A&1;A=A/2;IFC>Z C=C:Y;C=C&Z 80 NEXT B; NEXT Q 110 PRINT "SIGNATURE IS" &C' 120 END
Program size: 213 bytes Sample run:
>RUN PROM ADDRESS?#C000 SIGNATURE IS D67D >RUN PROM ADDRESS?#F000 SIGNATURE IS E386
The program takes about 6 minutes to run, and if these signatures are obtained the ROM is correct.
The Atom extension ROM, described in chapter 22, can be tested by giving the reply #D000 to the prompt. It should give a signature of AAA1.
If all else fails, owners of an ATOM may make use of the free Programming Service provided by Acorn. To ensure a rapid reply to any queries the special Programming Service Forms, supplied with the ATOM, must be used to submit the problem. New forms will be supplied with the reply to any queries, or on request.
All reports should be accompanied by a full description of the problem or fault, and the occasions when it occurs. Please also enclose a stamped addressed envelope for the reply. A program should be supplied which illustrates the problem or suspected fault. This program should preferably be only four or five lines long, and should be written in the space provided on the Programming Service Form, with any spaces in the original carefully included. If the problem or fault is only exhibited by a longer program the report form should be accompanied by a cassette tape recording of the program, and the title of the file on the tape should be entered on the form. The cassette will be returned with the reply.