The most annoying thing that can happen to a programmer is to lose a program he or she has spent hours typing in. This happens to every programmer at least once in their life. It should happen only once, because you vow never to let it happen again. It can happen for a variety of reasons:
Most of these problems are easily avoided with a little thought. If we were only as logical and methodical as the computer! If it hasn't happened to you yet, let's hope it never does. The following suggestions may help:
1) See that all wires are safely out of the way and cannot be caught by moving hands or feet.
2) Make it a rule always to save a program twice before running it. If you are fortunate enough to have a disk drive, this is no problem, but I know how laborious this can be with a cassette recorder. 99 times out of 100 you will probably have no problem - the BBC micro is quite tolerant of the idiosyncrasies of most recorders - but the 100th time after you've had 99 successful saves could just be the time something goes wrong.
When using cassettes, I find that the best thing I can do to ensure trouble-free loading and saving is to clean the recording and play-back heads regularly. Cassettes, cheap ones especially, shed their coating on to the heads, which impairs the signal and makes secure saving a problem.
I would advise against using a cassette tape with built-in cleaner, as these sweep the rubbish from the heads into themselves and sometimes have a tendency to sweep it out again. Far better is a head cleaning fluid, available from most chemists and hi-fi stores, which can be applied with cotton buds.
The BBC micro does not have a VERIFY command to allow you to check that what you have on tape is the same as what you have in the computer. The *CAT command is not quite the same and programs which have *CATed have, sometimes, refused to load. A better method is to use the following:
*LOAD "program"8000
where 'program' is the file name. With cassettes the name can be omitted altogether.
This attempts to load the program into the ROM area (see the memory map on page 500 of the User Guide) which, of course, it cannot do: it runs through the normal loading procedures and will report any loading errors more efficiently than the *CAT command. It will not interfere with the program already in memory so, if any errors are reported, you can SAVE it again. It does not check the program byte for byte with the program in memory, but it is the closest to a VERIFY command we have, without writing a special routine, and it is very reliable.
The programs have been fisted directly from the computer at a print width of 40 characters per line - the number of characters per line on a mode 7 screen. This will help when checking your programs against the listings.
You will probably be aware of the programmable function keys, described in the User Guide in Chapter 25. Here is a short program to initialise the keys before starting work on a program. Some of the routines are only applicable to cassettes, but most users who have worked up to disk drives will have discovered their own favourites.
10 REM PROGRAM X2.1
20 REM Function Key SetUp
30
40 *KEY0RUN|M
50
60 REM CAT
70 *KEY1*.|M
80
90 *KEY2LOAD""|M
100
110 *KEY3AUTO
120
130 REM MODE7, Paging Mode On, List
140 *KEY4MO.7|MV.14|ML.|M
150
160 REM Page Mode Off
170 *KEY5V.5|M
180
190 REM VERIFY
200 *KEY6*LOAD""8000|M
210
220 REM Print Program Length
230 *KEY7P.LOM.-PA.|M
240
250 REM Print Remaining Memory
260 *KEY8DIM P%-1:P.H.-P%|M
270
280 REM OLD, Page Mode Off, List
290 *KEY9O.|MV.15|ML.|M
300
310 FORX%=0TO10:PRINT"SOFT KEYS SET":N
EXT
320 END
A very useful facility available from OS 1.0 onwards is the ability to print teletext characters directly on to the screen. For example, pressing SHIFT and F4 simultaneously is the equivalent of PRINTing CHR$132 and produces a blue alpha-numeric character. As well as saving memory, this technique makes it harder to enter and edit menu and instruction pages, etc, and is worth cultivating.
As these codes will not fist to a printer in the usual way, they have been written out in full in the programs in this book. For further details see the User Guide page 439. Incidentally, the OSBYTE call mentioned there is incorrect. It should read A=&E2 (226).
I have tried to use meaningful variable names throughout the program and have restricted my use of integer variables (see the User Guide page 65) simply to aid readability. Many programs could be shortened and speeded up by using integer variables and shorter variable names especially where the program performs calculations before sending data to the SOUND command.
I have also refrained from using indirection operators (see the User Guide Chapter 39) for which I may be criticised. However, my aim was always that the reader should understand how the programs work and beginners may well be confused by such 'heavy' material. Those more expert will, I hope, let loose all the tricks of the trade as they experiment with the program.
Many programs fisted in this book use the same or similar routines and to save time and effort some of the programs have been designed to be inserted directly into other programs. These programs will not run by themselves.
The original programs are all numbered in steps of 10 but, for obvious reasons, this was not always possible with the other programs. Most of these are fairly short and can be merged with the other programs using *SPOOL and *EXEC as described in the User Guide on page 402. It is essential that every single line be entered, including the blank ones which are sometimes there to delete unwanted lines from the original program.
Alternatively, you could LOAD the main program and type in the new fines, but be very careful of entry errors.
For disk users, I would recommend the first option but if cassette users check the fine numbers carefully the second method may be quicker.
When experimenting with some of the programs, you may want to repeat a set of random numbers. This can be done by first setting the RND function with a negative number in brackets such as:
X=RND (-2)
Details are included in the User Guide on pages 84 and 342.
This can be useful if you want to check a program's output.