Burroughs B5500

B5000 / B5500 /B5700 image gallery

This gallery shows all the discovered pictures of the Burroughs B5000, B5500 and B5700 systems.

Emulating the Burroughs B5500 using a modern web-browser and Javascript

Quoting from the Reference Manual: "The B 5500 is a large-scale, high-speed, solid-state computer which represents a departure from the conventional computer system concept. It is a problem language orientated system rather than a conventional hardware orientated system."

This project is building a browser-based JavaScript emulator for the Burroughs B5500. The project code, blog and forum are hosted at:



Recent screenshot of the emulator in use:

Burroughs B5500 SPO screensnap

This screenshot shows an early version of the software loading a card deck via the card-reader, that the MCP detects and executes as a batch job submission, starts the ALGOL compiler and subsequently outputs the compilation listing to the line printer.

Films of the Burroughs B5000, B5500 and B6500

A transcript of the film "Burroughs B6500 Status Report"

A transcript of the film B5000/B200

Film credit: Preservation by Jeff Iverson and Scott Lurndal.

Burroughs in the UK

Burroughs in UK Banking system

Video from Tomorrow's World: New Banking 09 December 1969 - BBC

First 10 seconds - view of a scale model of a Burroughs B8500 system. I believe this film footage is making an indirect reference to the major bank-automation project that was kicked off by Barclay's bank in 1967 when they placed an order for the B8500 at a a cost of £4.5 million. A full account of this project and its mixed success is detailed here: Too Far Ahead of its Time :Barclays, Burroughs and Real-Time Banking by Ian Martin. The relevance of the B8500 to the B5500, is that due to Burrough's delays delivering the B8500, Burroughs provided Barclays bank with a B5500 as an interim measure so that Barclays programmers could gain familiarity and work on developing the software to integrate the branch-based TC 500 intelligent terminals with the centralised B8500 system.

3m29s Oblique view of Burroughs B5500 main cabinets, appears to be a 7 cabinet system. The cabinet nearest the camera (to the right) has the covers removed showing a view of the wire-wrapped backplanes. A 7-cabinet system suggests the system is configured with both CPUs (CPU A and CPU B) and a full-complement of main memory (32kWords).

3m49s - background image is of a Burroughs control panel

3m52s - view of a Burroughs equipped machine room with several tape drives on the middle right, system SPO console (Type 33 KSR Teletype) middle, Burroughs Disk File in centre far distance. 

Burroughs B5000, B5500 and B5700

Excerpt from the B5700 System Operations Guide, December 1973:

B5500/5700 Design Concepts
The current B5500/5700 hardware and software systems are the result of many years of evolutionary development under the Burroughs approach to computer system design. This approach is to totally integrate both hardware and software through a policy of cross-training the design specialists. Hardware engineers learn the intricacies of software architecture, and software specialists learn the subtleties of hardware logical design. These people are then merged into a single system design team.

Development and installation history
In the late 1950s, such a team produced the hardware and software design specifications for the Burroughs B5000 computer system. By 1962 the first B5000s were installed using the original software operating system called the Master Control Program (MCP). At this time the B5000 was used only for batch processing, the access mode for which it was designed. In 1965, the hardware configuration was expanded. The most significant change was the replacement of the auxiliary drum storage with disk storage. A revised operating system, called the Disk File Master Control Program (DFMCP), was supplied to utilize the new storage medium. Batch processing was still the only mode of access. At this time, Burroughs changed the name of the system from the B5000 to the B5500.

In 1966, the hardware configuration was again expanded. This time the most significant change was the addition of telephone interface equipment. A revised operating system, called the Data Communications Master Control Program (DCMCP), was supplied by Burroughs, to suppor the remote terminal access mode in addition to the usual batch processing. These events made available for the first time the new dimension of remote computing. The features of the original Master Control Program software were broad enough to require only a modest amount of alteration to produce DCMCP. Although the DCMCP permitted remote users to interact and converse with their programs, it treated remote jobs more or less teh same way it treated batch jobs. This caused some remote users to sit idle for extended periods of time before their jobs were initiated; however, once the job was initiated, the response time was usually satisfactory, psychologically, this left something to be desired. One solution developed for this problem was time slicing, or true time sharing.

The B5500 time sharing system, released in 1969, eliminated this inadequacy. The software operating system was modified and called the Time Sharing Master Control Program (TSMCP). Since both the DCMCP and the TSMCP evolved from the same design, they both contain the same important features of the original design, and they differ only in certain resource management strategies.

In 1970, Burroughs announced the availability of certain additional hardware for the B5500, such as extended core memory and a data communications processor. Newly installed B5500 systems with these hardware features are called B5700 systems. Subsequent to the B5700 announcement, some new Burroughs publications and several revisions to older manuals used the term B5700 in their titles. At the present time, all software and programmer reference manuals with either B5500 or B5700 in their titles are pertinent.

Design features
The original B5000 system contained many significant features, primarily as a result of the unified hardware and software design approach. All these original features are still present in the system as it now exists, although many changes and enhancements have been made in the interest of user convenience and operational efficiency. Some of the more significant features will be described rather briefly.

The Master Control Program (MCP)
One of the B5000 design objectives was a system capable of controlling its own resources and scheduling work on a dynamic basis. This was accomplished with the operating system software, originally called the Master Control Program, or MCP. Later, as significant capabilities were added to the MCP, it was called DFMCP, the DCMCP, and the TSMCP. The MCP is the controlling traffic director of the entire system. It always is in control of the hardware, or has the means of regaining control. Its main function is to permit the hardware to process all user jobs presented to it by the operator. Furthermore, it must perform all of the many, many tasks associated with job processing as efficiently as possible. To be efficient it must be cognizant of the resources available and the resources needed by each job, and be able to allocate and deallocate resources to the job stream as quickly as possible.

