Reverse Engineering the Prom for the SGI O2(mattst88.com) |
Reverse Engineering the Prom for the SGI O2(mattst88.com) |
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 in structure, as the latter are usually written in a combination of C and Asm (I can see why no one wanted to write MIPS Asm) and are self-extracting compressed archives.
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 :)
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.
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.
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.
I'd love an Onyx/RE on an FPGA someday. Next to my FPGA cray.
I'm working on some OpenGL stuff at least.
http://nekonomicon.irixnet.org/ -- Nekochan backup
If you want OpenGL demos, well, they exist. An example I made: https://forums.irixnet.org/thread-4796.html
You want newer FOSS?
Every quarter I update it.
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 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.
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.
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".
I'll give Ghidra a try!
Number 1 because Mainframes without the microcode is sent to the junkyard.
Applies here. SGI hardware holds interest because "ooh pretty animations/GL". IBM is great stuff, but it's all workhorses.
What SSD are you running? I'm still on 10k SCSI drives selected for the quietness of their bearings.
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
And yes:
- It's loud
- It's single core
- It's a furnace
- It's very very loud
:-D
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.
IRIX only supports about OpenGL 1.2. It does have a fragment shading extension though:
https://tech-pubs.net/reputable-archive/fragment_lighting.tx...
(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.)
I was always confused why sgi didn’t throw the rcp on a pci card and dominate the pc graphics market.
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