The APS assembler

Assembly Programming System - APS

In order to help with the testing of the simulator, I was writing more and more binary code. The next logical step was to create an APS assembler. The assembler takes code written with mnemonics and simple arithmetic phrases and converts it to the binary code that will run on the machine (simulator).

Of course, every new idea introduced challenges the framework and assumptions of the simulator. On the real computer, you would boot the DOS operating system from a simple load card, and then DOS would take over. DOS included the BIOS (Basic Input Output System) and the mechanism for loading system programs. APS was a system program which processed a text file, normally on punch cards. APS would produce a work file in the "free space" of the system disk. This was a convention share by all of the compilers. Then, you would "insert" the program into the program file on the system disk using a command API (Assembled Program Insert). Only then could you run your program by invoking PRL (Program Load) which would take a program from the program file and load it into main memory and transfer control to the new program. Afterwards, you needed to remove the program from the program file using a command called SDS (System Disk Strip), or you would soon run out of space in the program file.

When I worked for the London Board of Education in 1974, I create a new system program called EXE, short for execute. It replaced the joint API and PRL functions by loading directly from the free space into memory and executing the program. This worked much more efficiently in an education environment where you are running lots of new programs all the time. It also eliminated the problem of collecting old programs in the program file which were not deleted when they should have been. So, the EXE program replaced API, PRL and SDS. I am very proud of the work I did on this. Honeywell provided me with the program listings for API and PRL so that I could understand the formatting of the data in the free space and the nuances of loading the final program. I wish I still had those program listing now!!

This was a lot to implement in one go, so I took some shortcuts in the simulator to assist. I created some fake opcodes to do things in the simulator outside the context of the actual machine instructions. For example, I did not have either DOS or the BIOS to work with, so I created two enabling instructions called LBSS and DOS. I do not know what LBSS stands for, but I believe it is Italian. It handles unit record I/O such as card reading, card punching and line printing. I think, but am not certain, that it also handled disk reads and writes. LBSS in the real computer was a call to the BIOS which included a pointer to a control record which told LBSS what to do. I only scarcely remember the structure of such a thing, but began with the print function.

The new DOS instruction handed control over to a routine that reads cards and looks for system instructions. There are only three system instruction implemented so far: APS, EXE and LOA. LOA is for LOAD, which is used to load an object deck from cards. The LOAD program was not part of the original system software .. I made it up for the simulator so that I could make a human readable load file and get it into memory.

This required that I had to rethink how the simulator would hand off between running in DOS mode (hunting for and executings comands) and  running in emulation mode (executing individual binary instructions one by one). I think that the mechanism I settled on will work, but there is always more testing to do!

For now, there is no support for emulating the disk system, so I created an object in the simulator called FreeSpace, which is simply a load file in card image form. APS fills up the object and EXE loads it into memory and makes the magic happen.

It is entirely possible that no other human on the planet cares about this. I am okay with that, and enjoying every minute I spend on the Computer Room project.

Jim

Comments

Post a Comment

Comments will be visible once moderated

Popular posts from this blog

How it got started

The GE-115 Project When I was in high school in Barrie Ontario Canada in 1968, they installed a new computer called a GE-115. It was a room-sized beast which required several tons of air conditioning. It had an internal cycle time of about 7.5 milliseconds, so it could execute about 100 instructions per second, compared to current standards of several billion instructions per second. It had 12K of internal core memory, compared to my phone which has 32 GB (2 thousand versus 32 billion). I came to love this computer. I learned everything I could about it, including how to program in machine code using a language they called Basic APS (Application Programming System). By the end of high school in 1973, I was a local expert. We met with another high school in Pembrooke Ontario, and I learned from them. Then I went to the University of Waterloo to take Mathematics, majoring in Computer Science. In my first co-op work term, I was hired by Honeywell (who had acquired the computer division of...
Read more

The Student Computer Operator

After Eastview Seondary School in Barrie acquired its GE-115 computer in the summer of 1969, it also acquired an operational problem. Unlike today's computers, this computer did not run itself.  The computer processed individual submissions, one at a time. A student learning to program would prepare their card deck on one of the two IBM 026 manual card punch machines, wrap an elastic band around the deck and add it to the stack of jobs to be run in the metal rack just outside the computer room door. Then, the computer operator had to take that job, put it into the card reader, and process it through the GE-115. Then, the operator would take the resulting printouts and wrap it around the card deck, add an elastic band (we must have gone through a ton of elastic bands!) and return the completed job to the rack. Then, the learner would then have the opportunity to read through their printout, try to figure out what went wrong, fix the problem and re-submit. The turnaround time for thi...
Read more

So much has happened

 It has been a while since I posted. Such is life! This fall I have been poking around with the simulator, adding new features and testing old ones to make sure they still worked. In the meanwhile, some really interesting developments happened. The Computer History Museum digitized two new manuals for the GE-115: The GE-115 Users Guide Reference Manual and Programming the GE-115. I am immensely grateful to everyone at CHM for making this happen. These manuals had a tremendous amount of information in them. The Systems Manual (1965) had a more explicit definition of the APS assembly language, including assembler directives and storage declarations. This manual also clarified some information about binary and decimal arithmetic, particularly around how calculations proceeded when the operands are of different length. It took about a month to fix the simulator up to the point of accurately reflecting the new reality outlined in the Systems Manual. There were a number of interesting re...
Read more