[Raion]

Welcome to the forums fuel, I appreciate the support!

> I think the first step would be resurrect adding the ability to run irix 6.5.x (preferably .30) to qemu

.30 is very much not the exact pinnacle. Between post .19 versions the differences are mostly drivers/API. .30 has some bugs for older systems and doesn't support say, DPS, or other features .22 does. I'd compare it to say, Amiga OS 3.1 vs Hyperion's OS 3.1 -- not but so many differences!

The qemu-irix stuff works, with a bunch of caveats that make it unacceptable for all but compiler work (which is what the SM64 dudes were doing, using IDO 5.3). There's no X support, and implementing that would be impractical/difficult, and it can't emulate any graphics hardware or even support later CPUs. The fact is, IRIX is an "all in one" system and can't really be decoupled from the graphics stack it uses. Even the Onyx4 has an inferior experience since it uses XF86 instead of XSGI and has no IRISGL compatibility.

ABI-wise it's also limited to one ABI (they used o32 for sm64, but later stuff uses n32 or n64 ABIs)

> then it would make it easier for me to work on a fork. I'm not interested to work on the 32bits version of irix, if I'm making a clone it's going to be a clone of the 6.5.x kernel including its abis (o64, n64 maybe n32 as well). lmk.

MAME is currently the only way that really works accurately. Talk to flygoat here (Hatsune Miku avatar) he's a MAME contributor and MIPS guy.

As far as 5.3 vs 6.x, the main differences:

No vnode subsystem.

Retains COFF support from 4.x

No C99 support in libc and Cfront-only C++ support I think

No CXFS, trusted IRIX, attribute support and EFS, not XFS is the default FS.

That's a start, at least. But API-wise it's still not too dissimilar, so this would be a step towards IRIX 6.5 and up. We'll eventually go for it.

Lastly, a general statement:

For anyone DMing me, it is Memorial day weekend in the US, I'll be mostly spending time with friends. I'll catch up Monday and Tuesday!