• Please review our updated Terms and Rules here

Sun386i. Overdrive processors: Why don't they work?

C

czunit

Veteran Member
Joined
Aug 7, 2015
Messages
526
Ok, so 35 years ago the Sun386i was pretty much abandoned as a platform. Which is not totally fair, it's actually a nice little system with an impressive framebuffer, network, all the bells and whistles. It's biggest problem is the CPU is just dog slow. It has no on board cache, clocks at 25mhz and is just plain terrible.

While they never released a 486 version several companies (Cyrix, TI, and of course the IBM Blue Lightning) released chips that had accelerated 386 capabilities. 1k cache up to 8k, better execution engine and pin compatible.

A Long time ago I had a 386/25 accelerator chip with some logic on it that should have speeded the system up. Never worked, but I'll bet I still have it.

Last week I bought a Cyrix Cx486DLC-40GP processor which is a PGA132 pin compatible 386 replacement. 5 volt supply the whole nine yards. Dug out my 386i, fired it up and watched the LEDs flash on the back as it ran POST, shut down, popped in the Cyrix chip and....

Nothing. All LEDs on which means that whatever is happening the BOOT Rom is not getting to the point to turn on or off any LEDs.

So the question is: WHY?

Well let's think. First the chip is set to clock at 40mhz, so running it at 25mhz should be a simple slam dunk.

Second it does not have floating point instructions but can use the 80387 coprocessor. Since we're leaving that in the system that's not the problem.

There is the 1k cache, but why would that trash the 386i's boot? It's possible it interferes with the 82357 chip on the memory boards, not sure how that communicates with a 386 chip but plenty of 386 boards had off chip cache.

So hm.... I guess the first possibility is to see what's in the rom between first instruction and "toggle a LED" light. Any other thoughts?
 
Figured I would upload images of these accelerator processors. Went out to the shed and found my old 386/50 ish thing with the weird part on top.
cpu 2.JPG

Anyone got a 386 CPU board with say 4mb of memory and a vga video card so I can test these and see if anything works?
 
Just guessing, but because it's from Sun, it may simply only accept certain CPUs via a white list in the BIOS. Makes sense to me, as Sun did not want the owner to be able to upgrade the system with parts not bought from them. Remember, not even the original IBM PC/AT allowed faster CPUs. The BIOS would not allow the system to POST if the CPU was faster than what was hard-coded in the BIOS. Compaq did that with some series as well, even into the Pentium II era.
 
czunit said:
Well let's think. First the chip is set to clock at 40mhz, so running it at 25mhz should be a simple slam dunk.
Click to expand...

That's an internal clock doubled frequency. You're actually trying to run it at 50 MHz by installing it in a 25 MHz board. So that's potential problem one.

czunit said:
There is the 1k cache, but why would that trash the 386i's boot? It's possible it interferes with the 82357 chip on the memory boards, not sure how that communicates with a 386 chip but plenty of 386 boards had off chip cache.
Click to expand...

Even in PCs these chips caused loads of problems for (especially non-DOS) software, because of internal cache discipline and other assorted incompatibilities. One DMA transfer involving data that has been stored in the internal cache and you're toast, without the necessary hardware and/or software support to handle the invalidation(s). Which the Sun absolutely will not have.
 
bear said:
That's an internal clock doubled frequency. You're actually trying to run it at 50 MHz by installing it in a 25 MHz board. So that's potential problem one.
Click to expand...
No, that 486DLC does not double the clock. It's a drop-in replacement for a 386DX and is driven the same way as a 386DX. That is, 50 MHz clock for 25 MHz operation.

Coincidentally, I own exactly the same chip and had it run on a 386DX board for some time. For full speed, it used an external clock of 80 MHz.

And the SXL2-50 would also work the same way. You just need to mind that those are for a 386 socket, which means CPU clock is halved - even for "486"-class CPUs.
 
*nod* Good thoughts so far.

First, the chip isn't even getting the CPU to the point where it can rotate the LED lights. I'm not trying to get to OS boot, just to see if anything works. So unless the chip needs a tickle right at the first instruction it should be starting at zero and executing BIOS instructions.

In terms of the BIOS crashing it due to it not being a real 386, that's possible: The question then becomes how does it know.
 
Another interesting thing: This morning before going to work I tried pulling the memory card from the 386i and powering up. The system DOES flash the lights and start running tests, which means the system does NOT need the memory board to run tests, and the issue might NOT be related to the external cache controller that's on the 386i memory boards.

