A capability-based computer, from Britain, early 1970's

My first job was with Plessey, and I’d no idea they’d been involved with PDP peripherals, and indeed computers. (I was closer to their telecoms business, and rather later.) In this case, a rather advanced idea, a very secure idea in principle, and typically for Plessey, aimed at a low volume high value market.

As a real-time controller, PP250 provided fail-safe software applications for computerized telephone and military communication systems with decades of software and hardware reliability

(Not, I think, the best of Wikipedia, but certainly a notable system!)


That’s quite a bid!
If uneasy with the information provided by Wikipedia, there’s a good description of the system linked under “external links”:

Quote: “The reliability goal was very stringent: mean time between failures of 50 years.”

Also, “Several papers on Plessey 250 can be found in The Proceedings of the International Conference on Computer Communications, October 1972, and in The Proceedings of the International Switching Symposium, June 1972.

And there’s also a picture (from Google Photos, so it may be worth having a backup):

System 250 Telex

1 Like

Oh, that Chapter 4 is very good!

Several facts make the Plessey System 250 an important
computer system:

  1. It is the first functioning computer to use capability addressing.
  2. It is the first capability-based computer produced by a commercial manufacturer.
  3. It is designed to meet critical real-time performance and reliability needs.
  4. It applies capabilities to a multiprocessor environment.

The Plessey 250 is similar to both the Chicago Magic Number Machine and the CAL-TSS system. The use of capability registers as user-loadable segment/base registers is borrowed from the Chicago project, while its addressing resembles the CALTSS mechanism.

For more on Cal-TSS, see:

Butler W. Lampson and Howard E. Sturgis. 1976. Reflections on an operating system design. Commun. ACM 19, 5 (May 1976), 251–265. https://doi.org/10.1145/360051.360074 [Open access]

Howard Sturgis. A Postmortem for a Time-Sharing System. PhD. Thesis. May 1973. [scanned] (via bitsavers.org) [reformatted] [HTML]

Paul McJones, editor. Cal TSS Archives. https://www.mcjones.org/CalTSS/

1 Like

Ooh, thanks, great resources. Perhaps the BEAD Users Guide is a useful orientation.

But having the development history as contemporary documents is excellent.

The BEAD was the interim command processor used in the first phase, when we only had the kernel “ECS System” running, with an interim disk subsystem. In 1971 we completed the full higher level: disk files, directories, and a fancy command processor. Then the project was canceled for economic reasons (campus couldn’t afford two 6400s and we couldn’t support the batch load).

I’ve been working on a history paper that I hope can provide context for how the project got started, what development was like (e.g., starting with punched cards on a batch system with a machine simulator, eventually getting to the point of self-hosting its development, etc.).

Howard Sturgis’s thesis and the paper by him and Butler Lampson do an excellent job at describing and evaluating the design.


I first learned the Plessey name from a friend at DEC. He told me how their policies required that, before repairing any PDP computer under contract, DEC Field Service technicians had to insist any Plessey parts (e.g. core memory upgrades) be removed. Many computer companies were proprietary like this. DEC might have actually been on the more tolerant side, since they often sold the equivalent of microcontrollers integrated into industrial and laboratory equipment, begging the question: Where does the computer end and the customer hardware begin?

1 Like

I can see the case for DEC here, as even minor timing deviations (esp. in memory) can cause weird effects, which are Heisenberg-difficult to hunt down. (I believe, there were minor variations in some series of DEC machines, as well, which caused some headaches.) If third-party memory is the culprit, it’s probably also a case for the field service of that respective vendor. Which might be even better for the customer than DEC field service trying to support third-party components with questionable results.

P.S.: I first became aware of Plessey because of that stylish logo. :slight_smile:

1 Like

I supect, it was more for political reasons. What I really want to know is how many
K of memory that wall of rack unit contains. Relable takes more work than fast
or large.

I’m pretty sure I have a Plessey UNIBUS card; I know I’ve seen one, at least. I have a couple of third party boards (an Emulex tape controller for sure, and I think a Plessey ADC or similar). Nothing as cool as a capability memory controller. :wink:

1 Like

From the linked Chapter 4:

The multiprocessing architecture of the Plessey 250 allows connection of up to eight processors with up to eight storage modules through separate per-processor data paths. Each storage module consists of up to 64K 24-bit words. Multiprocessing is symmetric, and any processor can perform any function if another processing component fails

Bonus materials! @pmcjones has very kindly scanned some System 250 documents which can now be found online:

From the general introduction, a diagram showing the potential for internal redundancy (allows for fault tolerance, error recovery, and maintenance without downtime)