The Orion was a series of 32-bit super-minicomputers designed and produced in the 1980s by High Level Hardware Limited (HLH), a company based in Oxford, UK. The company produced four versions of the machine:
All four machines employed the same I/O sub-system.
High Level Hardware was an independent British company formed in early 1982 by David G. Small and Timothy B. Robinson. David Small was previously a founder shareholder and director of Oxford-based Research Machines Limited. Both partners were previously senior members of Research Machine's Special Projects Group. In 1984, as a result of that research, High Level Hardware launched the Orion, a high performance, microcodeable, UNIX superminicomputer targeted particularly at scientific applications such as mathematical modeling, artificial intelligence and symbolic algebra.
In April 1987 High Level Hardware introduced a series of Orions based upon the Fairchild Clipper processor but abandoned the hardware market in late 1989 to concentrate on high-end Apple Macintosh sales.
The original Orion employed a processor architecture based on Am2900-series devices. This CPU was novel in that its microcode was writable; in other words, its instruction set could be redefined. This facility was used to customise some Orions with instruction sets optimised to run the Occam and LISP programming languages[1] or even to compute fractals.[2]
The CPU consisted of an ALU that was built around the Am2901 bit-sliced microprocessor. To this a byte manipulation unit was added which could perform the shifting, rotating and masking operation required for handling eight and sixteen bit data. Additional logic was provided to support both signed and unsigned two's complement comparisons in a single operation, multiple precision arithmetic and floating point normalization. Most operations could be performed in 150 ns, however the cycle time was variable from 125 ns to 200 ns under microprogram control so that timing could be optimized. A microsequencer, based around the Am2910, directed the control flow through the microprogram. It could perform branches, loops and subroutine calls most of which could be conditional on any of several CPU status conditions.
The CPU instruction decoder, decoded machine level instructions (as opposed to micro-instructions). This was achieved by using map tables held in fast parity checked RAM which mapped one byte opcodes onto micro-instruction addresses. Control was transferred to these addresses using a special sequencer operation which was performed in parallel with other CPU functions. Hence instruction decoding overlapped instruction execution.
An escape mechanism was provided to allow the instruction set to be expanded beyond the 256 entries selected by any one opcode. A further mechanism existed to switch between several sets of dispatch tables, allowing the machine to support multiple instruction sets concurrently. Using this mechanism a different instruction set could be selected each time a context switch occurred. This mechanism was also used to implement privileged instruction, dynamic profiling (for performance monitoring) and multiple CPU modes (e. g. User and Kernel).
The role of the cache memory, independent of the main memory, was to hold the top of an evaluation stack for a procedure oriented language. The cache had a two cycle latency after which it could deliver one word per cycle and was divided into a number of pages each with 512 32-bit words with parity protection. The pages were grouped in pairs with an architectural maximum of 16 pairs. The original machine implemented two pairs. The second member of each pair was typically used as additional fast registers and scratch storage without affecting the stack page. The lower nine bits of the CPU register, which addressed the cache, was implemented with counters and allowed increment and decrement operations (push and pop) as wells as random access.
The control store was built using high speed static RAMs. This was normally loaded at bootstrap time, allowing the machine to be fully user microprogrammable. The control store cycle time was 125 ns, equal to the fastest CPU cycle. The architecture allowed for up to 32 Kwords (64 bit word length) of control store however due to the limitation in memory technology the original implementation allowed a maximum of 8 Kwords. The standard configuration had 4 Kwords on a single circuit board. Two such boards could be installed. Parity checking was provided. To achieve the required speed at reasonable cost, a two-level pipeline was employed around the control store. Later a 16 Kword board was implemented giving a maximum control store size of 32 Kwords.
Main memory was organised as 32-bit words with two-way interleaving, allowing 64 bits of data to be fetched or stored in one operation. In normal operation main memory was accessed via a virtual memory management unit.
In the original implementation, each main memory module contained 0.5 Mbytes of storage with parity protection constructed using 64K dynamic MOS RAMs. Random access cycle time was 500 ns per 32-bit word but multi-word transfers, for example to and from the cache, yielded an effective cycle time of 250 ns per 32-bit word (16 Mbytes per second). The memory modules decoded 26-bit physical word addresses and within this limit total memory capacity was restricted only by the number of available system bus slots; depending on the I/O configuration of the system, up to 10 Mbytes of physical memory could be installed. A later implementation of the memory module increased the size to 2 MB using 256K RAMs.
Logical to physical address translation was carried out using a set of address translation tables. Each process has access to threeindependently extensible regions of memory, used typically for program, heap and stack. A fourth region was normally reserved for the operating system. The tables also contained a set of rights bits for each memory page giving full protection and supporting the implementation of demand paged virtual memory. The translation tables were cached in the CPU resulting, in most cases, in an overhead of only one microinstruction when performing address translation. The page size which was fixed by the hardware, was 4 Kbytes. Each logical region could be up to 256 Mbytes.
The Orion I/O subsystems included a number of attached microcomputers to perform low level tasks such as running diagnostics and managing terminals and disks.
The diagnostic microcomputer (based around the Zilog Z80) was embedded within the CPU. Its functions included running a system confidence check when power is first applied, bootstrapping the CPU, and taking control should an unrecoverable control store parity error be detected. It could also be used to load new microcode dynamically whilst the machine was running. An RS-232C interface was provided to which a terminal could be attached. Extensive diagnostics could then be run in conjunction with special microcode to perform fault analysis in the event of a system failure. Problems could usually be isolated to one or two integrated circuits.
One or more intelligent I/O channels controlled peripheral activity. Each of these included a full function microcomputer based around the Z80 which performed control functions and housekeeping. Data transfers to and from peripheral devices took place via a direct memory access (DMA) path itself constructed using Am2901 bit-slice microprocessors. This allowed the full performance of the Orion memory system and of the peripheral device to be exploited, with the microcomputer able to take corrective action on soft I/O errors. Software on the Orion communicated with the microcomputer using a high level message passing protocol.
The operating system for the microcodable Orion was OTS (Orion Time Sharing) version 1.x, a port of the 4.1BSD UNIX operating system.
The Clipper-powered Orions ran OTS version 2.x, a port of the 4.2BSD UNIX with some additions. This was not notably reliable or secure, and had a tendency to 'forget' process user IDs, randomly leaving user processes running as root.
HLH also produced a graphics terminal for the Orion called the StarPoint, to which they ported the X Window System.
The Orion series was moderately popular with the computer science departments of British universities, including Westfield College, London,[3] Bath, Edinburgh, Heriot-Watt, Kingston Polytechnic, Kent, Southampton, Warwick, York, King's College, London. A typical multi-user Orion configuration would have had 8 MB of RAM, an SMD hard disk (e.g. a 168 MB Kennedy or a 434 MB Fujitsu Eagle), a 60 MB QIC-24 tape drive and 8 to 32 RS-232 terminal ports.
