# Shared support chips and tooling between 16 and 32-bit computers

Can a production line for a 16-bit computer save significantly on unit cost by sharing support chips and tooling with another 16-bit computer, to a greater extent than if it went 32-bit?

To be concrete: around the time of Windows 3, some of the most popular CPUs were the 286 (16 bit), 386 (32 bit) and 386SX (like the 386 but with a 16-bit data bus). Suppose a company is manufacturing 286 computers, and is looking at introducing a 386 model, but considering going with the 386SX to save money. Clearly the CPU itself will be cheaper, as will having 16 instead of 32 data bus traces on the motherboard.

But will a 386SX computer be able to share support chips, tooling or suchlike with the 286 production line, that the full 386 machine would not have?

• As far as I know (and I was a computer user but not builder back then,) the savings at the time were the chip costs, not in the tooling. – Jon Watte Sep 4 '17 at 16:51

I'm going to skip the more general question as it would require a book, or more, to address. I'll focus on the x86 line, instead. I recall some of the context, making writing somewhat easier (if perhaps also subject to imperfect recollections.)

The 80286 was quite quirky and released based upon a marketing strategy choice rather than a technical one. IBM had introduced the PC circa mid-year 1981 -- a full two years after the introduction of the 8088, upon which it was based. The 80386 was fairly clear in mind by this time (based firmly upon actually attempting to implement hardware consistent with the ideas of Multics.) But that project was still a long ways out, too, and by this time Intel's marketing department had concluded that a new processor was required. The 80286 was pushed out with the ability to enter protected mode by software commands, but without the ability to return to real mode without a processor reset. As a result, the keyboard was tasked with the job of generating the external reset signal. Switching back and forth between modes was the ONLY way of accessing memory beyond the 20-bit address limitations of the older 8088 (though the 80286 supported a 24-bit address bus.) And the process was quite slow (many milliseconds per reset switching.)

The IBM PC/AT entered the market with a clock rate of 6 MHz. And like the 8088-based IBM PC, itself based on 4.77 MHz (just under the 5 MHz max of the 8088), the bus rate was tied to the CPU clock rate. The 80286 could achieve faster speeds, though. I immediately changed the crystal from 6 MHz to 8.5 MHz in my own machine (the PC/AT costing over $5k at the time.) But this also sped up the bus, too. And a lot of add-in boards would fail. (Intel, around this time, made more money selling memory than CPUs. The cross-over took place later in 1985, when CPUs was to firmly establish itself as their primary profit center.) The first truly IBM PC compatible computer (there were quite a few, but almost all of them failed in some way or another to run some of the important software for the IBM PC) that ran almost 100% of everything the IBM PC would run (excepting the built-in BASIC interpreter) was the Kaypro 80286i. The motherboard sported socketed MSI and SSI logic gates (a huge number of them.) But it worked. Soon after, other manufacturers became "compatible enough" to compete well and a serious price war started. (The clone marketplace was soon very crowded.) Because of the ease of designing at these speeds and the relatively lower cost of test and measurement equipment needed, many companies could quickly field a motherboard of their own. And they started competing on speed. Soon, we saw 8 MHz, 10 MHz, 12 MHz, and even 16 MHz (about which time the 80386 was soon due.) But in order to achieve speeds in excess of 10MHz, the bus had to be decoupled from the CPU speed. There was no possible way for the I/O boards to keep up with the rapidly increasing speeds of the CPUs that Intel was now pumping out. Here enters companies like Chips and Technologies (aka C&T.) They made ASICs that would greatly simplify the design and manufacturer and testing of motherboards and these ASICs allowed the bus rate to be decoupled from the CPU rate, for the first time. (It's possible that someone attempted this with DIP ICs, but I don't recall it happening.) This allowed manufacturers to compete on speed without impairing the ability to support older (or current) boards that were also commonly used (EGA, VGA, printer, etc.) [Also, several BIOS-writing companies also entered the market (and had been) which lowered the barriers for a motherboard manufacturer to field competitive boards.] Intel was developing several new strategies, leading into the release of the 80386DX in 1985, though. (The 80386SX would be introduced 3 years later.) One of them was to include a wider data bus. Another was to implement the Multics support hardware, cleanly, and to fix the problem of moving into and out of protected mode. The timing was also considered important (3 year release cycles.) With the IBM PC, there was a socket for the 8087. But this was usually ordered directly through IBM. And most folks didn't feel the need for it (it wasn't fast, anyway, and it was an expensive option.) But with the introduction of the 80286, Intel continued to encouraged these new-minted alternative (non-IBM) motherboard manufacturers to similarly include 80287 sockets on their boards. And customers were just beginning to learn (through the usual magazine articles) that an 80287 was often worth adding. The 80386SX was released three years after the 80386DX (which had been called the 80386 without the DX, earlier.) This was arguably to allow motherboard designers to use a cheap chip and a narrower data bus (and the 24-bit address bus of the 80286.) While some argue that this including being able to use older C&T support ASICs, it's my recollection that both timing and the requirement to support the 80387DX argues strongly against the idea. By the time the 80386SX came out these C&T chips were already about five years old and they were not entirely compatible with the new 80386SX/80387SX pairing, anyway. [Around this time C&T was also starting to test the waters of competing with Intel directly (Super386 38600SX.)] By the way, Intel would take all this to the next level with the 80486 family. They would seriously engage development of their own chipsets and compete directly with C&T, themselves. And they would field not only an 80486DX (sported to include floating point), but also an 80486SX and an 80487SX soon afterwards. These were all the exact same chip, just repackaged and rebonded versions. (The 80487SX was just a repackaged 80486DX that literally lifted the 80486SX off of the bus and effectively disabled it. The 80486SX was also a rebonded 80486DX die that may have had a defective FP unit that would be disabled) Intel WANTED to sell chips to the public, directly, now! (Major profits.) They'd made some money selling 80287 and 80387 floating point ICs, earlier. And they saw an opportunity ahead of more seriously getting into the business of selling ICs retail. (Before, they sold to engineering companies that bought in huge quantities and expected narrow margin pricing all too often.) So the 80386SX was more about encouraging board manufacturers to include a socket, once again, but a socket that Intel would sell directly into through stores like K-Mart. Intel would get into the business of selling ICs retail!!! The PCI bus would still later be sold as a "green bus." But it's real purpose (reflection wave rather than incident wave design) was to solve yet another serious problem. Intel had addressed themselves to the C&T upstarts, with the 80486 family, and practically took over the ASIC support chip business. But now they found that the "mom and pop," clone-wars motherboard competition was killing them in another way -- boards were way too cheap. This meant that Intel had to sell their chips cheaply, too. Not so much profit in that. They needed to kill the "mom and pop" businesses and greatly reduce the competition in motherboard manufacturing. The PCI bus, when introduced, would mean that a single piece of test and measurement equipment would cost in excess of$100k apiece! Design rules were complex (serpentine clock, with 2ns skew relative to data, etc) and testing equipment expensive. This, and some other steps, helped to price the small companies out of the market and achieved Intel's goal there, as well.

