Why was hardware diversification an asset for the IBM PC ecosystem?

Question

The IBM PC was cloned very early on, and many third parties made hardware peripherals. This required users to run an OS, install drivers, manage IRQs and hardware bus addresses, etc. Why was this a strength of the platform, instead of a weakness?

I'm thinking specifically of Commodore/Amiga where the hardware was less diverse and end users/programs didn't need to manage so much fragmentation. I'm also thinking of modern examples like Android where fragmentation is a big problem, and iOS where the hardware is less diverse and that is seen as an asset of the platform in ways.

Inspired by Why weren't bootable game disks ever common on the IBM PC?

Answer 1

It was an advantage because the IBM PC became an extensible computing platform. The most popular competitor to it previously was the Apple II, another open platform.

The PC, as a platform, was popular to users because of the choices it enabled, as developers because of the foundations that it laid, and engineering firms because they could focus on what they wanted to do (say, a graphic card, or a computer vision system) rather than an entire computing system.

Since MS-DOS availed the ability to readily install things like drivers, the platform allowed things like configurable interrupts, etc. it gave everyone involved a lot of flexibility in designing their solutions.

So, not only was the hardware "open" (the PC bus system was reasonably well documented), the software was also "open" (in that it was straight forward to augment the system with your own drivers). I don't mean "open" as it's typically referred to today (i.e. free, source code available, etc.) but it was "open" in the sense that anyone could make a card, with no payment to IBM, and anyone could make a driver, with no payment to Microsoft. You also, as an end user, didn't have to rebuild the operating system software yourself like you did in CP/M. CP/M's design wasn't as flexible in this regard as MS-DOS was. (This changed a little later, but the legacy lived on.)

Yes, this led to complexity at the user level since the burden of configuring the cornucopia of diverse systems fell on them. It also lead to some complexity at the software development level - but only at the edge cases. In time things became common and compatible, lowering the barrier for software.

So, since the PC offered a unique combination at the time of a robust foundation, especially once the XT hit, of the BIOS, large memory space, the large array of peripherals (robust character graphics, nice high resolution graphics, color graphics, floppies, hard drives, printers, serial ports) and then the "infinite" expandability of an open bus and extensible base operating system, and then the explosion of the clones, the network effect surrounding the PC became very compelling despite all of its innate weaknesses.

The PC represented a maturity of the product and the industry after learning from the rise and struggles of the diverse early micro environment where everything was cordoned off to a limited platform.

Addenda:

I can not speak to the Amiga. But there is a distinct difference between a simple "expansion connector" and an actual computer "bus". A expansion connector is typically the signals of the CPU routed out to be connected to by external hardware. But, that's where it tends to stop.

A Bus is actually a communication protocol for peripherals designed to facilitate the sharing and management of those signals. It's more than just raw CPU signals; it's also potentially other signals and protocols to allow peripherals to request and gain access to the CPU and other devices on the bus. You can't have two devices "fighting" over the CPU signals.

For example, you may have the CPU trying to talk to a serial port at the same time as a disk drive is trying to use DMA to fill a buffer. They both want to use the data lines of the bus. How is that negotiated? That's what the bus control signals and protocols provide the designers.

The PC offered a series of card slots and a card cage for expansion. It offered a formal bus protocol. It offered a Programmable Interrupt Controller (PIC) and DMA channels. Those are all nice things to have in a computer system from a hardware point of view. It made it easy for users to add not just one peripheral, but several. Want to put in a pair of 8 port serial cards to run a BBS? No problem. Want to add a SCSI tape drive that use DMA to speed up transfers while the CPU is doing other tasks? The foundation is there.

Did the Amiga offer anything of this formality? I have no idea. I don't mean to slight it. I have no doubt you can easily to any one of these things to a computer with an expansion connector. But can you do more than one? From competing manufacturers? That's different. They may both assume that they have full control over the expansion connector. No doubt folks added peripherals to the Amiga (and other computers). But there's a difference between having access to the raw CPU signals, and building a community around a standardized bus architecture. There may well have been a de facto agreement within the Amiga community on how to be a well-behaved citizen on the expansion connector.

And yes, despite the bus, stuff collided and ran in to incompatibilities within the PC bus, but as evidenced by the vast array of peripherals, from the exotic to the mundane, the PC architecture was very versatile.

Answer 2

