SGI Indy CMOS Battery Fix
Replacing a dead CMOS battery in a Dallas NVRAM/clock chip without using proper tools. This was for our precious Silicon Graphics Inc. Indy UNIX workstation.
indy
Bytefest 2019
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).
Preparing my SGI Indy for a vintage computer event
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 Indy (1993)
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.