By Jack A. Allweiss, Copyright 2007

My name is Jack A. Allweiss, also known as "The Father of the B5900 System". I did not give myself that title, my friends and co-workers at Burroughs Corporation did, and I consider it a great honor. This true story is about the B5900, and why it was an important milestone for Burroughs and later Unisys, as well as the computer industry in general.

I have included all the technical details I can without violating Burroughs confidentiality. Since the computer architecture is still in production today,

I was a Burroughs Scholar from 1973 until 1977. During that time I worked as an intern at the Burroughs Plymouth plant near Detroit Michigan which manufactured the L-series accounting mini-computers. Burroughs awarded me a scholarship my senior year at Wayne State University in Detroit, where I received my Bachelor of Science Degree in Electrical Engineering (with distinction).

I was admitted to the Graduate Program at MIT in Cambridge, Mass. In 1974, Burroughs also awarded me a scholarship which helped me pursue my graduate work, I received a Master of Science Degree in Electrical Engineering at MIT, with a minor from the Sloan Business School. After graduating from MIT I worked for the Burroughs Corporation for a little more than five years, from January of 1976 until spring of 1981. I first worked at the Memory Systems plant in Piscataway, New Jersey. After a year I transferred to the Large Systems plant in Mission Viejo, California. The Large Systems plant manufactured the B6000 series mainframe computers.

Today, at the start of the 21^st century, only three mainframe computer architectures survive, the IBM architecture, the Univac architecture, and Burroughs architecture . The IBM architecture, which began with the IBM System 360 in the mid 1960’s survives because it eventually had the largest market share, about 80% of the mainframe market. The Univac architecture survived because it was the very first mainframe computer on the market in the 1950’s. The Burroughs architecture, which had its roots in the B5000 computer introduced in 1960, was not the first mainframe architecture, nor the one with the largest market share, so why did it survive? The reasons are both technical, and political (that is corporate politics). The Burroughs B5900 was critical to the survival of the Burroughs architecture into the 21^st century, and that is why its story is important. There is a component of corporate drama that will be told, not that different from other dramas, but people seem to never get enough of that genre. There is also an important engineering story, one that kept the Burroughs mainframe architecture alive into the 21^st century. Both stories are interesting, and both will be told, and I hope you enjoy both of them.

The B5900 implemented a computer architecture that was embodied in a specification John McClintock and I named "E-Mode". Not a great name, but better than the one that preceded it, which was no name. Yes, it was sort of like Prince in his symbol days, you could describe it, but it did not have a name. The symbols of E-mode were the B6000 and B7000 series large computer systems from Burroughs. John McClintock and I decided it was important to name the architecture of these computers, especially since the underlying hardware of our new computer would be different than anything which preceded it.

E-Mode was the end product of a computer architecture that was first implemented in a machine called the B5000 shipped in 1960. One could describe the B5000 as a stack architecture computer, but it was more than that. The concept of the computer was to implement the Algol procedure oriented language in hardware. In effect the goal was that each construct in Algol would map as closely as possible to one, or a few, machine instructions. The computer would have no "Assembler", or machine language compiler, because the machine language was essentially Algol. This was very different than all other computers of the day. Those computers were primarily programmed in Assembler, or machine language. Compilers for languages like Algol, COBOL, and FORTRAN existed to make end user programming easier, but each construct of those languages would require many machine instructions. Those languages could not be used for operating system programming.

Why was it important that the B5000 was an Algol machine? Because Algol supported many of the programming concepts and constructs that form the basis of general purpose computing, up to and including today’s modern systems. Algol concepts included security (segregation of data and code), procedure oriented programming, object oriented programming, strong typing, reentrant code, multi-treaded operation, multitasking, virtual memory, and much more. You can read more about these concepts in "Organick, Elliott I., "Computer system Organization: The B5700/B6700 Series", Academic Press Inc., New York, 1973".

It all started in 1960 with the Burroughs B5000, but that computer really did not work very well because of hardware implementation problems. Quickly Burroughs came out with the B5500, a much more reliable and much faster implementation. The next machine in the series was the B6500, delivered in about 1968, which also significantly enhanced the instruction set. The B6500, like the first B5000, had reliability problems, and was quickly replaced by the B6700. New technologies led to the B6800 in 1976, a higher performance and lower cost version of the B6700, with a new memory architecture. Following the B6800 was the B6900 first shipped in 1980, which used EPROM state machines to lower the cost further and a new, Universal IO system. The B6900 was the last of the "E-mode" machines that were implemented primarily in hardware.

The Burroughs B5000 was originally produced by the Large Systems group in Pasadena CA. After the B6500 the group moved to Mission Viejo, CA, while Medium systems (based on a decimal architecture) remained in Pasadena. The Burroughs Paoli, PA plant built large, special purpose computers, mostly for the military at the time, but wanted to build commercial machines. In the early 1970’s the B7700 was built by Paoli, and was the first "Very Large System" build by Burroughs as a commercial product, and it was an E-Mode machine, with some modifications. So by the end of the 1970’s Burroughs Large Systems (B6800) and Very Large Systems (B7800) were stack architecture E-mode machines. Medium systems (B2800-4800) were decimal machines, and small systems (B1800) were bit addressable emulators.

When I joined the Mission Viejo plant in 1978 the B6800 was in production. The B6800 was a major improvement over the B6700. It was smaller, faster, sported a new "Global Memory" architecture which really improved multi-processor configurations. Burroughs had a success on its hands, and the Mission Viejo Large Systems Plant was a corporate hero. Next on the schedule for development was the B6900, which was going to ride Moore’s law to higher speeds and better performance, but there was a hitch.

A couple of years before I joined Burroughs, Ray McDonald, the legendary CEO of Burroughs, retired. Ray was the guiding force that propelled Burroughs from a mechanical adding machine company into a digital computer powerhouse. If you look at the companies entering the computer field in the 1950’s, you would not have guessed that after IBM, Burroughs would emerge as the leader. After all, Burroughs was an adding machine company! Electronic giants like RCA, General Electric, Honeywell, Motorola, Philco and a host of others were all in the game. Even though there were a lot of companies in the business, they were all basically copying the UNIVAC design, the register based Von Neumann architecture. Ray felt that Burroughs could not compete by just copying. Burroughs needed something unique, so he encouraged internal engineering competition. Ray believed in competition, even within the company. As a result, several mainframe computer architectures were explored, and in the end three were brought to market, the E-mode B5000, the decimal B2000 (actually beginning with the B220 from Electrodata) series, and the bit addressable B1000 series. None of them were like anything else on the market.

The B2000 series, developed in Pasadena, was an immediate hit. In the early days of computing, mainframes were little more that large, programmable business calculators. They crunched numbers, mostly decimal numbers. Shortly, COBOL became the standard for business computational programming. The B2000 series was to COBOL what the B5000 was to ALGOL. It executed COBOL code almost directly.

After Ray retired Paul Mirabito was chosen as CEO. He was a finance guy. He was really chosen as a caretaker since Ray had not really groomed anyone for the top job. So Burroughs became more cautious, and oriented toward cost savings. Central Engineering in Detroit was given more power. One result of this drive for cost savings was that an edict came down to standardize logic families for all mainframes. The new logic family was BCML "Burroughs Current Mode Logic" (logic is the hardware chips used to build a computer).

A few years before I joined Burroughs the company had purchased a small semiconductor manufacturer in Rancho Bernardo, CA. In the mid-70’s all computer processors were designed using bipolar logic. CMOS (Complementary Metal Oxide Semiconductor) logic, which is the basis for today’s processors, was very slow and not very dense in the mid-70’s.

CTL (Complementary Transistor Logic) and TTL (Transistor-Transistor Logic) were the most popular bipolar logic families in the late sixties and early 70’s. Both logic families had a standard catalog of parts, and multiple vendors, the largest being Texas Instruments and Fairchild Semiconductor. By the early seventies designers needed more performance. TI and Fairchild developed ECL (Emitter Coupled Logic), which really was designed primarily to replace CTL because of power and design complexity issues (the more expensive and faster of the two logic families). TTL would remain the choice for lower cost but more highly integrated designs because it used less power.

By the time the B6900 was to be designed, ECL was a well establish logic family with impressive performance. In fact, as a graduate student at MIT I had used ECL in the design of a signal processing computer, the SSP or "Black Box" (see Allen J., Carroll F.X., Jensen E. "The Black Box, being a small, fast digital processor designed mainly for speech synthesis but nicely suited for myriad other tasks", MIT Internal Document, 1975). Because ECL did not have dense memory components, I used TTL memory, with TTL to ECL converter logic.

One of my first assignments when I reached Mission Viejo, California in 1977 was to work with Ron Tucker, who was section manager for the B6900 BCML project. I did not work for Ron; I worked in a group called System Management. We wrote the Product Development Authorizations (PDA’s) for projects at the plant. Technically speaking, each project at the plant needed to have an approved PDA, which released funding for the project. PDA’s were approved both at the plant level, and then at the corporate level in Detroit. Many PDA’s were routine (i.e. develop a new tape controller interface), but some were politically charged. The B6900 had TWO PDA’s in our group; one defined a project using CTL, the other using BCML. I worked on the BCML PDA; the more experienced System Management engineers were working on the CTL PDA. It became clear to me quickly that the plant did not want to build the B6900 out of BCML. I figured out why working with Ron and Bob Kim, the project manager on the BCML project. Only one computer was built with BCML at the time, the Pasadena B3800. The B3800 used a version of BCML that had a very low level of integration, and that could be air cooled. I visited Pasadena with Ron to find out how things were going with BCML. The information was not good. The machine did not meet its cost goal; in fact it was more than 50% over cost. The machine also did not meet its performance goal. In fact, the machine only offered about a 10% improvement in performance as compared to the B3700, and cost about the same! This is at a time where computer costs were dropping by half, and performance doubling with every new generation. In addition, Pasadena complained that production was highly constrained because several components were in short supply. Since BCML was made only by Burroughs in Rancho Bernardo, there was no second source. Finally failure rate of the machine in the field was higher than anticipated. The B3800 had a lot of problems.

