Re: What is the quintessential Apple II?

["Michael J. Mahon" <mjmahon@aol.com>]

mdj wrote:
> Alex Freed wrote:
>
>
> > > The fact that an 8-pin microcontroller is often now a better overall
> > > solution than a 555 timer doesn't alter the fact that the timer is
> > > a much simpler device, and a much lower level of technology.
> >
> > True, but does it bring you any browny points? If an 8-pin microcontroller
> > costs the same as a 555, should you try using a 555 with a cap and a
> > couple of resistors to say blink a LED? The 8-pin uC will do it even better
> > and the design will be more flexible. Want to change the rate, just write
> > a different constant into FLASH. No caps to change :)
>
>
> Interestingly, I find myself about half way between you two in terms of
> my 'design aesthetic'. I with Alex in terms of the Disk ][ design; its
> price-performance ratio compared to its contemporaries is astounding,
> and proved that other designs were using sledgehammers to squash flies.

And it was powerful insight that made the difference.  Put another way,
until the Disk ][ design, everyone thought that the drive should control
the dynamics of seeking and spinning, and trivial hardware bit encoding
was the obvious choice.

Only *after* the Disk ][, which was both faster and denser than all
it's contemporary floppy systems, was it clear that the host system
was capable of doing hardware control, encoding, and decoding without
costing speed--in fact, quite the opposite.

This is one of a large class of suboptimal designs in which the
suboptimality results from misallocating the responsibility for an
action in a design--a functional partitioning error.

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.

In the same way, the overall robustness and performance of a piece of
software may depend strongly on the partitioning of function within it.

<snip>

> I must agree with Michael however that there are real benefits to
> keeping hardware 'hard'. The availability of cheaper than cheap
> programmable logic in the electronics world has meant that hardware
> design is now suffering all the growing pains that software has
> suffered, and the quality of products being delivered has suffered as a
> result. The ability to download new hardware designs into a device
> after the product has shipped is fantastic in theory, but in practice
> the productivity gains are absorbed by marketing departments rather
> than engineering departments, and as a result it takes 5 revisions of
> the driver/firmware combination of, for example a PC wireless card for
> it to be fully stable and functional AFTER the product has shipped.
> When the cost of getting it wrong goes down, so does the incentive for
> getting it right the first time.
>
> Gee, that sounded a bit negative :-) Right, back to playing with uC's
> and FPGA's :-)

It's turning out that we are utterly dependent on a relatively small
cadre of embedded system programmers who are increasingly driven to
meet unrealistic time-to-market goals.

We are currently in the process (nearly completed) of teaching this
cadre that "Getting it first is better than getting it right.", and
"Don't worry, the early adopters will put up with anything."

You are beginning to experience the results of this training program.
;-)

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

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).

-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."