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.
This is my favorite photo from the Bytefest vintage computer show last year. A little girl playing Certain Impact on my SGI Octane2. Certain Impact is a flight simulator created by Paradigm for SGI in 1995. It was used as a graphics demo for the Indigo2 IMPACT line of workstations.
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.
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).
I’ve salvaged two SGI O2 workstations in a very good shape. They were used in Military Research Institute Brno (a state-owned enterprise in Czech Republic). Both have 300-MHz MIPS R5000, 128MB RAM and an extremely noisy 9GB hard drive made by IBM. One of them is full of dust and needs cleaning really bad but the other (which held classified information according to stickers) is clean like new. They were for free.
I was also given two packs full of CDs with SGI marketing materials, sets of hi-res photos of SGI computers for printed magazines and technical presentations for SGI customers. Most of it can be shared with public so I’m thinking about uploading it somewhere.
Viewperf is an interesting set of real-world OpenGL benchmarks. The original version was developed by IBM but other companies (SGI, Digital…) quickly joined the development and Viewperf became an industry standard for OpenGL benchmarking focused on CAD, CAM, CAE, medical and scientific stuff. Unlike 3D Mark and other benchmarks you can see today, Viewperf simulates a rendering pipeline of real applications on real data.
The data (viewsets) were not developed by the project group. They were provided by independent software vendors. In fact this is true even today with the current version of Viewperf (12). I still use this benchmark when testing workstation-class laptops and NVIDIA GRID virtualized desktops.
The version 6.1.1 was released in 2000 and it was the last version with precompiled binaries for SGI IRIX (among many other systems like Windows NT, Compaq Tru64 UNIX and SunOS). I’ve used it to check the performance of the SGI VPro V6 graphics inside Octane2. VPro V6 is a single-chip graphics solution capable of processing OpenGL commands directly in hardware and it is equipped with 32 MB of memory (24 MB for buffers and 8 MB for textures). SGI VPro and NVIDIA Quadro (which is an ordinary GeForce 256 SDR card with CAD acceleration functions enabled) were introduced at the same time. Although the SGI’s hardware was very advanced in certain capabilities*, Quadro (as a chip born from the consumer segment of the market) was for the first time (slightly) faster even in the CAD/CAE market. This was the beginning of the end of custom professional graphics accelerators (3DLabs, Evans & Sutherland, SGI…). This was also perceived as another hard blow for UNIX workstations after the introduction of Pentium II.
*) High precision 48-bit framebuffer, accumulation buffer for depth of field, FSAA and motion blur effects
We have three SGI Octane2 workstations in our “lab” but none of them were in the ready-to-use state. I’ve decided to take a look on the one which looked like it could work (the only one with hard drives). Already installed IRIX was somehow corrupted and was accessible only by using a serial terminal. I realized after a few hours that the original installation couldn’t be fixed with my knowledge although the hardware (graphics card) was ok. The only way was to install a fresh IRIX.
I used a laptop with a serial terminal emulator instead of local peripherals and SGI O2 as a server containing all the installation files. For the first time I used BOOTP and TFTP to boot a computer over network. I was surprised how easy it was. The former (BOOTP) is intended to get a boot program to the memory of a target computer (to be executed then). The latter (TFTP) is intended for simple file transfer. Good thing is that you don’t need properly configured Ethernet interface to get this working. A server just needs to know the MAC address of a client and a file to be sent.
It took me more than ten hours but I have one fully working Octane2 now. Surprisingly, booting and accessing all files over the network was the easiest part. Most of the time was spent on identifying the initial issue, “package dependency hell” (typical for UNIX systems) and the fact that the IRIX 6.5.22 boot file didn’t work. I had to start with IRIX 6.5.5, install a special patch and then install IRIX 6.5.22 (which correctly recognized all the hardware inside Octane2).
It was definitely an interesting experience… but I hope I won’t need to do this all again soon. Anyway, for a moment I felt like a real UNIX geek.