The version of BCML that corporate wanted the 900 series machines to use was different from that used by the B3800. BCML integration was very low because of heat problems that Rancho could not fix. So to allow for higher integration and better performance, they developed BCML 2, which required water cooling! (see "Stopper, H., "The BCML Circuit and Packaging System", IEEE Transactions on Components, Hybrids, and Manufacturing Technology, March 1980, Volume 3, Issue 1 pp110-120.)

I remember accompanying Ron Tucker, Arnold Spielberg, the BCML Program manager based in Mission Viejo, and Ron Delaura, the Engineering Manager at Mission Viejo, to Detroit. We were presented with the new BCML water cooled design by Dr. Stopper and Dr. Johnson, Corporate Engineering VP. I was shocked. The design required an eight to ten layer circuit board sandwiched between a water cooled manifold that the BCML chips popped into. The manifolds were stacked and connected to a water cooling system.

Water was used to cool the largest computers. IBM’s biggest computer was water cooled. These were very expensive computers, and accommodating water cooling added additional expense to the computer room and facility. While very large organizations that needed the maximum computing power were willing to pay for the luxury of water cooling, it was not clear to us that customers who bought the B6900 would be willing to pay for water cooling. In addition eight to ten layer circuit boards were very expensive at that time. The B6800 used four layer boards, and the newer UIO boards were four to six layers.

We came away from that meeting in dismay. Since I was doing the PDA, I was working with all the projected costs. The costs given to me by Detroit seemed way too optimistic, but even with those costs the B6900 would be far more expensive to build than the B6800. When I checked with Pasadena and Rancho Bernardo I got more realistic costs, which made the situation even bleaker.

When I first went to work for Burroughs in 1977 Bob Merrell was general manager of the Mission Viejo plant. By the time I joined Mission Viejo Bob had been promoted to Vice President of the Computer Systems Group (CSG), and Erv Hauck, who was the hardware engineering manager, was promoted to General Manager of Mission Viejo.

The first time I met Bob was in 1974 when I asked Burroughs to pay for my MIT education. The corporate types wanted me to agree to work for Burroughs for two to four years after graduation if I accepted the scholarship. I refused; I told them I would work for them after MIT if they gave me an interesting employment opportunity. They had me meet with Bob, who at that time was working in headquarters. He was a tall, intimidating guy, but I held my ground. He told me that Burroughs might not pay for MIT if I did not agree to the terms; I told him that it did not matter. If Burroughs did not pay someone else would, and it would be Burroughs loss. I guess he was impressed, because about a week later Jim Chambers, then in charge of the Corporate Scholarship program, called me and said I got the scholarship, no strings attached.

The second time I met Bob, and the first time I met Erv was at a meeting between the Memory Systems division (Piscataway, New Jersey Plant) and the Large Systems Group (Mission Viejo, California Plant) to "discuss" the future for semiconductor memory and the B6800.

My first job at Burroughs after I graduated from MIT in 1976 was at the Memory Systems division in Piscataway New Jersey. Piscataway designed and built all the memory for Burroughs computer systems. At the time the transition was being made from core memory to semiconductor memory (DRAM). The first large system semiconductor memory was designed the year before I joined Piscataway for Mission Viejo, and it was a disaster. The original memory for the B6800 was core, and it worked fine. Core was a mature technology, in use since the 50’s. The problem with core was cost; it was a labor and material intensive technology.

Piscataway proposed one of the new, semiconductor (DRAM) memories for the B6800 as a cost reduction program. Mission Viejo accepted the proposal. The first DRAM’s were made by Mostek and Intel (yes, the same Intel that makes the Pentium Processor, got their start in DRAM). The DRAM were 1kilobit chips (as compared to 512Megabits today, and growing!). The DRAM’s worked well, but had a problem called "soft errors". Every once in a while, a bit would flip for no reason (actually the reason was alpha particles). So Piscataway designed and built about a dozen cabinets of this memory, and shipped it to Mission Viejo. Well, the memory controller for the B6800 was designed for core memory, which did not exhibit soft errors, and had no way to deal with them. As a result the memory failed qualification. Then began a round of finger pointing, and shipping memory cabinets back and forth from California to New Jersey. Piscataway did not want to eat the cost of these memories, and Mission Viejo would not accept them. The net result was Mission Viejo was now loath to accept any DRAM proposal from Piscataway, and Piscataway was afraid to propose DRAM to Mission Viejo.

When I came to Piscataway, the Hardware Engineering Manager, Al Parsons, called me into his office. He had a problem Piscataway saw the handwriting on the wall. DRAM was the future, and core memory was going away. But Piscataway needed to convince their biggest customer, Mission Viejo, that they could build a reliable DRAM memory. He asked me if I could work with his top engineer, Reese Brown, a legend in the memory business, on a solution. After studying the history of the first DRAM project, visiting Mostek and Intel, and talking to Burroughs engineers in Mission Viejo, I came up with a solution for the problem.

DRAM was not like core, and if you interfaced it to a mainframe like a core memory, you are going to have problems. That is exactly what Piscataway did in the first design. The cabinet interfaced to the CPU just like a core memory, but it was not a core memory. I proposed that Piscataway design a new memory controller in the cabinet that would take into account the soft error properties of DRAM. While this would increase the cost of the memory a little, it would still be far less expensive (especially with the new 4Kb DRAM chips) than core memory. I was invited to fly to Mission Viejo with the Piscataway Plant General Manager, Al Parsons, and Reese Brown. I was going to give the presentation to Bob Merrill and Erv Hauck. I had met Bob before when he interviewed me for the Burroughs Scholarship, but I had not met Erv. Erv had the reputation for being a very tough guy. He was an ex-marine, was self educated in engineering, and had been involved in the design of several mainframes like the B6500 and B6700.

After I gave my presentation, Bob Merrill asked some tough questions on cost and some of my numbers, but he was not a technical guy. Erv was going to make sure this whipper-snapper from MIT knew what he was talking about, and gave me quite a grilling. I was impressed with his knowledge and common sense. During the discussion between the managers afterward I had the nerve to interrupt, and was put in my place by the Piscataway General Manager. Later, Erv ran into me and made it clear I had clinched the deal for future DRAM memory, from then on we were great friends. He eventually was the Vice President of Engineering for my company, Future Domain until I sold it to Adaptec in 1995.

When I reported my findings on BCML to Erv he was dismayed. He asked Engineering to continue designing the BCML version of the B6900. Shortly after that meeting we all met with Bob Merrell on one of his frequent visits to the Mission Viejo plant. Bob was very concerned; Burroughs needed the B6900 to be a success to compete with the new IBM 370 series mainframes. The decision was made that, at least for a while; a parallel CTL version of the B6900 would also be pursued. So, as a result we had two engineering teams. One was lead by Bob Kim, which worked on the BCML B6900, and the other was under the leadership of Bob Leamy which worked on the CTL version of the B6900.

At this time, Burroughs Corporate Engineering had a mandate, and BCML was the dictated logic family for mainframes. Arnold Spielberg told me that the reason for this decision was that Burroughs management felt the company should be vertically integrated, making as many components of the computer systems as possible.

Bob Merrill and Erv Hauck fought the decision to use only BCML, but it was a battle they were not winning. So the plant expended resources, designing a BCML version of the B6900. Problem abounded, because the BCML logic family was so limited. In many ways, the B6900 BCML was a through back to the B6700, almost all hard logic design. Bob Leamy’s group was looking at using a mixture of CTL and TTL, which had dense memory elements. As a result Bob’s group was moving ahead with more modern design methodology, like using State Machine Architecture. In early 1979 Pasadena was to deliver the first water cooled BCML computer, the B4800. It was a disaster, the cooling system did not work, Rancho Bernardo could not deliver half the parts, and the cost was out of control. Erv flew to Detroit, met with Bob Merrill, and although I was not there, I was told that a very fiery meeting took place with Mirabito, Dr. Johnson, Herb Stopper and others. Erv basically laid down the facts; the B6900 could not be done in BCML in its current state. Burroughs would not have a competitive large system. At that point sales and marketing had a fit, and Mirabito finally pulled the plug on BCML, Mission Viejo could do as it saw fit. The CTL version of the B6900 got the green light.

Bob Leamy had a small crew, his head designer Gary Beck had the machine design in hand, and now the full resources of Mission were at his disposal.

Most of the engineers working on the BCML version were transferred to the CTL version of the B6900, and I had to find something else to do.

After the B6900 BCML ended, I did some PDA’s for small projects, but I ended up with some time on my hands. During the B6900 project I got to know John McClintock, software engineering manager, quite well. I also got to know Erv Hauck better. During one of my "unofficial" meetings with John he said "you know Jack, Erv and Bob always wanted to do a Medium Systems stack machine. They joked about a Data Comm. Processor that executed B6700 code. But they could never pencil out the design. It seems the stack architecture is costly by nature. What do you think about that?" Now Tom knew I came from MIT, and had experience with VLW (very large word) emulators like "The Black Box". I told him I felt the machine could be built! He said well, let’s pitch it.

I put together a presentation call "Entry Level System – ELS" (Allweiss, J. "Entry Level System", internal Burroughs presentation, 1/23/1978). I presented it to Erv, Don Swanson, Software Engineering Manager, and Ron Delaura, Hardware Engineering Manager. The engineering managers were interested and asked a lot of good questions. Erv was mostly quiet. After all was said, Erv asked, "Jack, can you really do this?" I told him yes. He said, "Well, you delivered on the Piscataway Memory, you helped us avoid the BCML disaster, so I’ll bet you will deliver on this".

About a week later, Ron Tucker called me into his office; he said "Jack, you’re working for me now, on the new Data Comm. Processor (DCP) project". I said "Data Comm. Processor?" He winked, "yea, the one you pitched to Erv last week". I smiled, and knew exactly what he meant. Detroit would never approve the ELS. The machine would be a direct competitor to the Pasadena plant products, and Pasadena had a lot of allies in Detroit. If they got wind of this, it would be killed. Erv would bury this under DCP research. So began the development of the Entry Level System, it did not have a model number, because it was not approved by marketing! The computer was known as the ELS for the next year and a half, at which time it would be blessed by marketing and the corporation as…The B5900.

The concept was to build a fully microcoded machine that would emulate the B6000 and B7000 series mainframe architecture. There were slight differences between the B6700, the B6800 and the up coming B6900, not to mention the B7700 and B7800 mainframes. We needed to consolidate the instruction set so that future compatibility would be assured. John McClintock assigned Bill Ellis, a sharp Operating System programmer with a lot of experience porting the MCP from the B6700 to the B6800, and working with Paoli, PA on the B7700 differences. We told John McClintock and Ron Tucker that we needed to be away from the plant to get this done. We could not have any interruption if we were to pull it all together. In early November of 1977 Ron Delaura and Don Swanson gave use the go ahead to work on the ELS (later called the B5900) proposal.

Bill and I spent the next two weeks at his house in Mission Viejo, pounding out a spec for what was to become E-mode and the register level architecture of the ELS, later called the B5900 (from now on I will use the name B5900, although the machine was called the ELS during this period). I had a pretty good idea of what would work well for a VLW emulator, and he knew what was needed to maintain software compatibility. Up until then there were narrative descriptions of the e-mode instruction set, we expanded on those, but we also transformed them into an Algol like description. Actually we used a meta-language to describe the rigorously what the instruction set did. The Algol-APL like meta-language blend would later become the language we actually used to generate the microcode for the B5900.

One of the competitive challenges for the B5900 was that it would be a direct competitor with the Burroughs B3800, which was an excellent COBOL machine. The Mission Viejo software department wanted to add several instructions to E-mode that would allow it to be more efficient at executing COBOL. Bill and I had several meetings with compiler writers, including Bob Hall who was a senior compiler writer who worked on COBOL. The net result was we added some new instructions to help the B5900 execute COBOL.

When Bill Ellis and I returned to the plant in December 1977, we presented the E-mode specification and B5900 hardware architecture to Ron Tucker and John McClintock. They loved it, Ron for the simple, elegant design of the hardware, John for the first clear description of the stack architecture. Together these documents would form the basis for all future hardware and firmware implementations of the Burroughs large systems. After design reviews in both the hardware and software departments, the spec’s were signed off.

I worked on the Entry Level System presentation, which was presented to Erv at the end of January 1978. After Erv’s approval, I wrote the first PDA for the ELS (B5900) which I completed at the beginning of March, 1978 (Allweiss, J. "Entry Level System PDA", internal Burroughs document, 3/3/1978). Since we knew this PDA could not be approved by Detroit, it was approved internal to the Mission Viejo plant. The PDA called for design to begin in March of 1978, and complete by December 1978. I originally proposed that the first ELS B5900 would ship in December of 1979, but Erv said funding would not be available for that, and it conflicted with the B6900 schedule. The first ship date was pushed back to second quarter 1980. It was time to get to work.

Bill’s group would develop a compiler that would transform the meta-language descriptions in E-mode to actual VLW instructions that ran on the B5900 hardware. Bill would use the compiler to generate the E-mode microcode.

My group would design the hardware. Ron made me a section manager, and gave me four engineers, Dave Matty, Cas Pencak, Dave Eaves, and Al Regalado. It was now June of 1978.

The first rule we had to follow was that, to Burroughs Corporate, we were a Data Comm. Processor (DCP). This was a stealth project, if Corporate in Detroit (or Pasadena) found out about it, we were sunk. The DCP was part of the IO subsystem, so we had to use IO subsystem components and logic. I would have preferred to build the B5900 out of ECL logic, but, as I described earlier, that would not be in the cards. ECL was a competitor to BCML, and no competition of that type was allowed. All logic used at Burroughs had to be qualified by the components group. They were responsible for making sure the logic was suitable for Burroughs, that it had multiple sources, and was available from approved vendors.

I used ECL for the Black Box at MIT, and using it on the B5900 would have resulted in a processor that was about twice as fast as the final product we produced, for about 25% higher cost. A good tradeoff, but one what was not politically acceptable. We could use TTL, because that was what the IO group was using. TTL was approved by the corporation. The IO group had a standard logic card design and backplane design. While I would have preferred a different packaging scheme, there was no way for us to fund one. Erv told us we could design using IO subsystem components, circuit boards, and backplanes, or forget the project. The circuits group and I were concerned if the design of the UIO (Universal IO) circuit boards and backplane could support a computer. UIO circuit boards were about 14"x12", with a 194 pin backplane connector and four 48 pin frontplane connectors. The B5900 would be 14 boards, most UIO controllers were a single board, some were two or three. Most high speed data traffic was on the UIO boards themselves, we would be running several high speed data busses on the backplane between the 14 boards. These were unanswered questions, and were concerns, but we decided to proceed and deal with them later, which would cost us at the end of the project. Luckily by then we could afford the cost.

Next we had to write a detail design specification. The B5900 design was to be modular; the specification defined what each module did, and how it interfaced to the others. I partitioned the design into the Data Processor (DP) (which I designed), the Program Controller (PC) which Dave Matty designed, the Storage Level Controller (SLC) which Al Regalato designed, the Host Control Processor (HCP) which Cas Pencak designed, the Memory Controller (MC) which Bob Olson at Piscataway designed, and the Maintenance Processor (MP) which Dave Eaves designed.

The core of the B5900 design was the DP-SLC complex, which I modeled after the "Black Box", the signal processing computer I worked on for my thesis at MIT. The Black Box was a VLW (Very Large Word) processor with a hardware FFT (Fast Fourier Transform) unit and fast local memory. The Black Box processor was designed to interface to a DEC PDP-9 mini-computer, which would feed it high level signal processing operation codes (Op Codes) and data to execute. The Black Box had a control store that was loaded from the PDP-9 which implemented the instruction set.

The B5900 worked in a very similar way to the Black Box but was not tied to another computer to obtain its Op Codes. The Program Controller (or PC) was designed to parse the E-mode instructions directly from main memory. The PC would then present the SLC with an entry point to the VLW microcode routine in its memory which corresponded with the desired E-mode instruction. If there were constants or operators with the instruction, the PC would parse those and make them available to the SLC in a standard format. The PC was really the only thing left of the old hardware decode used in the B6XXX series mainframes.

I originally did not pick the name Stored Logic Controller (SLC) for the processor. I picked Microcode Processor. Erv and Ron did not like that name. They were concerned the field support force would be confused. They did not understand the concept of VLW emulation, but the B6800 and B6900 used PROM logic to emulated gates and flip-flops of the B6700. Those computers had a module called the Stored Logic Controller. Now our SLC used static RAM. When the B5900 was powered up the maintenance console read the microcode from a 8" floppy disk, and loaded it via the MP into the SLC RAM. If the B5900 lost power, the RAM had to be reloaded; the machine was completely useless without the microcode. Our SLC was actually a computer, not a simple PROM driven state machine, but I agreed with the name change.

I decided to construct the prototype of the B5900 using what was called a wirewrap breadboard. That was a common technique used in those days to design new computer architectures. The Black Box at MIT was designed as a wirewrap because of the speed and flexibility wirewrap provided. The concept was simple, each IC in the design was placed in a socket on a circuit board that was physically the same as the final design, except instead of the pins being connected by circuit etchings on the surface of the circuit board, they were wired to each other via thin, insulated wires. Each socket had a pin that extended out the back of the circuit board about an inch long. The pins actually had a square, not round, profile. A person or machine wrapped the bare end of the wire around the pin, and the other end around the proper pin somewhere else on the circuit board, completing the circuit. If a logic error were found in the design, it could be corrected easily. The offending connection was either cut or removed, and a new connection made. Of course extensive logic errors required more extensive rework, sometimes reworking an entire board. The drawback of a breadboard is that it is not electrically identical to the final design. In the final design the circuit boards would be etched with traces that connected the pins and wires would not be used. Wires and circuit traces have different electrical characteristics. Signals may travel either faster or slower, and you can have something called "crosstalk", where a signal carried on one trace can radiate into one close by. By the time the B5900 was designed, software programs called simulators were pretty good. Engineers began skipping the breadboard phase and going directly to printed circuits. Errors in design could still creep in, but these were usually fixed with some simple cuts and/or jumper wires. The circuit board with the error could then be "turned", incorporating the fix before, or shortly after production began (the first several machines may have had these manual fixes). The CTL B6900 was being done this way.

There were really three pragmatic reasons I decided to use wirewrap for the first B5900. As I stated earlier, totally new computer architectures often were prototyped. While the B5900 VLW design was not new to me, it was to Burroughs Mission Viejo, and I felt that if anything were missed, it would be easier to fix. The second was resources; the circuit board group was quite busy designing new circuit boards for the UIO group and the B6900. The UIO circuit board was much larger than those that proceeded it (for example, the B6900 circuit boards were about 4"x5"). Boards were routed using special design automation software that figured out how to connect all the pins, running one UIO board might take 24 hours or more, and sometimes the route failed and the IC’s would have to be repositioned and the routing tried again. I met with the design automation supervisor and he gave me the skinny, "Jack, we have several hundred B6900 cards to design and route, and we have a lot of UIO work, which is giving us a problem, you submit one of your Data Comm. boards and maybe we can get to it in a month or two, or maybe three?" As an unfunded project, we were the last in the queue, and the queue was pretty long at that time. Finally there was cost, UIO boards were costly to design for the same reasons as above, and we had a very small budget, only $240,000 for the first year.

However, manufacturing’s wirewrap department, whose use was declining in the plant, had an excess of capacity. Wirewrap was used not only for prototypes, but for backplanes, the rows of connectors circuit boards plug into. At this time wirewrap was the main way of wiring backplanes, and manufacturing had large, "Gardner Denver" automated wirewrap machines to wire the backplanes. Early machines, like the B6500 and B6700 had thousands of small circuit cards plugged into several backplanes, so there was a lot of wirewrap work in manufacturing. The B6800 uses about half the number of cards, because the logic was much denser. Instead of a single flip-flop on an IC, you now had four. The B6900 would use even fewer cards because stored logic was much denser. UIO did not use wirewrap at all; it used the modern method of an etched bus backplane. So the factory people were looking for things to do. I went and talked to them about doing the B5900 breadboard, and they were willing to do if for a bargain price. Erv was not totally happy we were going to breadboard the B5900, but he also realized that was about the only way we were going to get one built.

At that time Burroughs still did not have design automation for engineers. Graphic workstations were expensive, and were in the Design Automation department under Palmer. Design consisted of getting large (B size, 11x14) pieces of paper, and preprinted stick on logic representations of the IC’s, gates, and flip-flops. The engineers stuck them on and drew the connections with pencil. The page then went to design automation where a technician digitized the page. The digitized image was then printed, and from the image a netlist (list of circuit connections) was generated. From that netlist a wirewrap instruction tape could be generated to wire the board.

Because the design automation tools for generating schematics was cumbersome and non-intuitive, I first had each engineer do a block diagram of their part of the B5900. The block diagram is a high level depiction of the design. For example, the B5900 had thirteen 2901 chips, but functionally they formed a single block, the data path. We used block diagrams to "debug" the specification for the machine. This also pointed out where there were problems. I had two major kinds of problems, some were logic, but the more serious was the ability of my designers.

Management did not give me the cream of the engineering crop. They felt (and rightly so) that the future of the plant was tied to the B6900, and they wanted the best, most experienced CPU designers on that project. So who did I get? New hires who were not proven, older guys who might be a little slower than Bob Leamy or Gary Beck wanted. Cas Pencak’s Input/Output controller, or HCP, was my first problem child. Cas was a new hire with a good resume in the circuits area, not CPU design. The B6900 group had an overabundance of circuits’ guys, so they gave me Cas. Cas’ first block diagram had some serious problems. Cas decided to implement the HCP with discrete logic. As a result he was well over his budget for circuit cards, which was two. On the other hand Dave Matty, also a new hire, had developed a very innovative state machine design for the PC, which resulted in a single card design. I asked Cas to work with Dave for a new HCP design. Cas was upset, and was a bit defensive, but I told him that my only goal was a design that would work and meet our cost and performance goals. If he wanted to work on my team he had to be willing to do whatever it took, including working with a new hire who had some innovative ideas.

I had other design challenges with the team, but I was able to get the engineers to work together to buttress weaknesses while exploiting strengths. However, I could tell my team was suffering from somewhat of an inferiority complex because the plant was focused on the B6900. Bill Ellis, who headed up the E-mode firmware development team (which was smaller), was having the same problem. I got together will Bill and I suggested we have the next design review at the Aliso Creek golf club, a beautiful setting down in Laguna Beach. Now off site design reviews were common, usually at the local Holiday Inn, not in Laguna Beach. I thought a nicer setting would boost the moral of the B5900 troops. Bill Elis agreed, but was skeptical it would be approved. I called Aliso Creek, and negotiated a good conference rate, not much more that the Holiday Inn. Then I went to go see Erv. Now Erv was known as a tough, no nonsense guy, so anyone who knew my plan expected it to be rejected by Erv. They were wrong. Erv approved it without question. Later he told me he knew what I was trying to do, improve the moral of my team, and he thought it was a great idea.

The Aliso Creek design meeting was a great success; we solved a lot of problems and finalized the way the firmware, software, and hardware groups would work together.

After that meeting my engineers dove into the detail design process. We had 14 large circuit cards to design in a little over three months. I was the section manager for the B5900, and usually managers did not do detail logic design. But I was under staffed, so I designed the DP. Ron Tucker and Ron Delaura both talked to me about doing the design. Their point was I should not be doing it. I needed to concentrate on management. I told them both the same thing; without more engineers we would not make the schedule. I would work late in the afternoon and evening on the DP. Since it was similar to what I had done at MIT I could develop it quickly. Finally, being in the middle of the actual design I could detect problems with the other designers more quickly and head them off. They relented and I designed the DP.

About two months into the design process I could see Dave Matty was struggling. I talked to him about it, and it became clear to me that, while he was an innovative designer, he did not have the practical implementation experience some of the other engineers did. He was having trouble translating a really clever design into an actual implementation in hardware. A couple weeks later, in early October 1978, Dave came into my office to tell me he was quitting Burroughs to go back to school starting January 1979 to get his masters degree. I was in shock. I told Dave that we were in the middle of the design, and needed him. Dave said he was basically done, and just transcribing the design for the Design Automation group, but I knew that was not completely true. Dave had run into several roadblocks, he was beginning to panic, could he finish this design? He had an opportunity to go to graduate school on a scholarship, so I think he took the path of least resistance.

I went to Ron Tucker and told him the bad news. I told him that it would be risky to bring in a new hire to replace Dave, I needed an experienced CPU designer. Not only that, we were behind schedule in several other areas. I needed to replace Dave, and I needed at least one more engineer on top of that. I told him that even with additional help, we would slip the schedule at least one quarter. Our breadboard would now be delayed until March of 1979.

Just a few weeks before, one of the B6900 engineers, Jerry Ragland, told me how much he admired what we were doing. Jerry had worked on the B6800, and felt they were not doing enough innovation on the B6900; he wanted more of a challenge. It so happened that Jerry was an opinionated guy, so Bob Leamy and Gary Beck considered him "difficult to manage". I knew this, and intended to exploit it. I talked to Ron Tucker, and told him I wanted Jerry on my team. Ron had heard from Bob and Gary that Jerry was hard to manage, I said "good, managing is something I can do, what I need is an experienced engineer to replace Dave, I can’t do that since I am already stretched thin designing the DP". Well, Ron met with Bob and Gary and they agreed to give me Jerry.

One of the first problems I had with Jerry was his attitude. Since he came from the B6900 group he felt superior to my other engineers. I straightened him out very quickly. After work the first day I took him out to dinner, I told him, "Look Jerry, I know you are the most experience CPU designer on my team, but we are a team. I have a Masters from MIT, and am a lot smarter than you, or anyone on the team, but that is the last time you will ever hear that. We are a team, we succeed together or fail together, so there is no room for attitude". I never had a problem with Jerry after that dinner.

I put Jerry on the PC to finish up Dave’s design. After a couple of days he came to see me. He said "Jack, Dave is a clever architect, but not a logic designer, his implementation will never work, I need to start over". I was dumbfounded; I asked if he was sure? He told me to review some specific design areas and see what I felt. I took a day to look at the logic Jerry had questioned, and found he was right. I asked him the impact. Jerry said the basic architecture was fine, in fact inspired. The problem was mostly implementation. He felt he could straighten it out in two months. He actually finished in six weeks, costing us only one and a half additional months in the schedule. I was very glad to have Jerry on board; he would rescue us with his experience many times. Ron also arranged for me to add a couple of other engineers, Lee Watson and Mike Lithgow, which really helped get the design completed.

I have mentioned schedule a couple of times. Schedule in technology projects is critical. If you are building a house and are six months late, you may have some angry customers, but the house is still valuable and you can still sell it. In technology, if you miss a schedule by six months, you might as well cancel the project. No one wants it since newer and better computers are now available.

At the time of the B5900 the conventional wisdom was a new CPU required at least two years to design, in fact most schedules were 30 months. The B6900 was a 26 month schedule, considered aggressive (Bob Leamy actually beat the schedule, delivering in 24 months). I felt we could do better, I proposed a 16 month schedule for the B5900, which Erv made me pad out to 18 months. Since the B6900 was started about 6 months before the B5900, the shorter schedule meant the B5900 would be available about the same time as the B6900, which was desirable from a sales and marketing standpoint. If the B5900 slipped by to many months, it would not be as desirable. By the end of the design phase, we had slipped the schedule to 18 months, or the middle of 1980.

Once all the design schematics were in to Design Automation department (DA), it was time for another major design review using the "final" schematics. We would look for any last minute corrections, assess the status of the firmware and software, and design on our debug strategy. I knew that this was the lull before the "storm" of debug. Now the B6900 group was well funded, so they built three prototype CPU’s. This would allow them to debug on two, while the third was being reworked up to the latest logic level. We did not have that luxury. We would have one B5900 breadboard. So I had to schedule debug around the clock, which would mean my engineers would have to work in the middle of the night. The schedule was two 10 hour shifts, with one hour overlap, and two hours for rework, six days a week. The shifts were 5AM until 1PM, rework from 1PM until 3PM, and 3PM until 2AM.

So I wanted to really build up the troops, I decided to pitch the design review for Alta, Utah in January of 1979. Bill Ellis really thought I had gone nuts. No way the Erv was going to approve a three day ski design review! I informed Ron Tucker and John McClintock. They just smiled. I went to Erv with the details, he told me he had to think about it. I mentioned to him jokingly, "Erv, Piscataway is designing the B5900 memory controller, it’s only fair that we meet Ken Jensen and Bob Olson half way, and Utah is about half way between California and New Jersey!" Erv laughed. He knew the B6900 team had the luxury accommodations, three prototypes, the large lab, no late night schedule. He decided to indulge me. He approved the design review!

I remember that Bob Leamy and Gary Beck were angry. Gary told me he did not think it was fair that I got the trip to Alta. I said, "Gary, how can you complain? I am asking my engineers to work until 2AM. we have to do much of our own rework, and we have only a single prototype". He understood, but was still not happy.

We had a great design review, but mostly just had a lot of fun. The trip cemented a camaraderie between all the engineers and programmers that lasted though the project.

After our return the engineers began developing their test routines, or vectors. At that time the way machines were debugged was using test vectors. You loaded the flip-flops in the machine via a maintenance path, issued system clock, and verified if the state was as expected. While the B5900 had a lot of logic, it also had a lot of RAM in the processor itself. The DP had RAM, and the SLC was almost completely RAM. This required a totally different method of test. In the DP for example the proper way to test was to load short microcode sequences in the SLC and execute a command, then check the result. In order to load test vectors and microcode we needed a maintaince interface.

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 brand new 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 chip. 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 to 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. 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 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, so that was not a problem. We had to go up the corporate ladder to get permission to alter the Display Terminal 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.

Of course I regularly reported our progress to Ron Tucker, and informally to John McClintock. Tom told me we might have to slip the schedule because e-mode required some changes to the MCP. Because the software group wanted to fix some flaws in E-mode for all future machines, they decided the right point to make the changes was with the B5900. Since the B5900 was not really funded, getting MCP programmers assigned to make the changes was harder than originally thought. We met with Bob Hall, who was in charge of MCP development. It looked like we were facing a two to three month schedule slip. Don Swanson, the software engineering manager, was a big supporter of E-mode and the B5900. He told us he would do everything in his power to avoid the schedule slip, but in short order it turned out he would not have to. The trend in data processing and distributed processing was about to go our way.

Midland Bank UK had been a Burroughs customer for a very long time, since the original B5500. They liked Burroughs equipment, as did many banks, for its ease of use, performance, security, and accuracy. Midland like many banks was organized around the large central Information Technology center. Because of this they continued to buy bigger and bigger mainframes. They ordered B6700’s when they were available, and B7700’s, and B7800’s when they became available. However, a new trend in computing was in motion. Banks began to decentralize processing, instead of one large data center, they wanted several data centers, connected by high speed data links. Midland would still have the large central data center, but they wanted thirty smaller processing centers around the country.

Midlands went to Burroughs for a proposal. Based on the processing and cost requirements, Burroughs proposed the B7800 for the central system, and thirty B3800 (two per) for the fifteen satellite centers. Midlands rejected the bid. They wanted all the machines to be software compatible. Midland had written a lot of programs for their B5000/6000/7000 machines over the years, and they wanted them to work at every center. First Burroughs proposed to help Midland convert some of the software to work on the medium systems, but Midlands would not hear of it. IBM offered code compatibility in there new IBM 370 series, and they were telling all DP managers that what ever vendor they chose should be able to do the same. Burroughs could not, or could they?

Sales and Marketing were at there wit’s end. They came to Mission Viejo. The B6900 was too expensive to meet the Midland requirements for the satellite data centers. Could Mission somehow reduce the cost? I was called into a meeting with the VP of Sales and Marketing, Bob Merrell, and Bob Johnson, VP of Corporate Development, I presented the B5900. The people from Headquarters were stunned; it was exactly what they needed for Midland. It met Midland’s cost and performance requirements, and most importantly it was code compatible with the B7700 and B6800’s they already owned, and the new B7800 they were installing. The question was schedule; Midlands needed the machine in nine months. How soon could I deliver? I told them we had a breadboard that was functional at the hardware level, but did not have the budget to complete the project. The VP of Sales told me, "young man, as of today you have whatever budget you need, just ask". Now Bob Merrill and Erv tempered that statement, but basically said the same thing. Now, the B5900 was going mainstream. I began reworking the schedule based on having all the resources needed. It looked like we could complete the project in 9 months, or the third quarter of 1980. That schedule worked for Midland. One of the keys to meeting the schedule was to begin development of the final prototype (the machine using etched circuit boards instead of wire wrap) right now, before the firmware was tested and the computer was fully operational. The risk was that some major design changes would not be caught requiring extensive rework of the prototype. The reward was we would have an actual implementation of the CPU, not a breadboard. I requested five more engineers, effectively doubling our staff from five to ten. The big growth however was on the software side. The software department, while supporting the B5900 and E-mode, were skeptical, and like most software departments, they had more on their plate then they could handle.

Bill Ellis was in charge of the B5900 software development. He was given one other engineer, so while we started with four on the hardware side, only two were working on the software side, and one of them was writing a microcode compiler, and there was more software work to do than hardware work for the B5900. Now the microcode compiler was a bone of contention between me and the software group. The B5900 could store only 8000 microcode instructions in its fast static RAM. Fast static RAM was expensive, so it was important to have just enough of it, but not to much. During the time Bill and I worked on the E-mode spec I estimated the number of microcode words needed to implement E-mode. While we did not have a final design at that time, we understood what functions the B5900 could do, and about how many instructions we might need. As the design progressed we revisited our estimates. We felt E-mode could be implemented in 6500 to 7000 control words, so a 8000 word control store would leave us enough leeway for any miscalculations. When Bill and I worked on the initial specification, we used what was called a "meta language" to describe E-mode. The language could be compared to Algol, Java, or C# in being a recursive and reentrant block structure language. After the design concept was approved, I met with John and Bill to discuss how the firmware was going to be developed. Usually, the hardware department developed "Stored Logic", but since the stored logic for the B5900 was more of a programming task than a logic task, the software department wanted to do it, and John was especially interested in having software do the firmware. He saw that the firmware would be the key to compatibility and performance for all future machines. Developing the MCP along with the firmware in the same department would give Burroughs a great advantage.

The software department presented their plan to me. Write a compiler and a simulator that would take something very close to the meta language (called "e" by the software people) and compile it into the VLW instructions of the B5900. I was skeptical and concerned from the beginning. The normal procedure for VLW machines at that time was to hand code the firmware, using a simple assembler. On the Black Box at MIT I used MASM, a public domain assembler designed to generate VLW code after describing the design to MASM. My proposal was to do the same with the B5900. I had several concerns. First, the extra time to write a compiler and simulator from scratch. Second, would the compiler be efficient? Compilers in general were more liberal with the amount of code they used to generate a language statement. With lots of RAM and disk that was not a problem, but for a fixed size microcode store it was a big problem. If E-mode did not fit in the B5900 SLC, there was nothing we could do. Third, I was concerned with the software engineer they picked to write the compiler, Jim Pao. He was probably the most brilliant software engineer in Mission Viejo, but he was also the most temperamental and difficult to deal with. I argued with John and Bill, but they were adamant that we should use the compiler. I relented, but had a backup strategy in my head. We would use MASM for generating the engineering diagnostic code that was loaded in the SLC during debug phase. This would get my engineers comfortable with MASM. If the software group failed, I would have a backup; my engineers would code e-mode using MASM.

After Midland Bank visited Mission Viejo, the existence of the B5900 became known and quite high profile. Pasadena, which had pitched the B3800, was furious. They began a campaign to kill the B5900, arguing the customer should just accept the B3800. But sales made it very clear, Midland would dump Burroughs and go to IBM, which was pitching the 370/145 as the mid size system and 370/185 as the large system. Pasadena was sent home, but in a few months they would be fighting a new battle, now to try to keep the Medium Systems architecture alive, and their plant open.

When the B5900 was officially approved and fast tracked, it was not all good news. I had been the manager for the project, but now it was high profile. Erv had several other engineers with more experience, especially management experience, than I had. The thought went through my head, would I be replaced? Or would they simply put someone above me with more experience. I got my answer shortly after. Ron Delaura and Ron Tucker called me into there office. Ron Delaura was Hardware Engineering Department Manager, Ron Tucker was B6900 BCML Large System Engineering manager, Bob Leamy was B6900 CTL Large System engineering manager. The B5900 was put under Ron Tucker, with me as B5900 section manager. Bob Kim was B6900 CPU section manager, and Gary Beck was B6900 CPU section manager. The plan was to create a new, Small Systems Engineering group. The Ron’s gave me the news, and I was surprised and pleased, I would be the new B5900 Small Systems Engineering manager! Shortly after that, Ron Delaura left Burroughs and Ron Tucker became Hardware Engineering Manager, Bob Kim was moved under Bob Leamy and was reassigned to a new project. The B6900 BCML was finally put out of its misery.

Now it was full steam ahead, but there was another train on the tracks, the B6900. The B6900 schedule had slipped a little, and they were in the final throws of debugging the prototypes and getting the machine into production. Just at the time we wanted to start routing our circuit boards, the DA group was flooded with work to design the final production boards for the B6900. What were we going to do? It looked like a two or three month delay, however I had a solution. The B5900 used the new UIO boards, and several plants used UIO boards now. I was able to buy DA time from Pasadena (of all places) to get our boards done! We also had some work done for us in Santa Barbara, and since they were losing business to other plants, the Mission Viejo plant DA department found some extra capacity, so they could route several boards for us. It was tough, but we were able to get our boards done.

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. Thus 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 e-mode spec. 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 was over in microcode 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 instructions from the microcode and once again we 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 Algol, 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 ESBOL 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 until the first prototype). 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 pre-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 more 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.

