Locus16

Home

 

 

Overview

Locus 16 was designed as a multi-processing system. Design started in 1972/73 and it was being configured into systems from 1974 and in operation shortly afterwards. It was demonstrated at Farnborough 1974. There were two generic forms of Locus 16 though the boundary between them was blurred and circa 1980 they could and did co-exist in one configuration. The two forms could be thought of as ‘Early Locus 16’ and Microprocessor-based Locus 16.

 

Unlike most computers of its time, there was no central processing unit concept. At its heart was a Module Bin that utilised a new concept of a back-wiring panel with twenty-four identically wired edge-connectors providing the system highway and a power input connector. The system highway allowed inter-processor control, data transfer and the provision of dc power. Into the twenty-four positions were inserted the combination of  Modules required to achieve the desired system functionality. A Module consisted of one or, for more complex designs, two printed board(s) each eight inches square with two edge-connectors. The back edge-connector was to the Locus 16 interface and the second on the front-edge was to an item known as a ‘handle’. The handle enabled system configuration of the module specific to its role in that system (for example hardware address, access channel, communication speed, system identity coding etc) and external connections to other parts of the system (for example to radars, radar displays etc). The handle also held interconnections between two-card modules and provided test facilities.

 

Modules could be passive, only responding to being addressed by others, or active in which case they could be given control of the highway to address another to exchange data. Active Modules could also respond to being addressed by another. The next processor to be given access to the highway was determined by priority arbitration, and this was determined at the system design stage.

 

Application programs were pre-installed onto 16KB read-only memory modules (used in a few system designs) or more normally through floppy discs. Paper tape facilities were also provided.

 

Early Locus 16

Prior to the 1980s microprocessors were not sufficiently powerful to be cost-effective and Modules were designed using discrete logic devices. At least one of the Modules in each Locus 16 system was an Arithmetic Logic Processor (ALP) and many early systems only had one, so the Arithmetic Logic Processor was the cpu in all but name. This processor was designed to not request consecutive bus-cycles and it was given a very low, the second-lowest, highway request priority. It was always in operation whereas other processors would stop when an end-point was reached until they were restarted again by some other event.

 

The low highway priority, which seems counter-intuitive, was deliberate and higher priorities were for more time critical functions that typically transferred less data. The real-time-clock would take one cycle to generate an interrupt every 5mS or so and it had a high priority level just below that of diagnostics. Radar video, disc and HDLC communications modules had strict timing to adhere to in order to transfer their bursts of data and were then followed by highway inactivity. TV and display modules transferred much more data and operated to a fixed heartbeat of the display refresh (usually 50Hz or slower) and had priorities just above the ALP; the data rate of these was such that the ALP kept operating albeit at a reduced rate during those regular bursts.

 

It was the system designers job to ensure that the maximum number of highway cycles available was adequate in both peak and average circumstances (including a margin for growth during development and subsequent system operation).

 

If a secondary (DataCode) ALP was fitted, it took the lowest highway priority and would absorb any remaining highway cycles. It would have less administrative tasks to do and so its reduced performance was more focussed onto the application’s allocated tasks. Very few systems operated with such a secondary ALP. The Scottish Air Traffic Control Centre originally had one ALP and dealt with about 100 tracks per display position. An upgrade in the late 1980s increased this to 200 and each display and radar Locus 16 had a second ALP added at this stage to share the increased processing load.

 

Microprocessor-based Locus 16

As microprocessor capability increased, intelligent Modules using the Intel 8086, Motorola 68020 and similar devices were designed to perform a complete operation, only transferring data across the highway when that operation had completed. Each of these modules had a Local Processor Operating System (LPOS), held on-board, and together these LPOSs conformed to a designed set of software interface rules such that an overall coordinated Multi-Processor Operating System (MPOS) existed. The term MPOS meant such intelligent processors were in use. In these configurations one Arithmetic Logic Processor undertook the primary role of initialisation and overall coordination tasks but it was just one of many ‘cpus’ co-operating together. For example, UKADGE bins had such a primary processor plus many intelligent others.

 

Each one of these intelligent processors had the same or more processing power than the original Locus 16 Arithmetic Processor. The MPOS created a chain of LPOS interface Message Control Blocks (MCB) and each intelligent processor had a derived specific MCB chain that identified the communication paths and data areas. These were created dynamically on system startup.

 

The intelligent processors moved much of the invariant repetitive data transfers away from the Locus 16 highway. This evolution reduced bus traffic, removing one designer problem but introducing another. Designers now had to ensure that data flows through more complex processing chains didn’t violate customer’s tight time constraints between data arrival and final display under worst-case conditions.

 

