Hacker News Reader

Comment by tyfighter | Hacker News Reader

I think the lack of a real usable emulator for SGIs is holding back any kind of homebrew. I say this as one of the developer's that got SGI Indy emulation working in MAME. Yes, it works, but it's too slow and too old to be usable. I spent some time after the MAME effort working on a custom high performance emulator for Crimson/Onyx/Reality Engine, but I've kind of burned out again. Maybe some day if I'm really driven again, and had help. I've done most of the reverse engineering already, it's just a lot of code.

I think that if a high performance, usable emulator for some of the big systems existed I think some of the old software might be rediscovered and show up on the internet.

View on HN

I think the problem was that the machines were always very expensive, even used.

My Fuel has an SSD and Id use it daily except:

- It's loud

- It's single core

- It's a furnace

- It's very very loud

It has a fairly modern Emacs, ssh and a non distracting UX. The browser is the only real thing that is too old to be useful, feature and performance wise, but that's just bonus points productivity wise (besides, rdesktop into a modern machine and you can watch youtube)

If I had a 900 MHz O2 loaded with RAM, and an SSD (SCSI SSD, ha!) it'd probably be my daily driver.

I have a 600MHz RM7k O2, and my 700MHz R16k Fuel blows it out of the water. The O2 isn't that quiet or that quick even with upgrades!

What SSD are you running? I'm still on 10k SCSI drives selected for the quietness of their bearings.

Right now I cant get to the machine (off, in the basement) but it is some run-of-the-mill SATA drives using a SATA expansion card.

It works great but I just use it for /opt since I ran out time to move more of the machine into it.

You cant boot off the SSD, so I still use a SCSI but you can replace that too if you boot the SGI off the network.

Silent SGI:

Having gotten rid of the SCSI drives completely w/ the network boot, you can put a modern, more silent, PSU [1] (but hurry, ones w/ enough current on 5V (?) are rare), and then replace the GPU and CPU fans and turn of environmental monitoring.

[1] i had to replace mine; my 500 MHz Fuel is notorious for bad psu

Do not turn off environmental monitoring. That's for debugging only. That's how people are cooking the video cards. Please get your fuel /properly/ repaired by say weblacky on irixnet. The reason why? With env monitoring off, the system won't respond to overheating on the graphics card and it'll cook it alive. The fuel has notoriously bad airflow (air doesn't move right angles)

You could use the NVME driver to load the filesystem and boot the kernel diskless...

Yes, I have a restored Indigo 2. I fixed at lot of things in the PSU.

And yes:

- It's loud

- It's single core

- It's a furnace

- It's very very loud

:-D

I keep my Challenge S running 24/7 :)

Your contributions to the Indy alongside Ryan's contributions were neat, truly. You plowed the road so others can navigate it. There's a rumor about a faster Indy emulator... but don't hold your breath yet. (Not a project I'm part of, but I've been told snippets)

The OS/hardware though, has serious limitations that while no problem for me, definitely pisses off people. Examples:

No atomics/Thread local support. Doesn't matter that someone ported GCC 15 -- you can't make use of many useful newer language features.

Immediate Mode OpenGL only. There's no direct hardware access. Not a problem for me, but every SGI out there is fixed function only. I've had people bitch to high hell we don't have shaders.

and in general, some people just think the OS is janky. I love it, but not everyone is me.

> Not a problem for me, but every SGI out there is fixed function only.

Is that true? I remember sgi had a shader library for modeling light aimed at the automotive market. All the demos and examples were showing off car paint colours in different environments.

SGIs that matter (MIPS, etc)

IRIX only supports about OpenGL 1.2. It does have a fragment shading extension though:

https://tech-pubs.net/reputable-archive/fragment_lighting.tx...

They got the N64 running on the MiSTer. So an indy should be possible, they're closely related systems.

I'd love an Onyx/RE on an FPGA someday. Next to my FPGA cray.

The CPUs are close, but the Indy is otherwise pretty different from the N64. Totally different graphics architecture, and - relevant to getting it on MiSTer - it’s a workstation rather than a video game console, necessitating quite a bit more complexity. I’d be really surprised if it could be squeezed on.

(Though, full disclosure, I said the same thing about the N64 before the core for it came out - the folks working on MiSTer are incredible.)

Huh. I had thought the n64 was basically an Indy xz graphics. What was the rcp closest to?

I was always confused why sgi didn’t throw the rcp on a pci card and dominate the pc graphics market.

To my knowledge - and I'm not an expert here - the N64 hardware is pretty unique and doesn't really resemble any of SGI's other chipsets. Not in precise capabilities - the XZ, for instance, didn't even support hardware texture mapping - and not in overall technical design.

It does seem a little bit like an ultra-simplified, integrated version of the RealityEngine [0]. The RealityEngine had "6, 8, or 12 Geometry Engines" split out across three to six boards, each powered by an Intel i860XP, that then passed their work along to Fragment Generators. This roughly corresponds to the RSP, which was just another MIPS core (with vector/matrix extensions), passing its work along to the RDP on the N64. I'm not sure how programmable the RealityEngine's pipeline was compared to the surprisingly flexible RSP.

Remember, the constraints for a graphics workstation are really different than for a game console - especially on the low-end, totally different corners are going to be cut. An Indy still needed to be able to generate a high resolution display and allow modelling complex scenes for film and TV; but while some degree of real-time 3D was important, it was expected that artists could be modelling using wireframe or simplified displays. A game console was displaying low-resolution and relatively low-detail scenes, but they still wanted them to look aesthetically "complete" - shading, textures, fog, lighting, particles - while running at real-time speeds. SGI used their expertise and built something custom-fit for the job at hand, rather than just reusing an existing solution.

[0] https://cseweb.ucsd.edu/~ravir/274/15/papers/p109-akeley.pdf

I would have loved to have that paper when I was learning 3D and OpenGL.

Nay, the N64 is pretty unique hardware-wise. Conceptually it's vaguely similar to the O2, the RCP is an R4000 fixed function CPU with some extra graphics instructions IIRC.

Reply on news.ycombinator.com