Shortly after the New Year Bjorn Dahlberg delivered the MIP. Corinne Robinson and Dave Yonamine were making good progress on the Display Terminal software, and now he had help since the Midland meeting. Bjorn worked directly with the Corinne and Dave debugging the MIP/Display Console in our lab, but we were only a week away from having the first prototype, so we decided not to hook the Console up to the Breadboard, as it was being used extensively by software engineering. We wanted them to catch up on the schedule.

On a Monday morning at the end of January of 1980 the first two B5900 prototypes built by manufacturing were wheeled into our lab. There was great anticipation. The first thing was to connect the Display Terminal/MIP to the machine and begin debugging the maintenance path. A few problems were found, but Dave Eaves and Al Regalato made quick work of it. I remember Bjorn only had to come in for a day or so, and all was functioning. We began to load test vectors. A couple of days later Jerry came into my office with a serious look on his face. He said, "Jack, we have a problem. The flip-flop level testing seems to work fine, but the microcoded register level tests do not seem to work reliably. They may pass one test, and then fail the next. A register level test was a simple test of the 2901 data path. For example, the firmware would load the number 1 in register 1, and the number 2 in register 2, and then add the registers to get the number 3 in register 1. Sometimes this would work, and sometimes it would not. These tests worked flawlessly on the breadboard. So what was the problem? As the designer of the DP, I was called to debug again. Jerry and I worked together. My thought was the problem had something to do with either timing, or noise (sometimes called crosstalk) of the signals. The 2901 was self contained, so the error could not be there. We looked at the signals feeding the 2901. What we saw was that the command bits to the 2901 would change part way through the clock cycle. What started out as an ADD instruction changed to a SUBTRACT for a brief time, and then back to an ADD. Depending on the timing, the 2901 might execute the ADD, or the SUBTRACT, giving the answer 1, instead of 3.

