A specific feature of GCOS was its capability to operate in foreign modes by providing to the user an environment identical to that he enjoyed (?) in his previous machine. Those modes run simultaneously with GCOS native applications. While such simulators are now available for free as simulators for 8-bits microcomputers in our PCs, the performances ratio between a to-day 32-bits processor and the emulated machine is more than 10 to one. In the case of GCOS emulators, the margin was significantly lower and the realization of emulators needed more features and more talents. The marketing objective was to emulate with a positive margin systems that had a row computing power not inferior to 1/3 of the raw power of the GCOS hardware.
That hardware was based upon a 32-bits architecture, and used a bank of registers. The strategy adopted for GCOS emulators was to use that hardware in conjunction with a dedicated firmware to interpret the sequence of instructions of the emulated machine. No particular effort was made to reuse the native firmware. This architecture is similar to that used by the lower models of the IBM S/360 as opposed to the strategy used on the emulators of S/360-65 where native instructions were monitoring each emulated instruction. 
However some emulated machines had features that cannot well emulated by the native hardware. In such case, an additional feature was added to the hardware either as standard (like op-code decoding in the P7G system, or as an option (like flags processing in the P7 system). Those features were ignored in native mode.
The emulator firmware processed all instructions with some exceptions. The exceptions concerned features due to be shared by the native programs due to operate simultaneously with the emulators (timers, I/O ...).
The general architecture of the emulator was to encapsulate the emulated program into a native mode program that monitored the emulator launching and processed the functions not executed by the emulated firmware. The emulated memory was included as a native segment in the "emulator" process group. That "emulator" was in general multi-threaded, allowing a processing of I/O more effective than the emulated machine (for instance by increasing the buffer capacity, or in relinquishing control to the emulated program without waiting for I/O completion). Mapping the I/O devices of the emulated machine or faster native devices was also a way to achieve better overall performances.

GE-100 Emulator

The GE-100 system emulated on Level-64 was a batch second-generation system with card input, printer output and files located on tapes or discs. Sequential processing was the rule, but optional discs were often used in "direct access", by their physical addresses.

The system used byte addressing, as was Level-64, so there was no need for special hardware for the emulation. GE-100 instructions sequences were interpreted by the emulator micro-programs at the exception of a few instructions noticeably I/O that were trapped to the emulator support software.

The emulator software was a native GCOS process group including several threads dealing with I/O and exceptions and addressing a data segment image of GE-100 main memory. 
I/Os were buffered inside the emulator process group, allowing the operation to define larger data blocks on the native devices than the usual 80 characters of the emulated machine.

GE-100 discs were reconnected to the Level-64, but the emulator software offered also the access of the GE-100 disc image on native discs (GE-100 images being considered as native files on the direct access method).

H-200 Emulator

Honeywell H-200/2000 had an architecture quite different from Level 64. H-200 was derived from the IBM 1401 architecture. It handled data as 7-bits bytes using a flag (an additional bit in the last byte) to delineate character strings; when the native machine was processing 8-bits bytes defined by length in the instruction. A hardware feature to detect the flag by hardware instead to checking it by firmware for each data byte. The emulator was so able to benefit from the 4-byte word mover capability offered by the native hardware, instead of performing moves one byte at a time. That flag detection was the main feature of the special hardware card cage required by the emulator.

The software side of the emulator had a similar architecture to the GE-100, while designed in Billerica and initially delivered under the 4A Back-up environment (a back-up operating system designed in Boston) instead of GCOS-64. In 1975, it was integrated within GCOS 64.

H-200 discs were also supported for conversion purpose by the GCOS operating system through the HFAS access method. Few programs apart a conversion utility did use that native method. H-200 differed from other file organization in allowing a hardware search on the data field of a record. HFAS was also available on native discs allowing the emulator to tale advantage of higher capacity and performance.

The Honeywell policy evolved during the 1970s attempting to move H-2000 customers to DPS-8 by attaching a co-processor to the DPS-8. So, H-200 emulation was abandoned at the end of the 1970s on the different versions of DPS-7

S/360 Emulator

Honeywell placed hopes in a S/360 emulator and a running system was designed by Billerica's engineering.

As Level 64 basic instructions and registers had been limited from S/360 and as the I/O formats were a superset of IBM offering, the emulation of that machine was relatively easy. S/360 emulator was a specific piece of firmware reusing native firmware primitives. CSV statements were translated by software into native calls.

The delivery of S/370 and the ambiguous position of IBM on 360/20 put the technically successful program in marketing jeopardy. Paging would require the implementation of that feature on Level-64 to maintain efficiency of programs and IBM unbundling policy seemed to forbid a customer to use a DOS/VS license on a stranger system. 

Siris 3 Emulator

Siris 3 emulation was developed to maintain the CII-HB commitment to Iris-5x/6x customers. As it was the case with GE-100 and S/360, no special hardware was required. Some features of Iris-65 like topographic memory were not software supported or could be supported through the paging hardware of DPS-7/8x. 

A special firmware was developed for the P7G processor and was supported by a native software process group performing I/O and sharing resources with GCOS software. A few changes were made in Siris 3 software to minimize the interpretation work, especially for supporting the DSA front-end processor. Support of CII specific data communications protocols (TMM-VU and other) was also added to the FEP and handled via FNPS by the Siris 3 emulator software.

Siris 8 Emulator

CII Iris 80 architecture was an extension of the SDS Sigma 7 32-bits architecture. It added essentially a MP capability to the Sigma 7. The main difference from the native mode was the position of the op-code that was inverted inside the word. As op-code detection was the first thing interpreted by the emulator (as a branch vector) it required that the instruction decoding part of the P7G be able to reference the last part of the word instead of the first. The cost of that modification was low and the feature stayed unused in the majority of systems.

The emulator software interpreted CSV (call supervisor) instructions, bypassing the inner layers of Siris 8 for efficient data management. It was the first program to take benefit of the SMP operation of DPS-7.