The IBM PC was cloned very early on, and many third parties made hardware peripherals. This required users to run an OS, install drivers, manage IRQs and hardware bus addresses, etc. Why was this a strength of the platform, instead of a weakness?

A wide range of hardware devices was a strength, in that, if IBM wasn't willing to build it, or was unable to build it and release it in a timely manner, then someone else (perhaps many someone elses) could. This broadens the range of use for the platform as a whole. That makes for a virtuous cycle: greater range, more users, more incentive to support the system.

Dealing with the hardware configuration was a downside of the variety, sure, but apparently not a sufficient disincentive.

(The PDP-11 followed a similar arc, especially in its early days, where the documented bus architecture allowed a robust add-on marketplace to develop).

Answer 3

The hardware in PC clones was not particularly diverse, if the technical characteristics of the hardware is the distinguishing factor. Yes, there was a great diversity of manufacturers and vendors, but the diversity of features was pretty minimal. It is probably best to describe the PC clones of the 1980s as vanilla computers. And this was their real strength.

Because the hardware was "PC compatible", having the basic features required to make it so, it could be counted on to run the popular MS-DOS applications of the time. This actually liberated the user from having to think very much about the diversity of vendors. Most buyers of PC clones at the time weren't venturing into esoteric hardware for highly specific use-cases, nor were they buying components and assembling a properly configured PC themselves. They just wanted a machine to run Wordperfect, Lotus 1-2-3, dBase III, and other popular business titles. Therefore, their buying decision was generally driven by the price-to-performance ratio, and the performance was mainly a matter of CPU (e.g. 8088 vs. 80286 vs. 80386) and clock speed. This allowed for fairly simple buyer comparisons.

So, the diversity of vendors created little real hassle for buyers (they always got the same basic features and compatibility), while also fostering a highly-competitive market where price/performance ratio fell rapidly. It was the rapidity of falling prices with rising performance that allowed the PC clones to overwhelm the competition from Apple and Commodore, not to mention IBM, themselves.

Answer 4

Unlike the Amiga, the IBM PC was always seen as mainly a business computer. Having business done on lots of small machines on desks, rather than on large central machines via terminals, meant that businesses had to provide support staff to configure machines and assist users, rather than having staff to look after the central machines.

However, the total cost of ownership would seem to have been lower, judging by the runaway success of PC-based business computing. PCs also became less demanding to configure over time, as they came with more and more built-in capability.

Hardware diversification also provided ways for PC manufacturers to compete, driving costs down and ease-of-use up. However, they always remained PC-compatible, which meant they could run the same application software.

The fragmentation of Android, in my experience, has been caused by the fragmentation of the ARM 32-bit instruction set, which was a consequence of ARM's willingness to customise their processor designs for their hardware-manufacturer customers, and those hardware manufacturers' lack of appreciation for the benefits of application compatibility. It's just the same situation as you'd get if Dell and HP Windows machines had different instruction sets, custom-designed for Dell and HP by Intel. As a chip manufacturer, wanting the benefits of making millions of identical chips, Intel don't do that. ARM discarded the idea with ARMv8, which does not get customised by individual customers, curing the fragmentation problem.

Answer 5

The word "ecosystem" in your question gives a clue to the answer: hardware platforms evolve, to a greater or lesser degree, after release. It's inevitable that technology will progress to offer new capabilities after release, and one of the factors in the long-term success of a platform is how well these (often entirely unanticipated) new capabilities, such as networking, can be integrated into existing systems.

There are two major factors that affect this.

The first is the relative distance between the main bus of the computer and the expansion attachment points. Typically, the closer to the main bus and the fewer constraints, the faster devices can run and the more cheaply they can be made because less interface hardware is required. (Some devices, such as hard drives and network cards, become less useful if they can be used only at very slow speeds.)

On a system like the Atari 800, where new devices almost invariably had to be attached to the Atari SIO serial bus, this required extra hardware in the device to handle the bus protocol and also placed a couple of layers of hardware between the CPU and the device, greatly slowing the data transfer speed as opposed to a device on the main bus.

By contrast, a card plugged into an Apple II slot was directly on the system bus and typically require only minimal interface logic, with the CPU usually directly accessing the core chips of the peripheral.

