> On Apr 27, 2018, at 9:08 AM, Geoffrey Oltmans via cctalk
> <cctalk@classiccmp.org> wrote:
>
> Don't get me wrong. Like you I learned a lot due to all the variety of
> differing machines that were available in the market early on. From a
> business perspective I don't think it made a lot of sense however to have
> so many internally competing models.
>
> Of course then, I guess you could argue that Atari probably had the most
> cohesive set of computers, but that didn't necessarily translate to great
> success. I guess that did mostly work for Apple with the II line, save for
> the major III distraction.
This is actually a pretty interesting topic, and relevant both to
decision-making today and to classic computers. How did, and how should have,
companies select architectures (CPU families, bus structures, peripheral
strategies, etc.) to ensure continued viability? Some examples I see and my
simple-minded scorecard below. I’m trying to stick with hardware vendors, so I
left Microsoft and NeXT (possibly unjustly) off the list, but in some cases
(Tandy? TI? Digital Group?) I think the imbalance between hardware development
and software development was a huge factor in the company’s success or lack
thereof.
Comments or corrections most welcome!
Digital Group: support 3 (?) different processor families on the same bus
architecture (sort of)
technically very impressive, but flexibility -> cost -> low market
share; not long-term successful
DEC: support almost every available CPU, and invent some of your own besides.
since supported everything, had price/performance dominance in most
categories, but let *one* category slip away - business desktops - where much
of the money was. Successful for a long time, but development costs overtook
revenue eventually.
Apple: support one CPU, switching product line to another CPU as needed.
Able to pick architectures to create new markets; limited
interoperability but able to survive on single-market dominance (hobbyists,
then education, then graphic design, then PDA’s…)
Tandy: Support every architecture, often 2 at a time in the same box:
Mixed record, some winners and some losers; Software development often
lagging sorely behind hardware, ultimately not successful.
TI: Single-architecture, lock-in software ecosystem
Substantial money-loser even with potentially world-beating hardware
(CPU); software achilles heel along with architecture bottlenecks on
performance.
others?
There are many complicating factors, of course. E.g. embedded systems
have very different requirements from CAD workstations. Should a company
maintain different architectures to support both, and how compatible should
they be?
It looks to me like really strong support for outside developers is key
for hardware providers, whether that is in the form of a cheap and effective
development toolkit and good developer’s forum or a completely open
architecture.
- Mark
