After years, I’ve finished a long in-depth write-up about an interesting piece of history – the SGI IrisVision 3D accelerator from 1990. It was a scaled-down version of the graphics board set from the SGI Personal IRIS and was intended for PC compatibles (16-bit AT bus) and PS/2 computers (MCA).
The whole thing started when IBM licensed the graphics hardware and the IRIS GL 3D API for their IBM RS/6000 UNIX workstations. Although the IrisVision was not very successful (like all 3D accelerators of the era), it is cool that IRIS GL programs could run under DOS.
At the end of the article, there is a video showing the card in action in a high-end IBM PS/2 Model 70 with a 25-MHz Intel 386 and 387.
This is one of the demos that were used by Silicon Graphics and Nintendo to show the graphics features of their upcoming game console (Project Reality / Ultra 64 / Nintendo 64) during CES in 1994.
SGI used an Onyx supercomputer to run the demo. I recorded it in 1024×768 (true-color) on a much less powerful SGI O2 workstation (released in 1996). O2 is based on a graphics architecture similar to what was actually used in Nintendo 64. It was a perfect fit for an inexpensive highly-integrated computer as well as a game console.
I would rather use a different SGI computer (Octane2 was my first choice), but O2 was the only machine that was compatible with my cheap VGA-to-HDMI converter.
These were the computers we brought to Bytefest – a Czech vintage computer show. David and I decided not to bring more than two desktop systems. Amiga 2000 was an obvious choice – we fixed it not a long time ago and I played a lot with it recently. The other computer was SGI Indy with the original set of peripherals including the Indycam camera. There are not many vintage UNIX computers to see on vintage computer shows in this country. Thus, it is my duty to bring at least one every year.
The Aritma Minigraf plotter sitting on top of the Indy was connected using one of the Indy’s serial ports though a special ARM-based module that David built. The module contained the control software that allowed it to draw faster and with better precision than the plotter was originally designed for. From time to time, there were couple of people standing in front of the plotter, being hypnotized by the smooth movement of the pen. The Indy itself was communicating with the module as a serial terminal with the ability to send HPGL files that needed to be drawn.
I’d never played that much with Indy before (aside creating the OpenGL 1.0 version of our 3D graphics benchmark) and this was a nice experience. The graphics card in our Indy is able to display no more than 256 colors (or 16 colors for double-buffered 3D), but it’s pretty fast and allows you to have a different 256-color palette for an active window and the rest of the system. Therefore, the color flickering effects are minimized in comparison with PCs set to 256-color modes. I was surprised by the visual quality of the composite input from Nintendo 64 in 256 colors.
Commodore Amiga 2000 was configured to show the capability of this platform during the late 80s (thus, Workbench 1.3 and Kickstart 1.3 only). It didn’t have any accelerator board and the only expansions were a simple hard disk controller, 2-MB fast RAM card and A2088XT PC emulator (with an 8088 and 512kB of RAM). During the show, I also added an ISA card with a serial port (for Microsoft InterLink purposes) and a VGA adapter.
The other devices that we showed were: Apple PowerBook 100 (this year with a working hard drive and full of software), Digital DECpc 325SLC (because a 386 with color LCD is cool) and HP OmniBook 900 (just a service laptop to convert the Wi-Fi Internet into a cable form for the Indy).
Bytefest 2019 is coming and I have only two weeks to prepare all the machines I want to take with me. I want to the show this Indy with a Nintendo 64 game console because Indys were often used for N64 game development (after all, N64 hardware was designed by SGI). It is nice to see that Indy’s VINO interface supports progressive scanning (used by game consoles and old 8bit computers) on its composite/S-Video inputs – unlike newer SGI O2 and SGI Visual Workstation 320. Anyway, the main planned part is to connect a vintage Czechoslovakia plotter (Aritma Minigraf) using our custom interface (modified to use a serial port) and plot processed images of visitors taken using the Indy’s bundled webcam.
I’m surprised that serial ports on Indy support speeds only up to 38.4 kb/s. Pretty slow for a computer introduced in 1993. Maybe that’s one of the reasons why the serial port speed was not even mentioned in the user guide. They just didn’t care.
SGI Indigo2 IMPACT systems were the best workstations for game development and other activities involving textured 3D rendering in 1995. My system is equipped with High IMPACT Graphics, which is a two-card solution with a dedicated geometry engine (one million triangles/s), raster engine with two pixel processors (two pixel per cycle, 60-70 textured Mpixels/s), 12MB of pixel memory and a single texture-mapping unit with its own 1MB of texture memory.
The high-end option was called Maximum IMPACT Graphics. It took three slots in the computer and doubled the rasterisation performance by using exactly the same principle that was later used by 3Dfx Voodoo2 SLI (scan line interleaving).
The 3D performance of SGI Indigo2 IMPACT was years ahead of PCs and other workstations. In fact, 3Dfx Voodoo2, the best gaming 3D accelerator for PCs in 1998, had similar performance to High IMPACT graphics but unlike the IMPACT series, it didn’t support windowed rendering, 32-bit color precision and high resolutions.
This machine represented the SGI’s low-end workstation offering. It was targeted towards Mac users (DTP…) that needed more graphics and processing power than they could get from Macintosh Quadra systems. It’s a sleek pizza-box computer with just a single quiet fan inside (unlike other SGI systems). However, in comparison with non-SGI competitors, it was not slow. It had at least 100-MHz (64bit) MIPS processor, at least 16MB of RAM (reasonable configurations started with 32MB) and multiple graphics card options available. 10Mbit/s LAN, ISDN modem and video inputs (composite / S-Video / a digital port for the bundled webcam) were integrated on the logic board in all configurations as standard.
My Indy is from 1995 and has a more powerful 150MHz MIPS R5000 CPU. On the other side, it is equipped with the lowest possible graphics card (XL8/XGE8/Newport) that supports no more than 256 colors and was introduced with the early machines.
I always thought that Indy was the only SGI system without any 3D acceleration when sold with XL8 (2MB of 64bit video RAM) or XL24 (6MB of 192bit video RAM for true color modes) graphics cards. I expected just a crappy framebuffer (with BitBlt) and nothing more – like in Sun and HP machines. I was wrong. The REX3 chip inside the Newport graphics is pretty capable. Although all the 3D transformations and triangle setup are done in software, the chip can raster triangles with smooth (Gouraud) shading and per-vertex alpha-blending. Even Z-Buffering is partially accelerated using the chip (Z-Buffer is stored in system memory though).
In fact, this chip is not very far from early PC 3D accelerators (1996-1997) in terms of functions… except for the texturing support which was not available even with higher-end workstation-class 3D accelerators in 1993. This is for the first time I see 3D accelerated OpenGL (1.0) on such an old graphics card – and in 256 colors. To be correct, the scene with triangles has just 16 colors because any real-time graphics requires double-buffering. Each byte of the window in video memory contains one pixel from both buffers in the GBRG-GBRG arrangement of bits.
The graphics card is faster than I would expect. The pixel fill rate for smooth shaded triangles is ~50Mpix/s. If you add alpha-blending, you will get ~20Mpix/s. That’s 5-20 times as fast as the Windows NT 4.0 software renderer on a laptop with 133-MHz Pentium MMX and a 2D-only graphics chip. The speed in 3D is more comparable with 3Dlabs Permedia, S3 Virge DX and other consumer 3D accelerators from 1996.
I’ve brought some of my computers to Bytefest (a big Czech vintage computer show): Apple PowerBook 100 with an external floppy drive, IBM PS/2 P70 as a cool gas-plasma-screen serial terminal, SGI O2 (used only as a hard drive cloning machine running in headless mode), SGI Octane2 with all necessary peripherals and DELL Precision M50 for sharing wireless Internet connection with my other machines (and also to show how the graphics workstation market changed in less than two years from Octane2).
PC compatibility was a big thing for UNIX workstation manufacturers in the 80s and 90s. It started with x86/DOS emulators for text-only applications and later evolved in products like SoftWindows 95. This is a full x86 emulator with pre-installed and pre-configured Windows 95 in it and Insignia ported the emulator for non-PC platforms including IRIX, Solaris, HP-UX, MacOS, NeXT and other systems.
I have to say that installing the emulator on SGI IRIX is way easier than I expected. Just insert the installation CD, run the IRIX Software Manager, confirm the installation and that’s it. The first start of the emulator installs the Windows 95 by copying all the files on the virtual hard disk and deploying device drivers. It took maybe three minutes and didn’t require any user interaction.
Windows is preconfigured to see all UNIX folders as network drives, network is configured so you can immediately go on-line with Internet Explorer 3.0 or access SMB file shares. Mouse emulation works the same way as with modern virtualization software so you can seamlessly move the cursor between Windows 95 and IRIX windows. It also changes the Windows 95 screen resolution immediately after resizing the emulator window.
On the other side, games are not playable on my 400-MHz MIPS R12000. There are strange lags every few seconds (although between them, fps is similar to early Pentium systems). Office software runs ok and the only major limitation is in supporting up to 8-bit display modes (no more than 256 colors).
There will be an annual vintage computer show called Bytefest soon in Prague, so my friend and I must prepare all the hardware we want to take with us. Last year, I was told by some visitors that it is inappropriate to use an IBM keyboard with SGI computers. Thus, we started our repairing marathon with this defective SGI keyboard (although I don’t think that using IBM Model M with any computer is inappropriate).
I’m used to the fact that servicing SGI computers is always pain in the ass. It seems that SGI peripherals are exactly the same story. The keyboard is designed the way that it is not possible to clean switches if you don’t want to disassemble the whole thing destructively.
