ajz@mentor.cc.purdue.edu (T. Tim Hsu) (03/11/91)
I've been using a Mac for forever now, and I've been a developer for almost
as long. With these two things in mind, I'd like to point out the reason that
the Mac never had a graphics coprocessor.
Way back in the early days, this hardware was very new, very hip, and very
buggy. Just like all new equipment. However, the designers thought ahead and
decided that as long as you kept any routines that MIGHT be buggy in software
(patchable rom in this case) instead of in hardware, you could then easily
send out a new release easily and quickly without burdening all old users
with high costs.
A good case in point is that the original Quickdraw routines only supported
8 colors (not 8-bit color, but eight colors). Comparing that to the 32 bit
Quickdraw available now, you can see it was a wise move to do a lot of the
routines in software instead of in hardware. If the reverse were true today,
I truly doubt that 32 bit color would have caught on in such a short time
span. Any machine with a coprocessor or non-proprietary software
will always have a problem of upgrading to a "new" standards.
Another case in point is the i860, probably the fastest floating point cruncher
on the market these days with pre-implemented 3D vector graphics capabilities
to boot. The i860 is at least an order of magnitude faster than the MC68882,
with much more usefull capabilities, but it will never be incorporated into
a Mac as standard equipment since the costs in redesigning of the Mac hardware
to accomidate this chip would easily outweigh the profits that could be reaped
from the move.
Implementing something in software makes the routine much more versitile than
when you implement it in hardware. Unfortuantly, you give up a lot of speed
in the process. As an engineer, the question of a hardware solution over a
software solution will always appear, and it gets solved by examining whether
the versitility of the software approach outweighs the loss in speed that
approach produces. When the Mac came out with but a b/w monitor so that it
could fit on a small footprint, it was judged that a graphics coprocessor
would be unnecessary.
--
T. Tim Hsu UUCP ...pur-ee!ajz@mentor.cc.purdue.edu
ARPA ajz@mentor.cc.purdue.edu
FAX 1 317 494 0566 BITNET xajz@PURCCVM