I recently inherited the original instruction manual from the first computer my family ever owned, the Amstrad CPC 6128 User Instructions.
Flicking through this magnificent compendium has sent me on a serious nostalgia trip. It wasn't long before I downloaded an Amstrad emulator (or two) and began to relive some of the programming fun of Amstrad Basic.
The book takes you through every aspect of the computer, the hardware, the operating system, and two programming languages (BASIC and Logo). And it starts from absolute beginner level, in a way that no modern set of instructions ever needs to. Here's an excellent example:
When you reach the right hand edge of the screen by entering 40 characters on a line,
the next character will automatically appear on the following line at the left edge of
the screen. This means that you should NOT press
[RETURN] as those of you accustomed to typewriters might press a carriage return towards the right edge of a
The computer does this automatically for you, and will react to an unwanted
[RETURN] by printing an error message - usually a
Syntax error, either there
and then, or when the program is run.
...that's not a detail typically cover in a more recent text. And it recurs throughout the early chapters of the book, as they explicitly tell you where to hit return in case you've miraculously forgotten. They only stop adding the word
[RETURN] when they get up to teaching you about the
return keyword (used after a
gosub, for awesome fun times.)
Demonstrating the use of GOTO, GOSUB and RETURN leads to this interesting reflection:
See how much tedious typing we've saved ourselves? Well designed subroutines are
a principal part of computing. They lead to 'structured' programs, and develop good
...all by itself this seems to conflict with the ideas put forth in 'Go-to Statement Considered Harmful' but the very next paragraph really takes it up a notch:
Always bear in mind when writing sub-routines, that you do not necessarily have to
Jump into' the sub-routine at the same point, i.e. its beginning. A sub-routine written
from lines 500 to 800 can be called by: GOSUB 500, or GOSUB 640, or GOSUB 790.
...this isn't what you call the gold standard of structured programming. ;-)
The more I got into it, the more I enjoyed it. I was surprised at how much I'd forgotten, but equally surprised at how ready those memories were to spring back into place. My friend Dr Richard (of brisbane parks fame) pointed out that by reawakening such old neurons and marking them as new again, the brain is bound to believe that those memories are of very high importance and mark them as always hot. So now it's likely I'll never forget Amstrad Basic again.
One intriguing idea from the Amstrad, which seems to have been abandoned by the side of the information highway, is 'the copy cursor'.
Consider this startling example of using 'the copy cursor' to correct a typo. Their example builds on this code sample, which has a missing 'r' on line 10:
10 input "what is you name";a$
20 input "what is your age";b
30 print "I must say";a$;" you dont
Here's how a coding ninja would fix that typo, in the copy cursor era:
Copy Cursor Method
The copy cursor is another cursor (in addition to the one already on the screen) which
comes into view when you hold down
[SHIFT] and press one of the cursor keys. It then
detaches itself from the main cursor and can then be moved around the screen
To correct the mistakes in line 10 and 30, hold down the
[SHIFT] key then press the
cursor up key until the copy cursor is positioned over the very beginning of line
10. You will notice the main cursor has not moved, so there are now two cursors on
the screen. Now press the
[COPY] key until the copy cursor is positioned over the
space between 'you' and 'name'. You will notice that line 10 is being re-written on the
last line and the main cursor stops at the same place as the copy cursor. Now type in
the letter 'r'. This will appear on the bottom line only.
The main cursor has moved but the copy cursor stayed where it was. Now press the
[COPY] key until the whole of line 10 is copied. Press
[RETURN] and this new line
10 will be stored in the memory. The copy cursor disappears and the main cursor
positions itself under the new line 1 0. To correct the second mistake, hold down
[SHIFT] and press the cursor up key until the copy cursor appears over the
very beginning of line 30.
[COPY] until the copy cursor is positioned over the quotation marks next to
say. Now press the space bar once. A space wiil be inserted on the bottom line. Hold
[COPY] key until the whole of line 30 is copied, then press
(Using an Amstrad emulator with a windows keyboard, I found that the Pg-Dn key acted as the
But software quality assurance and refactoring magic aren't just left up to the wonderous copy cursor. There's another awesome tip on detecting errors in your code. The trick is to write your code in lowercase and see that the interpreter finds your keywords and shifts them to uppercase:
In the above program, and in later chapters and listings in this manual, BASIC
keywords will appear in upper case (CAPITAL) letters. This is how keywords
appear when a program is LISTed by the computer. In general it is preferable
that you type instructions or programs using lower case (small) letters, since it will
help you spot typing mistakes when LISTing the program - (because the
mis-typed BASIC keyword will NOT be converted to upper case).
I find something adorable in their vociferous way of describing the technique. The modern age is all too brief in its belting-around-the-headedness-about-the-simple-things. These days it's all "merge this, rebase that, man page if you don't grok" and the eyes are left spinny.
I've had some recent fun building simple programs on the Amstrad (emulators) but there's too much to cover here. I'd like to write a little about it, if I find the time, but that's enough for now.
Just reviewing the book was a joy in itself. Whoever said "nostalgia isn't what it used to be" must've been one of those filthy Commodore 64 programmers, I guess.