Now we knew what was happening, but the question was why? We began tracing the signals back to their source. The instruction to the 2901 came from the SLC. The SLC consisted of the microcode memory and sequencer, and a 30 bit command register. The instruction came out of the SLC memory and was clocked into a 30 bit register at the beginning of the machine cycle. The register drove the 30 bit C (or command) bus on the backplane that went to every card. The DP interpreted the commands directed to it.

We checked the SLC, and it worked flawlessly, the right command was in the C register. We traced the signal and found the problem. The breadboard used wires to transmit the signals to the edge connector that plugged into the backplane. The prototype used circuit etching. The breadboard wire resistance was much lower than the prototypes, and very close to that of the backplane. On the other hand, the resistance of the circuit etch was much higher than the backplane. When the signal hit the backplane connector, part of it bounced back, causing a reflection. The reflection is what caused the signal disturbance as it propagated across the backplane to the DP. How were we going to fix this? Basically, nothing in the B5900 prototype worked because all the C bus commands to the different parts of the machine were corrupted.

I called an emergency meeting with the circuit’s engineers. They spent a couple of weeks observing and measuring, and confirmed what Jerry and I found. They explained that the UIO used much slower bus speeds than the B5900. We exceeded the design specs for the hardware we were using, one of the tradeoffs of not having an approved project. They suggested we insert something called a ground plane in the circuit boards under the edge connectors. This was a minor change since the boards already had a ground plane under the IC’s and main part of the circuit board. They also suggested some changes to the signal routing and etch size on the backplane. I asked them is this would guarantee reliable operation? They said no, they could not guarantee that the design would be reliable without a complete redesign of the edge connector/backplane interface. I was dumbfounded; such a change would take almost a year. We needed another solution.

