latest posts

Going back to a post from a few weeks back, I'm proud to say all of the ppc/MacOS X code has been upgraded to the big 0.8 release a few months back.

You can download the 0.8.755.0504 release here.

For those curious on the latest code here at the results from Power Mac G5: [bash] jcBENCH 0.8.755.0504(ppc/MacOS X Edition) (C) 2012-2014 Jarred Capellman CPU Information --------------------- Manufacturer: Apple Model: PowerPC G5 (1.1) Count: 2x2 GHz Architecture: ppc --------------------- Running Benchmark.... Integer: 62.7726 seconds Floating Point: 142.774 seconds [/bash] In comparison a somewhat recent AMD E-350 D (Dual 1.6ghz APU) gets roughly the same numbers. To be fair, for an October 2005 G5 compared to a low end January 2011 processor it didn't do as bad as I would have thought. What is even more surprisingly, comparing the G5 to my HP DV7-7010us, the G5 is actually slightly faster in 2 threaded floating point tasks (probably the cache), 171.996 seconds. However in integer, my HP is considerably faster, 17.61328 seconds.

An updated version for x86/MacOS X should be available later this week as well as a x86/Linux release - stay tuned.

Brief Introduction

The Silicon Graphics Indy workstation was originally released in late 1993 starting at $4,995. For that price you received a diskless 100 MHz R4000 Indy, 32mb of a ram, the base 8bit graphics card and a 15” monitor. A more reasonable configuration: 64mb of ram, 1 GB hard drive, flooptical drive, 24bit XL graphics card and external CD-ROM was $23,695 at launch. I should note, standard features on the Indy included an ISDN modem, 10baseT Ethernet, four channel stereo sound card and composite video & s-video input, pretty advanced for the time especially compared to the Apple Mac Quadra.

Silicon Graphics Indy - Front
Silicon Graphics Indy - Back

My Story - Initial Hardware Setup

I actually received my Indy way back in May 2012 for a whopping $37 shipped with no hard drive and no memory, while having the R4400SC 150 MHz CPU and 8bit graphics. The SC in the R4400SC, stands for Secondary Cache. Commonly you will find the R4000PC and R4600PC on eBay which lack the L2 cache.

Silicon Graphics Indy - Boot Menu
Silicon Graphics Indy - hinv
Luckily the Indy takes 72 pin FPM memory that was pretty standard back in 1993 when it was first released, this made finding compatible working ram on eBay much easier. The Indy has 8 slots and supports up to 256mb of memory (8x32mb), which I was able to find for < $10.

Knowing I would be using this at some point for at least some vintage SGI Doom I also picked up the 24bit XL Graphics Option for $20 later in May 2012, hoping I would get the R5000 180 MHz CPU (more on this later).

Fast forward to January 23rd 2014, I was cleaning up my office after work and noticed the Indy sitting on top of my Prism and decided to invest the time in getting it up and running.

