[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is the quintessential Apple II?

mdj wrote:

Michael J. Mahon wrote:



In the computer engineering game, there were two popular allocation
biases:  "put it all in hardware" and "put it all in software".  (Of
course, now even the hardware is software!  ;-)  Which completely
ruins my saying that, "The hardware is the easyware--the software
is the hardware!")

I tend to the "put it all in software" camp, as my projects clearly
demonstrate.  Steve Ciarcia, for one, used to lean toward the "put it
all in hardware" camp--until hardware became software.  ;-)  Of course,
most real designs will not be all one or the other.  Each design point
of view will see the designs of the other as "distorted" by bias.  But
despite the difficulty of objectivity, experience shows that, under a
particular set of circumstances, functions should be allocated (or
partitioned) in a certain way to achieve a near-optimal result.



I've always felt a good rule was "do in software that which cannot be
done more efficiently in hardware". Doing too much in software can
compromise the performance of a design, while doing too much in
hardware compromises flexibility. Although, as you point out, not
anymore due to 'soft' hardware :-)


Agreed.  My own biases toward minimal hardware solutions for the
Apple II also come from wanting my designs to be usable by the largest
possible fraction of Apple II users, which argues strongly against
requiring *any* hardware.

NadaNet is an interesting case, since it began life as a completely
software-based network (hence, "nada-"), but changes to the Apple II
line starting with the //e made it necessary to add a tiny buffering
board with two emitter followers.  That minimal, but non-zero, hardware
requirement has probably done more than any other thing to prevent folks
from giving it a try.

If I could generate more electronic "drive" in software, I'd do it!  ;-)

I do agree that the no-hardware approach is a limitation that should not
apply in a more flexible environment.


Of course, we the enthusiasts would prefer to assess designs based on
the design, and ignore the time constraints on the designer. It's also
reasonable that design 'quality' have the time investment involved in
its realiastion be a part of it's metric. And herein lies the problem.


Yes, having the design time be the most fun does distort the metric
a bit!



My saying:  "Never get version 1.x *or* version x.0."



A number of firms are beginning to experiment with delivering the last
iteration of a products major version as the first iteration of its
next version, and 'quietly' slipping the major changes in x.1. I
recently had to fight the early adoption of x.1 of a product due to my
workplace considering it as a bugfix/update despite the underlying
reality that it was far, far more than that.


Wow--now there's a clear case of gaming the system.  If this continues,
then I'll have to revise my rule.  ;-)


But don't worry--help is on the way!  As even tiny embedded machines
get very fast with large memories, it is becoming possible to create
95% of what we need by parameterizing a standard framework (using a
graphical interface that marketing can understand and manipulate,
of course).



In a world where sub $1000 PC's have > 3GHz processors, more than one
of them, and multiple gigabytes of RAM, I'm mindful that promise was
made before. Each time a major improvement in design methodology came
along, demand (in terms of expected functionality of product) expanded
to match it. It takes seemingly no time at all for someone to come up
with an innovative product which pushes the limits of what's acheivable
with delivery technology X, and the rest of pack, in an effort to
scavenge whatever market share than can from the innovator, will push
the limits of any delivery methodology from a time perspective, with
the above mentioned consequences :-(


In the case of consumer electronics, the usual pruning factor is product
cost.  If a more customized approach can deliver functionality "X" at a
cost saving of a fraction of a percent, then someone will use it and
gain a lead over less thrifty competitors.

Interestingly, Apple is one of the few companies that routinely "spends"
on reducing product complexity, and it seems to be working for them.

On the other side, Microsoft used to think their job was consuming a big
part of the exponential growth in PC speed and capacity, so as to create
a need for newer hardware, and fuel the "virtuous cycle" of rapid
platform evolution.  I suspect they've changed their tune a bit since
Moore's law (and their stock appreciation) has slowed down.

The whole PC industry is suffering through the commoditization of the
PC.  Now a PC is as useful as it is an appliance, not as an extensible
platform.  Partly, this is the usual mass market evolution, and partly
it's the result of a decade without any new "killer app" to drive the
market.

Ironically, the "any media anywhere, anytime" potential killer app is
what scares the heck out of content "owners" (not creators), and so has
been slowed significantly.  It's the usual problem of protecting one's
share of the pie instead of taking a risk and growing the pie.

-michael

NadaNet networking for Apple II computers!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it's seriously underused."