In 1975, the good part about having a computer was that it could do almost anything you can imagine. The bad part is that you had to tell it exactly what to do, and how to do it.
In the early 1970’s. there were no iPhones, no video games, no personal computers, and no microprocessors. In fact, relatively few people had ever seen a computer – let alone used one. If you weren’t in a large business, the government, the military, or a large university it was unlikely that you would have access to or even ever seen a computer. There were mainframe computers (IBM, Sperry, Xerox) and minicomputers (Digital Equipment, Hewlett Packard, Data General, etc).
In the beginning, in order to get a “programmable” computer to do something, a programmer had to write down a sequence of numeric instruction codes (called “machine language”) that the computer understood and then load them into the computer manually through a control panel or an input device (like a Teletype, paper tape reader, or punched card reader). These programs could be hundreds or thousands of instructions long. Every minute step of a program had to be coded in numbers – often in represented in octal (base 7), hexadecimal (base 16), or binary (base 2) and then loaded before it could be “run”.
That process was so time consuming and error prone that computer engineers soon thought – why not create a simpler code for programming that was easier for programmers to remember and recognize, and then have the computer translate it into the numeric codes it needed? This was called an assembler, that performed several translation steps and converted “symbolic code” into “machine code”. There were still the same number of instructions – one for each machine operation, but it was much easier (relatively speaking) for programmers to use these “mnemonic or symbolic programming language” instructions like LDA SLOC for “Load A Register from location SLOC” instead of “B2E8 010F”, the hexadecimal code for the same LDA instruction.
LOC INSTRUCT LABEL OPER ARG COMMENTS 0029 0800 ADDREL ENT 002A 1350 LLA 1 SAVE THE SIGN OF A 002B 3201 002D JOR $+2 AND STICK IT ON BIT 0 002C 0150 IAR 002D BADF 010D EMA RBASE SAVE IT, PICK UP OFFSET 002E 0048 TAX WHICH IS SAVED IN XREG 002F 1350 LLA 1 MAKE IT COMPATIBLE WITH THE OTHER NO.
Above – a snipet of symbolic assembly code (center columns) and its translation to machine code (2nd & 3rd columns on left) from the LAMBDA program loader for the Alpha LSI-2
The mainframe manufacturers had developed “high level languages” – starting with IBM’s development of FORTRAN – to simplify the programming process , and allow the same code to be used on different models and even brands of computers. However, most minicomputers did not have the same resources as mainframes. They were limited in memory, processing power, and external storage devices. As a result, very few minicomputers were programmed in high level languages until several years later when costs decreased. In addition, many minicomputers were used for interactive and “real time” applications like communications controllers or process control systems, test system, or scientific measurement systems and high level languages did not have the performance needed for these applications. That meant most minicomputer programmers used symbolic assembly language.
In later posts we will discuss how to actually program the Computer Automation Alpha LSI-2 minicomputer. However, for now I want to show the newest treasure I have found for the project. It is a good copy of Walter J. Weller’s classic textbook – “Assembly Level Programming for Small Computers” – published in 1975.
Walter Weller’s classic textbook
This book was a popular textbook on assembly language programming – and – it was based on the Computer Automation Alpha 16 and LSI-2 minicomputers. All of the assembly code is written for Alpha computers, and the system architecture discussed is primarily that of the Computer Automation computers. I actually used this book to learn to program my first Alpha minicomputer in the mid-1970’s.
