A Monthly Column

Machine Language: The Beginner's Dilemma

Jim Butterfield
Associate Editor

The beginner in machine language programming is faced with a three-way task. It's not enough to learn about machine code itself; the beginner must also develop skills on the particular machine that has been chosen. These extra skills fall into two general categories: using the tools that are provided and finding your way around the architecture.

Machine Language Itself

The machine code is the easiest part. There are numerous books and reference sources that will supply this information.

The matter is confused slightly by approaches and titles. Some teach machine language, some teach assembly language, and others identify themselves as books on "programming" or "program design." There isn't really much difference; they all develop the same skills.

I tend to favor learning the machine itself First – hexadecimal codes and such – and working up to the more general assembly language level later. It seems to me that if you can retain a firm image of the instructions as they lie in memory, you will always have a strong feeling for the real nature of the machine. For a beginner, assemblers do too much; it's easy to lose touch with how the machine is really doing the job. Later, assemblers will prove to be a powerful aid to programming, but they may be too powerful for the beginner.

But the neophyte may find himself blocked at the start. It's all very well to read about these codes, but how do you get them into the machine? And how do the codes create output to screen or printer?

Machine Language Tools: Monitors And Interfaces

The user needs some understanding of the monitor before he can do anything useful. This is the tool that allows him to enter code into the machine; to check code for correctness; to initiate a program test run; and to intercept a program during the run in order to investigate its performance.

The monitor for a given machine may come in many forms. It may be built in, or loaded from tape or disk, or plugged in as a ROM cartridge. A given system may have one monitor, or a choice of several, or even extensions that can be added to a built-in monitor. Variety may be the spice of life, but it makes things difficult for textbooks. It's easy to show how to add two numbers together with a 6502; the coding is the same for all systems. But an outline of how to put this addition program into the computer must vary from machine to machine, from monitor to monitor.

There's another problem that needs to be solved. Different machines call for different interfaces to input and output. As a result, a general textbook can't complete the picture, since the input and output mechanics vary from machine to machine. On Commodore products, output (print) is generated by a call to $FFD2; but the identical activity on Apple, KIM, Atari, AIM, or OSI is coded in a manner unique to that machine. Pity the poor machine language book author: he/she can't complete the picture without either tying himself to a specific machine or attaching a long rambling list of interfaces.

Architecture

Even identifying the tools specific to your machine isn't enough. We need to know how the machine is structured: in particular, what parts of memory are used for what purposes.

Where is the screen? It's often memory-mapped, but might be one place on a PET and another place on an Apple. Machines like Atari and VIC have "mobile" screens. There are several places in memory which might reflect the screen, depending on circumstances.

More importantly: what space is available on your computer, and what is in use? It's hard to enter a program into your computer if you don't know how to find or create a safe place in RAM for the program to go.

Again, it's hard for the textbook. Either it specializes in your machine, or leaves the poor beginner without the information he needs to fit the program to his machine.

You cannot effectively learn machine language in a vacuum. Each learner must have a chance to try his hand at coding the things he learns. Yet it seems to the beginner that he's being prevented from doing this: his books don't tell him enough.

Try to gain information on your machine. It may come from various sources: manufacturer's literature, books, magazine articles, clubs, or examination of other people's programs.

Learn how to use the tools, especially the monitor. Find the best input/output interfaces for your machine. Study the mapping to find safe places to put your programs.

You'll find that all three skills will develop together. You'll learn machine language, machine tools, and machine architecture at the same time. Later you may want to transfer your skills to another machine and may need to learn new tools and architecture. By that time, you'll know enough about the whole machine environment to pick up very quickly.

For the beginner, machine language programming often seems to be an insurmountable obstacle. No single book gives all things needed to make a decent start. But a minimum set of skills can be developed, and after that the path becomes much easier.

An old joke tells of a drunk who falls down an open elevator shaft and then calls back to his friend, "Watch that first step – it's a big one!" The first step in machine language learning is a big one, too, but it sets the stage for unlimited further development – painlessly.