Module Summary

Some Modules were common to virtually all systems and this meant that certain positions were always used for the same purpose. This was for good design reasons. For example, the system control module generated key timing signals and arbitrated on competing requests for highway access and it also monitored the power rails and applied the reset signal if they were out of tolerance. It was always at the furthest position from the power input connector to enable it to measure worst case values and it was followed by the lowest power consuming modules (typically RAM storage). The terminations module was at the opposite end of the highway to ensure best signal matching with the highest power consuming modules preceding it (typically intensive processors).

 

Configuration

Module Bin

This provided the 19-inch mechanical framework, system highway and power connector. It was used for the majority of systems built. UKADGE was the major exception though variants for TEPIGEN and other non-Locus derivatives also occurred.

 

The address and data highways were 16-bits wide and were expressed in hexadecimal notation. x8nnn was for the initialisation program’s read-only memory plus system read-only memory. x7nnn (and E0nnn) was allocated to module hardware addresses and the remaining x9000-x6FFF was for read-write storage (56KB). Store management techniques later extended the amount of physical storage that could be utilised.

 

For very compact systems a Power Module could be fitted directly into the Module Bin. This unit occupied ~8 card slots and avoided the need for a separate power unit.

 

UKADGE used a later Module Bin design that utilised a multi-layer back wiring panel with a higher DC power distribution capability. This was only an issue when extensive intelligent processors were being used in one bin.

 

TEPIGEN was a visual and training simulator which came in two forms. The smaller variant used Locus.

 

Non-Locus products were also developed during this period and resulted in units similar to the Module Bins with different back-wiring panels; for example one was split into two halves with 8-inch boards specific to their design. These were not Locus systems, they just used a common infrastructure, standard tools and processes. Thus one big product development generated lots of peripheral aspects; for example, production was geared to 8-inch boards that then became a company standard size, spin offs from that could all be used by other development areas, environment testing results similarly, also specifications for power units. This reduced their development costs.

 

Power Bin

This was a 19-inch unit that contained the power sub-units needed by the Locus Module Bin, and was connected to the Module Bin by a suitable DC cable. It also provided switched AC power for connection to other systems (eg tape units, flexible disc units etc).

 

The higher power needs of the later systems were met by higher capacity Power Bins.

 

Cabinets

Module Bins, Power Bins and Flexible disc units were typically fitted into 4-, 5- or 6-foot cabinets. These cabinets would be free-standing or fitted into cabins for mobile usage. The other alternative was to fit these units into the controller’s console.

 

The cabinets included a fan unit and projected ambient air upwards which was deflected by the units above, when warmed, to the front. The front access for all wiring and connections meant that in locations of limited space, the need to access the unit’s rear was removed. All maintenance, including unit removal could be effected from the front. A door fitted to the cabinet’s front presented a tidy image.

 

Locus 16 Modules

        System Control

System Control provided the system 8MHz clock, power monitoring and bus arbitration logic. A later version allowed two bus cycles to be granted allowing contiguous read-modify-write which enabled inter-processor flags to be used within data areas used by the various LPOS processes. This module also generated the refresh signals to the RAM stores.

 

Bus cycle duration was determined by the speed of the addressed module (typically three or five clock periods).

 

Terminations and Clock

The primary role of this module was to provide highway signal termination. It also held space for 4KB of read-only memory used for the system initialisation program by the primary Arithmetic Logic Processor, and a programmable real time clock timer that would cause an interrupt to the primary Arithmetic Logic Processor.

 

Diagnostic

A hardware diagnostic module provided independent user access to the system to monitor store addresses, hardware addresses and also to write data to those addresses. Its priority was the next highest priority access to Refresh. The module was used with a console that provided banks of lights and switches grouped in blocks of four. Together they allowed other processor’s bus accesses to be stopped or single-stepped to aid problem diagnosis.

 

The independence of this diagnostic process from the primary Arithmetic Logic Processor meant that the ALP did not have to be stopped or specifically programmed to yield the data, and the ALP’s internal registers (visible to the system highway within the hardware address range) could be monitored in real-time. It included a system freeze capability when a specific address (pre-set by the user onto the data keys when in use) was detected on the highway. It was a basic, simple yet powerful mechanism. The module was fitted to most Module Bins and the console was taken to the system of interest and connected to the live system, while operating, when needed.

 

