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

31–40 of 40 posts

Re: Reverse Engineering the Prom for the SGI O2

#31

Post by ThatGuyRaion »

jrmcauliffe wrote: post #8
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?

The main watering hole for the hobbyist community around these machines vanished from the internet a while back, taking the forums and info around porting software with it.. I guess some of it is available via wayback etc.

Ummmm...

https://irixnet.org/

http://nekonomicon.irixnet.org/ -- Nekochan backup

Re: Reverse Engineering the Prom for the SGI O2

#32

Post by ThatGuyRaion »

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.

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

Re: Reverse Engineering the Prom for the SGI O2

#33

Post by ThatGuyRaion »

unixhero wrote: post #13

I for one is awaiting for the world to completely decompile and or reverse engineering the IBM mainframe microcodes for all their machines. Number 1 because Mainframes without the microcode is sent to the junkyard.

"We weep for the blood of a bird, but not for the blood of a fish. Blessed are those with a voice."

Applies here. SGI hardware holds interest because "ooh pretty animations/GL". IBM is great stuff, but it's all workhorses.

Re: Reverse Engineering the Prom for the SGI O2

#34

Post by Grosvenor »

ThatGuyRaion wrote: post #27
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…

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…

> 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.

Re: Reverse Engineering the Prom for the SGI O2

#35

Post by the_biot »

mattst88 wrote: post #24
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 fro…

Annotating the decompiled code is very much part of the workflow in using Ghidra, but the UI is not really intuitive. If you right-click on variables, function names etc there are a bunch of options for annotation. You can also edit the function signature, which can cause the decompilation to improve.

I know you can do various base address manipulations, but your case seems like it would be hard -- the base address is in the file, or has to be calculated.

Re: Reverse Engineering the Prom for the SGI O2

#36

Post by ThatGuyRaion »

Grosvenor wrote: post #34
ThatGuyRaion wrote: post #27

Earlier quoted context omitted.

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…

> 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...

Re: Reverse Engineering the Prom for the SGI O2

#37

Post by ThatGuyRaion »

rngfnby wrote: post #22
theodric wrote: post #18

Earlier quoted context omitted.

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…

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)

Re: Reverse Engineering the Prom for the SGI O2

#38

Post by rngfnby »

ThatGuyRaion wrote: post #37
rngfnby wrote: post #22

Earlier quoted context omitted.

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…

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)

[dead]

Re: Reverse Engineering the Prom for the SGI O2

#39

Post by nathan_douglas »

userbinator wrote: post #3

In the PC world this would be known as "BIOS modding". The first two instructions looked legitimate, but the third looked unlikely to be a real instruction. Given that the first appears to be a branch, that's not surprising. When disassembling, not following the flow will likely not give you anything meaningful. If the author is reading this: have you tried Ghidra? That said, this seems a lot simpler than PC BIOSes i…

> I can see why no one wanted to write MIPS Asm

At least in comparison to x86 assembly, MIPS assembly seemed very elegant and rich to me at the time. I wanna say that MIP R4K had 32 integer registers and 16/32 double- or single-precision float registers, but don't quote me on that. Either way, it was an embarrassment of riches :)

Re: Reverse Engineering the Prom for the SGI O2

#40

Post by Grosvenor »

wk_end wrote: post #19
Grosvenor wrote: post #17

Earlier quoted context omitted.

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

I would have loved to have that paper when I was learning 3D and OpenGL.
Post reply on HN