The BBC Micro is a computer that encourages the two approaches to programming that concern this book producing clear, bug-free programs, and using BASIC and assembler in combination. These features make the transition from simple programming in BASIC to 'advanced programming' a particularly painless and logical one.
It doesn't take long to discover that BASIC is a very simple computer language. The total number of BASIC commands can be numbered in tens and the set of commonly used ones is not many more than ten! In fact there is nothing very complex about any computer language but knowing the details of a language is not the same thing as being able to use it to achieve any given result. To make a computer work to your advantage you must not only know what you want it to do, you must also know how to make it do it. This is sometimes summarised by saying that our current use of computers is at the 'HOW' rather than 'WHA T' stage. The process of telling a computer how to do something is usually referred to as 'programming'. However, the subject of this book is 'advanced programming' and this raises the question of what the word 'advanced' means in this context. In this chapter what constitutes advanced programming is explored and, in passing, the topics that form later chapters are introduced.
As with so many things in computer science, it is easier to say what 'advanced' doesn't mean than what it does! Advanced programming certainly doesn't imply the use of an advanced or difficult programming language. It is a common fallacy that BASIC somehow lacks an essential ingredient and is thus unsuitable for certain programming tasks. This fallacy is reinforced by the way that academic computer scientists promote languages such as Pascal and - increasingly the newest language creation, Ada. However there is very little in either of these languages that a programmer familiar with BBC BASIC would not recognise and understand. The sophistication of a language generally doesn't extend the range of things it is capable- of; it just makes it more or less convenient for the application in hand. At the other end of the scale, it is often supposed that it represents an advance to 'graduate' to assembly language (often referred to as 'machine code'). This idea is fostered by the fact that many commercial programs that achieve effects that seem impossible from BASIC are written in assembler. However, assembler certainly cannot be thought of as an 'advance' in any sense of the word. If anything, the continuing use of assembler is a reflection of how inadequate and crude the current generation of computers are, in that the only reason for using assembler is to gain extra speed of processing. Assembler is fast but it isn't advanced.
The fact is that the elements which make up computer programming are very simple, no matter in what language they turn up. Very roughly speaking, a program, in any language, manipulates data, uses loops to repeat actions and selects between actions using the IF statement or its equivalent. Much confusion is caused by the assumption that problems encountered when writing a program in BASIC would be solved by using aother language. In most cases the program will prove just as difficult to write in a new language as it did in BASIC because you are trying to solve the same problem with only slightly different tools. Another way to sum this up is if you don't know how to do it in BASIC you won't know how to do it any other language!
Once you have learned what each of the statements in BASIC do, the next task is to use them to write programs. At first, the sort of programs that you write are short enough to be written in one sitting. They also contain very few statements so the scope for anything other than obvious bugs is limited. At this stage it is very easy to recognise a successful, working program. At the next stage, however, things are not so easy. There is a world of difference between writing a small program and writing a large program. It is important to realise that this difference is not just one of degree; there genuinely are new types of difficulty to be found in writing large programs. Some novice programmers never realise that this is the case and so fail to progress beyond short programs. Others discover ad hoe methods and create large programs through sheer enthusiasm. Both of these conditions are sad because it is very easy to learn and use techniques that make large programs not only possible, but possible without superhuman labour!
Using an organised approach to program construction is most certainly a part of advanced programming but it's not the only part. For example, writing larger programs using any method brings the possibility of introducing larger and more subtle bugs. There is also the question of making programs easy and pleasant to use. Writing programs that work as intended is difficult, if not impossible, without being aware of the stages of 'bug detection' and 'bug location'. Good initial program design is also a help in keeping the number of bugs to a minimum but there is no fool-proof way of ensuring that a program is entirely bug-free. Don't take this as an excuse for ignoring the responsibility for removing as many bugs as possible from a program but see it as an indication that a feature of advanced programming is the need to use what time and resources are available to the best effect. While it is possible to give firm guidelines on how to deal with bugs, it is much more difficult to be definite about how to achieve user-friendly programs. After all the methods for program design and debugging have become second nature, the advanced programmer can start to tackle the real problems of writing programs that not only are useful but are a pleasure to use.
So far, it looks as though advanced programming amounts to nothing more than a collection of methods to aid program construction. However, there is a world of difference between applying these methods and appreciating how they work. Another component of advanced programming is knowing when rules and regulations can and should be broken. To this end it is important that the underlying aims and theory of programming are understood rather than being just a collection of rigidly applied methods. In this sense there is still a great deal of freedom to be exercised and there is no need to fear that the fun will be taken out of programming by trying to do it better. Indeed, there is much more fun and satisfaction to be gained from a well-conducted programming project than from one that is scraped together by sheer brute force or hours spent slaving over a keyboard.
There is another aspect of using a systematic approach to programming that is worth explaining at this early stage. As programming develops, it is becoming as much a method of communication as a way of getting things done. It is almost a cliche to say that there are more programmers alive today than ever before (the world's population is such that there is more of everything!); but it is important not to miss the fact that programs are one of the main channels of communication between programmers. A working but difficult-to-understand program fails to satisfy the function of communication and in this sense it is doomed to failure in the longer term. The reason for this is simply that no program is ever complete. It may serve the needs of the moment but the progression of computer hardware and users' expectations mean that it will inevitably become inadequate. When a program reaches the end of its useful life it is usually replaced but this can be achieved in two ways - by starting from scratch or by producing a new version of the old program. In both cases the only way to avoid re-inventing the wheel is to make sure that the ideas that the original program contains are clear for all to see. This principle of building on the best of the past is one that is already well known in science subjects. To quote Sir Isaac Newton, the greatest English physicist and mathematician: 'If I have seen further it is by standing on the shoulders of giants'.
To make similar advances in computer science it is important that we learn to expect new software to 'stand on the shoulders' of its precursors. The skill of programming should include the ability to both read and write programs. In the past the emphasis has been on writing programs possibly because the current state of the art made reading existing programs almost impossible. Advanced programming must be about writing programs that are easy to read and learning to read programs written by other people.
The role of any particular computer in advanced programming has been played down until this point because, in the same sense that advanced programming is nothing to do with a particular computer language, it is similarly machine independent. However, this machine-independent attitude misses the point that you have to have the experience of knowing a particular machine before you can generalise. In the same way as you must learn BASIC before you can understand the ideas of programming, you have to study a particular machine before you can understand the broader ideas of computer science and computer use and this book is specifically about advanced programming using the BBC Micro - an excellent machine for the job of illustrating almost any idea in computing!
Many pieces of hardware information seem to be 'one off facts' that turn up by accident. That is, if you didn't know them there would be no systematic way of setting out to discover them. This 'one off aspect of hardware is only true in part because there are many methods of investigating the way that a computer works that are common to all machines. It is a step in the right direction to realise that computing is an experimental science! An advanced programmer will have an idea of the possible ways that a machine can operate. Using this knowledge and perhaps some initial observations it is usually possible to guess the way things might work in a particular case -- in other sciences this is referred to as an experimental hypothesis but for us the term 'guess' will do! On the basis of this guess you can predict what you would expect to find and then write a program or examine the machine in some other way to confirm or deny the correctness of your guess. This is an experiment in any subject's language, but computer scientists sometimes refer to it as 'having a look to see'!
Throughout this book there are many specific pieces of information given about the workings of the BBC Micro's hardware and software, but much of the time the emphasis is on how these facts were discovered. This means that as well as providing you with some information of practical value, it should be possible for you to see how to add to this body of knowledge. A great deal of information about the overall structure of the BBC Micro can already be found in The BBC Micro: An Expert Guide (Granada, 1983). Occasionally it will be necessary to summarise information from that book so as to make this book complete in itself, but the overlap between the two volumes is slight. In the same way the overlap between this book and the BBC Micro User Guide is held to the minimum but it is assumed that you have a copy available. Frequent reference is made to the User Guide so keep it to hand.
As already mentioned, BBC BASIC is a suitable language for advanced programming but it has to be admitted that sometimes the speed of assembler is indispensable, For this reason, although many of the examples in this book are in nothing but BBC BASIC, it would be impossible to write a book on advanced programming that ignored assembler. Rather than introduce it with apologies wherever it proves necessary, it is better to treat it on a more equal footing with BASIC. So, as well as turning up in some of the examples, you will also find whole chapters devoted to assembler. In particular, Chapter Four deals with a subject that is almost never discussed - programming style in assembler. The most probable reason for this neglect is that it is somehow assumed that assembler is such a difficult computer language that just to be able to write programs using it is a sufficient level of proficiency. This is, as the preceding discussion of advanced programming should indicate, completely untrue. Assembler is difficult because the programming methods that are advocated for languages such as BASIC are ignored in assembler! It is as possible to write a well structured assembly language program as it is to write structured BASIC, Pascal, ALGOL . . .
As with BASIC, it is assumed that you have reached the stage of understanding the rudiments of assembler and this book makes no pretence of being an introduction to 6502 assembler. However, this is not to say that you have to know assembler to get anything from this book. Most of the ideas are language independent and the results of the assembly language sections can be used without understanding them. The hope, of course, is that if you don't know assembly language you will be inspired to invest the time necessary to learn it!
The twin approach of using BASIC with assembler is realistic in that it represents what really happens in writing programs. Assembler is, at the best of times, a less readable language than BASIC and there are fewer programmers who understand it. For these reasons it is important not to use it without good cause. It is rare for the bulk of a program to prove impossible to write in BASIC and the best approach is to incorporate assembly language subroutines within programs where they are absolutely essential. This combination of BASIC and assembler is the most powerful way to write programs.
After all this discussion of what constitutes advanced programming you should be able to see how the topics dealt with in each chapter relate to the overall idea. Advanced programming is not a subject with an exact and finite syllabus and so it is impossible to include everything that is worth knowing. However, you should find that most of the important subjects are covered. The first part of the book is about programming methods in general, including structured programming, debugging and data handling. The latter part is devoted to some large example programs which serve more than one purpose. They are intended to teach aspects of programming, to iflustrate special facilities of the BBC Micro and to be useful and a-ttractive applications.
Finally, it is a little known fact that computer books should not be read in order of strictly increasing page number! Although the material in this book is organised to reflect an overall progression of information, you shouldn't suppose that you have to understand things in any predetermined order. It would be going too far to suggest that the best strategy is to read computer books backwards but you should exercise a greater degree of freedom in the order of reading than is normal. On the other hand, if you find that you do not understand something, don't give in to the very natural impulse to re-read or go back to earlier chapters press on. It is often the case that later material clarifies an earlier misunderstanding while rereading' previous sections would only reinforce it.