A software diagnostic application was included in most application software providing debug and break point facilities. This software was run by the ALP and interfaced to the user via an available communication module’s RS232 channel to a VDT.

 

Later diagnostics were programmed into a dedicated Intelligent Intel 8086 based processor. This provided a similar independence of operation as with the earlier facility (with the VDT connected directly to the diagnostic processor’s handle), built-in decompiling and break-point facilities and also the built-in ability to interface with the LPOSs of other modules fitted into the system through which access to the internal store and programs of those processors could be monitored.

 

In addition, when Logic State Analysers became available, an interface module was designed with banks of switches and mating connectors that allowed the highway signals to be easily connected to the analyser.

 

When ‘intelligent’ processors entered usage, the proprietary toolsets of those products also entered use. These included the Microprocessor Development Systems (MDS) and their In-Circuit-Emulation (ICE) attachments.

 

Arithmetic and Logic Processors (ALP)

General purpose computing modules were always identified by this name and were programmed to perform specific system functions. The original ones had a machine / assembler language called DataCode (this name was a legacy from the earliest inception when the system was known within the company as DataRoute. As this name was found to already be in use, the revised name of Locus16 was chosen.)

 

The first ALP had two cards. One held the registers and performed the arithmetic functions. The second decoded the instructions and produced the micro-steps needed to achieve the instructions. All functions were 16-bits integer / fixed point apart from two. One was multiply which yielded a 32-bit answer and the second provided a double length shift operation. It supported a base level plus three independent interrupt levels each with their own register banks increasing the speed of interrupt response.

 

Interrupts were caused by another processor's bus cycle writing to a specific ALP hardware address. The ALP, unless inhibited by software, would switch operation to the interrupt level where a complete set of registers was available to process the interrupt. By design, the preceding interrupt level program instruction had been to switch down to the base level. So it was ready to restart the interrupt process. This began with a ‘Who Are You’ identification read cycle where the interrupt source responded with its unique code. A consequence of the interrupt was often to suspend the base level program saving all of its register values and then to reinstate another suspended task.

 

A subsequent design using bit-slice devices reduced the design to a single card with fixed-point divide and some extra instructions but which only had the base and one interrupt level. Experience had shown that only one interrupt level was needed. This design was extended later to include the read-modify-write instruction to allow operation with the intelligent processors.

 

A second card could be added to the single card to provide floating point instructions. In practice this hardware floating point card was not widely used. It was superseded by the emergence of the microprocessor-based intelligent processors which provided the ideal place for intensive numeric calculations coordinated by the primary ALP.

 

16 bits of data and address meant that, unlike Myriad, each instruction was not able to hold the full address of the affected store location. Other than literal instructions which held an explicit 8-bit value, other instructions utilised ‘indirect’ addressing whereby the instruction held a signed 8-bit offset to a named register. This allowed store locations in the range +/- 127, two-byte words to be accessed. Byte accesses were also possible. One of the registers used in this indirection was the current instruction (P) register. This enabled the compiler/assembler to place addresses of more remote areas within range. By the time the instruction was obeyed, the current instruction register had already been incremented (by two bytes) to the next 16-bit word address. This meant that a jump-self was actually encoded by the compiler as a jump-self-minus2 making the pattern of xC102 probably the most recognised Locus 16 instruction.

 

Two specific intelligent ALPs were designed and widely used. One used an Intel 8086 with floating point co-processor (8087). The other was a much more powerful Motorola 68020 also with floating point. Both were capable of having their programs installed on-board to provide dedicated application functions (eg Tracking, Short Term Conflict Alert etc) for a given system.

 

Storage

These modules changed quickly. Originally a Module Bin had many fitted as each had a capacity of just 4KB per card using the Intel 1103 chip. Then came 16KB designs followed by 64KB and 512KB. The address zone they held was determined by the system links in their handles. Software complexity always needed more and two forms of store management were employed to extend the limitations imposed by a 16-bit address highway to an extended 20-bit physical address.

 

Store Management (1, 2 & 3)

The first method allocated four consecutive 4KB blocks of store addresses for paged store, and system convention established this as the 3xxx – 6xxx address range. Handle interconnections allowed the primary ALP to select which block of physical storage was in use at any time via a parallel input/output module, normally used to select peripheral radar system devices such as rolling balls, touch masks and keyboards., the output signals being wired in to replace the system links by programmable logic signals. A bank of alternative 4KB blocks thus existed and any combination could be active at any time. This arrangement typically provided 80-96KB of physical storage (40KB plus paged store).

 

