11–20 of 40 posts
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.
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'll give Ghidra a try!
Number 1 because Mainframes without the microcode is sent to the junkyard.
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…
I'd love an Onyx/RE on an FPGA someday. Next to my FPGA cray.
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…
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.
(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.)
Earlier quoted context omitted.
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…
I was always confused why sgi didn’t throw the rcp on a pci card and dominate the pc graphics market.
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…
What SSD are you running? I'm still on 10k SCSI drives selected for the quietness of their bearings.
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.
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