Spurred by the acquisition of a 386 ZIF socket adapter, I revived the semi-mysterious 386 board acquired over a year ago. To recap, the board is unusual in that it has CPU frequency configurable via jumpers, but I had trouble getting anything other than the soldered-on Am386DX-40 to run.
Experimenting with the PGA processor socket showed somewhat odd behavior: Plugging in another Am386DX-40, the board worked and both CPUs seemed to run. Lowering the frequency, it was even possible to have an Intel 386 CPU running in the PGA socket. But a Cyrix or TI processor would not work. The current theory is that as delivered, a CPU plugged into the PGA socket would be active, but the soldered-on processor ran as well. As long as the two were more or less identical, the system would work.
Jumper J1
There was a promising-looking jumper J1, or rather empty space where it should have been. An experiment with manually shorting the J1 pads was very encouraging: It appeared that closing J1 disconnected the soldered-on CPU and a processor in the PGA socket could run without interference.
I soldered on a real jumper and sure enough, with J1 closed I could run more or less any CPU in the PGA socket—now equipped with the ZIF adapter.
So what does J1 do? It turns out to be connected to pin 54 of the PQFP processor. That is the FLT# pin, which is specific to the PQFP Am386 processors (both the DX and SX variants had it). The pin supplies the Float signal which forces the CPU to float (tri-state) all of its input and output pins. It is very similar to the bus hold behavior, except the HOLD and HLDA pins are floated as well. It does not power off the CPU but it effectively disconnects it from the bus, allowing a different CPU to drive the system.
CPU Clocks
The next order of business was sorting out the frequency jumpers (J14-J16). After a few minutes, I ended up with a table that looked like this:
J14 J15 J16 8 MHz: On On On (shown as 16 MHz) 20 MHz: On On Off (no boot from C:) 25 MHz: On Off On 40 MHz: On Off Off 33 MHz: Off On On 50 MHz: Off On Off xx MHz: Off Off On (very slow, no POST -- kbd error) xx MHz: Off Off Off (super slow, no POST -- kbd error)
At 20 MHz, the board insisted on booting from drive A: despite being configured to try C: first and despite working well at higher frequencies.
When the BIOS claimed that the CPU runs at 16 MHz, the system was very slow and all utilities agreed that the processor in fact runs at 8 MHz, not 16.
The last two settings initially seemed like the board wouldn’t come up at all, but with a good deal of patience it turned out that it’s merely very, very slow and fails POST with a keyboard error (at which point it isn’t possible to press F1 to continue).
The behavior was strange enough that an explanation was in order. I looked at the clock chip’s datasheet for an answer—this was an Avasem AV9107-03. The original Avasem datasheet appears to be unavailable, but one for ICS AC9107-03 can be easily located. Presumably ICS bought Avasem around 1993 and continued manufacturing the clock synthesizers.
Sure enough, the answer was right there. The clock chip’s FS3 input is forced to logical 1. J14-J16 then correspond to FS2-FS0 and a closed jumper means logical zero. The table from the datasheet looks like this:
J14 J15 J16 8 MHz: On On On 20 MHz: On On Off 25 MHz: On Off On 40 MHz: On Off Off 33 MHz: Off On On 50 MHz: Off On Off 4 MHz: Off Off On 2 MHz: Off Off Off
The supposedly 16 MHz clock is indeed 8 MHz (as all the utilities indicated), and the very slow speeds are 4 and 2 MHz, respectively.
The 20 MHz boot problem can be worked around by disabling automatic configuration (“AUTO Config Function”) in the advanced BIOS settings. For whatever reason, that allows the system to boot up correctly.
All in all, the board can be used for 20, 25, 33, and 40 MHz operation, as well as for overclocking to 50 MHz. The 16 MHz frequency is unfortunately missing, although a 16 MHz CPU could still be tested at 8 MHz. This allows any PGA 386 processor to be tested.
Performance
Because the board is relatively new (for a 386 board)—early 1993—the BIOS/chipset has built-in support for Cyrix 486DLC processor. The BIOS can enable L1 cache on these processors and should also handle cache coherency.
The board is a good performer… for a 386 ISA system. It sports 256KB of cache on board, and this makes a difference. It will handily beat any cacheless 386 system. With a Texas Instruments 486 SXL2-50, it achieves performance which is in some ways better than that of a 33 MHz 486. With a 40 MHz 486DLC the performance isn’t bad either and leaves any Intel or even AMD 386 in the dust.
Pros and Cons
The board as 8 slots for 30-pin SIMMs and it’s hence trivial to equip it with 8MB RAM, which is not bad for a 386 system. It should be possible to go up to 32MB using 4MB SIMMs.
The board does not include any devices to speak of, but it has six 16-bit and one 8-bit ISA slot. Especially the 16-bit slots are plentiful, so adding audio, video, storage, and I/O should be no problem.
There is a 387 socket including Weitek support. Whether that works is anyone’s guess as Weitek FPUs are incredibly rare. Regular 387s do work in the board.
Obviously the board uses the AT form factor. It’s on the small side which is generally not a problem, except that the power connectors are too close to the SIMM sockets (or perhaps oriented the wrong way) and annoyingly difficult to connect.
The BIOS is old enough (early 1993) that it does not support any geometry translation. Booting from disks larger than 512MB requires care. A 512MB CF card works well with the board.
All in all, the board is not bad at all for a latter-day 386 system. It is very flexible and the jumper-settable clock chip is a great plus. With a 386 ZIF socket adapter it turns into a formidable 386 test bench.
Is it stable at 50 with cache enabled? I’ve seen many 386 systems overclocked (the hard way – via clock crystal) to 50 but I’ve never seen one where the cache didn’t go wonky.
If this board tolerates it that would be an impressive feat indeed.
Do you have any idea why it worked without the jumper as long as you used another Am386DX-40? Unless they were running in sync 😀
I think that’s exactly what happened, the two CPUs ran in sync. Their behavior was identical so they didn’t clash with each other. At least that’s the only explanation I can think of.
That is pretty impressive. I was curious and did some math: Given the length of a pulse at 40MHz and the speed of light, you shouldn’t have significant overlap of the pulses due to propagation delays, as long as the difference between the distances of each CPU to the bus are less than about 1m (a very rough estimation), so at least from that perspective it seems entirely within bounds.
It’s a shame that a 386 doesn’t have any kind of unique CPU ID (or does an Am386?), I would be enormously interested in seeing if you’d get back the binary OR or AND (I have no idea of the bus’s characteristics) of both CPU IDs.
Is there maybe anything else that could be different between the two CPUs, for such an experiment?
There are no IDs beyond what’s returned in EDX after reset, and that’s likely identical between the two. As far as I know, there isn’t even any way to tell the Am386 CPUs from Intel 386s in software, although their bus behavior could be slightly different.
With the AMDs, I’m not sure what would be different. I think the PGA and PQFP CPUs are extremely close to identical. In fact there were PGA Am386s which were really just a PQFP CPU soldered to a PCB with pins.
As far as I know, AMD’s 386 is mostly based on Intel’s 386, so it makes sense that an Intel 386 worked in parallel with the soldered-on CPU.
I know you have a few different Intel 386 steppings, so it would be interesting to see which ones will run in parallel with the am386, and what EDX revision identifier you’re able to pull from the combinations that work.
Sorry if this seems like a nitpick, but the limit with standard bios and ide drives is 528MB /504MiB, not 512MB/MiB.
https://www.win.tue.nl/~aeb/linux/Large-Disk-4.html
Any idea why the board threw a keyboard error on the 4 MHz and 2 MHz settings?
I don’t know. Untested code path probably 🙂