The second more powerful method, for which a patent was raised, utilised a dedicated store management module fitted into the Module Bin. It had two variants which were essentially an original and a later derivative form. The later one (SM3) provided all of the former's functionality  but had additional facilities to suit the Intelligent processors. 

 

The two modules (2 & 3) transformed the top four bits of the 16-bit address produced by the processor, plus the processors own highway priority signal to map to a programmable 8-bit address extension; which with the remaining twelve address lines  formed a 20-bit physical address used by the 64KB and later store modules. This allowed each processor to have its own view of the available memory with much less impact onto other processors. The ALP would page the physical memory into its view when needed to transfer data to or from the other processor. Physical store capacities of 96KB to 2MB were possible and similar storage within the intelligent processors was also common.

 

As stated above, the third method was an extension of the second, in later years, to allow nominated processors to produce a 20-bit address directly onto the Locus 16 highway. Such processors had their hardware address block within a 20-bit equivalent (E0xxx vs the earlier 7xxx) and provided with auto-transformation between the 16-bit and 20-bit hardware addresses and vice versa so that old and new hardware could be integrated in one system.               

 

Input / Output Communications

Numerous standard modules were designed and available to systems engineering when putting systems together. The most basic was for paper-tape devices supporting 8-bit punch and readers with an RS232 duplex VDT channel operating at selectable speeds up to 9600bps. Another provided four RS232 duplex channels and four of these could be fitted to any one Module Bin. Input speeds were normally limited to 2400 bps to avoid excessive load on the ALP which polled the module for availability of data.

 

Another module provided support for parallel interfaces with two 16-bit output channels and two 16-bit input channels. The output channels were used for selecting radar specific peripheral devices such as rolling balls, operator keyboards, touchmasks, and for controlling specific system lights; these output signals were also used for the early form of store management. The input channels received data from the controller’s peripheral devices or switches. A parallel input channel was typically wired as a low-speed highway to all of these devices. The devices would output their data onto that parallel highway only when a designated output signal combination was generated by the application program..

 

There were modules that provided synchronous radar data interfaces as used by the MRSL Plot Extractors and those of other companies taking in message data. These had FIFO buffers and were typically operated at high input speeds (7800 bps and above). The FIFO buffer allowed the ALP to collect multiple bytes with a less frequent scanning period.

 

Some systems required customer specific interface modules to allow a Locus 16 system to be integrated into a larger system.

 

A 2Mbps HDLC (High-level Data Link Control - Level 2 of the Open Systems Interconnect model) module provided the ability to send / receive higher speed HDLC message blocks and these modules were set to output data chained in message blocks in Locus 16 store by the ALP and to place chains of data received into other allocated areas of store. The ALP would be interrupted when tasks were completed. It was a two-card design. One card dealt with the message block and highway interface (this card-type was also used in the Disc Drum controller). The other handling the HDLC message formatting.

 

Later designs provided intelligent communications modules. Designs provided multiple RS232 channels and HDLC channels. These were programmed into a system role and their LPOSs collected / dispatched the data to and from the allocated system message blocks.

 

Flexible Disc Controller

This module was another two-card design and was able to be connected to two Flexible disc units (ie four discs in total).  It accessed the highway to transfer one sector’s data to or from a designated area of Locus 16 store. Each sector had a cyclic redundancy code (crc) checksum generated by the hardware when it was written. An error was reported if the data and crc code failed to match when the data was read.

 

In the 1980s an updated software compatible controller was designed that connected to the 5.25-inch PC disc units.

 

Disc Drum Controller

This was a two-card module. One dealt with the message block structure and data transfer across the Locus 16 interface. This card-type was also used by the original HDLC module. The second card dealt with the disc unit interface.

 

Television Module

This module allowed text data to be written into Locus 16 storage to be output to a television-style raster display monitor. One module connected to one TV. Several of these modules could co-exist and share a common highway access channel such that one Module Bin could support several controller desks (Air Defence systems often had three in simultaneous use from one Module Bin).

 

Display Processor

This was another two-card module with one holding the current data and interfacing logic and the second generating the micro-steps needed to collect the data from the allocated storage and send it onto the display. It had two levels of operation. One level dealt with the synthetic data derived from store. The other was used for synchronising the playout of radar video data onto the screen. This module provided a parallel interface for use in small systems for connecting peripheral devices such as rolling ball, keyboard, touchmask units etc. avoiding the need for an additional parallel interface module.

 