The design concept of putting the C register on the microcode store was the same I used on the Black Box at MIT, and it worked well. The MIT computer used ECL, which used a low voltage (.7v) swing and a terminated transmission line for signals longer than a couple of inches. With ECL noise was rarely a problem, even at very high speeds. The B5900 was designed with TTL, which had a very large voltage swing (3.7v) and no transmission line termination. To make matters worse, we used high speed drivers for the backplane which tended to make the noise problem worse. I needed a solution that would have minimum impact on the schedule. I brainstormed with the guys for a couple of days, but no one had a solution. That evening I thought about the problem, what if we move the C register to each of the cards that interface to the C bus. In the current design, the backplane must remain noise free for about 150ns of the 180ns clock cycle. If I move the register to the logic board, the C bus need only be stable for about 10ns, long enough to register it. I penciled out the design change, and it seemed to be a solution to our problem. But the B5900 circuit cards were pretty full of logic. Where would we get the room for the register. Turned out that the TTL logic family, which caused us this problem, would also present the solution. We used an eight bit buffer chip to control the loading off the C bus. Each card that took commands from the bus had to buffer them first. Turned out the TTL logic family had an eight bit register in exactly the same pin configuration. The register on the SLC would be replaced with a driver chip, and the buffer chips on the logic cards would be replaced with registers, which would also act as buffers and reduced the noise susceptibility window to a few nanoseconds.

