Re: What is the quintessential Apple II?

["mdj" <mdj.mdj@gmail.com>]

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.

But then to me, using a uC to make lights flash is ugly. It can be done
simpler ways, and I prefer reaching for caps and resistors to swap on
the breadboard than pulling a uC, going back to the PC and
reprogramming it. If I want to change the flash rate, I'll build
variability into my design.

There are exceptions though. Consider for example interfacing modern
storage devices to the Apple II. Now, if all you're implementing is
compact flash, then you can rig it for IDE mode, and with a handful of
74 series IC's couple it to the Apple II bus. Add some firmware, and
away you go. Nice simple clean design. I find a card that does this
with 74 logic more appealing than one using a CPLD.

It's easy to envisage features of such a device that go beyond what's
practical with a simple bit banger, and really require intelligence on
the peripheral, and this shows not just in modern Apple II cards, but
in many of the cards of the era. My Apple IIe has only original era
expansion cards in it, and there is considerably more processing power
on board those cards than there is in the IIe :-)

I would not propose that it would be a good call when designing a new
card, to add a 6502, some SRAM, ROM, PALs etc. to achieve what can be
done easily today with an 8-bit uC. Doing so is masochistic, when you
consider the design is logically and functionally the same either way.

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

Matt