Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!uwm.edu!uwvax!astroatc!nicmad!madnix!jason
From: jason@madnix.UUCP (Jason Blochowiak)
Newsgroups: comp.sys.apple
Subject: Re: Toolbox Coprocessor?
Message-ID: <1108@madnix.UUCP>
Date: 12 Feb 90 10:13:43 GMT
References: <3399.25c9904b@vax5.cit.cornell.edu>
Reply-To: jason@madnix.UUCP (Jason Blochowiak)
Distribution: comp
Organization: ARP Software, Madison, WI
Lines: 56

q4kx@vax5.cit.cornell.edu (Joel Sumner) writes:
>With all of this talk about a Toolbox co-processor or something, how about	
>this:  A chip that will take over all tasks that do not return parameters.
> [I nuked the rest of the article]

	As Dave Lyons mentioned, this idea is fairly flawed. Although
certainly possible (although it would be JSL/RTL, not JSR/RTS) with a few
major changes, it would almost certainly not be economically feasible.

	What I think would be better would be something fairly simple, but
RFF (really darn fast). Although regions couldn't be used in their
entirety (unless Apple wanted to be _really_ nice to somebody), they could
be transformed into something useable by hardware.

	I'm not sure exactly what hold Apple has on regions legally, but,
seeing as regions are basically just area definitions (with, I believe,
the possibility of being infinitely complex), they could be transformed into
a bitmap, element by element. This could be done by either software or
hardware - the engine would run through each element in the region and modify
the bitmap accordingly. When that was done, the graphics operations could be
performed using the bitmap. This almost certainly wouldn't help with region
modification operations (intersection, union, etc.), but could make actual
drawing RFF. Unless my memory is totally blown (entirely possible, folks),
the elements used in the region definition and the elements used in drawing
are basically the same (sans color/pattern info), the amount of hardware
would be (roughly) proportional to the number of elements, plus some
constant.

	That last paragraph wasn't exactly what I meant by something that's
"fairly simple" - it's just a nice thought. By something fairly simple I
meant a co-processor of some sort that would allow for memory moves (both
skewed and normal) and basic logical ops (AND, OR, NOT, EOR). This would
speed up the basic operations (and would be pretty cheap), allowing the
CPU to play with the higher level stuff (this could also possibly give the
System Software folks more time to optimize at a higher level - giving even
greater speed improvements).

	I know that I've commented on this before, but it seems that a
graphics-intensive machine without a graphics coprocessor is missing
something. All of this is, of course, just my (vaguely educated) opinion.

>Please comment on the viability or craziness of this idea.  It's just a 
>thought [while donning my flame suit]

	Flames? People would have to be nuts to flame that. Everybody on
the net is sane, rational, and polite, as been demonstrated a number of times.

>Joel Sumner
>Q4KX@cornella.ccs.cornell.edu
>Q4KX@cornella.bitnet


-- 
                      Jason Blochowiak - jason@madnix.UUCP
or, try:         astroatc!nicmad!madnix!jason@spool.cs.wisc.edu
       "Education, like neurosis, begins at home." - Milton R. Saperstein