By that time the team was pretty downbeat, it looked like we were going to slog through a complete redesign. I presented my solution. Jerry and Dave suggested that we do a quick test on the existing prototype by pulling the existing chips, and doing some rewiring. They volunteered to make the changes. They picked the DP, where we first found the problem. A couple days later they call me into the lab, they were running the DP diagnostic microcode at full speed, without error.

After that the engineers all got to work modifying the schematics, there were a few tricky areas because of the way the C bus was buffered on some cards, but in general it went smoothly. The changes were done in about a month. I told circuits to make the simple changes, like added ground plane, but not the ones that would impact the schedule. I met with Erv and Ron. We discussed strategy. We could rework the existing prototype, but then the boards would not really match the final design with the circuit group’s changes. However if we waited until all the boards were processed by Design Automation department and a new set built we were looking at two months. We needed more time to debug the Console, and software desperately needed more time to refine the microcode. So we decided to rework one of the prototypes, and begin building a new set of boards immediately. The net result of the backplane problem was about six month slip in schedule, coupled with the one month caused by late microcode. The B5900 was now seven months behind schedule. Prototype one was reworked in about a month, and we now had two machines available for testing. Testing proceeded rapidly, some additional problems were found in the prototype and these were fixed and cycled into the final prototype design.

Erv wanted to accelerate the availability of early production units, so he authorized the build of five sets of cards, plus another mainframe to replace the breadboard. We met with manufacturing, which had already got the orders for the 30 Midland units. Now several areas of the corporation had learned of the B5900 and wanted them for testing, demonstration, software development, and to replace older medium system doing payroll and other plant functions. The total backlog reached over 100 machines in just a few weeks, so manufacturing decided to start five units of their own. I had several meetings with the manufacturing engineers; the B5900 was different than the machines they were used to building. First, it was smaller. They used a drag line/cabinet assembly method for the bigger machines. For the B5900 that was not really needed and was not as effective. We developed a build in place methodology, which would be the standard for future machines because technology continued to shrink computers. The B6800 and B6900 used small circuit boards, so it was easy to fix bad boards by hand debugging. This was not the case for the B5900, with its large boards and LSI technology. Also, the B5900 would be the first machine in the field to use board replacement as a repair strategy. On earlier machines, the field tech would run tests which would identify the failed component. The field tech would fix the board right on site, using IC’s, wire, and a soldering iron. The B5900 boards were too large, with very fine traces and a lot of varied components. Since there were only 14 boards, I proposed that each field service organization be shipped one spare set of boards (more later as they got more B5900’s in their territory), the diagnostic would identify the failed board, the field technician would simply swap the board and send it back to the factory. My analysis showed that it was less expensive to the corporation to do board replacement then to do component replacement on the B5900. But the factory had to turn around boards quickly. To do so a special bed of nails tester had to be purchased and debugged. With it faults could be found in seconds. I worked with manufacturing to create this fast turn around depot repair facility.

About three months later we got the new prototype boards, along with the third mainframe. My engineers began installing and testing them. They worked like a charm. The backplane problem was solved, we tested clock margin and the machine had almost 15% margin, almost unheard of in those days. We also received two more Display Terminal consoles, now fully packaged in a cabinet with integrated floppy disks. After we got the two prototypes running it was time to decommission the breadboard. That was a sad day. Even though it was ugly, it worked, and was where most of the debugging of this brand new design was done. At that time we still had the small lab, but software engineering was clamoring for more space. They also wanted more B5900’s. The B6900 debug was done, so it was decided to move out older machines (there was still a B6700 and B6800) in the lab, and put in two more B5900’s. After only a couple of weeks more of testing we declared the design final. There was still a lot of documentation to complete, schematics to review, specs to sign off on, but the machine was now ready to go to production. It was December, 1980.

I decided it was time to celebrate. My team had done what many had thought was impossible; deliver an entirely new architecture in two years, and under great deadline pressure with limited resources. I went to Erv and said I wanted to throw a party. Now I knew one of his favorite restaurants was the El Adobe in San Juan Capistrano, so I pitched it. He gave me a serious look; they had never spent money on a design completion celebration. I told him I had already looked at the cost, and we could keep it reasonable, people could buy their own drinks. He smiled and approved it. We had a great party, software, hardware, and manufacturing people who worked on the team to make the B5900 happen. When Erv arrived he saw the bar setup, and people coming up to pay for drinks. On the spot he came up to me and said "What’s the matter with you Allweiss? This is a celebration, open the bar!" So we had an open bar, but I restricted it to one hour. It was a great night of dinner, music, and dancing. Everyone had a great time. At the end, Jerry Ragland stood up and thanked me for the party and I told him to thank Erv Hauck. Everyone laughed! He gave me a plaque that had a picture of the B5900 and an inscription "Father of the B5900". That plaque still hangs in my office today.

In February 1981, Arnold Spielberg came to my office. He was liaison to Corporate Engineering and Marketing. He said, "Jack, in about three months Burroughs will be exhibiting at the National Computer Conference (NCC) in Chicago. They were going to put a B3800 on display, but now they want a B5900, can we do it?" The problem was we had just started production, and there were very few machines and lots of orders. I went to manufacturing and asked if they could do it. After some phone calls and arm twisting, we got a machine for the show. It was shipped and installed, but field engineering had not been trained on it yet, so I traveled to Chicago with Arnold and one of my engineers and we made sure the machine was installed and working properly. We had a great time and sales and marketing were very happy.

