"Eclipse" or "Personal Iris Graphics" is the original graphics option for the Personal Iris machines. Later machines (i.e. the 4D/35) did support Express graphics boards and were especially sold with Elan graphics. Actually "Eclipse" was only the name of the Personal Iris chassis/system itself, but as the codename of this graphics option didn't find it's way into the public "Eclipse" is sometimes also used for the graphics.
The comp.sys.sgi.hardware FAQ mentions something called "Da Vinci" as codename of a graphics option for 4D/20 and 4D/25 Personal Iris systems with 24 bitplanes and no Z-buffer. A wild guess is that "Da Vinci" is base graphics as described in this chapter PLUS Full Color Option which would give a Personal Iris 24 bitplanes without Z-Buffer in hardware, but it is absolutely not clear that this is what the name "Da Vinci" has been used for.
The Iris Vision card (for IBM RS/6000, IBM PC) is based on the same technology that is used for this Personal Iris graphics option.
Turbo Performance: 200,000 3D Vectors/second Graphics (10-pixel connected vectors) Option Performance 20,000 polygons/second (Z-buffered, Gouraud shaded, 10x10 pixel polygons) Field upgradeable Entry Plus Increases window management planes to 8 with two Graphics additional window ID planes and two overlay/underlay Option planes plus 24bit Z-buffer (total of 40 planes). RGB mode: over 1 million colors with dithering Color index mode: 256 colors from a palette of 16.7M User installable Full Color Increases total to 24 color bitplanes plus four Upgrade overlay/underlay bitplanes plus four window ID planes (total of 32 planes) RGB mode: 16.7M colors Color index mode: 4096 colors from a palette of 16.7M User installable Super Increases total to 24 color bitplanes plus four Graphics overlay/underlay bitplanes plus four system ID bitplanes Upgrade plus 24 Z-buffered bitplanes (total of 56 bitplanes) RGB mode: 16.7M colors Color index mode: 4096 colors from a palette of 16.7M User installable
|Name||hinv||Bitplanes||ZBuffer||RGB colors||Turbo option|
|Base Graphics (" ")||GR1.1||8||no||no||no|
|Super Graphics ("G")||GR1.1 Bit-plane, Z-buffer options installed||24||24||1M||no|
|Turbo Graphics ("T")||GR1.2 Turbo options installed||8||no||no||yes|
|Super Turbo Graphics ("TG")||GR1.2 Bit-plane, Z-buffer, Turbo options installed||24||24||16.7M||yes|
The Big Picture
If you've read other pages about SGIs graphics hardware the following will not suprise you. The basic procedure of getting 3D graphics to the monitor looks roughly the same - at least on SGI hardware of similar age.
The basic idea is this:
- At the Host Interface commands and data enter the graphics pipeline.
- The Geometry Subsystem converts 3D data into 2D polygon data.
- The Raster Subsystem iterates through the data and generates pixel data which is written to the framebuffer.
- The Display Subsystem reads the framebuffer and generates RGB data for displays.
The main part of the host interface is the HQ chip. It maintains the interface to the host via a proprietary 32bit bus and is also the microcontroller for the Geometry Subsystem.
The Geometry Subsystem consists of Data RAM and the Geometry Engine. It takes geometric data performs the specified transformations and lighting computations, and then dies any necessary calculations to reduce the subsequent vertex data into spans, lines, or points which are passed to the Raster Subsystem. The standard Geometry Subsystem contains a single microcoded processor capable of 20 million floating-point operations per second (MFLOPS) - the control and data flow is handled by the HQ chip.
The Raster Subsystem contains a single memory controller chip, the Raster Engine, which performs scan conversion and controls the frame buffer memory and optional Z-buffer memory.
The framebuffer contains 12 bits for every pixel in the base version of the graphics hardware and 56 for the graphics hardware with Bitplane and Z-Buffer option boards installed. The following table gives an overview of how the bitplanes are used.
color window id overlay/underlay z-buffer Base 8 2 2 - = 12 Bitplane 16 2 2 Z-Buffer - - - 24 ----- ----- ----- ------ 24 4 4 24 = 56
The Display Subsystem receives pixel information from the frame buffer and then sends it to the digital-to-analog converters for output on the display.
As usual the graphics subsystem is devided into Host-Interface, Geometry Engine, Raster Engine and Display Generator.
- HQ - host interface
- GE - capable of 20 MFLOPS
- RE - does scan conversion and controls frame buffer / z-buffer (optional) memory
- MGP/RAMDAC - display subsystem
Boards and Daughtercards
- GR1, GR1.1, GR1.2, GR1.5
- The basic graphics board for the Personal Iris that offers 8bit framebuffer capabilities and no Z-Buffer.
The GR1 and GR1.1 have RE1 raster engines while the GR1.2 and GR1.5 have RE2 raster engines. The GR1.5 has a HD15 video connector in addition to the usual BNC connectors as well as an on-board genlock option.
All other boards are placed as daughtercards on the GR1.x graphics board.
- The BitPlane board, also called "Full Color Option", increases the number of supported bitplanes from 8 to 24 and allows the Personal Iris to display up to 16.7 Million colors. It also adds to the Overlay/Underlay as well as Window-ID bitplanes.
- This is a variant of the BP4 which only adds to the Overlay/Underlay as well as Window-ID bitplanes. hinv reports Auxiliary planes installed and the board itself is easy to recognize: It looks like a BP4 with a lot less memory installed.
- Z-Buffer board, that adds 24 z-buffer planes for hidden survace removal in hardware. The Z-Buffer Option requires that a Bitplane Option is installed (BP4).
- Turbo Option adds geometry acceleration with 4 Geometry Engines (made by TI). It consists of actually two boards (GT1 and GT2). The GT1 board is plugged onto the main GR1.x board and replaces (!) the Raster Engine RE2. The Raster Engine has to be placed into an empty socket on the GT1 board to which the GT2 also has to be connected. The Turbo Option requires a GR1.2 or GR1.5 board and does not work with the older ones. It can operate either with or without BP4 and ZB3 though.
- Genlock option (optional previous to GR1.5)
- Genlock clock input
- Composite HD15 (only GR1.5)
RE1 vs. RE2
On the difference of the RE1 and RE2 Raster Engines and the use of the X Window system:
Subject: Re: RE2 Performance Message-ID: <4761@odin.SGI.COM> Date: 1 Mar 90 17:58:29 GMT Getting an RE2 is the best thing you can do to help your X performance on a Personal Iris. The RE2 has several advantages over the RE1: 1) Does logicop in hardware. That means that when you specify XOR we don't have to read the bits back, twiddle them on the host, then write them back to the graphics board. 2) Writing 8 bit deep images is much faster since the RE2 can unpack 4 pixels from a single 32bit words, whereas the RE1 had to have one pixel per word, no matter what. 3) The RE2 is faster than the RE1. You may not see a huge speedup with the RE2 with today's X server, but in the future we will be taking advantage of the RE2 in a much bigger way. If you are serious about running X you probably want an RE2. To find out which RE chip you have run the 'hinv' program. If if says 'Graphics Board: GR1.1' then you have an RE1, GR1.2 is an RE2.
The GR1.x graphics board is installed in the E-Module of the Personal Iris on the back side of the CPU board. A ribbon cable bridges the two boards.
The optional boards that add further features like Z-buffer or additional bitplanes are installed on the base graphics board.
Two-color Cursor Modification
Readers of This Old SGI may have recognized the bit on the "Mysterious Cursor Hardware Hack". Following the modification the Personal Iris also displays a two-color cursor like later SGI systems do (red with white border). jan-jaap has done the modification on a Personal Iris and has posted a summary with pictures on the Nekochan forum.
The upgrade seems to be a part of an official upgrade as not only it gives the system the two-color cursor but also is a feature recognized in the hinv output. A copy of the usenet article dated July, 11th 1991 which included a description of the modification is here. Note that it mentions, that the two-color cursor modification will prevent IRIX versions before 4.0 from booting.