Which is another point: The 386 chip does have some hooks to handle external cache control, and the 82385 chip has the concept of multiple busses with DMA snooping on the device/peripheral bus, memory access on the memory bus, and the 386i gets a "clean" bus to access memory and such. That "clean" bus might be an issue because if something is cached in the 82355 memory, and a DMA device changes that memory location the 82355 will invalidate it's cache but won't tell the CPU that something changed so the CPU won't invalidate it's cache. However the CPU may still get IO signals saying something was done by DMA and it's time to flush the CPU cache just in case.

However I'm not at that point. I just want to see if any instructions are executing. I'll try putting in the Cyrix chip and then see if running it without memory (and thus no contention with the external controller) causes it to do anything or just lock up.
 
The 386i most definitely supports cache: They use the external 82385 chip to implement a fully snooping memory bus cache system. Which is nice, but it's external to the CPU thus isn't going to help much with clock-doubled processors.
 
I installed a Cyrix 486DRx2 in my Compaq 386/20e. It also has an external cache controller and no issues running Windows 95, Windows NT, and Linux. However, most of the fancy features of the CPU won't be enabled (including cache) until a utility is run to set them. Without running such a utility, the CPU should look pretty much like a 386 with more efficient instructions. I would assume the Cx486DLC is similar.
 
Hm. Well that brings back to the first question: If it looks like a duck, quacks like a duck and is put in a pond like a duck why doesn't it float like a duck?

Might be time to get the Logic probe out and see what's going on. Any particular pins to look at on the 386 cpu to determine if it's running or halted (maybe DAL 0-8 or something)

First I'll try it out of the box with just a power supply to minimize things and make chip swaps simpler. Then try swapping the CPUs to see if no memory changes things
 
Configuration point: With the 386i CPU board out of the box and no cards the system will start to flash the LEDs for a pre-bootup check with just the power supply plugged in. This will make swapping CPU chips a LOT easier.
 
Another point: With the board out, TI CPU in I get solid lights. Put in the normal CPU, lights flash. Pull the ROM, lights solid.

So either the CPU is not running at all or the ROM contains code pretty early that shuts down the system.

The big question is how is it spotting the CPU being different. 386 cpus do not have the CPUID register that Pentiums and such have, so it can't find it there. I doubt they do a whole bunch of timing tests because the CPUs are running without a cache, plus at least one reliable person got an IBM Blue lightning upgrade to work so SOMETHING has to be the same there somehow.

May be time to disassemble the boot ROM code. Anyone know if there's a copy already out there or do I have to dig out an EPROM reader?

Or should I start looking at pins to see if the address/data bus is doing anything? It's got no memory, maybe watch the address lines on the EPROM?

On the positive side the chip may be an EPROM as opposed to a normal PROM.
 
Ok. Further checking tells me you can run the board WITHOUT the timekeeper chip and with a real 386/25 it will start the LEDs moving (but stop pretty quickly). With a third party chip it does nothing.

So either the CPU is running, or it's not. Hm.

The EPROMis a D27010 Intel chip, 128k*8 bit. So if needed I can dump it and reprogram.

First though I'm going to try hooking some probes to see if any instructions are being fetched. My search fu is not working well, anyone know the pinout of the 27010 type chips?
 
This is fun!

So the 386 cpu does not have the concept of a CPUID register because that came along later. However there is a programming trick to see what's going on:
Upon CPU initialization the EAX register should contain 0 if the processor has no errors. Ok.
On a real 386 CPU EDX contains a "Device identifier" of 03x in bits 8-16 and a Stepping ID in bits 0-7.


On a Cyrix 386/486 EDX contains an 04x plus the revision ID in lower bits.

I'll bet that's what the Bozos at Sun were checking very early in the boot code. Instruction 1 could be "Check EDX, if 3 then go else halt"

All we need to do is change that first HALT to a NOOP and the system should pile right along.

So..... Who's an expert on EPROM dumping and reloading? I have an older programmer in the shed, but haven't used it in a long time......
 
czunit said:
In terms of the BIOS crashing it due to it not being a real 386, that's possible: The question then becomes how does it know.
Click to expand...
While there is no CPUID, the BIOS can identify the CPU. It is possible that the Sun firmware checks the CPU ID early and aborts. But when the system was designed, the Cx486 chips did not exist yet.

It's also possible that the firmware simply crashes because the CPU behaves differently. With the internal caches enabled, a simple timing loop will execute much faster than on a stock 386. I don't know if the cache are completely disabled if the BIOS doesn't know about the Cx486, it may just run in a degraded mode.

