Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineering the Prom for the SGI O2

mattst88.com

Post reply on HN
Print view View original

21–30 of 40 posts

Re: Reverse Engineering the Prom for the SGI O2

#21

Post by Aldipower »

rngfnby wrote: post #9
tyfighter wrote: post #6

Earlier quoted context omitted.

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…

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 i…

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

Re: Reverse Engineering the Prom for the SGI O2

#22

Post by rngfnby »

theodric wrote: post #18
rngfnby wrote: post #9

Earlier quoted context omitted.

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 i…

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

Re: Reverse Engineering the Prom for the SGI O2

#23

Post by rasz »

the_biot wrote: post #11

Awesome work! Enriching the disassembly with known constants and labels is great, great stuff. As somebody else suggested, try Ghidra's decompiler. It produces very sloppy C code, but still reads faster than assembly most of the time. Now enriching Ghidra's decompiler output to clean up the C code, that would be a neat trick, and one that Ghidra isn't doing.

>Enriching the disassembly with known constants and labels is great

speaking of PC BIOSes there is/was a great disassembler called Sourcer https://corexor.wordpress.com/2015/12/09/sourcer-and-windows... with its Bios Preprocessor producing very readable sources full of comments and enumerated hardware IO.

Author of Sourcer Frank van Gilluwe also wrote a somewhat companion book "The Undocumented PC, A Programmer's Guide to I/O, CPUs, and Fixed Memory Areas".

Re: Reverse Engineering the Prom for the SGI O2

#24

Post by mattst88 »

the_biot wrote: post #11

Awesome work! Enriching the disassembly with known constants and labels is great, great stuff. As somebody else suggested, try Ghidra's decompiler. It produces very sloppy C code, but still reads faster than assembly most of the time. Now enriching Ghidra's decompiler output to clean up the C code, that would be a neat trick, and one that Ghidra isn't doing.

I've loaded the PROM in Ghidra. The ability to decompile to C is great.

I looked at some particular parts of the PROM that took a while to understand to see if I could have understood them quicker with Ghidra. In particular, the part of `sloader` that searches for the `post1` and `firmware` sections and then calls `post1(&firmware)`. Given that I already understand how this works, I can see that this is happening from the decompiled C, but the lack of labels, comments, etc really hampers my ability to understand from the decompiled C alone.

This might all be down to inexperience with the tool.

The ability to iteratively add a label, rerun the decompiler, reread the decompiled assembly, make more inferences was really the key to building an understanding for me.

Another aspect I'm unsure how to handle in Ghidra is that the base address differs between sections of the firmware. E.g. the `firmware` section is copied to RAM and executed from `0x81000000`. It's not clear to me how to configure this in a granular way, rather than a single base address for the whole PROM image.

Re: Reverse Engineering the Prom for the SGI O2

#26

Post by ThatGuyRaion »

nebula8804 wrote: post #2

I often see superbly restored SGI equipment at VCF and also own a few SGI equipment that I hope to get to some point in my life but I have never seen any interesting new software or usage of these machines other than the stock "cool" demo programs(The file manager, the gears demo and others running at the same time). Is there any actual cool homebrew occuring on these platforms?

Where do I start?

If you want OpenGL demos, well, they exist. An example I made: https://forums.irixnet.org/thread-4796.html

You want newer FOSS?

https://nekoware.me

Every quarter I update it.

Re: Reverse Engineering the Prom for the SGI O2

#27

Post by ThatGuyRaion »

tyfighter wrote: post #6
nebula8804 wrote: post #2

I often see superbly restored SGI equipment at VCF and also own a few SGI equipment that I hope to get to some point in my life but I have never seen any interesting new software or usage of these machines other than the stock "cool" demo programs(The file manager, the gears demo and others running at the same time). Is there any actual cool homebrew occuring on these platforms?

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…

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.

Re: Reverse Engineering the Prom for the SGI O2

#28

Post by ThatGuyRaion »

rngfnby wrote: post #9
tyfighter wrote: post #6

Earlier quoted context omitted.

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…

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 i…

I keep my Challenge S running 24/7 :)

Re: Reverse Engineering the Prom for the SGI O2

#29

Post by ThatGuyRaion »

foldor wrote: post #4
nebula8804 wrote: post #2

I often see superbly restored SGI equipment at VCF and also own a few SGI equipment that I hope to get to some point in my life but I have never seen any interesting new software or usage of these machines other than the stock "cool" demo programs(The file manager, the gears demo and others running at the same time). Is there any actual cool homebrew occuring on these platforms?

I'm not aware of any cool homebrew, but there is a certain level of cool being able to compile the code for some N64 games using the original IDO compiler on original hardware. You can even compile one of the many decompiled games like Super Mario 64, Banjo Kazooie and more that all will produce the exact binary shipped on the cartridge byte for byte, all from reverse engineered work to create byte matching equivalen…

It runs like arse though.

I'm working on some OpenGL stuff at least.

Re: Reverse Engineering the Prom for the SGI O2

#30

Post by ThatGuyRaion »

Grosvenor wrote: post #17
wk_end wrote: post #15

Earlier quoted context omitted.

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…

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.

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.
Post reply on HN