The instruction set allowed lines to be drawn on the display from a designated x-y position (or current position) in any direction with any length; small graphic sub-routines allowing common symbols to be coded once and drawn many times; and hardware items fitted into the display unit to be activated. A hardware character generator and cards dealing with the retimed radar facility were examples of such display hardware. Brightness, size, line style, flashing and colour (when a colour display unit was connected) information were part of the instruction set.

 

Furnace Display Processor

The previous Marconi Air Defence computer system had been called FORGE and had used the Marconi Myriad computer. It utilised various interfaces and specific display units. When Locus 16 was substituted for the Myriad (the air defence system was then referred to as FURNACE), it was decided to retain the original radar displays and a specific display controller module was designed for this role. It allowed textual data to be displayed alongside raw radar signals on three display units each with their own picture. This module was only used for this role and only with the earlier display unit.

 

Magnetic Disc Storage

       

Flexible Disc Unit Floppy Disc origins / operation

In the early 1970’s, a new design of small mass storage units became available. These were known as floppy discs   History of the floppy disk

 

The Memorex 651 was selected, based on good performance and availability, and two were fitted to each 19-inch Locus 16 Flexible Disc Unit. The 651 used 8-inch hard sectored discs with 32 sectors plus an index hole. It had 64 tracks with the sector/index hole on the outer edge. The media held 64 tracks of 32 sectors each holding 128 bytes of data (262,144 bytes in total). Overall rotation took 160ms and each sector took 5ms. Sectors were interleaved by the Locus 16 Flexible Disc Controller to allow ‘numerically sequential’  sectors to be requested and read in one rotation.  Memorex 651 Manual

 

Shugart_Associates  subsequently produced another design and its SA800 went on to become the industry standard 8-inch floppy disc design floppy disk drives. It  was soft-sectored using just one index hole located near the centre of the disc. The SA801 was similar but with 32 hard sectors plus an index hole. Both had 77 tracks  Shugart SA800 Manual

 

 

Other than the index hole being on the outer circumference on the 651 and the inner on the other design, perhaps the most fundamental difference between the two was in a significantly improved head design. The SA800/801 manual (Para 2.5 Read/Write Head) states that:

 

“The head is a single element ceramic read/write head with straddle erase elements to provide erased areas between data tracks. Thus normal interchange tolerances between media and drives will not degrade the signal to noise ratio and insures Diskette interchangeability.”

 

In contrast, the 651 had no erased guard bands between tracks and this meant that the signal margins for the Shugart design were significantly better allowing more variability of media signal quality without introducing timing shifts and data errors. As the market dominance of the Shugart design became prevalent, media producers multiplied and heavily marketed media targeted at the Shugart design became normal.

 

Any failing disc media that were returned to the development team were investigated and it was found that visual examination of the failing sectors, through the slot where the head would make contact with the disc (by manually rotating the disc under a bright lamp), often showed surface blemishes that correlated with the failing sector. All purchased media were subjected to 100% visual surface inspection. Gradually as failure returns increased, signal levels were measured and found to be lower than with the earlier discs. It was speculated that the industry standard media was packaged for the 651 which possibly led to the media problems experienced in later years.

 

In the 1980s an updated unit was designed that used widely available 5.25-inch PC type disc drives. This unit had limited usage as the Locus 16 systems that followed were either Astrid-based, where on-board firmware was used, or UKADGE where the DEC Vax provided the backing store or were air defence systems using the drum stores. 

 

Disc Drum Unit

Some Air Defence systems utilised a higher speed, higher capacity disc drum unit.

 

Television Unit

The television screen size was not constrained but usually it was a small 12-inch unit that could be easily fitted into a controllers desk. It was primarily used in military systems and normally had an infra-red (Digilux) touchmask fitted.

 

Digilux Touchmask

The touchmask had 32 perspex studs as aiming markers and the TV was arranged to display the appropriate text behind the stud. The action of the operator in touching the stud caused an interruption in the light beams that identified the stud and caused the application software to change the displayed information and menu accordingly.

 

When the selection code for the touchmask was generated, this information was then made available to the parallel input channel.

 

This touchmask was supplied to other organisations (eg British Steel) for use on other systems as it allowed the use of gloved hands.

 

Radar Display

Basic S3017 XYZ Frame

The S3017 display had been designed as an ‘L’ frame to enable usage-specific interface units to be fitted into the rear, sitting on the step of the 'L' so making the whole a complete display unit. There were two main editions plus a second power unit for the added sub-frame that fitted into a space beneath it.

 

The two main editions were :-

·         “-03” which provided the interface to connect to a radar for basic video display

·         “-10” which provided the interface to the Locus Display processor

 

