INMC 80 News

  

May–September 1981 · Issue 4

Page 46 of 71

Shortly after putting our newly aquired Nascom 1 out in the shop, there was ‘this ‘ere fella’ who used to wander in, dressed in motor cycle leathers, and spend a lot of time making the Nascom do things that I had never dreamed possible. And so I got to know Howard (he used to be on the committee, but resigned about a year ago). Soon Howard came a regular visitor to the shop, and could be found on a Saturday explaining the niceties of Z80 machine code programming to customers with far more informed authority than I. What’s more, he was so dedicated to Nascoms that we didn’t even have to pay him. It was Howard who first put me on the right lines as far as programming goes. Up ’til then, it had been a case of “figure it out for yourself’. Who taught Howard I do not know (perhaps I’ll ask him before this article is put to bed), but it was under Howard’s guidance that some of the mysteries of machine code programming were revealed.

So far I don’t think I have drawn any distinction between machine code programming and assembler programming. To me they are one and the same. Purists will argue that machine code is the result of assembler programming. The machine code itself being the sequence of HEX codes that is generated by the act of assembler programming. That sounds like the same thing to me, so there we are. At the time, I would scribble the machine codes directly on to a piece of paper (Woolies Jumbo A4 work pad for 44p, incredible value) and then type them in to the Nascom. Howard pointed out that this was bad practice on two counts. Firstly, it was difficult to remember what more than about half a dozen codes meant, and secondly, if I practised hard I would learn the syntax of the assembler mnenonics and by so doing increase my vocabulary of instructions because I would be thinking of the descriptive action of the instruction I wanted instead of fumbling to remember the code for the few instructions I knew. After a while it became second nature to write a mnemonic for the instruction I wanted, and then look up in the book. Low and behold, there it was. Sometimes I would take this approach too far. Occasionally I would write assembler mnemonics for instructions that don’t even exist. But in the main, it works. Think of a way round the problem, write mnemonics to decribe the action to be taken, then translate the mnemonics into machine codes.

I have already mentioned that there comes a time when the light begins to dawn. I think I was past that stage, for as I remember, I felt confident enough to start writing ‘Hangman’. Now that is an important part of learning to program. Simple games are the very best thing to cut the teeth on, as the rules for the game are already laid out, and you don’t have to draw up the specification of what it is you are about to try to achieve. Games like ‘Hangman’ have very simple rules, and these in turn are very simply broken down into their component parts. So deciding what each individual part of a program is going to do is relatively simple. Be that as it may, it was Howard who introduced me to such things as labels, flags and text strings.

So let’s re-examine the asterisks program from part 3. First of all lets lay down the ground rules of what is to happen. In other words, let’s draw up the specification.

  1. Put an asterisk on the middle of the screen
  2. Hang about a bit
  3. Replace the asterisk with a blank space
  4. Hang about a bit
  5. Go back to (1)

We don’t need to draw a flow chart of that, it’s too simple. A flow chart in fact would probably confuse the issue. Now let’s take it stage by stage and write the mnemonics for it.

LD A,2AH        ; Load A with the code for an asterisk
LD (09E2H),A    ; Put the contents of A at memory location 09E2H, which just
                ; happens to be on the screen (see last part to see how that
                ; was decided.)

Now notice that I’ve use a semicolon to separate the mnemonic instructions from the comments. In other words, the program is already being written in two fields, the instruction (or mnemonic) field and the comment field. Separating them like this makes for easy reading and understandability.

Page 46 of 71