Although there were still a few fires to put out, my focus was now to change outward and to the future. The B5900, the machine that was not supposed to be because it was really not needed, was now the machine everyone wanted. Not only that, the whole Computer Systems Group architecture roadmap was now called into question. John McClintock and I were summoned to Detroit for a series of meetings. Is the B5900 a unique, one shot design, or the basis for a future line of computers. We told them in no uncertain terms that the B5900 was the seed of the future of the company. On the hardware side, I told them the B5900 was really not that great of a design. Since we were an unfunded project in the beginning, my hands were tied. I told them we could build a machine two or three times faster, at about the same cost, if we could use proven technologies like ECL. I told them we could build a family of high end processors faster than the B7900 and B6900, along with very low cost machines using CMOS technology that would be competitive with the B1800 and B2800/3800 Medium Systems. John told them E-mode, and the microcode compiler, meant the corporation would truly have a common code base, not the "minor" variations seen between the B6000 and B7000 series today. Corporate Engineering, Sales and Marketing had a big question for John. The Medium Systems had a very loyal following of COBOL shops. Could the e-mode architecture compete with medium systems in COBOL? John said it could. Changes had been proposed for e-mode that would make it a better COBOL machine, but time and budget did not allow for the implementation.

Shortly after that meeting Pasadena and Mission Viejo had a COBOL competition, and as I expected, the B5900 lost, but not by a large margin. The Pasadena machines were completely optimized for COBOL, including decimal addressing of the disk! The down side of the Pasadena design is that it was not very good at executing the new, modern languages like Algol, PL/1, and the language soon to explode on the programming world, C++. The Pasadena group was going to fight to keep their computer architecture alive, but the direction of technology was going to work strongly against them.

The Santa Barbara group, on the other had, was ready to embrace E-mode for their next computer. Hans Birchmier was the Engineering Manager of the plant, and Joe Trost was the General Manager. Hans was very interested in the details of E-mode and the B5900. The B1800 was in many ways similar to the B5900 from a hardware perspective, it used firmware extensively, but the hardware design was optimized for the conservation of main memory, or RAM. The B1800 was a "variable word length" computer; the compiler could create a one bit word, or a 100 bit word in memory. The hardware had to pack and unpack these variable words. The original design of the machine was considered innovative, cost effective, and original. The problem was the premise of the design, which was that RAM was expensive and needed to be conserved. At the time the B1000 series was conceived, main memory was magnetic CORE, which was expensive, and was not going to be significantly cheaper anytime soon. However, in the mid seventies semiconductor memory, DRAM was developed, and thereafter main memory costs began to plummet. It was clear to the Santa Barbara group, and too many of us at Burroughs, that the days of the B1000 architecture were numbered. So one of the results of our architecture meetings in Detroit was that I and some of my key engineers and programmers would visit Santa Barbara to educate them on the B5900. We spent a week in beautiful Santa Barbara going over E-mode, the concept of firmware emulation, and a vision for a complete line of code compatible mainframes for the next generation. Hans suggested we needed a new name for these computers, one that broke from the past because of the incompatibilities of the older, three architecture product line. We decided to call the new machines the A series. The Santa Barbara machine would be the A3 and would use CMOS technology. I also outlined three other machines in the family, the A7 which would be a medium system, the A10 which would be a large system, and the A15 which would be the very large system.

Major changes were in the wind at Burroughs as the B5900 began production. At Mission Viejo, Ron Delaura had left and Ron Tucker was now Engineering Manager. Arnold Spielberg was made A Series Manager, responsible for making sure all systems plants built E-mode compatible machines, and shared as much design methodology as practical. Paul Mirabito was ready to retire, and the board had been searching for a new CEO. In 1980 the board decided to go outside the company and hire Michael Blumenthal, former Treasury Secretary under the Carter Administration.

I was very curious about Blumenthal’s background, and what I found was not encouraging to me. Blumenthal had a financial background, like Mirabito, which I thought was not enough at this critical time. Mirabito at least had the advantage of coming up the ranks in a computer company; Blumenthal had been CEO of Bendix, an automotive component manufacturer. Bendix sold to other manufacturers, mainly the auto companies in Detroit. Burroughs sold to a wide range of customers, banks, government, etc. Bendix was a sick company; its stock was very depressed. Blumenthal’s solution to Bendix’s problems was to create a conglomerate of other sick companies. While this temporarily increased revenue and profit, by the time he left Bendix it was on its way down, and was sold within a couple of years to Allied Signal under a cloud of impropriety.

Burroughs had been drifting for the last three years. Internal politics like the BCML fiasco and the turf war with medium systems was taking it’s toll. Burroughs needed a strong leader, who understood the industry and the customers. IBM, with it’s 370 family of mainframes had rolled over the competition. Over the last fifteen years, since the system 360 was first delivered, most mainframe companies had quit the business. At this point in time IBM was the largest mainframe company, with about 80% of the business. Burroughs was second, with about 10%, Sperry Univac was third with about 5%, and all others represented the last 5%. I was very concerned that Blumenthal was not up to the task of being CEO of a company like Burroughs. In the end I was proven correct.

But in the interim more changes were in store. The Rancho Bernardo plant, that made BCML and CMOS chips for Burroughs, was a disaster. Costs were high, yield was low, and delivery to schedule was bad. Corporate decided to put Erv Hauck in charge. He was promoted to Vice President and given free reign at Rancho. Erv would try to fix Rancho for three years, but in the end even he could not get them on track. Rancho was closed in the mid 80’s. Then it was announced that Santa Barbara would be closed. The Santa Barbara plant had been one of the newest Computer Systems group plants in California, but shortly after Burroughs built it the city of Santa Barbara adopted a number of ordinances hostile to business. One of the most damaging was a water use moratorium, which effectively halted housing construction. As a result housing costs skyrocketed, which made it difficult for Burroughs to attract labor to the plant. After our architecture meeting in Detroit the decision was made that future Small Systems (the systems that Santa Barbara was to produce) would be based on e-mode. With Erv gone CSG needed a General Manager for Mission Viejo. In addition it was clear that the amount of space and labor needed to produce future mainframes would be drastically reduced. All these factors led to the decision to close Santa Barbara, and relocate the Santa Barbara engineering and manufacturing to Mission Viejo. So, shortly after we returned from Santa Barbara, Joe Trost followed us to take over as General Manager of Mission Viejo. A few months later Hans Burchmier and most of his engineers would follow.

My concerns about Michael Blumenthal were confirmed during a "get to know the company" visit by Blumenthal to Mission Viejo in the spring of 1981. He arrived by helicopter with Bob Merrell in tow, and his new chief operating officer, Paul Stern. Stern had worked with Blumenthal at Bendix, and taken over after he went to Washington. Now Blumenthal hired him away from Bendix, promising him the Presidents position. I talked to them briefly, they wanted a tour of the labs, and we showed them the B5900, and the new cost reduced version we were beginning work on, the B5920. From the questions he asked and our brief conversation, I came to the conclusion that he really did not know anything about our product, and even less about our customers. My general feeling was he did not see how computers were of much use to anyone! This right on the cusp of the most exciting revolution in technology, the PC. The final straw was when, a few weeks after his visit a request was made. Could one of the B5900 team engineers join him in Detroit to help him understand technology? The thing was, he did not ask us who the right person for that job would be. He wanted Barbara Bennett, a young, pretty, inexperienced software engineer who had joined my team a short time before. The request disgusted me, and became a big joke in the plant. I had her do a short presentation on her work, and apparently Blumenthal fell in love with her. He wanted a girl friend, not a technical liaison. My suspicions on this were confirmed a couple of years later when he divorced his wife and married her. My confidence in the new management was about zero.

In addition, I was becoming concerned about where I would end up in the new pecking order. My group was given several interesting assignments, but no new development. We worked on the Air Force contract, which would have resulted in a couple of hundred B5900 sales. The Air Force had been using the B2500 medium systems, but did not want to continue with the medium systems. Burroughs bid the B5900, but we were in competition with Sperry and IBM. The Air Force had a "fly off" where they benchmarked all three companies. Burroughs won the fly off, but part of the bid was a fixed price maintenance contract, and Burroughs was much higher than the others. Add to the fact that the new administration was Republican and our new CEO was a prominent Democrat (another smart move by the board), and the end result was Burroughs lost the bid.

Another major project, one that Burroughs won, was the World Bank. They were setting up an automated funds transfer system for the world, with centers in every major country. Two to four B5900 and B6900 systems would populate each of these centers. They required several security enhancements to the Console, and we were able to make them quickly because we used the microprocessor controlled Display Terminal.

Burroughs Brazil, one of the corporation’s oldest overseas markets, decided the B5900 was the right machine for them. They came to the plant and we spent a couple of weeks educating them. I sent Cas Pencak down to Brazil in the spring of 1981 for two months to help them get up and running. Brazil continued to build, and enhance the B5900 for several years after it ended production in the US.

We also were asked to develop a low profile, physically more compact version of the machine. It was called the B5920 and was liked by the customers for its space saving design. Arnold Spielberg ran that program, and it became the standard for future cabinet design for the A-series mainframes.

We started working on the specification for the A7, my intention was to build it using ECL logic. But because of the management transition in Detroit, and our new General Manager, no new projects were moving forward. They wanted to "re-evaluate" the company product line. Pasadena was still fighting for the Medium Systems, but I felt they would lose that battle, and suffer the same fate as Santa Barbara, which did happen a couple of years later. So I began to worry, where would I fit in? More senior managers would be needing a job, and the A7 fit in the product line where many twenty and thirty year veterans were now residing.

