The Common Console

Now as part of corporate standardization effort they mandated something called the “Common Console”. This was to be a small minicomputer that would do maintenance. The Santa Barbara plant was to develop it. The B6900 was going to use it, as was the B5900. The console was supposed to be done months before we were, but it was not. Bob Leamy and I flew to Santa Barbara to find out what was happening. What was happening was that the console was not a priority at Santa Barbara, and it was far from complete. In fact, Bob and I both felt that it would not work as designed. Bob decided to use a modified version of the B6800 maintenance console. Since the B6900 and B6800 were very similar, only a few modifications would be required. However, the B5900 was nothing like the B6900. We needed to load firmware from floppy disk, but the B6900 did not. The B6900 used switches and lights. We did not have the connections for those, and we needed a terminal, a soft console. Time was growing short, what were we going to do?

Shortly after I came to Mission Viejo I worked on a PDA for a new display terminal. I traveled to Sorrento Valley, CA where Lloyd Cali was working with a small group of bright engineers on a new display terminal design. Up until then, display terminals were designed with hardware logic; this made them fast, but not flexible. The new group was using a brand new technology called the microprocessor to control the display terminal. The Sorrento Valley group was using the Intel 8008, a microprocessor from Intel. Now, almost two years later a bell rang in my head, could we use one of these programmable terminals as a console? I scheduled a visit to Sorrento Valley with Ron Tucker, John McClintock, and Bill Ellis. By now the group had switched to the new and more powerful 8086 microprocessor. They had also developed an operating system and programming language for the terminal. All of us were impressed. Could we use this terminal for our console? We brainstormed at the plant on our requirement. The Common Console required a fast serial interface to the host CPU, and that is what we designed. The display terminal had a serial interface, but it was not fast enough. The display terminal also had an option for a floppy disk, but it also was too slow for us to load the SLC. What to do?

We liked the programmable terminal, but it was not powerful enough for use as a maintenance processor by itself. We decided to design the MIP, or Maintenance Interface Processor. The MIP did all the functions that required high speed. It had its own floppy controller and could read directly from floppy and load directly to the SLC. The MIP could execute comparisons of test vectors from the B5900 directly. So the display terminal attached via its serial interface to the MIP formed our new Common Console. The Display terminal was the “executive”, sending high level commands to the MIP, and formatting responses to display on the screen and interacting with the operator or field service technician. The display terminal/MIP combination in various forms became what the Common Console was supposed to be for the corporation for the next couple of mainframe design iterations. The Santa Barbara Common Console was canceled a few months later.

The problem I had now was who was going to design the MIP? John McClintock found a software engineer, Corinne Robinson, who was really interested in programming the new microprocessor based display terminal, so that was not a problem. We had to go up the corporate ladder to get permission to alter the display ferminal for our use. It was designed by the Terminal Systems Group which “would not support” our non-standard use (although the Sorrento Valley people were chomping at the bit for us to use their product and development tools). After some higher level wrangling the proper permissions were in hand and we “bought” a development station from Sorrento Valley.

But the MIP was hardware, and I was already stretched for hardware designers. A year earlier I befriended one of Bob Kim’s engineers, Bjorn Dahlberg. He was hired to work on the BCML version of the B6900. I immediately took a liking to Bjorn, he was a sharp engineer. Later, my wife Patty and I would begin socializing with Bjorn and his wife, Gloria. Thus began a friendship that unfortunately would end bitterly years later, but that is another story! Once the CTL “backup” version of the B6900 was approved, and Bjorn was left to work on the “main” BCML version, Bjorn figured out he was working on a dead-end project. He had an idea for a product, something called a bit-slice emulator. With his wife’s support he decided to go out on his own, do consulting to pay the bills while developing his bit-slice emulator. One of the things Bjorn worked on while at Burroughs was the maintenance interface for the B6900, so he was familiar with what was required. I called Bjorn and asked if he would be interested in a consulting project to design the MIP. He needed work and was happy to take on the job. The question now was, could I get Erv to approve a consultant to design the MIP? Ron Tucker, Ron Delaura, Bob Kim and I got together to talk it over. They all thought it was a good idea. Ron Delaura and Bob Kim were especially supportive because they felt Bjorn was hired for a bad project without really being given the strait scoop. They went to Erv, and he found the money (I think he took it from the Mission Viejo contribution to the Common Console since we could not use the thing!).

Bjorn was hired as a consultant and he began working with the software engineers on the console. Problem was, it would not be ready for our breadboard! How were we going to begin debug? At MIT I used something called a bit-slice emulator. It was made by a company in Santa Clara and did not work very well. I had discussed this with Bjorn; he had used the same type of product in an earlier design and was not happy with it. He thought he could design a better bit-slice emulator. Bjorn had just finished the design of his first bit-slice emulator before I talked to him about the MIP. He showed it to me, and I was impressed. The emulator allowed us to load and edit the SLC memory directly. It also connected to the data path so we could observe all the registers directly. With some simple modification to our maintaince processor we could access and display any of the serial data and display it. We also added a small LED display register to the DP that would give us a quick readout of any state we deposited in it. So with the bit-slice emulator and some other test tools we could debug almost all of the design before having the console.

In March of 1979, about a year after Erv first gave the go ahead for the ELS, our breadboard prototype arrived from manufacturing. They had done a great job. We had most of our test routines ready, and the debug schedule was set. The first part of the machine that had to be debugged was the maintenance processor along with the test equipment interfaces. We teamed up two engineers at a time, one the designer and the other to assist. Dave Eaves and our Belgian engineer (I have forgotten his name), who designed the maintenance processor, had done a great job of keeping it simple. Within a couple of weeks, the MP was up and running and we could load firmware into the machine. Things went pretty smoothly, with a few major gotchas, like a whole set of memory address signals wired backwards on the SLC! Most of these were simple errors but required extensive and time consuming rework. The debug of each module of the processor went quite well, the real challenge began when we started testing interactions between modules. As expected, there were misunderstandings, errors, and just some bad luck. The changes began to pile up. We had a lot of trouble with the HCP interface to all other parts of the CPU. Cas had made some serious errors. Once again Jerry Ragland came to the rescue. He worked with Cas to get the HCP working properly. One night I came in during my debug shift on the DP to find that the schematic I was working with did not match the design! Although we were using strict design control, a change was put in on top of another. We had lost control. This is the worst thing that can happen during a debug. We had been working 20 hours a day, six days a week. People were getting burned out. The next day I called a meeting and declared a three-day holiday. No debug and the technicians from manufacturing would do a complete verification. Well, it ended up taking two weeks, but in the end, there were only a handful of errors. We had dodged the bullet.

After that, things seemed to pick up, and the debug went well. It was now June 1979, we were about a month behind in our breadboard debug schedule. In a couple of weeks we would be ready to load microcode and begin E-mode debug. Now we had another problem. E-mode microcode was not ready.