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.
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 again, and had help. I've done most of the reverse engineering already, it's just a lot of code.
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.
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 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 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 on MiSTer are incredible.)
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 equivalent C code.
Yes! I don't use my O2 a lot (I think the PSU is flaky, and I'm not super interested in IRIX), but I'm aware of at least https://forums.sgi.sh/index.php, among other similar sites, full of people porting/developing software for IRIX. It's a pretty active community for a 90s workstation platform, the most active one I'm aware of!
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.
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.
Thanks!
I'll give Ghidra a try!
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.
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 again, and had help. I've done most of the reverse engineering already, it's just a lot of code.
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.
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 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.
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.
They got the N64 running on the MiSTer. So an indy should be possible, they're closely related systems.
I'd love an Onyx/RE on an FPGA someday. Next to my FPGA cray.
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 on MiSTer are incredible.)
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.
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 equivalent C code.
Yes! I don't use my O2 a lot (I think the PSU is flaky, and I'm not super interested in IRIX), but I'm aware of at least https://forums.sgi.sh/index.php, among other similar sites, full of people porting/developing software for IRIX. It's a pretty active community for a 90s workstation platform, the most active one I'm aware of!
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.
Oh, the PROM, not the prom.
Yes, I submitted it as "PROM". I have no idea why it has been changed.
I think it’s to prevent SHOUTY TITLES. I also think there are some hardcoded acronyms that are safe.
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.