• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Whenever you search in PBworks, Dokkio Sidebar (from the makers of PBworks) will run the same search in your Drive, Dropbox, OneDrive, Gmail, and Slack. Now you can find what you're looking for wherever it lives. Try Dokkio Sidebar for free.


Locus 16

Page history last edited by Alan Hartley-Smith 1 year ago








This is an extract from Arthur Young's contribution to the proposed centenary history.

It was immediately obvious that the MECSL computers would not provide a sensible basis for Radar projects. Moreover the first real silicon integrated circuits were just becoming available - first a memory chip and soon afterwards an arithmetic chip - ­and Brian Partridge saw, with quite exceptional insight, how intelligent terminals would develop. We started a new system, Locus 16, in which a printed circuit backplane would provide communication between computers, memory, display drivers and other devices each housed in a smaller printed board plugged into the back-plane. To custom-build an intelligent terminal you chose the necessary devices and plugged their boards into the backplane. Of course the software would still present a problem, often a serious one as designers kept trying to sell a quart of facility in a pint pot of Locus 16. However even this was less intractable than in previous generations of equipment as integrated circuits of increasing power allowed us to introduce higher capacity storage boards, and more elaborate processors, progressively modernising the product range while retaining the backplane unaltered.


We tried to interest MECSL in Locus 16, without success. This was probably a great lost opportunity as this backplane technology was introduced by Digital Equipment Corporation at about the same time and has become virtually universal, notably in the IBM personal computer and its clones. Although a substantial marketing investment would have been needed a major business could have been built on the Locus 16 architecture. As things turned out, Locus 16 became the mainstay of the Marconi Radar display business for more than a decade, some hundreds of machines being sold in Radar projects during the nineteen seventies and early eighties. The potential was not recognised, and for that reason was never fully developed.


The first customer for Locus 16 was, I believe, the Admiralty Surface Weapons Establishment, ASWE. Far from interesting ASWE in further purchases of Locus 16 we succeeded only in helping ASWE to control Ferranti's design of a very similar system called Military Argus; ASWE appeared to use Locus, and a similar Norwegian system, only as a source of guidance in deciding the specification which should apply to Military Argus. Military Argus was soon adopted by the Navy, and later by the Ministry of Defence, as a standard computer to be used throughout all MOD projects unless a sound contrary reason could be advanced. Naturally a lengthy and tedious political war developed in which I led the technical effort in GEC. The policy never really took hold, there being too many adverse cases and too much protest; it was defeated, after some years, more by personal attitudes than by its technical merits.


[Editors note - the original product was intended to be called Data Route but another product already used this and a new name was needed. As a matter of interest I coined Locus from "the place where it's at" - the point of view being that Marconi was ahead of the game with the concept of backplanes housing a collection of optimised processors. We were starting to get publicity out and needed a name.]


Input by Peter Bain

The Locus was a good machine to program because of such features as re-entrant code. However although it was intended as a display processor it was quickly used for applications for which its limited address range proved too small. This was solved by paging the physical memory, which was a nightmare for program compilation.


In the late 1980s I was a member of a small team set up to define a set of protocols to be used by intelligent Locus processors in order that they could co-exist within a single Locus bin, to create a multi-processing environment. The team was led by Brian Partridge and included Keith Ryder, Clive Gildersleeves, and Graham Smith and we met every afternoon for some weeks to deliberate on how it was all going to work. The outcome was a set of specifications for system initialisation, inter-processor communications, error reporting, & diagnostic facilities. A new set of intelligent peripheral processors were then defined working to these specifications. Four such processors were developed to provide high speed communications channels, low speed communications channels, tabular display facilities & software diagnostic facilities.


At the same time I was responsible for defining a Multi-Processor Operating System (MPOS) and implementing it for two existing Arithmetic and Logical Processors (ALPs), one supporting the original Data Code 1 programming language plus Coral66 and a second based on an Intel 8086 microprocessor. The definition of the inter-processor protocols and the design of MPOS drew on the experience of previous projects, for example the Bridge project which produced its own infrastructure software (although it was never called an operating system). The concepts from these previous projects were reviewed and refined and generalised so as not to impose unnecessary limitations on application software. These two ALP processors plus the four new peripheral processors could then operate together to provide a very powerful computing capability. Store boards with a capacity of 256K bytes plus a dynamic store paging system were also developed at this time. The first application for this was IUKADGE and each IUKADGE console included one such Locus.

