TMPLee@DOCKMASTER.ARPA (02/09/89)
As long as people are druthering, it would seem to me that the natural way to enhance the performance of the GS rather than attempting to accelerate the whole thing would be to selectively put various parts of the Toolbox into hardware. I thought, in fact, that that was the whole idea of defining that level and kind of interface. One can even see the opportunities for selectivity -- you could buy hardware to accelerate only those parts you use (recognizing that if you use higher-level routines you'd have to accelerate the lower ones as well.)
hassell@tramp.Colorado.EDU (Christopher Hassell) (02/09/89)
In article <890208220053.845007@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.ARPA writes:
# As long as people are druthering, it would seem to me that the natural
# way to enhance the performance of the GS rather than attempting to
# accelerate the whole thing would be to selectively put various parts of
# the Toolbox into hardware. I thought, in fact, that that was the whole
# idea of defining that level and kind of interface. One can even see the
# opportunities for selectivity -- you could buy hardware to accelerate
# only those parts you use (recognizing that if you use higher-level
# routines you'd have to accelerate the lower ones as well.)
NO NO NO NO, gosh that'd be almost as simple as putting in a new processor
to handle background tasks (like those) (and it would be :-).
Wellll, I assume that "Keith" as everyone knows him (from Apple.COM)
ain't going to talk about the reasons against putting in a powerful and
flexible background processor. SOOO in another burst of net-logic......
We can only assume they ARE going to use it for the *next* //GS+????????
(or maybe the Mac //+ :-( :-). POWER!!!!! THERE'S an Apple I would LIKE!
This might be a serious possibility folks... let's get some juicy rediculous
rumors started out there!!!!!
(Well heck, if he's going to, THAT oughta make 'im talk!)
Another WILD extrapolation and unfounded assertion (of course) FROM...
### C>H> ###blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (02/10/89)
Isn't a region just a list of components? (What else could it be???) If so, then the coprocessor would have to have a set of operations to be performed on the list of stuff... I'm not a hardware person, but remember, this is the 80's (almost the 90's) - we can do anything, right? :) Btw, since it is Apple's proprietary data structure, then only Apple can come out with this thing, right? As far as a post-regions coprocessor. Are you really trying to tell me that a hardware blit of a block of screen memory wouldn't be fast enough to justify it? Hardware slower than the //gs in software??? Just some (relatively) simple stuff - raw memory move (maybe not - that's what MVN & MVP are for, right? But they're limited to CPU speed), "screen form" memory move (based on a whateverYouCallIt - the data structure that defines a bitmap), a pattern fill (even in just rectangular areas would help bunches...). The blitter in the Atari ST (newer ones) does a bit more than that, but not tons, and it sped the user interface up significantly - and this was already on an 8Mhz 68000! Ahh... What a thought: ScrollRect & PPToPort working at blistering speeds! Jason Blochowiak (blochowi@wherever_i_am - garfield.cs.wisc.edu?) "Not your average iconoclast..." Dave Whitney: Where are you? Write to me; either here or @lakesys will do.
friedman@porthos.rutgers.edu (Gadi ) (02/11/89)
In article <25565@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes: > erase it, or even clip to it when drawing. Very powerful, yes, yes. However, it > is very difficult to design a hardware chip to recognize and/or manipulate > regions. As far as I know, no one has ever done it. And without such a capa- Oh no, it's never been done!! Must be impossible!!! What did you guys buy that Cray for anyway?? :-) > so that is our problem. Now you know why we or anyone else hasn't come out with > a graphics accelearator for QuickDraw. My question to you all it: How do we > solve this problem? Well, I guess QuickDraw has to go... I got it. Introduce a new graphics standard (or extentions to QuickDraw) that works with GAs, and implement Quickdraw in this standard. This way, software that uses Quickdraw will still run while stuff that needs GA speed will also run. > Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support Gadi PS. (From someone who has an AppleIIe since 1980 and still uses it.) All you guys who want something faster buy an AMIGA. The AMIGA 500 cost ~750 including color monitor and blows the GS away. If you feel loyal to Apple, keep your current system. I've used the GS and its a poor excuse for a machine. Its too slow, and too limited. Its basically the same machine as a IIe (which I already have). Almost nothing takes advantage of the new features, and for good reason. Why bother? If something is to be written from scratch, why not write it for the best machine available? It much more fun to program for a fast machine than limited one. Don't expect a new GS to be much faster than the current one. The way the 65816 accesses memory, we won't have fast enough ram for an 8MHZ machine. If the current screen handeling and memory refresh is continued, an in an 8Mhz machine, memory is accessed at 16Mhz so you would need 60ns memory. -- uucp: {ames,att,harvard,ucbvax,iuvax}!rutgers!aramis.rutgers.edu!friedman arpa: FRIEDMAN@ARAMIS.RUTGERS.EDU
mj0i+@ANDREW.CMU.EDU (Marquis Eugene Jones) (02/11/89)
"...it is very difficult to design a hardware chip to recognize and/or manipulate regions. As far as I know, no one has ever done it. And without such a capa- bility, we can't put QuickDraw on a card. ." I think that Texas Instruments has a series of graphics chips that may help. Marquis Jones ----------------- mj0+@andrew.cmu.edu