Sun 3/60 - Notes and Resources

Rom images

• Sun Archive EPROM Page for the 3/60

Version 3.0.1 can boot CDrom, but is missing many self tests.

Dan says he would prefer the last 2.8 if he could get it.

Schematics and Sun documents

• Sun3 Architecture Manual (bitsavers)
• Sun3-60 Ghidra project
• Sun 3/60 schematics
• Github: Dan's stuff
• Flash for ROM
• Github: Dan's 020 to 030 adapter

Dan's comments on various questions

The 3/60 schematics (and original board) actually have room for a 68030 alternate, but it's wired to run in 68020 mode. It wouldn't be that easy to use a different MMU, I think it would be more about software than schematics. I think 3/80 schematics are out there too.

Framebuffers should be doable. The 3/60 has an onboard monochrome version that's ram stealing from the main system - in the schematics but I chose not to do it for the first version. It's ECL logic but I made and tested an adapter to VGA levels. That stays on the menu but perhaps after SCSI. The P4 CG6 I don't think is available as schematics, but there's a guy who made an FPGA alternative, which even though is sbus, might be easier to port over.

Re:serial, there are 2 serial controllers on the original: keyboard, mouse, serial A and serial B. I did knockout testing on the original board (removing chips and seeing how it behaves) so I knew ultimately that I can get away without the KB/mouse controller - especially since I'm not implementing video, it was gonna be a headless system anyway.

The failure mode is that it passes all the tests, then at the final prompt for extended testing it 60% crashes silently into a loop (I can see it on the diagnostic LEDs) or it reboots and starts all over again. Here's the test sequence - you can find the strings at the end of the prom, but I couldn't find their addresses in the code. The ghidra guy (Klaus) found printf in the code, and tracked the strings eventually but it's indirect/offset addressing of some sort. Knowing it's c should help somehow, no? Fun fact you can dump prom build info. This one was from /usr/src/sun/fwrelease/sun3f/mon/SUN3F :)

I've taken to pinging old SUN folks on LinkedIn to see if someone still has the sourcecode. One guy answered already, he did the next gen firmware for sparcstations and he mentioned it's nothing more than loading code from the external device and jumping to it. If we crack the code and can actually push custom complied versions, some serial bootloader like Kermit would fit perfectly.

What he sees when he boots his system

Test sequence:
Boot PROM Selftest

PROM Checksum Test
Context Reg Test
Segment Map Wr/Rd Test
Segment Map Address Test
Page Map Test
Memory Path Data Test
NXM Bus Error Test
Interrupt Test
TOD Clock Interrupt Test
MMU Access Bit Test
MMU Access/Modify Bit Test
MMU Invalid Page Test
MMU Protected Page Test
Parity Test
Memory Size = 0x00000004 Megabytes
Memory Test (Testing 0x00000004 MBytes) Testing...

Selftest passed.

Type a character within 10 seconds to enter Menu Tests... (e for echo mode)

!!!!-- without the keyboard controller present, it crashes here. If I have it patched in, we can keep going:

Selftest Completed.

Welcome to BEAR workstation !!!!!!!
ROM Rev 1.9, 4MB memory installed
ID PROM invalid.

EEPROM: Using RS232 A port.

Selftest Completed.

Welcome to BEAR workstation !!!!!!!
ROM Rev 1.9, 4MB memory installed
ID PROM invalid.


Type a character within 10 seconds to enter Menu Tests...
Diagnostic Auto-boot in progress...sd(0,8,0)

Device not found

More from Dan 5/xx and 5/17

1. Wondering if the boot paths for different diagnostics conditions (DIAG switch on or off) are substantially different - I could see it being just a few jumps around the tests and early serial initialization, but never know. I've been mostly running it in DIAG mode, though I did run it a few times "regular" and other than the printing out, it did mostly the same routine.
2. I saw a question in your notes around the registers. SYSEN is read/write, BERR is read only and DIAG is write only - by how they are wired to the data bus.
3. What would it take to install a larger boot prom? should be doable but definitely with change to the schematics and probably one of the PALs. Right now the eprom is wired directly on the CPU address bus, but the output enable goes through an address decoding PAL that takes in a few MMU address lines, as well as init/boot signals. It's pretty clear how it's enabled directly until the system gets taken out of the boot state, when it starts going through the MMU.

   Right now the MMU address lines read to decode are 17-20, and eprom has real address lines 0-15. Depending on the code, we might be able to use a larger eprom, wire up address 16 and not actually have to change anything. I need to verify how much space is allocated in the address space for the prom, aka. at what address is the next device.

   I'll test from the ROM monitor what happens if I overshoot the prom addresses on A16 but technically stay within what the address decoder selects - do I get error, or do I get whatever is in the prom at 0-15.

   I'll think about it and read through the architecture manual, schematics and PAL equations - I might be completely off base here. We'd also only double the size, but better than nothing, and then we know we could change the PAL.

4. "help" is broken in the ROM monitor:

   >h
   Invalid Page Bus Error:
     Vaddr: FFFED100, Paddr: 00001100, Type 0, Read, FC 5, Size 2 at 0FEFC25E
   

   It looks like it fails the same way on the original as well, so I'm guessing bad code.
5. For the serial initialization code, could you figure out what values are sent to what addresses? I might be able to poke those sections from the monitor and change the baud back to 9600, etc. Not critical though.