• Please review our updated Terms and Rules here

Restoring a Sun 386i: What a mess, anyone have a running one?

czunit

Veteran Member
Joined
Aug 7, 2015
Messages
526
So I'm digging through all my old stuff here and in the pile are three Sun386i's that I last used back in the 90's. One of them has a CG3, one has a CG5, and the third has a mono display card. All have been stored in the bedroom closet and haven't been powered up since about 1996 I think.

Anyway I'd like to see what's on them so I have been trying to figure them out. Of the three two have power supplies and both blew up on the bench while testing.
  • Problem 1: Anyone have a schematic for them? They seem to be the usual "rectify AC to 300v, then pass through two FETs to make AC for a transformer that then goes to a set of rectifiers to make +5 and +12. The main power FETs aren't shorted but it looks like the circuit board to gate them has problems. Not sure where, working on it but a working schematic would help.
  • Problem 2: With the supplies out I did try back-feeding +12 and +5 into the CPU board with an ATX supply. All the test LEDs go on but that's it. I reconstructed the -5 and -12 supplies as well with isolated supplies but no difference. Sun4 keyboard beeps, LED for mouse is on, fans work, that's it.
  • Problem 3: No display signal (I'm using a 4 BNC to VGA adapter to an LCD display). I'm not sure if that works, is anyone running a 386i on a more modern flat panel screen?
The first system has a working timekeeper chip, because 25 years ago I modified the chip to be powered off two 1.5v aaa batteries. I replaced those, and it's getting 3v power so should be working.

Anyway, things I have forgotten:
  • Can the systems run without a frame buffer? It would be nice to simplify this.
  • I know the power supply outputs +5, +12, -5, and -12 but there's also one last tab I don't know what it is. Is that a 60 cycle system clock? Interlock? Something else?
  • Could the SCSI drives be mounted on another system? I don't remember if UFS was around on 4.01 and 4.02 but if so could I mount them on my NeXT or something like that in read only mode?
Maybe it won't start up without that last power supply line doing something. Is it power OK? Something else?

The old Sun 386i FAQ is good and I did re-read it, but I think it could use some updating....

Thanks for any thoughts.
C
 
  • Can the systems run without a frame buffer? It would be nice to simplify this.
  • I know the power supply outputs +5, +12, -5, and -12 but there's also one last tab I don't know what it is. Is that a 60 cycle system clock? Interlock? Something else?
  • Could the SCSI drives be mounted on another system? I don't remember if UFS was around on 4.01 and 4.02 but if so could I mount them on my NeXT or something like that in read only mode?
1 - I can't think of any Sun that does not default to serial port 1 for the console if the keyboard is unplugged
2 - Can't help you there. Never owned one of the x86 Suns
3 - The filesystem should be UFS.

The first system has a working timekeeper chip, because 25 years ago I modified the chip to be powered off two 1.5v aaa batteries. I replaced those, and it's getting 3v power so should be working.
Are the batteries still reading 3V or did you just replace them? All bets are off on the NVRAM holding its settings for a battery swap.
 
I had mine so long ago, wish I had kept it.

I can't remember if the Stop-A/Stop-N stuff works on these guys. If they are like the Sparc machines, you may have to wait a long time (10 minutes) for diags to complete and get any output. I agree with poster above and would try a serial console with the Sun keyboard unplugged.

If you do get yours running, I have the external SCSI case with the HD and tape drive that matches.
 
I had mine so long ago, wish I had kept it.

I can't remember if the Stop-A/Stop-N stuff works on these guys. If they are like the Sparc machines, you may have to wait a long time (10 minutes) for diags to complete and get any output. I agree with poster above and would try a serial console with the Sun keyboard unplugged.

If you do get yours running, I have the external SCSI case with the HD and tape drive that matches.
I seem to recall it would come up pretty quickly, even with a corrupted NVRAM. I'll try hooking up to the serial port and see if anything is there, but it shouldn't be locking up this hard, I'd expect something from the LEDs.

That external case: Does it have the same power supply in it as the 386i? Can you do a quick check?
 
1 - I can't think of any Sun that does not default to serial port 1 for the console if the keyboard is unplugged
2 - Can't help you there. Never owned one of the x86 Suns
3 - The filesystem should be UFS.


Are the batteries still reading 3V or did you just replace them? All bets are off on the NVRAM holding its settings for a battery swap.
Ok if it's UFS I may be able to mount it somewhere else. I know Linux supported (supports?) ufs, the problem is I don't have a SCSI port PC anymore so I would really have to start from ground zero and build one. Oi. Do you know if the NeXT can mount UFS filesystems?

I replaced them, they were beyond dead and leaked a bit. Fortunately the battery holder was nowhere near the motherboard so no damage there, just a good cleaning with vinegar and alcohol cleared it up. It will come up corrupted and I'll have to enter a new MAC address and serial number but I should be able to get it going if I can get the display working.

Fun!
 
NeXTSTEP is UFS, so it should work.
It's been years since I last used Linux but an AHA-2940UW was a very well supported PCI card.
 
It's been years since I last used Linux but an AHA-2940UW was a very well supported PCI card.

I likewise can recommend this card plus Linux as a good choice for classic hackery. Back in the day I used one to r00t an SGI machine's HD, among other things.
 
NeXTSTEP is UFS, so it should work.
I dimly remember having trouble with NeXTSTEP's preference for a slightly unusual block size, but I could be making that up?

If I'm not: then if the NeXT doesn't want to read the disk, don't give up!
 
Well after banging around a bit I got my Nextstation up and running. God I have stuff there from 1990, including some documentation on why VGA won't work with Sun mointors (and probably vice versa) and dumps of my 386i's NVRAM parameters. Apparently this is not my first rodeo. So I'll have to think about finding an old Sun BNC monitor, unless I can find a cable that will allow the NeXT color monitor to work.

Anyway the NeXT supports the "4.3" filesystem types, CIFS, DOS, and old Macintosh formats. I'm not sure if 4.3 is the same as ufs, but I could give it a try.

I'll enable hardware write protection on the scsi disk before trying to mount it, just in case the NeXT tries to throw up on the disk. :)
 
A bit of a braindump noting that my experience of Sun boxes started back BITD with SparcStation IPX running SunOS 4.1.3....

I've managed to mount Sun UFS discs in Linux in the past. For me it meant building a custom kernel. It's not enough to build in UFS support, you also need Sun disk label support.

My advice regarding data security is to use dd to dump the whole disc image, and play with that imagefile rather than the disc itself. Use dd if=/dev/sdX of=disc1.dd bs=512 where X is the letter of the Sun disc to dump the whole disc. This method also allows you to split the tasks of data recovery (requiring a SCSI interface), and data reading (requiring a custom kernel) between different PCs (or even between real hardware and a VM).

It may be possible to plug the drive into a Sun SPARC box to recover data, but I found that a SPARC UFS disc on Solaris x86 didn't work at all (probably a deliberate block due to the different endianess, 68000 and SPARC are big endian, x86 is little). A sun4c or sun4m box running Solaris 1.1.2 (=SunOS 4.1.4) would be my weapon of choice. (In my "lab" my network booting SPARC IPX would be used).
 
Thanks @mdog69 , I tried plugging one of the 386i disks (a Maxtor 4380) into the NeXT scsi bus to see what I could see.

First I jumpered JP18 to enable hardware write protect; didn't want the NeXT to throw up on the disk for some reason. I then verified it was set to SCSI id 2, and that termination was out (it was). Plugged it in, fired up the NeXT, and sure enough during boot it did see the maxtor at SCSI 2, did set it to be sd1, and did note that the disk was read only.

However /dev/sd1a did not mount instead I got an IO error. Likewise NeXT doesn't have a "sd1" or "rsd1" device, they're all rsd1a, sd1b, etc. So dd doesn't work either, which is crummy.

This is possibly because it can't read the sun partition tables, well probably. Likewise your comment about endian-ess is something to think about; the NeXT is a 68040 which is big endian and the 386i of course is little. Oi. :) Regardless I don't think the NeXT is flexible enough to read this disk out to a file.

Need to stop and regroup for a bit. Unless I want to go and buy something like a Forensic Falcon or a Talon I might have to build a PC based Linux box. This could be tricky as the only PC I have left I think is a Compaq Deskpro/XE4100 system which oddly enough has NextStep/Intel on it and I THINK still has a 1541 scsi adapter.

Hm. I wonder if I could install Linux from floppy discs. Or floppy images as I do have a Gotek floppy emulator for my pdp11's.
 
Last edited:
Regardless I don't think the NeXT is flexible enough to read this disk out to a file.
I think it is. In fact, I've used a NeXT as a device for making raw dumps of SCSI disks on several occasions :)

You just have to use the right /dev/rsdxx device --- one of them corresponds to "raw" access to the disk. If memory serves, it's /dev/rsd1h, but I think the `sd` manpage will say for sure.

The only way you'll run into trouble is if you try to dump a disk bigger than 2 GiB --- dd can't handle that. It's still no problem, though, because you can use some NeXT-specific system calls to talk to the drive directly. Let me know if this is an issue and I can share some code I wrote to dump data that way.

Naturally I couldn't create a >2 GiB disk image on a NeXT filesystem, but that wasn't a problem either: I piped my super duper disk dumper into netcat talking to a Linux box.
 
Hm. I'll give it another try again. These are 180-330mb disks from the Sun, so I should be able to make an image, then slurp it over to one of the Rpi's for linux love processing.
 
Progress, sort of. Using the /dev/sd1h device I was able to make a file of the Sun386i SCSI disk. Now I just need a place to mount it. My Raspberry Pi Debian systems don't seem to have ufs support, and doing a modload ufs gives me this:

modprobe: FATAL: Module ufs not found in directory /lib/modules/5.15.32-v7+

Looks like it's time to hand build the module and a new kernel....


Another detour into a new learning experience.....
 
Last edited:
Oh this is fun. I finally got the ufs to work under Linux, however the only partition that shows is the first unix partition (0). This had the boot and root file systems, and I can see that the other file systems were at (from /etc/fstab)

/dev/roota / 4.2 rw 1 1
/dev/rootg /usr 4.2 rw 1 2
/dev/rooth /files 4.2 rw 1 3

Question is how do I figure out the offsets for the second and third partitions? fdisk doesn't show anything and cfdisk with selecting "sun" as the file system type only shows a big and a small partition. So I may have to find the superblocks manually.

Oddly enough I can use good old strings and grep to find old emails on the disk, they are there, and it's fascinating.

If I could find out what the preamble of the start of a partition looks like I can probably hack it together manually. The first clue is that the first partition on the disk is exactly 14,159 blocks. Now if we know what the preamble is for the disk's boot sector and junk we should be able to do an offset to the next partition and leapfrog our way through.

Hm. Need to find documentation on the oldest UFS schema imaginable.

Thoughts?
 
Last edited:
You can try testdisk or binwalk on the drive image, it should be able to identify anything (probably more than you ever wanted to know).

Of course, you can mount the first partition, make note of its size; the next partition should start on the next cylinder (for whatever geometry the system used; just bruteforce the next few KB).
 
That's what worked. I started with a person suggesting a shell script that basically tried mounting every sector and noting when the mount succeeded. Then I remembered that in old SunOS the system would only write new partitions on a cylinder boundary so I modified it to jump 512 bytes * the head and sector count and only go to 1500 or so. Got all partitions in a moment.

Modern computers. They allow you to swing a sledgehammer so much more quickly than old systems :) Now I know both disks are good, and it's fun to read emails from the 1990's. Next step is to fix the power supply.....
 
Meantime back to power supply. After staring at the mess for awhile I'm beginning to think it's just a normal PC-AT style supply. Those were pre ATX, and supported 5v, 12v, and -5/-12 for the ISA bus (which is in the 386i of course). The last tab is the kicker, what is it? I'm beginning to think it's the "Power OK" line, which was asserted when all the voltages were good. The lack of which may be why the systems were stalled at all LEDs on when I tried to back-power with just +5 and +12 through the hard drive power port.

450 watt AT supply is on order, I'll try trying it in and see what happens.
 
Ok, I've taken apart a wrecked 386i power supply and I found something interesting. On the control board there is an potentiometer for adjusting the +5 supply and another next to it to adjust the "+5 ready" signal.

So there it is: The power supply on a 386i is basically the same outputs as a PC/AT supply. +5 and +12 are the main lines, with -5 and -12 for the ISA bus standard and a final power supply ready +5 signal, just like on an XT/AT supply.

I've wired in the 450 watt supply into the proper pins so all voltages appear on the output edge card properly. I'll plug it into a 386i and see what happens tomorrow.
 
Back
Top