General Stuff(tm)

[stephen_usher]

I've got the Sun 3/80 out of storage again to take a look at getting it at least mostly working.

IMG_5504.jpeg (249.59 KiB) Viewed 33 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.

[stephen_usher]

I was slowly getting somewhere... then the other SCC read enable output from the DECODE1 chip stopped working. *sigh*

So, unless I find a way to decode 17 address lines and the R/W line... and find where I can pick them up,,, I'm dead in the water.

Oh well.

[stephen_usher]

Well, I have a plan.

The DECODE1 chip has to be using "information" from the inputs to the chip to generate the SCC control lines. So, if I can find the combinations which match the write operations, which still work, add in the read operations, which should just be the CPU read/write line, hopefully, then I can theoretically write a GAL logic program to reproduce the signals and I'm back in business.

So, my plan is to 'scope out the chip as it is finding all the signals which don't change when there's a pulse from the SCC write line. Any lines which change during this are unlikely to be anything to do with the signal. I can then write ROM code which purely sets up the machine and then does the following continuously:

Code: Select all

loop:
	Write to SCC1 register
	Read from SCC1 register
	Write to SCC2 register
	Read from SCC2 register
	Pause
	Write to Parallel port
	Read from Parallel port
	Pause
	Goto loop

In this way I have a continuous and deterministic set of operations, with both reads and writes, and a set of separated reads and writes to another I/O address to sort out any false positives.

My 16 channel logic analyser should be ample for this.

[stephen_usher]

OK, I think I have a ROM image ready.

I've put all the initialisation stuff from the original boot ROM into the new one in case the hardware needs setting up.

After lunch I can map the pins on the DECODE1 of interest and then wipe the EPROM and burn my ROM into it.