Hardware status monitoring
In many operating systems the available resources (hardware configuration) are specified as parameters when the software is assembled for loading (system generation). In such systems, if the hardware configuration should change either by adding more devices such as core memory, tape units, card readers, etc., or by removing some device, possibly for temporary maintenance, the operating system may require partial or complete regeneration. In Burroughs systems, the MCP continually checks the status of the total system. It maintains comprehensive but compact availability tables that indicate the number of tapes, disks, printers, I/O channels, and other devices which are available and ready. Changes in status are easily detected because of the high degree of hardware-software integration.

Fail-soft capability
This dynamic assessment of current resources permits a fail-soft capability; i.e, malfunctioning devices can be dynamically removed for maintenance and the system will continue to function. Of course, there are fewer resources and throughput may decrease, but, nevertheless, the machine will continue to function. A memory module, an I/O channel, a peripheral device, or even a central processor in a two processor system, can be taken off-line and the MCP will reroute the work around the missing components; certain devices may even be removed while the system is operating without causing a system failure.

Dynamic resource management
Provided with up-to-date resource availability tables, the MCP is able to dynamically assign certain resources to a particular user job. Rather than, at job initiation time, assigning all resources that will ever be needed, specific resources are dynamically assigned and deassigned to each job as required. This dynamic assignment is accomplished not only for peripheral devices such as tapes, printers etc., but also for the floating I/O channels and main core memory. This means that only that portion of main memory (the most expensive resource) which actually required at that instant is ever assigned to a job.

Multiprogramming and multiprocessing
Because most jobs require only a portion of the total system at any given instant (especially core memory), the MCP is able to initiate several jobs concurrently and assign them disjoint sets of resources. With only one or two central processors, only one or two jobs "in the mix" may be in execution at any given instant; however, the processor(s) may be assigned to different active jobs during brief, disjoint intervals of time. This ability to have many jobs (or programs) concurrently active is called multiprogramming. If a system contains two or more central processors and is able to execute simultaneously a job in each process, it is said to be capable of both multiprocessing and multiprogramming. Furthermore, the sets of resources assigned to the active jobs need not be disjoint. Since assignments are made dynamically, they need only be disjoint with respect to time. This leads directly to the concept of "time-sharing" of resources, although the current discussion pertains to a feature of the batch processing MCP.

Automatic file recognition
A practical necessity of the multiprogramming MCP is the authority to make specific peripheral device assignments. A desirable consequence is that the programmer need not, in fact can not, make specific unit assignments. The programmer need only specify the type of device and then address all program and data files by name only, for example, if a program needs to create a tape file, the MCP assigns an available tape unit and thereafter associates that unit with the programmers choice of file name. Similarly, if a program requires some particular tape file for input, it is called by name only, the operator can mount the tape on any available unit and the MCP automatically recognizes the file name and makes the unit assignment.

Peripheral device independence
Automatic file recognition also facilitates the realization of true device independence. This permits magnetic tape and disk to be used as backup, pseudo-devices, for the card readers, line printers, and card punch. Instead of forcing a job to wait for access to a busy peripheral device, the MCP automatically assigns a temporary backup device. This feature provides a considerable increase in efficiency and throughput.

Homogeneous hardware architecture
The hardware architecture which makes multiprogramming and dynamic resource allocation practical is centred around two exchanges - the memory exchange and the input/output (I/O) exchange. Each central process can access any of the eight core memory modules through the memory exchange. Likewise any of the four floating I/O channels can access memory without interfering with the processors. In turn, the I/O channels can access any of the peripheral devices through the I/O exchange. Thus, both processors and all I/O channels could simultaneously access different modules of memory. The exchanges contain the logic necessary to float the access requests to a free I/O channel. Each I/O channel contains the logic and registers necessary to autonomously complete the information transfer once it has been initiated.

Typical B5700 configuration
A typical configuration is as follows:

1 Central processing unit
8 Core modules (4,096 words each)
3 Floating I/O channels
5 Magnetic tape units, 7-track, 200/556/800 BPI
5 Disk storage modules (1,200,000 words each)
2 Line printers (1100 lines per minute)
1 Card reader (1400 cards per minute)
1 Card punch (300 cards per minute)
1 Operator console (SPO)
16 Telephone line adapters and buffers

Essential B5500 characteristics

  1. 1MHz CPU cycle time
  2. 49-bit memory words, 48-bits user/programmer visible and one bit for parity
  3. Maximum of 32KW of memory (32K x 48-bit words, in modern terms 192 kilobytes of directly accessible memory).
  4. Either one or two CPUs.
  5. Four "DMA-like" (direct-memory-access) channels.

B5000 / B6700 memory management

In the October 1976 issue of COMPUTER, "Virtual Memory", Robert Doran notes:

The memory management organization essentially as used in the B6700 is described in "D. Knuth, The Art of Computer Programming, Vol. I:Fundamental Algorithms, p.435 ff. Addison-Wesley, Reading, Massachusetts, 1968.

From the 1997 edition of Knuth's book, pp. 461 is this text:

Dynamic storage allocation algorithms were in use several years before they were ever described in print. A very readable discussion was prepared by W.T. Comfort in 1961 and published in CACM 7 (1964), 357-362. The boundary-tag method, introduced in Section 2.5, was designed by the author in 1962 for use in an operating system for the Burroughs B5000 computer.

The algorithm is detailed on pages 440 - 442, Algorithm C (Liberation with boundary tags).