(I did chip-set testing for Intel circa the introduction of the Pentium, Pentium-Pro, and Pentium II.)

To answer your question about the 80386SX... Earlier chipsets that had been used for the "clone wars" 80286 PCs could NOT be used with the 80386SX in 1988 when it was introduced (many years after the C&T chipsets for the 80286 existed.) This was primarily because of the seriously different timing issues that separated these two families. Instead, ACC, C&T, G2 (whom I worked for, as well, for a short time), Western Digital/Faraday, and of course Intel, fielded chipsets to directly support the 80386SX. (Not to mention the need to support the 80387SX.) I can't recall if anyone even attempted to use an older C&T 80286 chipset with the 80386SX. But I seriously doubt it was even attempted, that late in the game and with other chipsets readily available those 5 years later on.

• Great answer, thanks! Just one small correction: 'building floating point directly into the earlier 80386DX' - the 386 didn't have built-in floating point, that only came about with the 486. – rwallace Sep 4 '17 at 15:21
• PCI also solved some pretty big technical problems with ISA/EISA. As an OS developer at the time, I really appreciated the plug-and-play as well as the speed. I don't think "make it complicated" was an explicit goal; I seemed to me like "so what if it's complicated, let's forge ahead!" was more of the thinking. If mom-and-pop happened to fall by the wayside, no tears shed by Intel. – Jon Watte Sep 4 '17 at 16:59
• @JonWatte It CREATED technical problems. For example, ISA supported DMA but only at a fixed rate. PCI supported bursts. South bridge had to sort it out. 50%+ of all the chipset bugs were from the ISA-PCI south bridge and side channel signals added to get things "working." Kind of working, anyway. And there's a lot more but no room here in the comment for them. I was there, working at Intel tracking these things down, as that was my job. (I liked ISA because I would wire-wrap something up and it would work -- cheap.) The mom/pop was a prime reason too. I was there & got it straight from a VP. – jonk Sep 4 '17 at 17:09
• For an electronics engineer's point of view, having to push the envelope, I entirely understand!From a systems software point of view, it was great! (Just like putting Multics support into the 386 was great.) To witness its greatness, we STILL use many of the concepts from PCI, as it has evolved into PCI-Express. (Compare to the evolutionary appendix of the AGP port. Can't say VESA was any better, either...) – Jon Watte Sep 4 '17 at 17:13
• @JonWatte I wrote O/S's and worked on those by others and really enjoyed my first 80386 O/S writing experience. (I go back to 1975, writing O/S code.) I also truly enjoyed BSD386's very clean design fit to it, too. But I also did hobbyist hardware and ISA was very simple and easy. PCI was very expensive to design, time and money. -- yes, I took classes on PCI, paid for by Intel. (I was also there when AGP was added.) Still, I like the ease for hobbyists of ISA. I keep two ISA bus boxes running here because of that, by the way. – jonk Sep 4 '17 at 17:24

While not exactly answering your question, you should consider the biggest success story of them all: the original IBM PC. This used the 8088, an 8086 (16 bit) CPU with an 8-bit data buss, and 8-bit IO chips.

More to the point, other than RAM there is generally no purpose to using 32-bit support chips, and no advantage to using them if they did exist.

In general, 386SX machines did use 286-family support chips.