This Special booklet was published by Future Publishing and was given away free with the October 1995 issue of Amiga format.
We have republished the first chapter from the booklet which deals with coding on the Amiga for your enjoyment
Get the Most out of Your Amiga IV
(Part 1 Amiga coding)
Computers are tools, designed to do what we want them to. More often than not this means running commercial programs which present us with a list of options via requesters and menus. These options are converted into an action to be performed, and the program makes the computer perform it.
Writing your own programs is a direct way of telling your Amiga what to do – you can make it perform any of the actions within its power.
So, learning to program gives you power over your Amiga, or rather the ability to use your Amiga’s powermore directly and effectively. But don’t be fooled by what you may have heard – programming isn’t difficult. In fact, at a basic level, it’s very straightforward, no more complex than entering CLI commands.
At the heart of your Amiga is a silicon chip called the Central Processing Unit (CPU). This understands and obeys a limited set of instructions. A program is an ordered combination of these instructions, each of which is to be carried out one after the other. The instructions themselves are short and crude, but in concert they can be very powerful.
Think of an old-fashioned piano player. It has a set of notes, like an ordinary piano, and each of these may be likened to a processor instruction. A single note doesn’t count for much, but subtle combinations of them can create beautiful music.
A piano player isn’t played by a musician, but receives its instructions from rolls of paper with holes punched in which represent a note. The roll is the equivalent of a program.
The metaphor isn’t as strained as it may seem – early programs were stored on punched cards, as oftenshown in 60s spy movies, and the holes in the cards correspond to instructions. Now, programs are held on floppy disks, but the principle still holds – the instructions are stored as a series of electronic ones and noughts, the same as holes and no-holes.
The CPU’s instruction set is very crude, and many instructions need to work together to create an appreciable effect. This is fine from an engineering point of view – the smaller the instructions, the easier it is to build electronic gadgetry to understand and execute them quickly – but not so good for the easily confused human. This confusion is exacerbated by the form the instructions take – they are just simple numbers.
Programming languages operate on a compromise basis: they are far from English, lacking all of the language’s subtlety, but their instructions take the form of English-like words, each equivalent in power to many of the CPU’s numerical instructions, making it easier and quicker to write programs with them.
One of the most popular programming languages is BASIC (standing for Beginners’ All-purpose Symbolic Instructional Code). It was created in the 70s to help introduce the foundations of programming to students before they went on to study more complex languages.
Because of its simplicity, BASIC has become immensely popular with home computer owners. This in turn has caused it to evolve, until it is now much more than a mere beginners’ language. There are few things you can do in another language that can’t be done in BASIC, yet it’s still easy to learn.
BASIC, like most languages, is a procedural language. This means that programs written in it define a procedure to be followed. The procedure consists of the program’s set of instructions, to be executed in the order they appear
It’s useful to represent this sort of program as a flow chart – a diagram showing each of the instructions to be followed, and in which order. Flow charts are valuable when you come to design complex programs they help you envisage the overall flow of things before you get involved with the nitty gritty.
If you were to write a program to add two numbers together, you might break the procedure down to the following consecutive steps: print a message to the screen; get first number from the user; store it in memory; get second number from the user; store it in memory; add the two numbers in memory together and store the result elsewhere in memory; print the result in memory out to the screen.
Look at the diagram (above) to see how this would be expressed as a flow chart.
Notice that the three numbers involved in the calculation have to be stored in memory. Generally, you as a programmer don’t have to worry about the specifics ofyour Amiga’s memory. Instead, you refer to areas in memory by means of variables.
A variable is an area in memory of sufficient size to store a single item of data – in this, case, a single number. The program gains access to data by referring to a variable name. A name might be
something like ‘number 1’.
If you wanted to store a number in the bit of memory this name represented, then you’d write the name, followed by an equals sign, followed by the number to be stored. If you wanted your program to deal with the number held in memory, then you’d use the name itself. Here’s how the program would look in BASIC:
PRINT "Enter the two numbers to be added" INPUT numberl INPUT number2 number3 =number1+number2 PRINT "The answer is *,number3
The PRINT instruction enables you to print text and the contents of variables out to the screen. The INPUT instruction tells the Amiga to take whatever the userenters at the keyboard and store it in a variable, in this case first numberl then number2. The next line adds the two values held in numberl and number2, then stores the result of the addition in number3. The nextline prints out this result, and the final line tells the Amiga there are no more instructions to be executed.’
Completely linear programs like this are rare in practice. It’s usual for the order of execution to be
varied depending on the data a program is given to operate on. Two programming concepts in particular make this possible.
The first is decision-making. With it, a program can test the value of something – for example, testing whether a variable holds a particular number – and follow one of two courses of action depending on the result of the test.
The second is the idea of procedures. A procedure is like a miniature program, usually carrying out a more specialised task than a complete program. It need only be written once, but can be executed, or ‘called’, several times from different places within the same program. A common technique is to call a procedure if a certain result is yielded from a decision-making test.
There are several variants of BASIC available for the Amiga. The original is AmigaBASIC, from Microsoft, which, until a couple of years ago, was bundled with every Amiga sold.
In many respects it’s a powerful language. It gives adequate, though not complete, support for the
Amiga’s graphics and sound facilities, and considerably extends the decision-making and procedure-calling facilities of BASIC.
It’s not without its problems, though. AmigaBASIC won’t take advantage of the AGA graphics modes or any of the Operating System improvements sinceWorkbench 1.3 (after 1.3, Commodore bundled the language ARexx instead but didn’t bother supplying any documentation) .
It’s also dreadfully slow. This would be almost bearable, but the editor that comes with it (all programs are entered as text from the keyboard, which is done with the aid of a text-editing program) is even slower, which makes developing programs with the language near unbearable. The final problem – something of a blessing, actually – is that AmigaBasic is no longer available. If you want to get into BASIC on your Amiga, look elsewhere.
AMOS, from Europress Software, was originally intended primarily as a language for creating games. It provides much better access to the Amiga’s innards, the hardware that makes all those wonderful graphics and audio effects possible, than AmigaBASIC. It does so with a simpler grammar, or syntax, and it does so much more quickly.
AMOS provides all the facilities you’d expect in a modern programming language, and has been used
for writing games and many other applications, most notably for educational software. It’s a good, solid, straightforward language, easy on the beginner.
Europress released two variations on the original (known as AMOS The Creator and now no longer on sale). Easy AMOS and AMOS Professional. Easy AMOS (about £35), is aimed at the beginner, but comes with many extras, such as on-line help (click on a command to find out what it does and how to use it) a better-than-average manual and a debugging mode.
In debugging mode, you can force your programs to execute a single line at a time, with the ability to look at the contents of any variables in use. This is a real boon when it comes to removing mistakes from your work.
Easy AMOS is good, but AMOS Professional, (rrp £49.99, but given away on the Amiga Format issue 67 Coverdisk) is better.
Even as a beginner, you’d be advised to choose AMOS Professional over Easy AMOS. It has the same
debugging features and a much larger and improved command set, making it a speedy, powerful language ready for just about any programming task.
Although AMOS is fast, it’s still not fast enough to fulfil its original goal – to enable the creation of fast, arcade-style games. They require too many moving objects on the screen at once – try and animate a decent number of aliens in AMOS and things stagger along at a drunkard’s pace. If you want to write this sort of game, you’d better look for something other than BASIC. Or at least, that used to be the case, until the arrival of Blitz Basic.
Acid Software’s Blitz Basic 2 is built for speed. The only problem is that it’s difficult to find a copy
because it proved so popular, although a revised version should be out by the time you read this.
You still won’t be able to write the more sophisticated kind of arcade games with it, but fast movement on a more basic level is certainly possible. A more-than-passable version of the arcade classic Defender is provided with the package, complete with zipping aliens and tremendous explosions.
Acid Software’s excellent racing game, Skidmarks, was written in Blitz
Basic 2. A new version of the programming language is on the way.
If Blitz is faster than AMOS, then it’s also more complicated to grasp. Its syntax in places looks more like C than BASIC, making some commands a bit obscure. It does provide more power in raw programming terms than AMOS, though. One significant advantage is the use of records for grouping several related data items together under one name. It may not sound like much, but once you’ve been programming for a while you realise that organisation is the key and that being able to arrange your data like this is a must.
Blitz Basic has yet to become as popular as AMOS, but it’s a great language, and if you want to write fast-paced games in BASIC, this is the one for you.
Remember the numerical instructions that the CPU follows? These are what an Assembler language deal with. Instead of referring to the instructions as numbers, you get to call them by cryptic, three or four letter words, and you can refer to areas in memory by assigned names (labels) rather than having to remember the numerical addresses.
But writing a program in Assembler is a cumbersome, errors-prone business. You have to string so many instructions together, and you’re dealing with themachine in such a raw, unbuffered state, that you’re bound to make mistakes.
When you make a mistake in BASIC, the translator tells you and gives you a chance to correct it. If you make a mistake with Assembler, the Operating System will probably hold up its hands in horror
and crash the Amiga.
So why do it? Speed, and control. Because there’s no automatic translation involved (well, your three-letter words are turned into numbers, but that’s it), because you’re writing in the CPU’s own tongue, there is no more efficient way to code a program. Every instruction, chosen by you, counts, so with Assembler you get the fastest programs of all.
Also, when a program is translated by something like a BASIC package, the translation needs to take into account certain generalities. A command you’re using, for instance, may be able to act on more options than you are, at the time, concerned with.
Those optional extras need to be taken care of by the translator, even though you don’t need them, and that takes time.
There’s none of that nonsense with Assembler – you only write the instructions you need to be executed.
There are a few Assemblers available for the Amiga. A68K is a very good PD one, available from just about every library, and there are two commercial ones – DevPac 3 (about £70) from HiSoft and Macro 68 (about £130) from Helios Software.
Macro 68 is the more powerful of the two, but most people prefer the longer-established and more accessible DevPac 3. If you want to get into Assembler, you’ll find both give you more than you need, but it might be advisable to start with A68K, just to see if you’re suited to this style of programming.
BASIC is too slow, and Assembler is too error-prone, there must be a compromise, right? Well, there are many, but the most popular is a language called C.
Unlike BASIC, C’s translation process is one of compilation rather than interpretation. With interpretation, the translator goes through each line of a program in turn, translating it and executing it. If, for some reason, execution returns to a line that has already been executed once, then it must be re-translated. It’s inefficient, but it makes it easy for the programmer to correct mistakes.
With compilation, the program is translated enmasse before it is executed. The result executes much
faster than its interpreted counterpart because no further translation is required. The downside is that the translation process can only pick up some of the errors in a program. The remainder, as in the case of Assembler, cart cause anything from some mildly odd behaviour to a complete system crash.
C is the choice of most professional, non-games developers. The Amiga’s Operating System was
written with it, it’s extremely powerful, it gives complete access to all of the Amiga’s facilities and
it’s just about the fastest compiled language.
Its syntax, though, is awkward. Most of the commands are very brief – a painful contrast to the more
English-like words of BASIC – meaning that programs can be harder to understand when you come to look at them some time after they’ve been written. Some people like this approach and it can be very satisfying to create a program that does an awful lot with relatively few lines of code.
If you think of C as some sort of cross between Assembler and BASIC, then you won’t be going too far wrong.
There are two C compilers for the Amiga. SAS C has been popular for many years, and comes with many support tools, and DICE is a package which used to be Shareware and has only recently been released as a commercial offering (a Coverdisk version appeared on Amiga Shopper 47).
DICE is a solid package with plenty of extras and it’s likely that its author, Matt Dillon, will be more committed to the Amiga than SAS, a company whose primary concern is with other platforms such as the PC.
There are plenty of other programming languages available for the Amiga:
Pascal is like a more academic version of C, with a clearer syntax and more easily-remembered commands. It hasn’t quite caught on in the same way as C and the only commercial version for the Amiga is HiSpeed Pascal, from HiSoft.The rest are mostly available in the Public Domain, and as such tend to be on the ropey side and poorly supported.
The following sorts of languages have been designed for specific purposes:
Smalltalk is an object-orientated language, based on the philosophy that the data a program has to deal with is more important than the procedures that deal with it.
Lisp is a functional language – in which every instruction behaves like a mathematical function, taking arguments and producing results – designed for artificial intelligence research.
Prolog is also used for artificial intelligence. It relies heavily on formal logic, so programmers specify data and propositions about that data which may be eithertrue or false. It can be used to solve the sort of logic puzzles that would be much more difficult to code in conventional language.
E is an Amiga-only language that’s best described as a lean and mean version of C.
© Future Publishing 1995
Beauford Court, 30 Monmouth Street, Bath, Avon BA1 2BW
This book is provided free with the October issue of Amiga Format
It contains excerpts from Get the Most out of Your Amiga IV, the latest edition of the best-selling Amiga owner’s guidebook. This 300-page book explains everything you need to know about how your Amiga works and what it can do, and comes with a disk containing specially-selected public domain and shareware software to further enhance your machine. The full book is available in all
good bookshops, and direct from Future Publishing.
About Amiga Format
Amiga Format is the UK’s best-selling Amiga magazine. With its blend of authoritative reviews, up-to-the-minute news coverage and expert technical insight, it has led the field since its launch.
You can contact Amiga Format by the following means:
Mail Beauford Court, 30 Monmouth Street, Bath, Avon BA1 2BW
Phone 01225 442244
Fax 01225 318740
email [email protected]
(please include dept. in subject text)