Offering only one slot for direct bus access was often nearly as harmful as not offering it at all; the Commodore 64's cartridge port was directly on the system bus but, because there was only one cartridge port, almost all peripherals ended up on the somewhat slower user port (essentially a parallel port, and even here there was only one) or most often the horribly slow CBM serial bus. (You could buy expansion units that would give you multiple cartridge ports, but here again we now have the issue of extra cost, though for the user rather than the peripheral developer.)

The second factor is whether a peripheral is adding missing functionality or simply an improvement over existing functionality. This is basically a cost issue: you'll sell a lot more sound cards of any kind for a system that has extremely poor or no sound capabilities than you will improved sound cards for a system that already has sound capabilities. (And of course the initial system cost for an otherwise equivalent system with no sound capabilities is lower, tending to help with initial sales.) Thus platforms that start with "good enough" capabilities in some area such as sound tend towards keeping those same capabilities over the life of the system, whereas platforms very poor in such areas will have new platform owners continually buying slightly better peripherals than previous owners and you'll tend to see the capabilities broadly available in the population increase over time.

So basically what it comes down to is that providing direct bus access for peripherals and fewer capabilities makes it easier and cheaper to add new capabilities both initially and over the life of the system, at the cost of users having to deal with a lot more software configuration complexity to handle both the wider variety of peripherals and the lack of standard interface routines from the start.

Answer 6

Very good answers here already; I'll try to focus on direct answers to your questions.

This required users to run an OS, install drivers, manage IRQs and hardware bus addresses, etc. Why was this a strength of the platform, instead of a weakness?

Because configuration hassle is much more affordable than buying a new system to support your new hardware.

I'm thinking specifically of Commodore/Amiga where the hardware was less diverse and end users/programs didn't need to manage so much fragmentation. I'm also thinking of modern examples like Android where fragmentation is a big problem, and iOS where the hardware is less diverse and that is seen as an asset of the platform in ways.

Two points:

• The Amiga was a particularly elegant platform on how its components talked and delegated responsibilities to each other, but its hardware interoperability suffered from a few issues. Notably, the PCMCIA Type II that shipped with the entry model A600 and provided as external hardware interface wasn't fully compatible with the standard since the A600 was released before the standard was finalized (that issue was later partially fixed on the A1200, but then it couldn't support the new 32-bit CardBus peripherals.) Also, it added an extra licensing cost.
• Commodore, at the time under Mehdi Ali, seemed unwilling to allow Amiga clones to exist - even self-sabotaging a licensing deal with Sun Microsystems not only, but twice, by unreasonably raising its licensing fees.

Finally,

Why was hardware diversification an asset for the IBM PC ecosystem?

Because the IBM PC standard provided a baseline structure that hardware developers could use to augment the system instead of being forced to develop their own.

Answer 7

One problem in designing future-proof systems is deciding what features of the system's present design should be regarded as fundamental and what aspects should be considered happenstance. If some features of a design get treated as fundamental, it will be very difficult to change them later, but features needed to accomplish tasks efficiently can't be relied upon, it will be impossible to accomplish those tasks reliably and efficiently.

Some aspects of the PC's design (e.g. the presence of CGA display memory at hardware address 0xB8000) ended up being treated as fundamental because IBM and Microsoft failed to provide a reasonable alternative, even though it would have been better to avoid such dependance (e.g. by providing a function to inquire where display memory is located). For the most part, though, the PC ended up with a relatively practical mix of fundamental and happenstance design elements.

Answer 8

I think it was just a nice middle ground.

Warning: anecdotal knowledge ahead.

Commodore/Amiga had basically just one configuration which sold exceptionally good - C64 and A500. Revisions worked well by maintaining compatibility, but did not add any extra performance.

Then came the C128, which had a C64 compatibility mode. No seamless upgrade, but rather a 2-in-1 solution. Developers did not really adopt the new platform well, because they would be cutting out a huge userbase, so the C128 never really caught on.

For Amiga - they did both Hardware and Operating System themselves, retaining pretty good compatibility, but ultimately went bankrupt, and with them their ecosystem died.

The Intel-based IBM PC had everything right in hindsight: variations of the hardware in terms of CPU, RAM, disk drives, sound cards, peripherals... you could buy a new PC, drop your cards in, re-use your disks.

DOS was great. I think 6.22 still worked on my 8088 with no problems. All old software I remember could be run on any newer iteration (8088 -> 286, 386, 486; DOS 3.3 -> 5.0, 6.0, 6.2, ...), and new software could be run on a rather old PC as well, if it were not for speed - I remember playing Wolfenstein 3d on my 286, in a very small window though.