Then, in the winter of 1980 Ron Tucker was reassigned to help Erv Hauck at Rancho Bernardo, Mission Viejo needed a new Hardware Engineering Department Manager. The choice was narrowed down to me or Bob Leamy. I was looked at as a shining star at the corporation, I was the youngest systems engineering manager in the company’s history, I was the youngest section manager. My picture was in the 1980 annual report. But Bob had a lot more seniority, he had worked on the flagship products of the Mission Viejo plant, he had gone back and gotten his MBA, it was a tough decision. In the end, Bob was chosen ad Department Manager, and that, along with my other concerns, solidified my decision to end my career at Burroughs. My friend Bjorn Dahlberg at HiLevel Technology had, with my input and support, developed a superior bit slice development system. His company was struggling because of his lack of management skills. He asked me to join the company, and offered me 10% of the company in stock options. I decided to take the offer.

When I told Bob Leamy and Joe Trost, they were unhappy, but John McClintock and Don Swanson were crestfallen. They felt I revolutionized the company’s mainframes, and should have a prominent position at the company. I think Bob saw me as a competitor who he would no longer have to deal with. The B6900 group was not in love with the B5900. Joe Trost had his own problems playing corporate politics. I did not have the same relationship I had with Erv. Bob Merrell called me and was very unhappy. "Jack, how are we going to compete with IBM in the future without you contributing?" I told him of some of my concerns, and he admitted privately that he had some of the same concerns.

Bob Merrell, John McClintock and Don Swanson arranged for me to meet with Paul Stern, to maybe take a corporate job on his staff. I flew to Detroit and met with Paul. We had a lengthy discussion, but I did not see anything I liked in his style. He was very cold, and seemed to live by the spreadsheet. Now I am all for numbers, but there has to be some gut conviction along with that. He seemed to feel that he had to be smarter than anyone around him, that they should worship his intellect. I made it very clear to him, I was an MIT graduate, and knew a lot more about computers than he did. He did not like that. My concern about the corporate direction was even stronger. I did not ask him for a position on his staff, and he did not offer one.

Two weeks later my engineers held a going away lunch for me at El Toritos. Joe, Bob, John, and Bill all came, and even Erv and Ron came up from Rancho Bernardo. We said our goodbyes in June of 1981, and I began a new era in my career.

Three years after I left Burroughs Michael Blumenthal engineering the merger of Burroughs with Univac. In 1985 the company was renamed Unisys and the name Burroughs faded from the corporate world. Arnold Spielberg did not retire from Unisys until 1992, during that time he continued to coordinate the A series, which later became Unisys ClearPath MCP, and is still a major profit center for Unisys today.

The End

Evolution of Burroughs Stack Architecture

Mainframe Computers

From the 1960’s until the early 90’s most mainframe manufacturers offered a range of computers systems. Most fit into the following general classifications

Small systems – Branch office or small business computer

Medium systems – Medium size business computer

Large Systems – Large organizations or heavy DP, Banks, Universities

Very Large Systems – the largest organizations, Corporations and Government

The chart below shows how the Burroughs stack architecture eventually came to cover the complete spectrum of mainframe systems offered by Burroughs. The dates are approximate and there is overlap in systems not shown.

In the 1960’s Burroughs small and medium systems offering were the B200/B2000/B3000 series of decimal machines. In the 1970’s the B2000/B3000 series was consolidated to the Medium market and the B1000 series of bit addressable machines was introduced for the small market.

In the 1960’s Burroughs did not have a very large business computer offering. The B5000/5500//5700 Stack architecture computers made up the large system offering. Each machine had a slightly different instruction set.

In the 1970’s the B6000 and later B7000 Large and Very Large stack machines were introduced. They were based on the B5000 series but had a significantly upgraded (i.e. more complex and complete) instruction set. Code for the B5000 series had to be recompiled the OS (MCP) or Compiler code rewritten to run on these machines.

In the 1980’s the first E-mode machine, the B5900 was introduced. It was about 98% compatible with the B6000/B7000 series of the 70’s. In general user programs would run unaltered, but there were some OS changes, and Compiler tweaks to take advantage of new string instructions. The B6900 and B7900 were not microcode architectures, but were tweaked to be about 99% compatible with E-mode (they were between the Late Stack and E-Mode architectures).

The B5900 did not replace the B2000/B3000 machines in 1981, but was offered along with them. The B3000/B4000 series were produced into the mid 1980’s and the A series finally ended that architecture and the Pasadena Plant was closed.

The A series was based on E-mode. The low end machines were not only code compatible, but were about 90% microcode compatible with the B5900. The A3 was a CMOS implementation of the B5900 and replaced the B1000 series machines in 1983. They were designed by the same engineers who used to work in Santa Barbara but who were moved to Mission Viejo and worked with my group. Because of some of the technology differences, and the fact that E-mode was now a standard and received full corporate backing, we were able to make several improvements to the microcode architecture.

The A9-A15 were also fully microcode, used different technologies to achieve higher speed, the high end A15 had a lot of special hardware and did not share the microcode of the B5900, but was fully E-mode compatible. These machines were all designed in Mission Viejo, CA. or Paoli PA. Mission Viejo also developed a single chip e-mode machine called the Micro-A, but it was never really marketed.

The A series was the end of the fully Burroughs designed hardware machines. In the 1990’s microprocessors became very powerful and very cheap. The strategy changed to implement E-mode as an emulator on microprocessors, with some CMOS coprocessors to handle operations that were too slow when emulated. To get more performance, more microprocessors were added. Unisys engineers were at the forefront of multi microprocessor design architecture in the 1990’s.

In the 21^st Century microprocessors became powerful enough to emulate E-mode without any custom CMOS hardware, so my understanding is the latest Unisys Mainframes rely entirely on emulation and commercially available parts (actually Unisys Mission Viejo engineering had an E-mode emulator running on a standard laptop that I saw around 1996, but this was for software development purposes only, it was not powerful enough to replace a mainframe). Multi processors is still a key component of the emulation, but Intel basically incorporated much of the Unisys multiprocessor technology in there offerings. I am not completely familiar with the current Unisys designs so a better source for this information would be a Unisys mainframe engineer.

Variants of the B5900

The original B5930 was housed in a full size ("A" size) cabinet with a separate console that could house two displays (SPO’s) and the Maintenance Interface Processor (MIP). After production began Arnold Spielberg headed up a project to cost reduce the B5930, it was called the B5920. The product was housed in the lowboy cabinet being used by the B3950 at Pasadena. The separate console was eliminated and the MIP was integrated into the cabinet. The SPO terminal could be placed on top of the computer or on a desk. The B5920 was introduced in 1982.

Burroughs Brazil began producing the B5900 in 1981. They loved the machine as it was perfect for there market. The B5900 went out of production in the US in 1983, but continued to be produced in Brazil until 1988. One of the issues Brazil faced was technology export controls, which did not let US companies produced there highest performance machines in Brazil. Extending the life of the B5900 was a way around this problem.

The original design of the B5900 allowed for three expansion cards. In the US this feature was never used, but in Brazil they actually did use this feature. One of the limitations of the B5900 performance is that it has only three top of stack registers. The B6800/B6900 had sixteen, which corresponded to registers called lambda/delta pairs. Lack of these registers was a significant performance limiter for the B5900. To boost performance the Brazilians designed a card that implemented all sixteen registers. This gave the machine about a 50% performance boost.

The second add on the Brazilians did was a math coprocessor. The B5900 did not have hardware multiply or divide units, so these operations were not particularly fast. The Brazilians added this function and increased that performance by several hundred percent.

Technical Details of the Design

The heart of the DP was the AMD 2901 bipolar bit slice processor, and about half of the SLC control word was dedicated to controlling this device. I had used a very similar ECL bit slice for the Black Box. By bit slice I mean that the 2901 was a 4-bit "slice" of a general purpose computer data path. You could build any size data path by simply stringing multiple 2901’s together. Later AMD would develop a 16 bit data path, so to get a 48 bit data word you would need 12 2901’s, or three 2916’s. The 2916 was the last of the "bit slice" bipolar data paths, after that designers switched to CMOS where an entire processor could be designed on a single piece of silicon. The next most important part of the DP was the shift and isolation module. The 2901 could only shift one bit per clock cycle. The e-mode instruction set made extensive use of shifting and isolating different parts of the 48 bit data word. For example, one instruction, xxx, did this (describe shift isolate).

For the B5900 to be effective, we needed to implement a module that would do this kind of work in one machine cycle. By combining a ROM state machine table with hardware shift and mask logic almost all e-mode shift and insolate actions could be accomplished in one cycle.

The DP also implemented the top of stack logic. While the 2901 datapath had sixteen general registers available, the B6700 did not use general registers, all operations had do be done on the stack. The B6700-B6900 implemented the two top of stack locations in processor hardware, known as the A and B register. The b5900 maintained these same two registers in the 2901. However, addressing data on the stack was accomplished using what was known as the lambda/delta pair. The lambda delta pair was an address relative to the to top of the stack. Let’s say that you wanted to add the fourth item from stack one two the first item from stack 1. The instruction would be ADD 1,4 to 1,1. In the original B6500 only the A and B registers were in the processor, so if you had a delta greater than 2, or a cross stack reference, a memory access was forced, which slowed down the operation. Later machines implemented up to sixteen lambda,delta registers, which stored recently accessed lamda,delta data. This was basically a cache of the most recently used data in the stack. Since the compiler writers knew about this cache, they tended to optimize code for it. The B5900 was "register poor", it did not have enough registers in the 2901 to implement the entire 16 lambda.delta registers. As a compromise, we implemented four, but maintained an associative memory for the eitire 16. So if one of the four lambda.delta data stored in the DP were accessed the operation was immediate. If it was not, but was one of the 16, the DP created an interrupt to the memory controller, which fetched the data directly. That data then became on of the four local top of stack words.

Burroughs B7700 Very Large System

B6800 Large System

Burroughs Plymouth Michigan Plant

Design Review, Alta Utah

Bob Olson from Piscataway NJ memory plant with me

at Alta design review.

Arnold Spielberg with me at NCC show.

Happy customers with there B5920 system.