Revelations from California

What an exciting development! On Friday, I was able to download the GE-115 System Manual which had been digitized at the Computer History Museum in Mountain View, California. What an amazing document!!! There is a link at the end of this post so that you can read it yourself.

First, I want to express my thanks to Penny and her colleagues at CHM. They are doing great work preserving important aspects of computer history. Without them, this manual and many others would have ended up in a landfill instead of a knowledge-fill. Kudos to everyone! Here is a link to their site: Computer History Museum

My experience of reading this manual was first a sense of deja vu. I had first read this manual, published in 1966, in about 1970. I had poured over it, trying to take in all the detail as I tried to learn how to tame the beast and bend it to my will. (A little overly dramatic there, sorry about that, but that's what it felt like). The nuances of why things worked one way and not another. I was hungry for the information in this book, and now, I was hungry again.

The system manual talks about the architecture, how the processor works with the peripherals through channels, what some of the various buttons and indicators on the control panel do. This was my first big surprise, as my recollection of the CPU control panel was different. I knew there were missing buttons and indicators, such as the Power button, DC fault indicator, etc, but I also discovered there were three different Load buttons, which would load the bootstrap from different peripherals. It makes me wonder if the control panel could be customized by the manufacturer to hook up to different wire pairs.

The manual goes on to describe every different machine code instruction, its opcode and how it was represented in the assembler program, APS. Again, there were differences between my recollection (version 1) of the simulator and the clearly laid out messages in the manual (the soon to be ready version 2 of the simulator). For example, my jump codes were all over the map. I had picked JGT for jump if greater than, but the actual code is JG. Jump is JU (jump unconditional). I was certain the opcode for JRT (jump and return) was 43, but it was in fact 41. (43 is the code for all the conditional jump instructions, using a conditional mask to distinguish be JL, JE, JG, JU, etc. The only opcode I remembered correctly was PER (peripheral operation) at 9E.

Architecturally, I had made the wrong assumptions about how the logic status registers worked. It turns out there are only two status bits. The first bit is ZE/NZ which, informally, is set to 0 is the result of something is 0 and otherwise 1. The second bit is UF/OF which, again informally, is set to 0 if there is an underflow or overflow, and otherwise 1. By combining these two status bits, there are four unique combinations, and three of these are used to communicate the result of a comparison for less, equal or greater. Some situations require four unique combinations, the earlier interpretation of ZE/NZ meaning zero and UF/OF meaning under/overflow goes out the window. It required a bit of study to see how the combinations mapped into the hex masks that are used in the JC (jump on condition .. the mother of all the other jump statements). 

I knew that the JRT (jump and return) put the return address in 254-255, but I did not know that the loader places a jump instruction in 252-253, so that you can simply JU to 252 and it will return from whence it was called. Kind of slick, really. Also, I discovered that the result address of SR/SL (search right and search left) also gets jammed into 254-255. It appears to the be only memory address used by the CPU to store a result, other than those directed by the programmer.

I discovered I had made an error about the order of fields in APS. I had debated with myself a long time, and reluctantly went with a "Cobol" interpretation. In Cobol, you would say "move this into that", so I used that for the APS order, for example MVC (move complete octects) would be "mvc this,that". However, it never seemed quite right to me, as I knew from earlier documents that the result address was always first in the machine code. In fact, the order matches the machine code order, so move this into that, you would code "mvc that,this". 

There were other areas of enlightenment in this manual, including a long list of peripheral operation codes. For example, how to make the printer print a line, advance a single line, a double line, page slew, test for out of paper, etc. This will be really helpful if the simulator evolves to the point of simulating devices. Currently, it just reads and writes files instead of emulating the card reader and printer, and used the system routine LBSS (still using only my recollection of parameters) to read and write lines.

Finally, there was information about the EDT (edit) function which was used to format output using a mask of special characters for zero suppression and a rather complex internal algorithm for making formatting decisions.

I have now made all of the changes in the simulator, with the exception of EDT. However, all of my library of test programs in APS have to be change to the new field order. I will also have to change my approach for testing the various jumps, as the two bit indicator is not compatible with my earlier creation!

So it will take a while to fully test the new virtual machine! After I am confident that the APS is working well, I will update the Fortran compiler. I don't think there is very much to change there.

I have reached out to a few people with this blog and if you are reading this, you are welcome to try it out once it is ready. I am still working out a mechanism for sharing it with others, as it is a desktop Windows application right now, so it may require an installer and certification and other such hoops. I may use FTP in the short term for those who are so inclined. I can be reached at jim (at) paradynamics.com

There is another manual at CHM called the GE-115 User Reference Manual. I can't wait to see what is inside that one!

Here is the link to the manual at the Computer History Museum:

GE-115 System Manual


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