For graphics, there were just a few standards: (Hercules,) CGA, EGA, VGA. Always backwards compatible, so a VGA card could emulate EGA and CGA. Old games running on a newer PC was the norm. Games were DOS-based anyway.

There were no drivers. VGA for games was the norm, and it was standardized. No matter the vendor, a VGA card understood VGA commands, and that was about it.

Sound cards needed drivers, but there were just a few standards, and games supported them. SoundBlaster Pro/16 and AdLib were the most popular.

Hardware vendors had to make their cards compatible to those, then they worked as well. I had an ESS Audiodrive which was much cheaper than an original SoundBlaster, I just told all the games I had a SoundBlaster 16 and it worked perfectly.

Changing expansion Cards, RAM and even CPUs was dead simple. You open the case, one screw holds the card in place (same system as used still today btw.).

For RAM and CPU no extra tools were needed at all. Only with 486s CPU fans became popular. Up to 386s it was common for CPUs to not even have a heat spreader.

You could salvage old parts from whoever got rid of them (schools, companies, friends), and upgrade your old PC for free!

Security was not an issue back then. Viruses spread via diskettes, and manual virus scanners were popular and necessary. But apart from that, when a system was running, it ran until it was replaced.

There were no annoying security updates, it was not uncommon to leave an installation of Windows 3.1, Word 6.0 and whatever you needed untouched for a couple of years.

Fast forward to Android.

Starting with a couple of screen resolutions, different sets of hardware buttons, CPUs with varying speeds, and entry level devices with way to little RAM. Top off with apps requiring OS updates which are unfortunately not available for that pricey device you bought just one year ago. Those are the true downsides of an open platform: vendors trying to cater to a price point which tecnically works, but in practice just ruins the experience.

Back to DOS. During that period, I perceived no fragmentation. Everything ran everywhere, if your CPU could handle it. Oh, the only thing that absolutely needed a driver loaded in CONFIG.SYS was the CD-Rom drive.

Graphics Cards were among the first ones to fragment the platform: using Video Drivers in Windows 3.1, you could go beyond 640x480 with 16 colors.

This continued with Windows 95, when sound cards did not even bother to retain Soundblaster compatibility - handling Windows Sound was enough. At least Video cards remained VGA compatible, and still are, up to this day.

Answer 9

Two decades ago I read an essay (sadly now impossible to find) that used this and a few other similar tech platform competitions to make a rather deep point:

In a competition between two at least somewhat competitive platforms, the more open platform wins every time.

Now personally I'm not so sure about the "every", but I've found this statement to have a lot of predictive power since.^*

The problem the less open platform has is that all the incentives for developers are to produce for the more open platform. APIs and tech specs are cheaper (often free), and there's no authority they have to answer to other than customers. The devices themselves will end up being cheaper, at first due to lower barriers, but eventually due to the fact that there are more companies producing for that platform, so the market competition on it is far more intense. The lower prices drive up unit sales, which increases competition more, which puts even more pressure on prices. Its a huge win for the consumer.

What this also means is that the closed platform has great trouble not falling behind technically. In a contest of innovation between the two platforms, its one company's engineers against the rest of the world. That one company may have some truly rocking engineers, but its highly unlikely they can outdo the entire rest of the world indefinitely.

The obvious solution is to open up the platform. Commodore actually saw this and tried sanctioning 3rd party clones for a while. The problem here of course is those are competitors, and no company can really justify going out of its way to help competitors. A closed platform is essentially golden handcuffs for the company that maintains it.

^{* - OK. Admittedly this predicts Android would obliterate iOS, but iOS is now bumping around in the 15-20% market share territory, with nearly all the remaining 80-85% being Android. 5 years ago it was close to even. However, Apple has learned over its history how to survive having more expensive products on niche platforms. If anyone can beat the odds with a closed platform, they can.}

Answer 10

First, having the plans available allowed small companies to build their own IBM PC clones. You didn't have to be a monolithic company like IBM to build one. A modern analogy is that you don't have to be Google to design an Android phone.

Second, each of these numerous little companies did their own marketing, greatly expanding the platform's visibility in the marketplace.

Third, these companies often shared technology, reducing development and manufacturing costs through economies of scale. Chipsets, CPUs, BIOS firmware, etc.