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?
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 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 :)
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'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.
The successor to SGI, after several acquisitions and bankruptcies, is Hewlett Packard Enterprise.
There's a forum for abandoned HP products.[1] The SGI O2 has been mentioned, but not in recent years.
12 comments
[ 2.9 ms ] story [ 27.3 ms ] threadIf 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.
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 :)
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'll give Ghidra a try!
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 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.
Number 1 because Mainframes without the microcode is sent to the junkyard.
[1] https://community.hpe.com