Re: General Stuff(tm)
Posted: 07 Nov 2026 10:01
I've got the Sun 3/80 out of storage again to take a look at getting it at least mostly working.
A bit of background:
I bought the machine second hand via a friend who used to work for Sun Microsystems back in 1993 when Sun were disposing of them. It worked fine but then I put it away when I transitioned to Linux a couple of years later. It stayed up in the loft for about 20 years before I tried getting it to run again. Unfortunately it didn't even get to POST.
In about 2020 I determined that it was one of the custom chips, DECODE1, which had gone faulty in storage, not enabling the serial port(s) and hence the boot ROM was failing early on.
I tried several times to try to do hardware hacks to get it to work but none worked.
This week:
I went back to basics. I'd already tried a few times to disassemble the ROM using Ghidra but didn't get a long way but this week, due to having sinusitis and not having the energy to do energetic things I got back to it with the idea of patching the ROM to ignore the bots of the machine I know aren't working and trying to see if the bits which are will get me anywhere.
Well, I've definitely got further, despite Ghidra. Don't get me wrong, it's generally a good tool but there are limitations which drive me up the wall, such as the memory map set-up tool, which didn't allow you to amend entries. This isn't good when you're trying to reverse engineer the memory map and all you can do is delete and recreate. Also, the assembly analysis tool deletes the previously sorted code and often resets it to just bytes if it gets confused. (Oh, and you can't import the memory map data and the devs have stated that you never will be able to.)
Anyway, how far have I got?
Well, I once got the machine to start POSTing properly, but that was a fluke. It *IS*, however, consistently lighting the power/indicator LED for a long time at power on but then sits there constantly reading the second SCC chip's status register... but it only does two writes, which isn't correct when looking at the code. So, more to do. I have a sneaking suspicion that it's not just the main serial port enabling which is up the creek but maybe the parallel port access as well.
- IMG_5504.jpeg (249.59 KiB) Viewed 5 times
A bit of background:
I bought the machine second hand via a friend who used to work for Sun Microsystems back in 1993 when Sun were disposing of them. It worked fine but then I put it away when I transitioned to Linux a couple of years later. It stayed up in the loft for about 20 years before I tried getting it to run again. Unfortunately it didn't even get to POST.
In about 2020 I determined that it was one of the custom chips, DECODE1, which had gone faulty in storage, not enabling the serial port(s) and hence the boot ROM was failing early on.
I tried several times to try to do hardware hacks to get it to work but none worked.
This week:
I went back to basics. I'd already tried a few times to disassemble the ROM using Ghidra but didn't get a long way but this week, due to having sinusitis and not having the energy to do energetic things I got back to it with the idea of patching the ROM to ignore the bots of the machine I know aren't working and trying to see if the bits which are will get me anywhere.
Well, I've definitely got further, despite Ghidra. Don't get me wrong, it's generally a good tool but there are limitations which drive me up the wall, such as the memory map set-up tool, which didn't allow you to amend entries. This isn't good when you're trying to reverse engineer the memory map and all you can do is delete and recreate. Also, the assembly analysis tool deletes the previously sorted code and often resets it to just bytes if it gets confused. (Oh, and you can't import the memory map data and the devs have stated that you never will be able to.)
Anyway, how far have I got?
Well, I once got the machine to start POSTing properly, but that was a fluke. It *IS*, however, consistently lighting the power/indicator LED for a long time at power on but then sits there constantly reading the second SCC chip's status register... but it only does two writes, which isn't correct when looking at the code. So, more to do. I have a sneaking suspicion that it's not just the main serial port enabling which is up the creek but maybe the parallel port access as well.