Alex's Silicon Graphics Systems Page

You'll probably find that I have erred somewhere on this page, probably in a lot more places than one. If you see something wrong, or can add specificity to something, please e-mail me.

Recent changes

Introduction

Considerations



In Depth (the empty sections are "in progress," which is my way of saying "never, ever going to arrive, ever")

  • IRIS Indigo
  • Indy
  • Indigo2
  • O2
  • Octane/Octane2
  • Fuel (not here yet)
    • Overview
    • Physical characteristics
      • Size
      • Weight
    • Processors
    • Graphics
    • Environmental characteristics
      • Heat
      • Noise
    • Drives
    • Networking
    • Audio
    • Reliability
    • Prices
    • Pictures
    • Related


  • SGI monitors
  • A word about IRIX media
  • Using CD-(ROMs/Rs/RWs) on SGIs
  • Linux on SGIs
  • Quake on SGIs
  • SGI Links
  • Credits
  • Copyright information

    Introduction

    Why go the used SGI route? There are many reasons for which to do so:

    To be fair, I'll also make points for the other side. Why not buy a used SGI?

    To summarize, I wouldn't recommend any SGI IRIX machine to a Unix rookie without a genuine interest in the Unix platform, or at least a genuine appreciation of solid engineering.


    Considerations

    I'm not going to give any recommendations - my hope is that I can give you enough useful information to help you decide for yourself what you want to buy. There were more SGI model lines produced in the 1990s than I have fingers, and there are many different major and minor variations within those lines. In order to understand exactly what you want to get yourself into, you should first ask yourself what you're going to need.

    The whole shebang or just parts?

    Whatever you do buy, it will probably be best to buy an entire working system and then upgrade from there instead of buying parts individually and piecing them all together. Why? Used SGI systems are worth less than the sum of their parts, believe it or not. Much less. One example of this is in the case of the Indy power supply - if you want a good used Sony power supply, you'll probably pay at least a couple hundred dollars for it (as of August 2000). But if you want an entire used Indy, with a Sony power supply inside it, you may pay less than $100. What-everrr.

    How fast?

    Before buying anything, it would be helpful to realize that what you will be buying will be far slower than the average PC on the store shelf today in just about any given respect. If you try to match the overall CPU speed of the latest PC or Macintosh with an SGI, you'll spend many thousands of dollars and probably not even get there. Keep in mind, however, that "slowness" is usually relative; even though a 150MHz R4400SC's integer speed may only match up to a 150MHz Pentium's, it's still fast enough for everyday web surfing, e-mail, word processing, and so on, as long as you don't mind choppy web page scrolling and a little more waiting and making do with older software.

    It is difficult, if not impossible, to accurately assign a ratio to the difference of real-world speed between a PC and an SGI, firstly because the two have vastly different architectures on just about every level, and secondly because there are thousands of different SGI configurations to compare to literally millions of different possible PC configurations. Trying to quantify an "overall speed difference" is like trying to quantify what the "overall temperature difference" of Africa compared to Antarctica is on a given day. Sure, the coldest area in Africa might sometimes be a bit colder than the warmest area in Antarctica for a short period, but...

    As a rule, don't trust a SPEC number. SPEC scores are derived by testing speeds of many different applications and compositing the results into (generally) two final numbers  - two final numbers that represent all the vastly different types of work a computer can do, and really don't stress the graphics or peripheral subsystems. For many older SGIs, performance results are only available for the SPEC95 or SPEC98 (or - *gasp* - SPEC92) test suites. For the most accurate benchmark possible, sit in front of the machine and use it for a while.

    Also, don't rely a megahertz measurement. Megahertz is not a measure of how well a CPU performs - it's a measure of how many times a CPU cycles per second. The more efficient the CPU, the more work it will be able to do in one of those cycles. Yes, a 2GHz Pentium 4 will generally be faster than a 600MHz R14000, but not the three-plus times faster that you would think.

    The exploding market for business software in the '90s blessed PCs and Macs with video cards that could accelerate 2D graphics like nobody else's business, in 24-bit color and at insane resolutions. SGI just hasn't paid attention. SGIs' built-in framebuffers have typically been limited to just a few resolutions at most, at a fixed color depth. SGI has been, and still is, selling $10,000 machines that can't display anything higher than 1280x1024, so if you're used to something higher than that, you could be in for some serious disappointment. I prefer to use my PC for many 2D intensive things, just because my PC's graphics accelerator is so much faster than my Indigo2's XZ boardset. The fact is, any recent Matrox, nVidia, ATI, etc. PC video card will totally blow away any SGI - at 2D tasks in X. (Then again, PC card companies like nVidia are still just a wee bit behind the IR at 3D. But not as far as you might think.)

    As a tip, a good solution to any speed disparity is to just pretend that you live in the year your SGI was made. If you have an R3000 Indigo, George H.W. Bush is the president of the U.S., the Bills lost the Super Bowl again, Vanilla Ice is at the top of the charts, and your badass 33MHz dual-geometry-engined monster can handily beat the pants off any 486. Word to your mother.

    What are you really looking for?
    If you're going to work with photo-quality graphics at all (including browsing the Web), you'll want 24-bit graphics. If you want - dare I say need - to play Quake, get a system with hardware texturing capability. If you think a video input would be cool, look at the Indy, the Indigo2 with IndigoVideo, or the O2 with the video I/O option. Or the Octane with video I/O, which is the system that most clued-in local TV news stations use today to compute and render what gets projected behind the weather person onto the green screen you see during the weather forecasts of your local news station.

    I will go into much more detail after showing my little summary of some of the '90s SGIs below.

    A word about the Crimson
    This is totally unrelated to what's above (and below), but worth mentioning. We all know that computers have been increasing exponentially in speed for decades - SGIs are no exception to the rule. But, incredibly, some of the machines of yesterdecade are actually still fast enough to be of good use to some people. As an example, I cite the Crimson. The IRIS Crimson is a document unto itself, so I'm only going to give it a paragraph. In 1991, its RealityEngine graphics subsystem was the absolute fastest in the world at any price point. It's amazing even to think that a deskside computer built in 1991, with just a single 150MHz R4400SC CPU and RealityEngine graphics, can beat a semi-modern (gigahertz Athlon or so) PC with the latest MadFX Nausea3D Turbo card - or even a decked-out Octane - at some 3D applications (namely those that don't rely too heavily on the CPU) especially considering the triple-accelerated Moore's Law that's been in effect in the graphics industry since then. Unfortunately, support for this machine was killed in IRIX versions beyond 6.2, which means no Quake on Crimson. Even with that in mind, keep your eyes open on the second-hand market for one of these astounding red-maroon cubes - even if they do weigh 300 pounds, even if they can't run Quake, and even if they are illegal to run at home. The law was made to be broken, folks!

    (Accept nothing less than RE graphics, though; the next step down, VGX, is far inferior to the RE, and is optimized for the long obsolete IrisGL, not OpenGL.)

    In the following table, I include the 33MHz R3000 Indigo for the sake of completeness. I feel that, in general, R3000-based SGIs are just too old to be of serious usefulness to the average person in the market for a used SGI, except for very light utilitarian tasks. R2000 and M68K SGIs - those that haven't fossilized yet - belong in a museum, not in your house.

    The Table

    You'll notice that the Onyx, Onyx2, Origin, and Challenge series weren't included - they won't be unless I get some volunteers to cover them for me, in part because I know little about them, and in part because their size and power consumption makes them impractical and illegal to run in residentially-zoned areas, at least in the US.

    As for SGI's x86 ("IA-32") lines, I'm not covering those in part because you're already pretty familiar with them if you're familiar with PCs in general, and in part because I don't like them. If you wish, you can write up a section on them yourself and I'll add it to the page.

    In Depth

    IRIS Indigo
    Overview
    Considered by many to be the best-built and best-designed workstation ever made, the IRIS Indigo (usually just called Indigo) was the first SGI to sport a hip color case. It was originally marketed as the "IRIS Indigo RISC/PC," which symbolized SGI's desire to make it integrate more smoothly in a networked PC/Macintosh corporate environment.

    What is the "IRIS" for, you ask?

    Physical characteristics
    As much as I love SGIs, no one is going to convince me that the Personal Iris, in its cheap-looking diarrhea-brown plastic enclosure, was not one of the ugliest computers ever made. Even SGI knew this, and usually shined colored light on it in pictures to hide its physical resemblance to a block of frozen poo. The Indigo is a huge improvement. At the time, its blue color was quite radical in a land of beige and more beige. Now that Apple has come along and made beige un-hip, though, the Indigo seems downright conservative.
    Processors
    The first generation of Indigos used the good ol' 32-bit MIPS R3000 CPU, running at 33MHz. Although comparing speed to a PC is difficult, some say that its integer performance is about on par with a 66MHz 486, while its FP speed is around a 90MHz Pentium's. I would say its integer speed is more in-line with a 50MHz 486, but really, at these speeds, what's the difference? In any case, the 486's FPU was a total piece of crap, when it had one at all, and it's no surprise that the R3000 leaves it one bitch-slap short of a police report.

    The second generation of Indigos moved to the 64-bit R4x00 series: The R4000 running at 75 and 100MHz (the latter much more common) and the R4400 running at 150MHz. At 75MHz, the R4000 was not available with secondary cache. At 100MHz, secondary cache was optional. Secondary cache was mandatory with the R4400.

    The R1000 - before MIPS existed as a company - originated at Stanford, if I'm not mistaken, and was the first RISC CPU. The R4000 was another MIPS milestone: It was the first 64-bit CPU. It has been said that the integer speed of the 100MHz R4000PC is comparable to a 90MHz Pentium's (which has the advantage of secondary cache), while its FP speed is comparable to a 133MHz Pentium's. (Add 20-30MHz to both for the SC version.) The 150MHz R4400SC's integer speed is somewhere between a 150MHz and a 166MHz Pentium's. Its FP speed is between a 150MHz and 180MHz Pentium Pro's. The R4000 series, especially the R4400 and R4600, were not known for their FP performance.

    Graphics
    The first generation of Indigos had fairly crappy (but great for the time) 8-bit graphics called LG1; these graphics could display only 1024x768 and offered no hardware 3D acceleration. Keep in mind, though, that these graphics were decent for their time. LG1 graphics output an ordinary fixed-sync VGA signal through a standard HD15 connector, unlike later graphics in the Indigo.

    The second generation of Indigos offered five far superior graphics options: 8-bit XS, 24-bit XS (XS-24), 24-bit XS with a hardware z-buffer (XS-24Z) XZ, and Elan. XS graphics have 1 geometry engine; XZ has 2; Elan has 4. XZ and Elan have similar (slow) 2D speed; XS is faster at 2D. All of these graphics systems can display 1280x1024 (at 72Hz, I believe) at maximum.

    Also, XS/XZ/Elan graphics boards support 3D stereo graphics, and have on-board genlocks.

    Commenting on performance differences between LG1 and later graphics options, Sean writes, As a former owner of a R4000SC (100mhz) based Indy (XL 8-bit graphics), and still an owner of an R4000SC Indigo (LG1 "Entry" Graphics), I can assure that the graphics option seems to make quite a difference in the speed feel of the machine.  Both of those machines had 96MB of RAM, and both ran IRIX 6.2.  I didn't do 3D stuff, just screwing around, browsing with Netscape, etc.

    The Indy's speed felt exactly like my Pentium-90 Thinkpad (running Redhat 6.2).  The Indigo, however, is much slower.  Either the unaccelerated LG1 graphics are the bottleneck, or perhaps limitations of the Indigo backplane make it slower, but it's discernably slower than the Indy was, and slower than a 90mhz x86 machine.

    My guess is that the XL graphics are good for more acceleration than one would think.

    Environmental characteristics
    Drives
    The Indigo is equipped with one internal and one external SCSI-2 bus. These are both 10MB/sec. The external connector is a SCSI-1 CN50 (50-pin Centronics). Internally, all drives must be mounted on their own sleds, which are, of course, proprietary, expensive, and hard to find.
    Networking
    The only network port on the Indigo is for AUI Ethernet, which allows for 10Mbps max, half-duplex. This is no problem if your Ethernet network is based on twisted-pair cable - all you need is an AUI/10BaseT transceiver, which effectively plugs into your AUI port and changes it into a 10BaseT port.

    If you need 100Mbps Ethernet, you can add Phobos' GIO32 100BaseTX card.

    Audio
     
    Reliability
    The Indigo is almost as solid as the Indigo2 that replaced it, which would make it comparable to a Humvee on the solidness scale. Many R3000-based Indigos are still alive and well, even after nine or ten years of running constantly. Be wary of putting computers this old into service in important positions, though, as likelihood of failure increases with age.
    Related
    Craig Magaret's Indigo Page

    Indy
     

    Overview
    The Indy was the fruit of SGI's effort to muscle into the markets for desktop publishing, low-end CAD, and multimedia that, at the time, were dominated by Apple and specialized PC manufacturers. It was the first computer to include a digital video camera as standard, and SGI's attempts to prepare it for the future included a standard built-in ISDN adapter. With the inclusion of analog and digital I/O, SCSI, and standard composite and s-video inputs, the Indy really was a multimedia machine.

    At the beginning of its life, the Indy came standard with 16MB of RAM. IRIX 5.1, the first OS for the Indy, was the Windows NT 4.0 of Unices, magically able to, performance-wise, transform an R4000PC Indy with 16MB of RAM (the standard configuration) into a 386SX with a weird blue box.

    SGI realized this and quickly upped the box to 32MB, at considerable cost. (As you may recall, 16MB of parity 70ns RAM was hardly cheap in 1993-1995.) Subsequent IRIX releases made huge improvements in memory usage.

    Physical characteristics
    The Indy packs a decent amount of power into a very small (16"x14"x3"), simple, and elegant package. The chassis is just three parts: The "tray," which is sheet metal; the power supply; and the skin, which is a one-piece plastic cover with a thin sheet of metal covering the bottom of it to meet FCC compliance. The steel tray occupies the entire depth of the Indy, but not the entire width; four inches or so of the left side belong to the power supply, which occupies the entire depth of the tray and is a separate box. The whole unit is, although well-built, very economical and, dare I say, cheap. Speaking as someone who has had an opened-up broken Indy sitting on his basement floor, this is not a machine that screams "I cost $10,000." It's obvious SGI made a darn nice profit off these buggers.
    The "door" of the optional magneto-optical drive is on the right side of the case, toward the front. The Indy is tall enough to hold up to two 1" drives internally; they are positioned behind this "access hole." There are no eject buttons (except for the paperclip emergency eject hole) for the optical drive; disks must be ejected via software. This drive uses obsolete 21MB media cartridges that have vanished from existence, but it can also read and write 1.44MB floppies, I think.
    The Indy is surprisingly durable. It is, of course, built to sit under huge monitors weighing upwards of 75 pounds. I am a 135-pound shrimp, and I was able to stand on the center of mine with one foot without even flexing the top plastic. In fact, this is what I usually do in my spare time. Small steel supports inside, which screw through the top and bottom of the graphics board, support the lid. Without these in place, the top plastic would surely sag, under a monitor's weight
    Processors
    Early Indys used the 100MHz R4000 CPU, which quickly proved inadequate. So the Indy, at the bottom of SGI's price list, became the primary platform for MIPS' new "low-cost," low-power-consumption R4600 series of CPU. The R4600 had impressive integer performance, but lacked floating-point capability even moreso than its big brother, the R4400. This, however, wasn't too huge of a problem in a box that was generally not designed for FP-intensive applications. And the R4400 was an option, anyway. For this reason, the R4600 made an appearance outside the Indy line just once, and only briefly, in the Indigo2.

    Both PC and SC R4600s are common in the Indy. The SC variant at any clock rate can be anywhere from 20 to 40 percent faster than the PC.

    The Indy was also the first SGI to utilize the R5000 CPU, which offered significant advantages over the R4400 and R4600 it replaced. The Indy's 180MHz R5000 module can be "overclocked" to 200MHz by replacing its crystal oscillator chip, with no apparent loss of stability; I'm not sure about the 150MHz variant, though.

    Graphics
    There were three graphics subsystems available: 8-bit XL, 24-bit XL, and 24-bit XZ, which came a little later. Each of them were limited to 1280x1024 resolution.

    8-bit XL

    Also known as Newport graphics, these were designed for general 2D X11 applications and not much else. If you don't need to surf the Web, these graphics work just fine for 2D CAD or software development. Or at least, they used to, back in the day...
    24-bit XL (XGE)
    These were the same as 8-bit XL in every way except color depth. 2D speed was pretty good, but 3D still was not, as everything was still done in software. If you're not planning on working with 3D graphics at all with your Indy, these graphics would probably be your best choice, because XZ is slower overall at 2D X11 tasks.

    In an R5000 Indy, these graphics are called XGE. Reason being, an R5000 CPU can perform more FLOPS than the XZ subsystem's two GEs - therefore, all 3D is done in software, faster than hardware XZ. XZ graphics were never paired with the R5000 for this reason.

    XZ
    These graphics were a port of the Indigo2's XZ (Elan) graphics into Indy - they offered very good non-textured 3D performance at the time, sacrificing a bit of 2D performance in return. In R5000 Indys, they were sacked in favor of software 3D, because software 3D on an R5000 is faster. These graphics take the form of two boards, one on top of the other, and occupy one GIO slot.

    See also this tidbit in the Indigo2 graphics section.

    Video
    The Indy was the first and only SGI to have video inputs by default. Each and every Indy has a composite, s-video, and digital video input built into the motherboard, which collectively are known as "Vino" video. None of them are of professional quality, but are still usable. The digital input is a weird proprietary D-sub with a rectangular array of pins, and is used by the IndyCam. It is proprietary, not DVI.

    The maximum supported input resolution is 640x480 (NTSC) or 768x576 (PAL). It takes a fast machine to capture at either of these resolutions, though; if you have, say, a meager 133MHz R4600PC CPU, you're going to have to lower the input resolution. However, if all you want to do is display the video on the screen without capturing to disk, the Vino hardware is capable of DMAing directly into video memory with only trivial CPU overhead.

    None of the Indys support a video output by default - that would require the Indy Video GIO32 card. On top of that, there is an optional module called CosmoCompress, which offers on-the-fly JPEG video compression and decompression and uses up another GIO32 slot.

    Environmental characteristics
    Heat
    Inside the small enclosure, there's not a lot of room for large fans and such. Most Indys have power supplies custom manufactured by Nidec/Power General, which use one fan for cooling aimed 45 degrees downward and outward. That's the only thing mechanically keeping the Indy cool. In terms of vents, the entire rear of the unit is riddled with little holes for ventilation, but the only vents on the blue plastic are in the rear right and front left (at the end of the power supply box).
    Later Indys have a Sony power supply which, I hear, have a fan that does not run. Most likely, there is a temperature-sensing circuit somewhere that turns it on if things get too warm. In any case, the Indy is the most sensitive of all SGIs to its surrounding environment.
    Noise
    In Indys with Sony power supplies, the only noise produced is from the hard drive. The Nidec/Power General power supply causes the Indy to make noise, but only about as much as the average desktop PC.
    Drives
    A word about the SCSI controller onboard the Indy, Indigo2, and Challenge S: It's a finnicky little bastard. On the PC, you might be able to get away with using a passive terminator on even the latest SCSI CD-ROMs. On an Indy/Indigo2, forget about it. On the PC, you might be able to get away with using cables that are kind of long and/or are perhaps not as well-shielded as they should be. On an SGI, you wish. The SGI-designed WD33C93B SCSI controller is truly as anal-retentive as SCSI controllers come. Keep your cables as short as possible, keep them well-shielded, make sure all connections are clean and secure, use active and only active terminators, and pray to the almighty SCSI gods before mounting your disks.

    Drives. Right. The Indy, as I mentioned, has room inside for two 1" drives. The only requirement is that you use cool drives, which is to say cool as in temperature, not cool as in big and fast, though big and fast drives would be great as long as they're also cool as in temperature.

    Keep in mind that the earlier the drive of a particular spindle speed is, the more heat it is likely to generate. Early 7,200RPM drives got quite hot, but technology has improved enough to make this pretty irrelevant. The earlier advice was to limit the Indy to one 7,200RPM drive internally, with 5,400RPM being the maximum for two drives internally. Nowadays, it may be safer to use two 7,200RPM drives or one 10,000RPM drive internally, but as always, be careful. See also the Reliability section.

    Networking
    All Indys shipped with AUI/10BaseT Ethernet and ISDN as standard equipment. The Ethernet ports are half-duplex only, and are mutually exclusive (you can use one or the other, but not both). The 10BaseT port takes precedence over the AUI port - if the system detects a carrier on both ports, it will use the 10BaseT.

    If you need 100BaseTX Ethernet, you'll need the expensive GIO32 NIC from Phobos, which, as of October 2000, is still sold.

    The ISDN port has no NT1, whatever that is. You will need to pick up an external NT1 if you wish to use an ISDN network connection.

    If your Indy came to you with a red triangle sticker over the ISDN port and a rather harshly-worded warning on the bottom advising you that your immediate family would be raped and tortured by armed Chilean guerilla fighters if you connected the onboard ISDN port either directly or indirectly to the public phone system, it's safe to disregard it - apparently some Indys shipped before the ISDN standard was finalized in Europe. It's finalized now, of course.

    Reliability
    The part of the Indy most prone to failure is the Nidec/Power General power supply. This is really too bad, because these power supplies are very complicated and difficult to repair. The failure of so many of these things have caused prices for individual power supplies - even of this model - to be quite high. $150-$200 is pretty common as of August 2000. The Sony power supplies, however, go for $250 and up, as of the same date. Compare this to the fact that whole Indys without hard drives frequently sell for $50 on eBay at this same time, with working Sony power supplies, and you'll leave scratching your head. Just when you thought you knew all about the market economy...
    Another thing worth mentioning is that the Indy's Ethernet address, which doubles as the system's serial number, is stored in battery-backed RAM. This means that when the internal battery dies, so does the system - it will hang at the PROM montior and refuse to boot any further as a result of the Ethernet address being all FFs.

    All things considered, the Indy is probably a bit less reliable than other SGIs of similar age. Perhaps this is because their internal components were not as well cooled as other machines' were, or perhaps it's because they simply weren't built with as much quality in mind as the more expensive SGIs of the period. Of course, I could be wrong - there are still many Indys running without a hitch today.

    As with anything else, keep the Indy in a cool, dry place. Although there is a lot of talk about keeping the skins on your machine in order to prevent overheating, the Indy is the one SGI box I would recommend keeping the skins off of if you're really worried about overheating or are using especially warm hard disks without an external SCSI case - provided you can keep dust under control. There's not much ventilation inside the thing anyway, and the only function the lid provides is to make it harder for heat to leave the box. In any case, pointing a small desk fan right into the right-side ventilation grille (or into the innards if you've got the plastic off) would help a great deal to cool the unit.

    Related
    IndyTech, by Reputable Systems, is a very thorough guide to Indy hardware.

    Indigo2
     

    Overview
    After the Indigo, which was the bridge from the older 4D series into the "next generation," SGI once again divided its product lines very clearly:  digital media/entry-level 3D/entry-level graphics (Indy); high-end 3D, CAD, and imaging (Indigo2); very high-end visualization and simulation (Onyx); and all levels of Internet, database, file, and application servers (Challenge). In 1993 - the year Indigo2 debuted - its graphics capabilities were hands-down the best on the desktop.

    Although it looked nothing like the Indigo it replaced, it was actually an expansion on the Indigo platform. It upgraded the GIO32 bus to GIO64, and added EISA slots for extra expandability.

    Physical characteristics
    The Indigo2 is, perhaps, the best-built under-the-monitor workstation ever made. It's 19 inches square and 5 inches high, but it weighs considerably more than most solid steel full-tower PCs. The "fins" that extend all the way down the left side of the plastic enclosure are not just decoration; the entire left side is a vent for the EISA/GIO backplane and the huge graphics board(s). R4400 and R10000 Indigo2s have huge heat sinks, but CPU fans are present only on the R10000s.
    At 40 pounds, the Indigo2 is built like a tank. The front bezel and door have a tendency to break, probably most often from weak people like me trying to heave 80 pounds of Trinitron onto the unit and banging into the front in the process, as do the small plastic hinges that help guide the lid into place in back. But the metal chassis could probably survive being thrown off a 5-story building onto solid concrete at least twice. Just in case you were having trouble deciding on the perfect used workstation to chuck off a building.
    Although designed to be placed underneath a monitor, SGI included a set of matching-color tower feet with all Indigo2s, allowing them to stand up vertically, left side (fins) down. These feet raised the units a few inches so as not to impact airflow from the fins. As long as the unit is on a flat, hard surface, though, the feet are not essential, at least in my experience with the XZ boardset - the fins themselves provide enough ground clearance.
    Processors
    The very first Indigo2s shipped with 100MHz R4000SCs. Units equipped with these are even harder to find than those with R8000s. SGI quickly switched to the R4400 series, which became the flagship high-performance MIPS chip from the time of its release until the debut of the R10000 (in 1995-1996 or so).

    The Indigo2, compared to the Indy, was clearly SGI's higher-end machine, and therefore, fewer compromises were made for price. All CPUs in all Indigo2s have secondary cache.

    The R4600 made an appearance in this line just once, at 133MHz, with its usual 512KB of cache. This chip at this clock had better integer speed than the R4400SC at 150MHz, but inferior FP speed.

    Even the R4400 was not the greatest floating-point performer. Though clearly superior to any x86 chip of the time, several competing RISC CPUs were still faster. SGI realized this, and made every effort to minimize the problem. Borrowing a chapter from Intel's book, it clocked the hell out of the chip. At the end of its life, the R4400 had reached 250MHz and had 2MB of secondary cache. (And a massive heat sink.) That doesn't sound like much today, but keep in mind that this was 1995, when the fastest PCs barely broke three digits in megahertz. Realizing that this was not enough, SGI began to roll out the R8000, which it had been working on since before it acquired MIPS, in all its product lines except the Indy. See the R8K "side" note below.

    About the R8000

    The R8000 was a very interesing slab of silicon. Although it only ever reached 90MHz (75MHz in the Indigo2), it had an amazing FPU that, when executing code optimized for it, was extremely fast (on the order of 300 MFLOPS). But only when running optimized code. Its integer speed wasn't blinding, but wasn't as bad as one would expect from a 75MHz chip. In any case, the R8000 was intended specifically for FP-intensive scientific and engineering applications. In terms of design, it was very complex, much like IBM's POWER chips. That complexity made it difficult to code for, but SGI's compilers were very good at optimizing for it.

    All R8000-based SGIs had "Power" prefixed to their names. An R8000 Challenge was a Power Challenge; an R8000 Indigo2 Solid IMPACT was a Power Indigo2 Solid IMPACT. The R8000 did not last long in SGI computers - its clock rate was not easy to increase, nor was its architecture easy to expand upon, and the more general-purpose R10000 on the horizon gave it an aura of impending obsolecense.

    Serguei Patchkovskii has this to say about the R8000 (from comp.sys.sgi.hardware): R8k was/is a tricky CPU to program right - it is an in-order superscalar design, and executes instructions in the order it sees them. It is also a bit underpowered in integer performance, which can be a problem even with some nominally floating-point codes.

    On the other hand, if you *did* manage to program it right, it is amazingly powerfull for it's age. With a well-tuned floating point code, a 90MHz R8k would often tie or beat a 200MHz R10k. (The fact that R8k was able to use much larger external caches than early/slower R10k's does help here).

    R8k also had a rather nifty (and quite rare) feature, only found in IBM Power architecture otherwise: it implemented floating point multiply-accumulate instruction in a way, which made it very easy to support efficient 16-byte floating point variables, with about twice the precision of regular doubles. Unfortunately, support for this floating point format was only included in (the exotic, and rather old) IRIX 6.0 and 6.1. SGI killed the support for the fast double-double when R10k came out (R10k implements multiply-accumulate in a different way, and cannot benefit from the trick used on R8k).

    R8k was a truly remarkable CPU for the time it came out - a real technological tour de force in scientific high-performance computing, which, for a while, promised to position SGI as a clear leader in this area. It is really a shame this promise failed to materialize, despite the outstanding system-level design of the O2000 and O3000 series.

    The R10000 finally arrived shortly after SGI was ready to upgrade the Indigo2's graphics and change to the purple cases. Even at 195MHz, it was roughly three times faster than the 250MHz R4400SC. The R10000, like the R8000, was fully binary-compatible with all code compiled for the R4x00. In the Indigo2, it was available at two clock speeds: 175 and 195MHz. It gave the Indigo2, and all SGIs except Indy (which got the R5000 instead), a much-needed shot in the arm.

    About Indigo2 R4400 heat sinks: They don't even look like heat sinks. They're aluminum and almost shaped like a box, except with tiny "fins" on top. They look more like CPU insulators than CPU coolers. They're also huge, sealed directly to the CPU module's perimeter. They are hollow, though, and the only part of the CPU module the heat sink touches is the CPU itself. R10000 heat sinks have a recession in the top inside which a fan sits. R8000 modules have two heat sinks, covering the two areas of that peculiar processor; R4600 modules have the relatively smallish Indy-style porcupine heat sinks.

    Graphics
    There are two basic generations of Indigo2: The green generation and the purple generation. In the green generation, the graphics options available were XL, XZ, and Extreme. All of these featured 24-bit color and 1280x1024 resolution at 60 or 72Hz.
    XL
    These graphics, only ever available in 24-bit for Indigo2, were optimized for 2D. They offered no 3D hardware acceleration whatsoever - everything was done in software, which meant 3D speed was directly dependent upon CPU speed. XL graphics were, however, the fastest 2D graphics available in the first Indigo2 generation, and in fact, for a short time at least, were the fastest desktop X11 graphics, period. XL graphics consist of one card.
    XZ
    This is what my Indigo2 has. The 2D speed is awful compared to a modern desktop PC. A 100MHz Indy R4000PC with 24-bit XL graphics is much faster than a 150MHz R4400SC Indigo2 XZ at 2D operations in X11 - moving windows, scrolling in Netscape, etc. Just about all 3D operations, though, are way faster than XL, given the hardware geometry engines and z-buffer. (Unless you by some chance happen to have an R10000 XL system, which SGI did not sell but may be possible to piece together.) The XZ boardset is probably the second most common set in used green Indigo2s after Extreme.
    There are two versions of XZ, distinguished by their names in hinv: GR3-XZ and GR3-Elan. GR3-XZ is the earlier version and has two GEs (geometry engines). GR3-Elan came later and is identical except for having four GEs. Both are a two-board set; the latter is often called just "Elan," even though its official name is XZ - reason being, the graphics with 4 GEs in the original Indigo were called Elan.
    Extreme
    For a time, Extreme's 3D graphics were the best on the desktop. These debuted about the same time as XZ and offered slightly better 2D and much better 3D - theoretically four times faster, taking into account the 8 geometry engines vs. XZ's 2. Hinv calls these graphics "GU1-Extreme." They consist of three double-sided boards - six entire full-length EISA-sized sides of PCB surface area.
    The purple generation signified Indigo2's transition to IMPACT graphics, several versions of which were available:  Killer, Solid, High, and Maximum. All of the IMPACT versions have theoretically identical, but much better, 2D performance. They also offer other improvements over the first generation of Indigo2 graphics, such as 48-bit RGBA color (vs. 32-bit RGB), a hardware 32-bit z-buffer (earlier graphics had a 24-bit Z and had to do 32-bit Z in software), and the ability to do stereo in a window.
    Killer
    A Killer IMPACT boardset is a Solid IMPACT boardset; SGI called a Solid IMPACT having a 175MHz R10000 instead of a 195MHz R10000 a Killer IMPACT. There are many Killer IMPACTs making the rounds on eBay these days, but the sellers are pseudo-lying and calling them Solids (which is why you hardly ever see Killer Indigo2s for sale used). What a fab name though, huh? I want a computer called "Killer." A shame that this was the weakest of the bunch.
    Solid
    These graphics, as they are named, are intended primarily for solid modeling - 3D tasks which don't involve texturing. At anything not involving texturing, this boardset is very fast - theoretically just as fast as High IMPACT. Unfortunately, Quake involves texturing, so don't expect anything more than a few frames per second at 1280x1024 even with a very fast CPU.
    High
    High IMPACT graphics were the entry-level option for hardware texturing on the desktop. These are basically just the Solid IMPACT boardset with additional texture processing chips. High IMPACT systems were sold with a paltry 1MB of RDRAM texture memory, which was very proprietary and very expensive (indeed, one would expect no less from Rambus), though they were upgradable to 4MB. But nothing more or less.
    Maximum
    Max IMPACT is High IMPACT on steroids. It does everything that High IMPACT can do, only it does it anywhere from 20 to 100 percent faster. 4MB of TRAM (texture RAM) comes standard with Max IMPACT, and the maximum screen resolution increases to 1600x1200 @ 60Hz. Many Max IMPACT systems are still in service today.
    Environmental characteristics
    Heat
    The Indigo2 puts out a lot of heat - the purple more than the teal - but thanks to the exceptional cooling of the system, it's not much of a worry. Put your hand anywhere on the front of an Indigo2, and you'll feel the suction.

    The hard drive in my Indigo2 is an SGI-original 5400RPM Seagate Hawk ST31200N, installed in the bottom 3 1/2" slot. Even after days of continuous running, no part of it is even warm to the touch - even while it's running. Either it's an extremely efficient drive, or the Indigo2 has awesome cooling. Judging by the fan noise, I have to lean toward the latter.

    Noise
    Even without a CPU fan, the Indigo2 is not exactly quiet. SGI apparently took little notice of the fact that the two fans in the unit (three in R10K systems) - one in the front left corner and one in the power supply in the rear right - generate a considerable amount of noise. My Indigo2 with these fans and a 5400RPM SCSI hard drive is significantly louder than my PC, which is a full-tower model with two hard disk cooling fans, a power supply fan, a CPU fan, a chassis fan, and a 7200RPM SCSI HD. This white noise source can be extremely annoying, especially when working with audio. The Indigo2 may have been marketed as an under-the-monitor desktop computer, but you'll probably want to put it under your desk, or perhaps in a nearby closet.
    Drives
    Inside the Indigo2, there are two 3.5" drive bays and one 5.25" drive bay. Drives must be mounted on proprietary sleds, third-party versions of which used to be very expensive but are now worth little more than their weight in metal. SGI doesn't recommend mounting a 3.5" drive on a 5.25" sled; they say it can negatively alter air flow in the system, but I take that as SGI's way of saying, "We would like you to pay us an even more money for an external hard drive."
    Earlier Indigo2s support plain 10MB/s SCSI-2 (not wide, not Ultra). Later Indigo2s feature 20MB/s narrow Ultra SCSI. All drives must be SCSI-compliant and able to support a block size of 512 bytes. SGIs are generally much more picky about total SCSI-2 compliance than PCs. SCA disks can't generally be used - there is not enough room on a 3.5" Indigo2 drive sled for a SCA adapter. The connector that the drive sled fits into looks like SCA, but isn't. It would theoretically be possible to modify a SCA connector to fit this proprietary adapter's pinout, but it would be a fair amount of work, and seeing as how this connector also supplies power to the drive, one mistake could lead to disaster.

    Curious readers may be wondering whether it is possible to install a 68-pin drive on a 3.5" sled using a 68-to-50-pin adapter. On this subject, James Holden writes, I have this setup running in my I2. It's a Fujitsu 9.1GB 10k RPM drive with a 68 pin connector. I'm not able to screw the drive to the sled though, as the adaptor takes up too much space. The drive and sled fit in the bay though, and the front cover just about closes. Incidentally, drive sleds are cheap enough if you look on eBay, I picked one up last week for less than ten USD. In fact, the shipping to the UK was *more* than the sled!

    Indigo2 drive sleds used to cost hundreds of dollars. What a steal! James also offers photographic evidence of his impressive feat of SCSI connectory mojo.

    Russell Elliott confirms that using such an adapter on such a sled is possible, writing, I've got a 68pin 36.5Gb SCSI drive running in my Indigo2 no problem. ... It was a bit tight, but the cable didn't look like it was bent that much that it would be a problem. The converter I got with the drive was about 2cm deep, and I tried to get the drive as far forward on the sled as I could.

    Given the Indigo2's excellent ventilation, you should be able to have all three bays full of hot drives if you so wish. Although I haven't tried it myself or heard anyone's input, I would be willing to bet that three 15,000RPM drives would be no problem in an Indigo2. Of course, an external enclosure is always the best way to keep drive heat out of a machine.

    Networking

    10BaseT and AUI Ethernet ports are onboard. As with the Indy, they are mutually exclusive - you can use one or the other, but not both at the same time. And also, as with the Indy, they are both half-duplex, with the 10BaseT port taking precedence over the AUI port if both are connected at the same time.

    For 100BaseTX Ethernet, there are several third-party options available. Phobos used to make a 100BaseTX EISA card for the Indigo2, the E100, which cost upwards of $500. Being a standard EISA card, though, SGIs were not the only computers in which they could be found. The E100 was actually merely a rebadged 3Com 3C597 for which Phobos wrote IRIX drivers and jacked the price through the roof. James Holden writes in and once again says it best: The section on Indigo2 networking, mentions the 3Com 3C597TX card. The 3C597TX can be found in many old Dell and Compaq servers and I picked one up for 2 UKP off (you guessed it!) ebay.

    The drivers are quite easy to get, and Ian Mapleson has an install guide at: http://www.futuretech.blinkenlights.nl/fastether.html.

    Previously, this card was not supported in IRIX for lack of drivers. This is great news for Indigo2 users everywhere, as it means that they will now be able to add a second, reasonably fast Ethernet interface for dirt cheap.

    Even though the E100 (3c597) claims 100Mbps, you will only be able to achieve a fraction of that speed over the EISA bus. To reach that full 100Mbps, Phobos also offered a GIO64 Fast Ethernet adapter - the G160 - and as of October 2000, it was still being manufactured, according to their web site. (It has since been discontinued.) Both the E100 and G160 are supported in IRIX 5.3, 6.2, and 6.5. The G160 used to be very expensive, but it has plummetted in price in the past couple years, as with everything else in the used SGI world. Russell Graves informs that it can be found on eBay for $50 to $80 as of March 2003 - a fraction of what it used to cost.

    Reliability
    Prices on the market are very low for units of '93-'94 vintage, indicating that there are many high-quality machines of that era still alive and operating well.
    Pictures
    These pictures are all 2 megapixels and 150-350KB each. I'll upload them some day in the distant future when I have enough web space. In the meantime, if you'd like to see any of them, you can e-mail me and I'd be happy to send any of them to you.
    • Alex Dolski
      • Teal Indigo2, top down, lid off
      • Teal Indigo2, top down from rear, lid off
      • Teal Indigo2, diagonally from EISA slot side, lid off
      • Teal Indigo2, slot cover down revealing XZ graphics cards
      • Teal Indigo2, top down, lid off, 5 1/4" drive bay removed
      • Underside of an R4400SC CPU module
      • Side of an R4400SC CPU module with heat sink attached
      • Top of an R4400SC CPU module with heat sink attached
      • IP22 motherboard under the removed 5 1/4" drive bay (1)
      • IP22 motherboard under the removed 5 1/4" drive bay (2)
      • Teal Indigo2, top down from rear, lid off and 5 1/4" drive bay removed
      • IP22 motherboard under the removed 5 1/4" drive bay (3)
      • Upper surface of the top XZ graphics card
      • Top of an R4400SC CPU module with heat sink removed and thermal pad attached
      • Diagonal view of R4400SC CPU module with heat sink removed and thermal pad attached
      • Top of an R4400SC CPU module with heat sink and thermal pad removed
      • Underside of the heat sink of an R4400SC CPU module
      • Underside of an R4400 CPU
      • Top of an R4400 CPU
      • Top of an R4400SC CPU module with heat sink and CPU removed

    O2
     

    Overview
    Probably the epitomization of SGI style, the O2 set the standard for power and efficiency in a small space. It picked up where the Indy left off in every respect, offering things like hardware texturing, more versatile video I/O, greater expandability, and faster processors. Its imaging abilities were improved and its graphics subsystem - make that all of its subsystems - were built from scratch. Audio I/O of course came standard, but unfortunately, video I/O - which included both analog and digital ports - was sold as a very expensive option.

    Still, SGI clearly had video manipulation in mind during the design phase of this machine. The O2 is a fine video editing machine, although perhaps not as fine as a Power Mac.

    The O2's massive I/O is facilitated by its unified memory architecture, which transcends the concept of a point-to-point bus and allows for memory bandwidth up to 2.1GB/s.

    All that said, it's kind of a shame to see the once-proud SGI still selling these things. They're over five years old now, and they have not been following Moore's Law even remotely closely. Virtually every part of them is dated. They were great, fast machines in 1996. They're still great, but they're no longer fast by any stretch. And they look quite stupid in purple with that pitiful "sgi" logo on them.

    Physical characteristics
    Perhaps the first impression this blue box makes is its tiny size. Smaller than even the compact Indy, the O2 is often compared to a toaster. It's just a bit larger than an Apple G4 Cube, and smaller than a mini-ATX PC...

    ...But it's better looking than both, and it's actually surprisingly expandable. There is room inside for two hard disks in addition to the CD-ROM, and there are two optional PCI slots. All in a tiny toaster.

    Processors
    In 1996, the O2 launched with the R5000 CPU at two clock speeds, 180 and 200MHz, with and without secondary cache. A few months later the more robust R10000 was brought into the O2 at 150 and 175MHz, both with secondary cache.

    The O2 was not originally designed with the R10000 in mind. Early revisions of its chipset did not deal well with the R10000, resulting in marginal speed gains at best over the R5000. This problem was, for the most part, corrected not long after the system's launch, and the extra several thousand dollars that an O2 with an R10000 cost became justified.

    In late 1996, the fastest x86 integer CPU was the Pentium at 233MHz, and the 195MHz R10000 was able to beat it hands-down. But when late 1997 rolled around and the R10000 was stuck at 225MHz (?), with Intel at 300MHz using the Pentium Pro core, the story began to change - Intel, for the first time, pulled ahead in integer speed. This is not to mention Sun, DEC (then Compaq, then HP), IBM, etc.

    SGI is not a company known for matching step with its competitors. Indeed, the CPUs of Intel and AMD (and also DEC/Compaq and IBM/Motorola) certainly improved faster than SGI's MIPS lines. This can probably be at least partially attributed to SGI's overall retardation from late 1997 to early 2000 or so, as the company embraced Wintel, questioned MIPS/IRIX, and in doing so hesitated to make serious improvements in its MIPS CPUs until its "roadmap" was clearly defined.

    In short, the O2 was lacking in CPU power for a long time, and still is. The R12000 is here at 400MHz, and so is QED's MIPS IV-compatible RM7000, but with Pentium 4s set to break the 3GHz barrier and showing no signs of slowing down, the technologically superior architecture is losing out against the technologically inferior but faster-clocked architecture.

    Graphics
    Another unique thing about O2 is its graphics subsystem. Instead of getting 2D image operations done the "old-fashioned," brute-force way, as with previous systems like Indy and Indigo2 and modern PCs, the O2 relies on dedicated image processing hardware to deal with certain image and video manipulation tasks.

    The centerpiece of O2's image manipulation abilities is the ICE, or Image Compression Engine, which is a custom 66MHz R3000 processor capable of hardware acceleration of many graphics operations in applications like Photoshop and imgview, real-time playback of NTSC/PAL format video in a variety of formats, and more.

    Unfortunately, the ICE is not used at all in any application not explicitly written to support it. This means that basically 99.9% of all the software that runs on the O2 still does everything in software. Which is not to say that things are slow per se, but hardware acceleration always helps.

    The O2 is, of couse, the Indy's replacement, and just like the Indy, it isn't really intended for heavy 3D tasks. But it's still much better than the Indy at virtually every 3D application, because unlike the Indy, it supports some very useful graphics features like texture-mapping and mip-mapping in hardware. (Geometry is still done by the CPU.) It also sports a 32-bit hardware z-buffer. What does this mean? It means that Quake 2 is actually somewhat playable!

    One downside of the O2's display is that it's limited to 1280x1024 resolution (or 1920x1024 on a 16:9 display). Not such a bad thing when you're coming from a 1024x768 world, but a real kick in the groin when you're used to 1600x1200 or higher. One would think that a $10,000 graphics workstation would be able to at least equal a $50 PC video card's maximum resolution... oh well.

    See also Ian Mapleson's Melting the ICE.

    Environmental characteristics
    Heat
    One would think that so much power packed into such a tiny enclosure would generate a temperature high enough to be a cause for concern. Not really. The O2 has one small vent in the black plastic of the front of the case, but a huge vent in the rear. Air is sucked by the power supply fan from front-to-back efficiently and quietly.

    Two 7200RPM disks should be no problem inside an O2. Two 10000RPM disks is pushing it. As always, if you're worried about heat, use an external enclosure.

    Noise
    The O2 is not much louder than an Indy with a Nidec/Power General power supply. The R10K/R12K(/RM5200?) models have a CPU fan, but even in addition to the power supply fan and the hard disk, the system is not exactly loud. Its plastic chassis serves as good sonic insulation.
    Drives
    The O2 took a big leap over the Indy in having a much faster SCSI interface built-in. The Indy, of course, was limited to 10MB/s SCSI-2, whereas the O2 is capable of 40MB/s Ultra-wide. The O2 is not limited in the size of drives it can support. As long as it's SCSI and not too buggy, it should work.

    Also unlike the Indy, a standard SCSI CD-ROM drive is built into the chassis. Early O2s sported a zippy 4X drive, then upgraded to 12X, then 24 and 32X as drive technology improved. All O2s shipped from the factory with Toshiba CD-ROMs.

    Networking
    The only Ethernet port on-board the O2 is for 10BaseT/100BaseTX Ethernet - it's full or half-duplex in either mode and autosensing.
    Audio
     
    Reliability
      The O2 has a higher ratio of plastic-to-metal than prior SGI computers. This has prompted some to assume that the O2 is of lower quality than its predecessors. But what the O2 lacks in physical build quality it makes up for in a genius design that looks great while still allowing for sufficient cooling. The O2 is really no less reliable than the Indy it replaced. In fact, given the Indy's notorious power supply problems, it may even be more reliable.

      Some people complain about weird noises showing up over time coming from the power supply. This is probably a result of the power supply's cooling fan getting dirty. Cleaning out all the grime and perhaps oiling the ball bearings reportedly solves the problem.

    Related
    Octane/Octane2  
    Overview
    With pants-wetting I/O capabilities, bad-ass looks, and serious graphics muscle, the Octane is a desktop workstation to be admired. The Octane got rid of the bus and switched over instead to the crossbar, which provides an extremely high-bandwidth link between whichever subsystems happen to need one at the time. The result is a killer machine with the best I/O on the desktop since 1997, and a worthy replacement for the Indigo2.

    The Octane and Octane2 are melded into the same section here because they are no more different from each other than the Indigo2 and Indigo2 IMPACT are from each other.

    The Octane has become quite popular in the used SGI market recently; used Octane prices have fallen through the floor into sub-$500 territory.

    Physical characteristics
    A frontal shot of the Octane does not do it justice. The true badassedness of the Octane is seen from other angles. There is a huge air scoop in the front, but it can only be seen from the left side. On the top side corners there are more huge air vents. In the back, there are two more huge vents, these being for fans.

    If the Indigo2 was a tank, the Octane is a bank vault. It occupies almost double the volume of an Indigo2, and is about 15 pounds heavier (54lb total, according to SGI's PDF datasheets).

    Unlike the Indigo2, there is no room for internal 5.25" drives in an Octane - just enough for two hard disks and one 3.5" drive (which is usually a DAT drive, but can be a third hard disk if you wish).

    The Octane uses an upgraded version of GIO called XIO. PCI is available as an option; the slots are housed in a modular "card cage," and that card cage, even though hardly electronically sophisticated, must be purchased separately for several hundred dollars.

    Processors
    Early Octanes, like the late Indigo2s, offered 175 and 195MHz varieties of the R10000SC. These speeds were later stepped up to 225MHz and 250MHz, but not soon enough. The R12000(A), with 1 or 1MB of secondary cache, replaced the R10K in 1999, offering a choice between 270 and 300MHz.

    All Octanes support two-way SMP with processors of matching speed - definitely a welcome feature for the secondhand market, seeing as how two 175MHz processors are cheaper than one 300MHz processor at SGI's prices.

    Graphics
    All graphics options in Octane and Octane2 are XIO based, and can be interchanged between systems.

    Octane

    The *I graphics are ports of IMPACT graphics to the Octane. They are functionally the same as their respective ancestors in the Indigo2 line, but completely redesigned at the board level, making them incompatible with Indigo2s.

    SI

    SI = Solid IMPACT, using an XIO rather than a GIO64 interface. Otherwise, not much is different. Hardware texturing, though, unlike Solid IMPACT, is available via an add-on module.
    SSI
    High IMPACT. 1MB of texture is standard.
    MXI
    Maximum IMPACT. 4MB of texture is standard.
    The second generation of Octane's graphics ends in E. They are merely speed enhancements of their predecessors, with identical texturing capabilities.

    SE

    You thought Solid IMPACT was as solid as it got? Well, you were wrong.
    SSE
    Higher than High IMPACT.
    MXE
    More maximum than Maximum IMPACT. Yes, this section needs a bit of work, doesn't it?
    Octane2
    The revamped graphics hardware in the Octane2 is really the only thing that justifies the "2." As a group, the V* graphics are known as VPro. SGI released two sets of VPro at the same time, one in Octane2 and one in one of their Intel boxes. They're in no way similar - Octane2's VPro is dramatically faster and completely different architecturally.

    V6

     
    V8
     
    Environmental characteristics
    The Octane puts out more than twice the amount of heat of an Indigo2 XL/XZ, and almost twice as much as an IMPACT. But it's just as well-ventilated. It's also even louder, which is saying something.
    Drives

    Although this section still needs a lot of work, Russell Graves writes in with the following: The drive bay has 3 standard SCA80 connectors on the backplane. The drive trays are little more than a U that wraps around the front and sides of the drive. The SCA80 connector on the back of the drive connects straight to the backplane. Any SCA80 drive should work. I'm personally using a 18 gig in there.

    Networking
    The Octane has one auto-switching full- or half-duplex 10/100Mbps Ethernet port on-board. Other interfaces can be added with expansion PCI or XIO cards.
    Audio
     
    Reliability
    The most common reports of problems with the Octane have to do with their motherboards, which apparently are not as physically secured-down inside the case as they should be. Sometimes moving the unit causes this problem, and sometimes there is no obvious cause. Sometimes re-seating the motherboard can fix the problem, and sometimes the problem is more persistent. In any case, spare Octane motherboards are hard to find, and expensive if found. You may have to call up SGI.

    Aside from the small percentage of Octanes that experience the aforementioned motherboard problem, most Octanes are very well-built and just as reliable as anything else.

    Monitors

    Very big SGI monitors are selling for very cheap second-hand nowadays, and people who don't own SGIs often want to use them with their PCs. Also, often, people have acquired SGIs without getting an SGI monitor at the same time and want to know if they can use their PC monitor with their SGI. The answers to these questions are not easy. Ultimately, if you're willing to shell out some cash (anything from the price of a 13W3-HD15 adapter to the price of that plus a sync-on-green adapter), you can probably do it. There are FAQs on the newsgroups and on other web pages that address these questions better than I can, but I figure, what the heck, why not take a crack at it myself.

    If you have an SGI computer and an SGI monitor, any 13w3 cable wired straight-through should work, including those made by SGI, Sun, NeXT, and other companies. For the best image possible, use the shortest, best-shielded cable you can.

    So you want to use an SGI monitor with a PC, eh?

    So your 15" PC monitor is dying a much deserved death and you've snagged a 20" SGI behemoth off eBay in the hopes that you can use it on your PC, and you're staring at that totally whacked-out D-shaped connector on the back with three big holes and a bunch of smaller ones and asking "WHAT the HELL is THIS?" It looks like something designed specifically to frustrate you - a cable adapter company conspiracy.

    Well, that's called a 13W3 connector. SGI, Sun, and others used to use 13w3 cables because their R, G, and B signals were individually shielded (HD15's aren't), and therefore presumably, but not so much realistically, more resistent to image-degrading EMI. This was actually very convenient for them, because since the 13W3 cable was more complex and very hard to find, it meant they could charge a lot more for it.

    Yes, there is an adapter available from HD15 (the connector type used by your PC's video card) to 13W3, although you might have to look around for it. But that will only solve the physical problem of connecting the monitor to the PC. The other problem is electrical. Your PC's video card is using dedicated separate lines for horizontal and vertical sync. The SGI monitor is expecting the sync signals to not only be on the same line as each other, but on the same line as green.

    Some video cards can output a sync-on-green signal with just an extra parameter somewhere. I have no idea how to do it in Windows; using XFree86, if your card can do it, you will be able to simply add

    Option "sync_on_green"

    to the adapter definition of your XF86Config. (Note: This is dated information that may not work with newer XFree86 releases.) I can personally verify that both the Matrox Millennium G400 and Number Nine (R.I.P.) Revolution 3D are able to output sync-on-green. Most video card companies will say nothing about whether their cards can do sync-on-green, because most video card customers don't need that capability. If the tech support person from the video card company has any idea what sync-on-green is, you are very lucky, and he/she deserves a raise. If you run XFree86, look at the documentation for your card. If you can't, try Usenet.

    If your PC's video card can do sync-on-green, it will probably do separate sync at the same time, so that it can be compatible with PC monitors in addition to whatever else requires sync-on-green.

    On top of all this, it is important to know that the older SGI monitors - all the pre-GDM-xxE21 series, including GDM-20D11 and GDM-17D11 - will not sync at any resolution lower than 1024x768, with or without adapters. You can still use them with your PC, but you'll have to have Windows (or X) set to at least 1024x768 resolution, and you'll be blind until the video adapter switches to high-res. If you run some form of Unix, you can probably at least hook a terminal up to a serial port to see what's going on before X starts.

    If you do have a GDM-xxE21 monitor, though, or any SGI monitor made after these, you can disregard everything I just said. It should plug right in and accept your composite sync video card signal just fine at any resolution.

    So you want to use a PC monitor with an SGI, eh?
    It depends on your PC monitor and your SGI. If you have an O2, Octane, or R3000 Indigo, your PC monitor should plug right in. The R3000 Indigo, with its sissy LG1 graphics, will only work at 1024x768. If your monitor can't do 1280x1024, you will probably have to change one of your system's NVRAM variables via serial console in order to drop the system's resolution down to 1024x768. Otherwise, your monitor won't sync.

    If you have anything besides O2, Octane, or R3000 Indigo, your PC monitor (with 13W3 adapter) should work if it supports sync-on-green. Most newer mid-range and high-end monitors with on-screen displays can accept a sync-on-green signal. Your monitor's manual is the place you should look first.

    If you have an older or cheaper monitor, you can still connect an SGI if you acquire a sync-on-green adapter on top of the 13W3 adapter. Reputable Systems may carry these. They are not easy to find, and can cost $100 or more.

    Either HD15 or RGB BNC inputs should work, although some manufacturers allow sync-on-green on only one of the connectors. Most, however, allow sync-on-green on both. No matter how many BNCs your monitor has - 3, 4, or 5 - the only ones you need to pay attention to are the R, G, and B, because the monitor doesn't need any additional signal. As a matter of fact, in my experience (with a 5BNC Samsung 900p monitor), connecting any more than the 3 color BNCs will prevent the monitor from synching. So if your monitor has a 5BNC input and you use a 13w3-4BNC or 13w3-5BNC adapter, you may have to just let the extra BNCs dangle.

    A word about IRIX media

    So you screwed up your SGI's OS somehow and you don't know how to fix it, or your system has been cracked and you want to eliminate the possibility that one of the binaries on your system has been replaced with a trojan horse. Or you lost your root password and can't get in. Or you bought your system without being told the root password. Or...

    If it's just a password problem, and you have an XFS filesystem, you may be able to move the SGI's hard disk to a SCSI-capable PC running Linux, and patch the Linux kernel to include XFS and SGI partition support, so that you can mount the SGI disk and rewrite its /etc/passwd file. But if your SGI disk uses EFS, you're out of luck - the Linux EFS driver is, as of July 2002, read-only.

    If the above is not an option, you'll need IRIX media - the CDs that hold the most precious software on your machine. As of December 2000, you'll almost certainly pay over $100 for an illegal copy of the most recent version (6.5.x). A legit version can be obtained from SGI with a support contract, which costs massive dough. Without a support contract, it's around $600. Even if you're willing to settle for something a bit older, like 6.2, you'll still pay around $75(?). 5.3, at least $25.

    Why so expensive? Many SGI machines were sold to large companies which bought huge loads of them but didn't need separate install media for each machine. They just needed a few copies, so they could configure a few "boot servers" and have all the client machines do network installs. As a result, there are definitely more SGIs out there than there are copies of IRIX media, and as you know, low supply causes high prices.

    So you've lost your root password, but you do have your operating system media lying about. This page at Tek-Tips should be able to help you regain control of your system without having to re-install your OS, at least if you're running IRIX 6.4 (and maybe 6.3) or later. (And thanks to Russell Elliott for that tip.)

    What's the difference between all the releases? (This part needs A LOT of work! Please help me somebody!)

    Anything before 5.x (IRIS x000, Personal IRIS, Power Series, etc.)

    Prehistoric, insecure, buggy, and only usable on very old hardware. But much leaner than later releases.
    5.1, 5.2, 5.3, 5.3-xfs (all platforms)

    5.1 came out in the early '90s and was able to support SGI's new machines (Indy, Indigo2, Onyx, Challenge) while retaining support for most older (R3000-based) stuff. It also introduced the Indigo Magic user environment, which was the forerunner of the modern SGI GUI. But in the rush to ship tons of new features, the code quality suffered severely. I recently dug up something very interesting (local copy) from the Unix Haters Handbook about this.

    Although a milestone, 5.1 was slow, buggy, and leaked memory like a firehose leaks water. It's more than a decade old now, anyway; avoid it like you would avoid radioactive squirrel poop.

    5.2 was a major improvement, fixing a whole lot of bugs in 5.1 and improving overall speed by a healthy amount, especially on low-memory systems. 5.3 expanded on 5.2, with general updates, more bug fixes, more speed improvements, and minor enhancements. 5.3-xfs introduced the way-cool XFS filesystem, though EFS was still the default. 5.0 was never released, as far as I know.

    6.0 (all R8000 platforms; released ?)
    This was the first OS to include support for the R8000 processor, and ran on all R8000 platforms. It was also SGI's first 64-bit big-endian OS, and the first to use XFS by default.
    6.1 (Challenge and Onyx only; released ?)
    This release was an update to 6.0 that ran only on the Challenge and Onyx series.
    6.2 (all platforms; released late 1995)
    This release took what was at first only available on SGI's more expensive machines and made it available on the smaller and/or older machines, including Indy, R4x00 Indigo and Indigo2. Support for the R3000 was dropped in this release. This was also the last version that ran on Crimson.

    Initial versions of 6.2 didn't include support for the R10000 processor. To run on an R10K system, you'll need media that explicitly states R10000 capability:  e.g. "IRIX 6.2 with Indigo2 IMPACT 10000."

    6.3 (O2 only; released late 1996)
    This version was an update to 6.2 that allowed it to function properly on the O2, including support for the O2's new architecture and graphics subsystem.
    6.4 (Octane only; released early 1997)
    This version was also an update to 6.2, but instead for the Octane, Onyx2, and Origin 200 & 2000.
    6.5.x (all platforms; released early 1998)
    This version is an update to the entire 6.x series, and runs on every system, except Crimson, that prior versions of 6.x do. All modern SGI MIPS machines ship with 6.5.x. (The "x" is "20" as of 6/2003.) Jerry Jorgenson writes in with details about the individual 6.5.x releases:

    6.5.3 : The first release that had the nds networking mostly correct
    6.5.4: Minor changes from 6.5.3
    6.5.7: 6.5.6 broke Oracle (I never used 6.5.5)
    6.5.8: A good all around release
    6.5.14: 6.5.9 was the first release that supported the O3000 systems
    6.5.16: 6.5.15 was the first release that supported the 0300 systems
    6.5.17
    6.5.18
    6.5.19
    6.5.20 : No problems dectected so far (by me), this release has lots of enhancements such as open ldap being supported as part of the O/S rather than just freeware.

    Using CD-(ROMs/Rs/RWs) on SGIs

    It would seem that since an SGI only requires SCSI-compliant devices, any SCSI-compliant CD-ROM, CD-R, or CD-RW drive would work just fine. Sorry, but that's not the case. SGI must have thought that making a system that accepted any off-the-shelf SCSI-2 compliant CD-ROM drive would have been unprofitable. Their systems, therefore, are very finnicky about the drives they will work with. A CD-ROM drive must:
    • Support a 512-byte block size for booting. Not many drives do this properly, though it's not really the drive manufacturer's fault - SGI only requires 512-byte blocks in order to emulate a hard drive, and it is somewhat crazy that the PROM monitor can't just deal with 2048-byte blocks, since that's what ISO-9660 filesystems use. Sometimes a drive's block size can be changed with a jumper; sometimes a drive can switch block sizes on-the-fly with a software command. Sometimes the drive is stuck with 2048-byte blocks for use with PCs and Macs. If your drive can't support 512-byte blocks, it can be used in IRIX but can't be used in the PROM monitor, which means the only ways to install IRIX are from tape or over the network - you can't install it from the CD-ROM. Can your SCSI drive handle 512-byte blocks?
      • Check Brent Bates' Working CD-ROM Drive Poll Results for SGIs, even though most of those drives are really old.
      • If your drive isn't listed, ask its manufacturer. If your manufacturer actually knows, then that manufacturer is automatically cool.
      • Toshiba and Plextor drives are the most commonly recommended for use on SGIs, though some Toshibas and Plextors don't work. Some other brands' drives work too. Some don't. 2X and 4X drives are a dime a dozen on eBay.
      • Try upgrading your drive's firmware, if possible. Hope you have a PC with a SCSI controller, because you'll probably need DOS in order to run the manufacturer-supplied flash program. Otherwise, call your manufacturer and see what they can do for you.
    • Be a CD-ROM drive, probably. Believe it or not, you can't use most CD-R or CD-RW drives for reading CDs of any kind via IRIX or the PROM monitor (says Rick Verbeck of SGI). Both will recognize that the drive exists, fm will place an icon for the drive on your desktop, and IRIX will allow you to eject a CD, but you can't do anything more than that. Unfortunately, this is not well-documented. The reason, apparently, is that most CD-R(W)s expect a different SCSI read command which SGIs don't know how to send. This seems to me to be outrageous, and is entirely SGI's fault. (You can still write a CD on an SGI, but you can't read what you've written in the same drive.) Some CD-R(W)s, on the other hand, do work - but far fewer than the number that don't.
    • Be actively terminated. Don't use the drive's onboard terminator, because unless something says otherwise, it's probably passive.
    The blame probably shouldn't lay entirely on SGI for being so "picky" about which drives it supports when block size isn't an issue. The PC market is what most manufacturers aim for, and sometimes violating the SCSI specification even slightly can increase profits. Many CD-ROM manufacturers try to cut corners every way they can in order to keep prices as low as possible, and in doing so, cause the problems many SGI users are having today.

    For more information, see the CD Writing/Reading CDs and Recommended CD Writers FAQ, by Carsten Koch (local copy).

    Linux on SGIs

    Considering the scarcity of IRIX media, it's not suprising that so many people are wondering whether Linux will run on their SGI or not. It depends on the machine. This information may be out of date; visit the Linux/MIPS HOWTO for more information. I suppose I'll create a "NetBSD on SGIs" section if I ever get around to it.
    • Everything before Indigo:  Not supported, and almost certainly never will be.
    • Indigo:  Not supported. Maybe some day.
    • Indy:  Fully supported on all CPU types, including a working (slow) XFree86 server for XL systems only, and including a driver for the Vino Video subsystem.
    • Indigo2:  Fully functional except for graphics. The network and SCSI adapters work, but the system can only be controlled by serial console (and over the network of course).
    • O2:  Not supported. NetBSD does, however, partially support R5000 O2s.
    • Octane: Not supported. Maybe some day.
    • Onyx/Onyx2: Not supported. Maybe some day. Doubtful the graphics subsystem ever will be, though.
    • Challenge S: Fully supported, except for the extra SCSI port(?).
    • All other Challenges:  Not supported. These are very sophisticated and proprietary SMP machines, and even if Linux could be ported to them, it's doubtful it would support more than one CPU.
    • Origin series:  Ditto re the Challenges. Except for the Origin 200 - the port for that is still in its infancy. The O2K/O3K, however, is a radically different architecture from anything Linux has run on in the past, and a port that harnessed even a fraction of the system's functionality would be a lot of work. SGI has, however, done some interesting things in open-sourcing their software, causing one to wonder whether or not the reasons for the Linux big-memory patch and the Linux XFS port were so that Linux could be ported back to SGI hardware as an IRIX replacement. My guess is that this would only happen for Itanium-based Origins, since their officially-sponsored Linux/MIPS port is pretty much dead in the water.
    If Linux runs on your SGI, you will still need to install over the network - you can't do it via CD-ROM yet.

    Visit SGI's Linux on SGI site for more info.

    Quake on SGIs
    You'd think that a machine that cost $40,000 in 1994 would be able to play Quake II just fine. Not so. In order to play Q2 at an acceptable frame rate, you'll need to invest in an SGI that can do hardware texturing, which means at least an Indigo2 High IMPACT or an O2. Even an Octane sucks for Quake if it can't do hardware texturing. Most of the older graphics systems (e.g. XZ, Extreme) are fine at anything that doesn't involve texturing - but Quake does involve texturing, so you'll have to settle for a piss-poor framerate. Solid IMPACT is better, but not by much, since the bottleneck is still in the CPU, which just can't process those textures fast enough.

    High IMPACT graphics with only 1MB of texture memory is not quite sufficient for Quake. For good frame rates, use a Max IMPACT with 4MB (or an O2 with unlimited texture memory).

    Of course, for smooth frame rates at all resolutions, under all conditions, and with all graphics features enabled, an Onyx2 RealityMonster couldn't hurt... and while we're at it, neither could this.

    SGI Links (this part is just a placeholder for what's to come in the distant, distant future... not)
    Credits

    Contributors (you could be world famous like these people!)

    • Ronald Dujinski
    • Russell Elliott
    • Russell Graves
    • James Holden
    • Jerry Jorgenson
    • Sean
    • Serguei Patchkovskii
    Copyright information
    This page is public domain. Giving me credit for whatever you may plan to do with it would be nice, but not absolutely necessary.

    The views and opinions expressed in this page are strictly those of the page author.
    The contents of this page have not been reviewed or approved by the University of Minnesota.