Cyrix also had to jump through a some hoops to get the internal cache working reliably even on 386 mainboards with various external cache solutions. The OS/2 museum has a good article about the details: https://www.os2museum.com/wp/386-cache-coherency/. A Sun386i is not a PC, so some assumptions taken by either Sun or Cyrix may just not work as intended.
 
Yep, all true. From what I can see though the Cyrix chip starts out with cache off so it's really more of a boring 386. I'll bet a sandwich that Sun is checking for a 3 in that field and I'll also bet that if I got an Intel RapidCAD set (thinking about it but $350 is a fair bit) that it would work perfectly as it would respond as a CPU type 3 as well.

I mean it would be a completely dick move to test the CPU right out of the gate, but this is Sun and they want 1000% control over all their systems. Sad but true.

Once the system is up I can start working on the cache. I know I downloaded the K486.zip onto one of those drives back in 1991 or so (30 years ago?) which is good because it seems to be lost on the net again. But that should give me the clues to start fiddling with the registers to turn cache on and see what blows up.

From everything I've read it sounds like you can only do cache flushes by watching for DMA access and just dumping the cache. In fact on that TI 486 that appears to be exactly what that little wire thing does: When a DMA line is asserted it does a hard flush. Which isn't great for performance (PDP11's are much better) but we'll see what happens.

Dumping the ROM will show the answer pretty quickly. Any thoughts on how to do?
 
Unfortunately, I don't know enough about these systems for really good answers. The firmware is most likely memory-mapped permanently, so you should be able to read it somehow. Obviously, removing the ROM chips and reading them externally would also work.

The firmware appears to be similar to other Sun machines, so they should run a variant of FORTH, which can read memory. Try "10000000 100 dump" or something along those lines. If that works, and you've got a serial console, you have a workable, if slow, solution.

In DOS, you have DEBUG to read physical memory, and Linux has /dev/mem which can do the same. I don't know if old SunOS has that device, and I don't think NetBSD ever supported that platform.
 
This document (search for 386i) seems to indicate it does check the CPU:


Mentioned in the EEPROM/NVRAM section:

0x111 Sun386i CPU revision level
0x01 P1.5 CPU (should not be in the field)
0x02 501-1241/1324-xx
0x03 501-1413/1414-xx

0x112 Sun386i CPU revision level
0x00 P1.5 CPU (should not be in the field) ([0x111] = 0x01)
0x00 <= 501-1241-02 Rev 15 ([0x111] = 0x02)
<= 501-1324-02 Rev 15
0x02 >= 501-1241-02 Rev 16 ([0x111] = 0x02)
>= 501-1324-02 Rev 16
0x00 501-1413/1414-xx ([0x111] = 0x03)

I don't know what would happen if you cleared the related values or if you tried adding in the information from the "other" CPU in those values...
 
MrImprovement said:
This document (search for 386i) seems to indicate it does check the CPU:


Mentioned in the EEPROM/NVRAM section:

0x111 Sun386i CPU revision level
0x01 P1.5 CPU (should not be in the field)
0x02 501-1241/1324-xx
0x03 501-1413/1414-xx

0x112 Sun386i CPU revision level
0x00 P1.5 CPU (should not be in the field) ([0x111] = 0x01)
0x00 <= 501-1241-02 Rev 15 ([0x111] = 0x02)
<= 501-1324-02 Rev 15
0x02 >= 501-1241-02 Rev 16 ([0x111] = 0x02)
>= 501-1324-02 Rev 16
0x00 501-1413/1414-xx ([0x111] = 0x03)

I don't know what would happen if you cleared the related values or if you tried adding in the information from the "other" CPU in those values...
Click to expand...
Good data and thanks for spotting this. I wonder if that is a CPU revision (Intel die) or a CPU board revision (motherboard). Will have to look into it.

One thing I did notice though is that if you completely pull the Timekeeper chip the LEDs will start to light and flash with a real CPU but will not do anything with the Cyrix/TI chips. Which tells me that the ROM is not first checking the Timekeeper or comparing to the Timekeeper chip for the CPU value but instead is using a hard coded value to see if it's an Intel chip. If it was then pulling the chip would cause a stall regardless of CPU.

Hm. Doing a quick look at my dumps of the disks I don't see a copy of K486.tar.Z on there which could mean it's lost forever. Unless it's on one of my NeXT backups. Hm.
 
You must log in or register to reply here.
Back
Top