Development tools were also developed to automate and control the software development process together with an autonomous diagnostic processor to aid software testing. This was used very successfully for the UKADGE display consoles (which contained more code than the Hughes VAX central processors!).


The reports I've seen on Locus 16 on the internet describe the initial version of it rather than the far more sophisticated version it developed into.


Input by Brian Partridge

The dynamic storage allocation system for Locus 16 was designed and a patent taken out by myself and Arthur Young followed by the detailed basic implementation by myself and Clive Gildersleeves on Liverpool St station whilst waiting for a train to Chelmsford. We had missed the last train before midnight and had to wait until about 2.30 for the next one!!!! Later the patent was dropped which was a shame as future systems such as the later PCs were to use the same technique.

Locus 16 was also one of the first computing systems to use multiple processors in collaboration. DEC would not believe this when I told them of our system whilst on a visit to the USA. (so many firsts which never got full recognition)


Input by Richard Worby

As I recall it, programming LOCUS was far from straightforward when compared to Myriad. Myriad had a very decent User Code consisting of function mnemonics which made sense, LOCUS was much less easy on the grey matter. Myriad had a much more user-friendly compiler (I know 'cos I developed the relocatable binary version from John Keene's original version), LOCUS compilation was made complicated by the lack of memory and consequent addressing structure. Myriad also had more standard software (Edit, Trace etc..) to unravel the mysteries of why your spangly new program nipped off off into the dark corners of the memory and never came back (or 'hung' as the spotty youth of today call it). I have to confess, although I had a hand in selling the Scottish ATC Locus system, I would not have wanted the job of programming it. But thanks to progress (!), by then I had reached my Peter principle level and become a Sales Engineer, thus able to be less than exact about anything difficult. The bloke we really need is one ANDREW YUILLE, who was a software engineer, and a young one to boot, who always supported me when giving LOCUS demonstrations to passing VIPs.


Input by Andrew Yuille

The only Farnborough dates I remember are 1978, after I had left Marconi, when I took my oldest son to the exhibition, and was pleased to be able to show him 'my' Locus demo on display in the Marconi tent. That was its second or (more likely) third appearance at Farnborough, which would match with 1974 being its first. Sorry - I don't remember versions of Locus now. Only setting the 16 binary keys to enter the hex patterns to boot in the tape to read the program ... and then the static discharging and wiping the store so I had to start again. That was only at Writtle Road / Cromptons, until one rapidly learnt to discharge to the door-handle first.


Input by Richard Worby

I don't think Locus was at Farnboro in 1974. But I do recall a DIY all-wood display console mock-up, containing one of the early synthetic displays and a Locus (I think), being at 1976. I remember demonstrating synthetic display capabilities to the Duke of Edinburgh (yes, really) and I also remember a certain Alan P Carnell, once of Marconi, but by then of Plessey, being exceeding bothered about what we had on show, display-wise. Thanks Andrew for using the word "store" in the context of memory. I still do it! Todays IT generation just look at you blankly if you say 'store', and if you say 'core store', a la Myriad, it is assumed you were on the Ark! While on the subject of memories, does anyone remember the max memory Locus could have? Myriad was 32k of 24bit core memory, but Locus of course was RAM.


Input by Andrew Yuille

I've consulted my wife, who remembers dates. The circumstances around the first appearance for Locus at Farnborough were rather significant for her. In 1974, the decision to take/not take the Locus demo was vacillating dependent on the function of a new radar tube. I was tweaking the software regardless of other concerns. The day before, the new tube blew, and it was decided not to go because exhibiting this tube was a significant feature, so I got going on a new cycle of software tweaks. The next morning - when we would have taken it all to install at Farnborough, I was working away at the console when Richard came in, decisions had been reversed, we were to go ahead using the old tube. I explained that I would need an hour or two to get a stable program, and couldn't let my wife know I'd be away (we didn't have a home telephone of any sort in those days!). You volunteered to go and tell her, while I completed preparations, as the hardware would only be ready around lunch time anyway.