Little did I know all of the spare Ultra 160 and Ultra 320 SCSI drives I had laying around either were dead or didn’t have the backwards compatibility to SCSI-2 which the Indy utilizes (I didn’t realize some manufacturers dropped SCSI-2 support in the U160/U320 era). Luckily, I just purchased several Maxtor ATLAS 15k II 73 GB U320 drives (Model #8E073L0) for use in my Fuel, Tezros, Origin 300s and Origin 350. Maxtor ATLAS 15k II Ultra 320 Drive
Realizing it was a long shot, I put one of those in the Indy (with an SCA->50pin adapter I got off of eBay for $2) and the Indy recognized it without any problems. Granted the SCSI-2’s 10mb/sec bus limits the outbound and inbound bandwidth the drive has (I had previously benchmarked it around 95mb/sec of actual transfer speed), fluid dynamic bearing motors (virtually silent), the 3.5ms access time and internal transfers far outweigh trying to find an “original” SCSI-2 drives, which I might add often go for $40+ on a Seagate 5400pm 2gb drive. I should note the Seagate Cheetah 15k.3 18 GB U320 (Model #ST318453LC) and the Fujitsu 18 GB U160 (Model #MAJ3182MC) drives did not downgrade to SCSI-2.

I should note, my Indy randomly refused to boot (no power to even the power supply fan). Apparently this was a common problem with the initial power supplies from Nidec. The later Sony models didn’t have this problem, but had the problem of not running the fan 100% of the time, instead only when the temperatures hit a high point. Some folks have modified their Sony power supplies to keep the fan on 100% of the time, I did not as I only really use the Indy in the basement where the hottest it gets is about 69’.

Silicon Graphics Indy - Nidec
A solution I found was to disconnect the power cable for a good 20-30 minutes and then try again. 9 times out of 10 this worked and the system had 0 issues booting into IRIX and maintaining it. So before you run out to buy a “new” power supply of eBay try this solution out. These are 20-21 year old machines afterall.

My Story – Getting IRIX Installed

Having installed IRIX now on a Fuel, Tezro and an Origin 300 I am well versed in the process. For those who are not, checkout this howto guide (http://www.futuretech.blinkenlights.nl/6.5inst.html), it is very detailed and should be all you need to get going. This assumes you have IRIX 6.5.x. Depending on which workstation/server you have, you might need a higher version. 6.5.30 is the latest version of IRIX released, however those typically go for $300+ on eBay. I highly suggest simply getting some version of 6.5 and downloading the 6.5.22m tar files off of SGI via their Supportfollio (this is free after registration).

In my case, the Indy is so old that any version of 6.5 is acceptable, though I wanted to get it to 6.5.22m so I could utilize nekoware. Nekoware is a community project where several contributors compile typical open source software like bash, Apache, MySQL, PHP etc. for MIPS/IRIX. You can download the tardist files here (http://nekoware.dustytech.net/index.php?path=current/) (a tardist is similar to a rpm if you’re coming from a Linux background).

I should note, if you install from an older IRIX 6.5.x release (prior to 6.5.22m) you need to install Patch 5086 (available via the Supportfollio for free) prior to the upgrade.

Another question that might arise especially for those installing to an Indy, I pulled out the DVD-ROM Drive (SCSI-2 50pin) from my Silicon Graphics Fuel to install IRIX. For newer systems that utilize SCA like an Octane or Origin 3x0, you could use a 50pin -> SCA adapter with the drive or do as I did with my Origin 300 a while back and setup a VM of DINA. Basically this allows you to install IRIX over the network to your hardware. After installation before continuing I highly recommend you clone your drive and keep it locked away in case you ever accidentially mess up your installation of if your hard drive dies. Depending on the speed of your system, you could have just invested several hours of time. Cloing a disk is very easy in IRIX, simply follow this guide (http://www.sgidepot.co.uk/disksfiles.html#CLONE). I had done it myself previously on my Origin 300 and it only took about 10 minutes. For my Indy for those curious, it took about 20 minutes.

My Story – Post IRIX Installation

After installation my first step was to get nekoware installed, I typically install the following (including the dependencies for them):
  • BASH
  • OpenSSH
  • wget
  • SDL
  • Firefox
  • GCC
  • Nedit
  • rdesktop
  • Samba
  • Subversion
There’s countless others, but those are the essentials that I utilize very frequently. Depending on your system, the installation (especially of GCC) could take some time so be patient. Something to note, if you have an R4x00 CPU you need to utilize the MIPS3 tardists, however if you have an R5000 Indy you can use the MIPS4 variations. At some point it seems contributors to nekoware for MIPS3 trickled off so you’ll more than likely be compiling from source for most things. As I compile stuff I’ll start contributing to my local repository as well.

What’s Next?

I’ve been on a hunt for an R5000 180 MHz CPU or at the least a 150 MHz variant so I can be close to the highest end Indy available.

As for its use, I plan to start on the MODEXngine project now that I have a pretty clear multiplatform architecture.

In addition I want to use it as test bed for writing efficient C++, in a future blog I will be focusing on laziness of programmers (not all, but many) that I feel the commodity PC hardware of today has gotten so fast and cheap that programmers don’t consider efficiency or writing with performance in mind.