Now I faced a new challenge. It was September of 1979 and I had turned the breadboard over to the software group for about 60% of the time (we still had some hardware testing to do, and to refine our test routines) to begin firmware and software testing. The first week went by, with almost no activity by software. I went to Bill Ellis, I asked him “What’s up”. He gave me an embarrassed look. He was well along with the firmware source code, but Jim Pao was having problems, he could not generate microcode for the B5900! I asked Bill what he was doing about it, and he basically did not have an answer for me. I was in shock. The schedule said they should have just about finished the firmware, and essentially, they had not even generated one word of firmware.
I went to see Jim Pao, he was a smart guy, and many people did not understand him, but I did. I figured out he really did not understand how the B5900 worked internally. So I started a three day marathon session with him, one on one, stepping him though the process of generating control words for the machine. It turned out he actually had a very cleaver compiler but was missing some key elements. Once the missing link was provided, he was able to complete the task. I met with Bill and John McClintock to discuss what had happened, and my concern that the software department was way behind. I found out from Bob Hall that nothing had been done to the MCP or compilers, which all needed modification to meet the new E-mode spec. MCP was written in a special version of Algol called ESPOL. A new MCP compiler was needed for E-mode and it was called NEWP. Bob had told me that no work had been done on NEWP yet. I told John, “Look, you insisted on the E-mode changes for the software department, now you don’t provide the resources to make the changes? If you don’t fix the problem, we will get rid of E-mode and go back to B6900 emulation”. John was taken aback, but he knew I was serious. I was going to deliver the B5900 on time, with his help or not. About a week later John called me into his office and introduced Joan Arnett, a senior programmer and section manager. She was the new B5900 section manager. She had a tiger team of about a dozen programmers to get the software and firmware done. I was pleased, but I was also sad for Bill, obviously he was passed by, and I could not help that I was part of the reason, bringing to light his inability to manager Jim Pao. It talked to Bill about it, and he had no hard feelings. He insisted it was he who went to John and said he did not want to be a manager of a large group. In fact, Bill went back to being a software engineer, and to my knowledge did not take a management position at Burroughs again.
Joan was a tough, experienced manager and programmer. She had a lot of heated discussions with John and Don Swanson regarding the changes they wanted in E-mode. Even though Jim now understood what needed to be done, Joan kept the pressure on him to deliver a compiler that would generate microcode. As a result of Joan’s input, some changes were made to the E-mode plans, but I was not privy to the details. All I did know what that software department had exceeded the 8000 word microcode memory size. Part of the problem was that John had requested several new instructions in E-mode, primarily to improve COBOL performance. The instructions turned out to require a lot more microcode than Bill had estimated. Worse yet, John did not really get the COBOL compiler group to buy into the changes. We had a meeting with the compiler group, and they admitted that the new instructions really would have a minimal impact on performance, and that they did not intent to use them! Software eliminated the COBOL instructions from the microcode and once again it fit in the control store.
Joan’s people began running test cases on the firmware with great results. The software group had made up some of the early schedule slip and the value of the compiler was showing, the firmware was very solid. Joan and I did have some heated words as we tried to control the schedule with limited resources, but we remained friends. By this point logic debug was pretty well done. Once in a while the firmware would do something that caused the hardware to develop unexpected problems, but these were few and were easily fixed. Our biggest challenge would come later.
After Joan’s test routines it was time to turn the machine over to the MCP group. Because the Burroughs MCP was all written in a version of Algol (now called NEWP), they were able to use a unique method of porting the MCP to a new design. The process was as follows; a small hand coded boot loader brought in a small version of the NEWP compiler, which began compiling a full version built into the MCP, that version would then begin compiling the MCP, and at the end of that compilation the MCP would begin executing. At the end of all that, every CPU instruction and function would have been tested, with the exception of maintenance functions.
Bob Hall and his people came in one morning with the MCP source tape and began the process. The machine loaded and executed about two dozen instructions and halted. I had to help them understand how to access the machine because it was unlike any of the earlier machines. We still did not have the Console (we would not have a functioning Console until the first prototype B5900). So my guys would have to load the emulators and show them how to access state. Bob went back and did not appear again for two days. Turns out the E-mode had bit us again. Bob, Joan and John met. There was a misunderstanding on how some fundamental bit definitions in stack control words needed to work. While John was very smart on the theory, Bob knew the practical compromises that had been made through out the years on the B6000/7000 series. After some serious negotiations and a few days of tweaking the firmware and software, Bob was back to try again.
This time the B5900 zipped though about 200,000 lines of code before halting. The delay this time was only a half a day. Late that afternoon Bob returned, Jerry Ragland and I stood by as the B5900 read the entire MCP tape. A few minutes later, the signature MCP SPO display was on the Operator display. The B5900 was up and running! Of course, what was running was a breadboard, not a production prototype; we were still a few weeks away from having the first prototype delivered. But the proof of concept was done. We had several small logic errors to deal with, and performance was not up to spec, but we had time to optimize the firmware and make small design tweaks over the next two weeks.
I had originally planned for breadboard debug to take five months. In the end it took nine. We began releasing schematics for prototype manufacturing in October of 1979. The MCP was up and running by December of 1979 on our breadboard. Our prototypes were due in February 1980.