This all went to plan, and we had completed installation around Farnborough closing time of 5 p.m. How young I was shows by my expectations of going straight home, whereas we all actually went for a good meal out. I arrived home around 11 p.m., to find my wife in a panic, as she had understood you to say that we would go straight back at 5, and be home by about 6. I had difficulty persuading her to let me into the house. She can place that as 1974, as our 4th child was due that October. [Addendum by RW - Sounds to me like what I attributed to 1974 may have been 1972, because the synthetic display was the new tube, I suspect.] [Addendum by AY - synthetic tubes rings a bell. They displayed orange instead of green, but at that stage were rather liable to pop.] [Editors note - was this due to offset scanning causing the beam to burn through the tube neck - I thought this was an old problem long solved?]


Input by Alan Matthews

I believe Locus started off with 4K store boards and due to "expansions of the software requirements", at the request of the software lads I finally had to ask Brian Partridge and Co. to design 32K store cards for Bacchus!! I have photos of the Locus cabinets we provided, but can not resolve enough detail to see how many store cards were eventually used on that project - I think it may have been four and the same for Malaysia. However I'm sure Peter Bain or Brian Partridge will know the answer.

A lot more processing power in the form of plug in computing cards (Alp4 etc.) was also needed in the end to give the systems enough "clout".


Input by Peter Bain

I think the initial boards were only 2k but ?8K boards became available for Bridge/Bridget etc. Weren't the Bacchus boards 256K? TOR needed 8086 based ALP4s to provide additional clout. Bacchus needed multiple 68020 based ALP8s for even more clout.


Input by Richard Worby

The synthetic displays at Eurocontrol Bretigny were certainly orange, but the synthetic displays I used to demo were green. Chacun a son gout.

On the matter of storage, and before we get carried away by how relatively tiny the memory was in the Myriadaceous and Locusene periods cf. today, remember this - programs were small too. OK, not that small, or indeed small enough to fit, so we still ran out of memory, but somehow we managed. Mind you I never figured out how AEW Nimrod was going to work with an Elliott 8?? with 32k, and of course it never had to. But programs were indeed small because machine code (one-to-one compiled from user code) is very VERY much more efficient on both memory and run time than machine code derived from high level languages. We used to reckon on MiniCoral being about five times bigger and ten times slower on execution. So at Bretigny we used a lot of machine code for anything running in real time.

A good alternative way to look at this is to consider the operating systems used by PCs and Macs as they have evolved over twenty years. Chips have gone from one meg to 3 gigs, and OS occupancy from less than a meg to infinity. Why! Chips is cheap, storage is cheap, high level language programming is easy. We had it tough, guys! We led, others could only follow. We performed miracles with what we had. Don't it make you proud......Amen!


Input by Andrew Yuille

On memory sizes, one of my early jobs on the Myriad, as part of FPPS was to write a comparative post mortem, reading in a program tape, and comparing it with store contents. A criterion was that it should occupy as little space as possible, in order to minimise any effect it had on what it was diagnosing.

The Locus machine language had 4-character code mnemonics throughout, which meant that conditional jumps were expressed as negatives to maintain the pattern - JNNx and JNPx for Jump Not Negative and Jump Not Positive on accumulator x, where x could be A or B, I believe. Someone (Dave Newman?) took this as a backhanded basis for his farewell monologue when he left the company I recall...


Input by Alan Matthews

On the subject of Locus 16 storage, I think Peter Bain is probably correct that the last store boards were 256Kbytes. I do not know how many of these could be used in a Locus but I seem to remember that the software writers had some nasty problems in addressing this "large!!" amount of storage with a 16bit machine.


Locus 16 design


Locus 16 - a paper by Arthur Young


Letters in Computer Bulletin May 2004 - see No 3 in particular also a reference to radar in No.2 


Computer Museum at Haverhill





Comments (3)

Ian Gillis said

at 2:28 pm on Feb 12, 2016

Page checked

Ridzuan hazam said

at 2:29 pm on Dec 10, 2021

Hi sir,how do i share a photo?

Ian Gillis said

at 4:15 pm on Dec 10, 2021

Sorry, Ridzuan, the comment field is restricted to text.

You don't have permission to comment on this page.