Data General ECLIPSE ®
Instruction Set Summary


Foreword

    This document will attempt to describe the Data General ECLIPSE line of 16 bit computers in sufficient detail to allow a hobbyist to begin to program the device at a machine- code level. Heavy reference was made to Data General's Programmer's Reference Series - Eclipse ® Line Computers in the preparation of this document. Some might say that a lot of it was plagarised; in many instances, I agree.

    This document is not intended to be an in- depth analysis of the machine, nor is it intended to be a tutorial on programming the device. I've prepared it primarily as an aid to hobbyists who may have acquired one of these systems and who wish to use said system as an amusement or part of a working collection. I've tried to be as accurate as possible, but I'm sure there are errors and will welcome E-mail with any corrections.

    Enjoy.


    This document is arranged in sections which cover:


Architecture

    Data General Corporation, of Southborough, Massachusetts (since purchased by EMC) introduced the original Eclipse in 1973 as a successor to its venerable Nova line of computers. From those beginnings the Eclipse line grew into a family of compatible machines which were formidable competitors to DEC's later pdp11 series machines. They eventually evolved into the 32-bit MV series of machines.

    The Eclipse can be simply described as a 16-bit 4-accumulator machine which operates on a load/store basis. This, in plain language, means that the ALU and data paths are sixteen bits wide (from a programmer's viewpoint), there are four ACs (Accumulators, aka "registers"), and there are no fancy addressing modes (as in the pdp11). In addition to the four 16-bit accumulators there is a single-bit register known as "Carry" which participates in arithmetic and logic instructions.

    Words in memory are represented in this document thusly:

   +---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
   | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
   +---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+

    The Eclipse has separate I/O and memory buses and separate classes of instructions to access each of them. Memory transfers can involve a 16-bit word, a 32-bit double-word, an 8-bit octet, or a single bit. Block memory transfers of more than one word are possible. I/O transfers are either 8-bit bytes or full 16-bit words. Both memory and I/O buses are sixteen bits in width.

    The I/O system in the Eclipse is defined by a six bit address bus yielding a total of 64 possible devices. I/O transfers involve the full 16-bit word, but devices may choose to only use a subset of those bits. A data channel facility is available for DMA functionality.

    The mainstore in the Eclipse machines operates on a word basis, 16 bits at a time. This means that for byte- level accesses, a 16 bit quantity is taken from memory, and, in necessary, masked/ shifted to provide the desired eight bit byte.

    The Program Counter (PC) in the Eclipse is 15 bits in width. This feature defines the basic 32 kW memory capacity of the machine. Most Eclipses support memory management and mapping schemes which could boost the physical memory capacity to as high as 256 kW; logical program space, however, remained at 32 kW.

    Data General chose to use the octal (base eight) numbering scheme to represent values stored in the Eclipse's memory and in its operation. I'll stick to that convention here; unless otherwise specified, all numbers in this document will be expressed in octal.


Memory Addressing in the Eclipse

    As mentioned earlier, Eclipses operate on a load/ store basis. This implies the existence of (at the very least) instructions to load an AC from main memory and to store data back to memory. There are also instructions which access memory for the purposes of program flow control (jumps) and instructions which modify memory locations (increments). All of the instructions which access, or modify, memory share the same basic instruction format.

    Eclipses support three addressing modes, known as "Page Zero", "PC Relative", and "AC Indexed". Two of the four Accumulators may be used as index registers, these being AC2 and AC3.

Producing an Address

    The Eclipse produces its target (or Effective) address (E) in two steps. It first step computes the so-called "intermediate address" which is the base it uses if indirection is later required. In many cases, the intermediate address is the value required and address calculation stops there; in others, indirection is required and the intermediate address forms the first address for that process. Indirection is discussed below.

    The basic format for common memory- reference instruction in the Eclipse is:


                         I          /---------- Displacement ----------\
                       /   \       /                                    \
   +---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
   | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
   +---+---+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
                           \       /
                              Mode  

    Bits zero through four control the instruction operation and what ACs (if any) are to participate in the instruction. The rest of the fields will be discussed here.

    The Mode field controls what mode the Eclipse will use to access memory. As mentioned above, the Eclipse supports three different memory addressing models; the use of the Displacement field will vary according to the mode in use. The modes are as follows:

    Here's how they work:

Page Zero:
In Page Zero addressing, the value of the Displacement field is taken as an unsigned (0 to 255) value and is the value of the intermediate address. Page Zero addressing may be used from anywhere in the address space, regardless of Program Counter (PC) contents to access any word in the lowest 256 memory locations. This mode is selected when both bits six and seven of the instruction word are "0".
PC-Relative:
In PC- relative addressing, the Displacement field is used as a signed quantity which is added to the current value of the Program Counter (PC) to form the intermediate address. This allows access to any word within the range of PC+127 and PC-128 words. Note that this form produces inherently relocatable code. In this mode, bit six is a "0" and bit seven is a "1".
AC Indexed:
In AC- indexed addressing the Displacement field is taken as a signed value and added to the contents of either AC2 or AC3 to form the intermediate address. In both of these modes, bit six of the instruction word is a "1" and bit seven selects the desired AC ("0" for AC2; "1" for AC3).

Indirect Addressing on the Eclipse

    Once the intermediate address is formed, the machine examines the value in bit five of the instruction word. If that bit is a "1", then indirection is called for and further address computation is performed; if this bit is a "0", then the intermediate address is deemed the effective address and is used unmodified.

    In indirection, the value which is fetched from the intermediate address becomes the next address in the chain. This value may, itself, be an indirect address if bit zero is a "1". If bit zero is "1", then the word specified by bits one through fifteen is fetched and the indirection cycle continues. When bit zero of the fetched word is "0", then the chain is said to be complete and the final address is the value which last came from memory.

    Note that on unmapped Eclipses it is possible to disable (hang) the machine by way of an indirection loop. Pressing "stop" on the console will have no effect on this condition; the machine needs to be reset, and in doing so all context will be lost. Mapped Eclipses can have their memory management hardware cause a trap if an indirection chain goes longer than sixteen references, but this is not enabled by default. Don't do indirection loops.

    Memory locations 20-27 and 30-37 behave in very special ways when accessed indirectly. These are auto-increment and auto-decrement locations, respectively. When these locations are addressed in an indirection chain, their value is increased or decreased by one before their value is fetched for use. They are especially useful for traversing lists and arrays in linear fashion. When accessed non- indirectly, they behave as normal memory locations.


I/O Interrupts on the Eclipse

    The Eclipse has a fairly simple interrupt scheme compared to many computers. It's implemented as a single line system which implies that priority is associated with a device's physical position on the I/O bus. This is partly true, but the Eclipse uses a neat trick with interrupt masks which can be used to mask out interrupts from certain devices creating a form of ``interrupt priority''. In these paragraphs, I'll attempt to convey to the reader a sense of how the Eclipse interrupt system works.

    The normal power- up default state of the machine is to have the interrupt system turned off and interrupts disabled on all the I/O devices. This is also the state following the issuance of an ``IORST'' instruction. The interrupt system is ``primed'' by the ``INTEN'' instruction and goes active after the first instruction following the INTEN.

    When an (interrupt- capable) I/O device requires service, it raises an interrupt request. The CPU checks this line between each instruction and if an interrupt request is pending it enters the ``interrupt state''. In this state the interrupt flag is reset, the current PC (the next instruction to be executed, in lieu of interrupts) is saved to physical location zero, and the machine executes an indirect jump through physical location one.

    It is the programmer's responsibility to place the address of the interrupt handler into location one, to enable interrupts in the first place, and to re-enable them following the completion of the interrupt. It is also the programmer's responsibility to save the state of the machine (e.g. all ACs and Carry) so the interrupted program can continue on.

    With interrupts disabled immediately following an interrupt, the handler need not be concerned with itself being interrupted (unless the programmer sets it up that way) and can identify the interrupting device. This can be done either by polling or via the ``INTA'' (Interrupt Acknowledge) instruction. ``INTA'' will load the device address of the interrupting device into a selected AC when it is executed (remember to save the AC before using it!). From there, the driver program can dispatch the device and handle the request.

    In addition to the mechanism described above, the Eclipse supports the use of the "Vector" instruction which combines many of the steps listed above into one instruction.


Magic and Reserved Memory Locations on the Eclipse

    Locations 20 through 37 (octal) in the logical address space (there may be two or more location 20s in MAPped machines) behave in a special manner when accessed indirectly. When hit via an indirection operation, these locations either increment by one or decrement by one automatically before the value is taken to be used in the effective address. 20 through 27 are the auto-incrementing addresses and 30 through 37 are the auto-decrementing ones. This makes them useful for traversing lists and areas of core. They behave normally when accessed directly.

    In addition to the auto-increment and auto-decrement locations, the Eclipse defines the following locations as Reserved:

  Location        Name                  Function
  --------        ----                  --------

     0      Interrupt Return       Return address from Interrupt
            Address                and first instruction of power-
                                   fail auto-restart routine

     1      Interrupt Handler      Address of the Interrupt handler
            Address                routine.  This address is
                                   indirectable.

     2      SC Handler Address     Address of the first word of
                                   the System Call handler.
                                   This is indirectable.

     3      Protection Fault       Address of the first work of
            Handler Address        the Protection Fault handler.
                                   Indirectable.

     4      Vector Stack Pointer   Address of the top of the
                                   VECTOR stack.  This is NOT
                                   indirectable.

     5      Interrupt Mask         Current Priority Interrupt mask

     6      Vector Stack Limit     Address of the last normally-
                                   usable address for the VECTOR
                                   stack.

     7      Vector Stack Fault     Address of the first word of the
            Address                VECTOR stack-fault handler.  This
                                   is indirectable.

    40      Stack Pointer          Address of the top of the current
                                   stack.  Not indirectable.

    41      Frame Pointer          Address of the current stack frame
                                   minus one.  Not indirectable.

    42      Stack Limit            Address of the last normally usable
                                   location on the stack.

    43      Stack Fault Handler    Address of the first word for the
                                   Stack Fault Handler

    44      XOP origin Address     Pointer to the beginning of the
                                   XOP table.  Not indirectable.

    45      Floating Point Fault   Pointer to the first word of the
            Address                Floating Point Fault handler.
                                     Indirectable.

    46      Commercial Fault       Pointer to the first word of the
            Handler                Commercial Instruction Set Fault
                                   handler.

    47      Reserved               Reserved.

    In the foregoing, if an address is marked as "Indirectable" it indicates that bit 0 may be set to reference another location that contains the desired datum.



[ Museum Lobby ] [ Museum Catalogue ] [ Carl's Homepage ]


Copyright © 2003, Carl R. Friend. All rights reserved.

Comments to: carl.friend@rcsri.org
Last Modified: Sat Sep 6 10:55:28 EDT 2003