These display units were cursive. This meant that the deflection signal moved the beam across the screen to the desired position. A corresponding video signal then caused a visible glow to be seen or not according to the need. Movement could be fast for repositioning, taking a few microseconds, or slow when drawing potentially visible lines. This approach gave straight lines with no jaggedness and avoided the need to convert the required line into pixels on a raster with its consequent need for storage. Magnetic deflection gave a smaller spot size than electrostatic deflection systems. This did use more power, take longer to get the beam to the required point and needed special screening to avoid magnetic pick-up; however, magnetic deflection was normal for radar displays of that era.

 

The Locus 16 unit

This provided the interface to the Display Processor. It contained an interface card, a timing card for controlling the integrator run times and the deflection waveform generators (one X and one Y axis). The deflection generators converted the digital value through an integrator to the required deflection voltage with a rapid mechanism when a reposition was needed. There were two other card-sets that could be fitted.

 

Character Generator

Most systems usually held a hardware character generator that was fitted into this unit. These caused auxiliary deflection waveforms to be produced which were connected to and attenuated by the display's main deflection amplifiers  (reducing any noise signals too) prior to being combined with the main deflection signals.  A main deflection reposition was needed every few characters.

 

Retimed Radar

In some systems the unit also contained  a retimed radar card-set.  The radar retiming system allowed the incoming radar video to be sampled and stored at an appropriate rate. Then on the subsequent radar scan, the Display Processor switched the input / output stores and generated the required signals for the display deflection, and the previous data played out as video causing brightness variation. The play-out rate was optimised to the display system and appropriate to the length of line on-screen. This meant that the resulting video brilliance was much greater than on conventional displays when used under high expansion and off-centring conditions.

 

XYZ and Backup

Later displays were designed as X-Y-Z monitors taking in main deflection signals (X and Y) plus video together with auxiliary character X and Y deflection signals. The latter two were heavily attenuated to reduce the noise that would otherwise be superimposed on the characters. These later units included 16-inch, 20/22-inch, rear-port, colour and electrostatic displays. These displays were used with Locus using a separate backup unit, virtually that from the S3017-10 display with its card set. A higher signal handling ability was the essential difference for the longer cable connections.

 

Display Test Set

One of the first usages of microprocessors within the radar company was for this small unit which was designed to allow easy field setting up and checking of displays. Until then displays had to be set up on the bench and then finely adjusted to the system in-situ. This was to ensure that optimum character shape was achieved without introducing errors that would cause the beam’s return to a given position to actually be offset by an error depending on how long the beam had been settled on a distant place on the crt screen. This was known as ‘settling and wander’ and could give rise to a little movement of lines / characters on the screen in normal use.

 

The small microprocessor display test unit allowed

·         standard grid lines to be produced that could be used

o   for deflection coil alignment for true vertical and horizontal lines

o   to adjust amplifier gain using the distance between the lines

·         settling and wander tests to be performed with several resting periods at various places on the screen

·         character bandwidth / response adjustments using the classic oscilloscope-like square wave patterns

 

It could be connected directly to the XYZ display interfaces and was found to be much more accurate than previous methods and very fast to use. With a simple set of connectors, it could also be connected and used for the Locus S3017-10 display setting up.

 

Once the XYZ monitor had been adjusted against a known datum, it was then easy to adjust the backup unit’s circuits to match. This aspect had previous needed more skill and experience, as an incorrect set of settings in the XYZ monitor’s amplifiers could be compensated by other incorrect settings within the backup unit. Such a condition was non-optimum.

 

Raster Displays

The advance of technology meant that processing performance and memory were able to deal with the task of converting the computer image to a high-resolution raster system of 1600-2000 lines. These gradually came into use from the late 1980s onwards and were used with proprietary VME-based (VersaModularEurocard) display units.

 

ASTRID Central Data Processing Unit

One special Locus 16 variant was produced in the 1980s  for the ASTRID product range. This was usually deployed in small ATC rooms. It had a standard Module Bin with power module, system control, terminations and storage modules plus one intelligent  Intel 8086-based ALP  and an ASTRID-specific display processor.

 

The ALP contained firmware specific to the system and this allowed low-cost display facilities to be provided at small airports. The ASTRID display processor generated the XYZ display signals that were connected to either the 16- or 22-inch ASTRID generation of displays and the controller used a connected ASTRID desk unit containing keyboard and rolling ball.

 

A personal view from Brian Buick is appended in the page Locus 16 - A Software Engineer's Perspective.

 

 

Locus16

Home