The UX challenge

One of the great challenges for this project is how to represent a room sized computer on the screen. For context, the GE-115 that I first knew was in an air conditioned room about 10 m square. There was a raised floor to allow for cabling to run underneath, so the door opened to a ramp that went up about a foot to the raised floor.

Turning right at the top of the ramp, you would see the computer laid out in a U-shape (the big "U"), and you would be standing at the open spot in the "U". On the left was the line printer. Beside the line printer was the CPU main cabinet, which was also U-shaped (the small "U") with two cabinets extending back (to the left from this perspective). There was also an extension from the CPU to the right, which begins the bottom of the big "U". It was work table height and was flat on top so that you could organize cards, manuals and other things necessary to operate the computer. This work cabinet included the control panel for the CPU. To the right of the work cabinet was the card reader. The right hand side of the big "U" was composed of two disk drives with removable platters.

The operator worked in the middle of the big U most of the time, walking out to the door to get more card decks to run, and to return card decks and printouts to a rack. I also worked at a manufacturing facility which had large trolleys with the production schedule card decks laid out, along with instructions for which disks to load, and what to do with any printouts and punched card decks that were produced.

It is anachronistic to think about the computer operator today. Instead we are computer users. Only a massive amount of simplification of user interfaces has allowed this change to transpire. Back in the day, the operator was central to processing success.

So, returning to my user interface challenge, it occurred to me that most of the time I would, as an operator, load cards, press buttons on the CPU panel, the card reader, the printer and the disk drives to get things done. So I felt that a minimalist interface might convey this best, so version 1 looks like the CPU panel and the card reader panel, Disks are not yet implemented and there is a display below the panels for "printed" output to appear.

The main CPU panel

It had only a few buttons:

  • CLEAR - This button stopped the computer from processing. It was the only way to stop an infinite loop! It also reset the instruction counter to 0, meaning that once resumed, the computer would reload the disk operating system, under normal circumstances.
  • LOAD - This button was pressed after CLEAR in order to load a binary program from a load card into low memory (addresses 0000 to 004F). The card would be loaded before the computer resumed processing at zero, ensuring the new load card would determine what would happen next. Quite often, it was standard procedure to reload the boot card which, in turn would load DOS and the BIOS from disk. (See end notes about the load deck)
  • START - This caused the CPU to start executing at the address in the instruction counter. Normally, this is how everything got running!
  • SINGLE STEP - This caused the CPU to stop after every single instruction. Pressing the START button would execute the next instruction, as long as the SINGLE STEP button was lit.
  • SWITCH 1 and SWITCH 2 - These toggle switches (ON/OFF) were used by the operator to communicate with the program running. The machine code included two instructions (JS1/JS2) for testing whether these switches were set. An example might be that if switch 1 was set, then the data was verified, but did not update anything. Once everything was good, then you might run it again without switch 1 set to do the update.

The main CPU panel also had some indicators

  • As noted above, STEP BY STEP, SWITCH 1 and SWITCH 2 would be lit when on.
  • There was an ALERT button which turned red when a programmer used an instruction (LON/LOFF) in assembler. The interpretation of ALERT depended on the software context.
  • The address of the next instruction was displayed. I believe that it was displayed in binary, but I could be wrong on that. This was the primary way for programmers to communicate to the operators. If a particular problem was encountered, the programmer would put in a halt (HLT) instruction to stop all processing. The address of the next instruction would be displayed, and most programs that communicated this way would have a list of addresses so that the operator could determine what went wrong.
  • That was it for indicators. There was no terminal, no teletype, nor alphanumeric display. Hard to image now how we figured out what was going on!

The card reader was a CRZ100

It had the following buttons on it:

  • READY - After placing a stack of cards (up to 500) into the hopper and placing a weight on top of the pile, you would press the READY button. This meant that there were cards ready to be input.
  • EOF - Since there was a limitation of 500 cards in the reader, end of file was not signalled unless the EOF button was pushed. If EOF was not set, then software would read the entire stack of cards and then wait for more to be loaded. Once the next batch was loaded, the operator would press READY again.

The card reader had the following indicators:

  •  As mentioned above, EOF would be lit when selected
  • There was also an alert light of some kind. I think it was called JAM to indicate a card jam caused by a misfeed or torn cards. You may have been able to press the button to clear the JAM signal.

Simulator implementation

For the CPU panel, all of the switches work the way they would on the machine, with the exception of LOAD. Since we don't have the BIOS or DOS, there is nothing that you can really load. Instead, pressing the LOAD button puts the instructions to start DOS in low memory.

In addition to displaying the next instruction address, I have chosen to display the next instruction, it's op code and parameters. This is very valuable during debugging. I also chose to display the logic status register, which has the results of the last compare (less, equal, greater) and the last logical test (true, false). Note these are independent statuses, so changing one set does not change the other.

For the card reader panel, things are a little different. It doesn't make sense to have a JAM indicator. Also, since we are loading files instead of cards, the EOF switch is not really needed. It is implemented anyway, so you can load multiple files, one after the other. The name of the current file is displayed.

The READY button on the card reader panel causes a file open dialog box to open so that you can select a text file of card images. If the file is successfully loaded, the READY light will turn on.

Next steps

This is a very minimalist user interface, perhaps stark. I am open to ideas about how to improve the user experience. However, it is also true that the process of programming and operating this computer was, at times, a very frustrating activity, given the very limited amount of information on the display panels. A simulator such as this is a balance between authenticity and utility.

Historical notes: The standard load deck

The standard load deck consisted of three cards: a binary bootstrap program on one card, a system check command, and an initialize command.

If memory serves, the cards looked like this:

  1. The binary bootstrap was about 5 or 6 instructions long and started with 9E (the peripheral command) to retract the disk arm to cylinder 0. The second command read the BIOS from sector 0 of the system disk. It checked for successful completion, and halted if there was a hardware error. Then, it would transfer the entry point for DOS that was loaded with BIOS.
  2. The second card was .SYS (I believe). I think that this program simply verified that the disk on spindle 0 contained a program file, which in turn contained all of the other commands that could be called upon. It may also have set some low memory reserved words regarding free space on the drive.
  3. The final card was initialize. It took the form similiar to .INTyyyymmdd . Every day, we had to make a new card to tell the computer what day it was. There was no internal clock.
Without DOS and the BIOS, it does not make sense to put any of this into the simulator.




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