TMPLee@DOCKMASTER.ARPA (02/11/89)
Strange that they would have to do something to the compiler to support the board. Being ignorant of any of the details (I've asked for a brochure but it hasn't shown up yet) I would think that the way you would make an interface to the board would be to make a RAM patch to the SANE toolset so that compiled/assembled code would continue to call the SANE entry points which instead of doing what they did before would possibly massage the parameters a bit and then call on the FPE board to do the real work. TMPLee@dockmaster.arpa re: not being able to accelerate Quickdraw because of the region facility. Big deal -- accelerate everything else adn I'm sure you'd make a lot of people happy. Where does the finder or any of the standard menu stuff use regions other possibly than rectangular ones? (I also think that coming up with hardware to accelerate even the region stuff should be possible -- sounds like a good project for an advanced college/grad school electronic engineering project.)
keith@Apple.COM (Keith Rollin) (02/11/89)
In article <890210210540.993637@DOCKMASTER.ARPA> TMPLee@DOCKMASTER.ARPA writes: >Strange that they would have to do something to the compiler to support >the board. Being ignorant of any of the details (I've asked for a >brochure but it hasn't shown up yet) I would think that the way you >would make an interface to the board would be to make a RAM patch to the >SANE toolset so that compiled/assembled code would continue to call the >SANE entry points which instead of doing what they did before would >possibly massage the parameters a bit and then call on the FPE board to >do the real work. I would suspect that the support mentioned for ORCA Pascal is that it calls the FP board directly. This would get around the overhead of making calls through the Tool Dispatcher, which can be quite significant. Having a chip that executes a math operations in a few uSecs would be useless if called through a dispatcher that takes 100 uSecs. > >TMPLee@dockmaster.arpa > >re: not being able to accelerate Quickdraw because of the region >facility. Big deal -- accelerate everything else adn I'm sure you'd >make a lot of people happy. Where does the finder or any of the >standard menu stuff use regions other possibly than rectangular ones? >(I also think that coming up with hardware to accelerate even the region >stuff should be possible -- sounds like a good project for an advanced >college/grad school electronic engineering project.) The Finder uses the Window Manager, which definitely uses irregularly shaped regions. For instance, what if a window that is covered by two other windows is brought forward. The area that needs to be updated is collected into one region, which is then used for clipping. On the other hand, accelerating everything else is something that is already done - Transwarp GS. I know that it is unfair to ask everyone to buy a $700 3rd party product in order to get the performance that they feel that they should get in the first place, but that's all there is right now. Besides, who knows what tomorrow will bring (besides me)? RECALL OF CHALLENGE TO THE TEEMING MILLIONS: ============================================ After some thought, I realized that my asking you folks for a solution to the graphics acceleration problem was uncalled for: 1) The data structure of a region is not published or very well known. Therefore, it is unfair to ask people for their solution for a card that will implement it. (On the other hand, deciphering the data should not be too hard for an advanced college/grad school electronic engineering student. But that's not the point.) 2) People aren't really asking for a card that will accelerate QuickDraw II or Window Manager operations. What most people seem to be asking for is a chip like the one in the Amiga. Rather than having a windowing system like the Mac, many people would simply like to have a high-powered graphics chip that would manipulate the screen as a whole. Such capabilities would include Blitting, Video Overlay, background updating, and Sprites. Possibly more. ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your limitations, and sure enough...they're yours" -Bach, Illusions
V112PDL5@UBVMSC.CC.BUFFALO.EDU (02/11/89)
Direct access to the 68881 proves much faster than going through
SANE. In the Mac II it's 10 times faster.
- Mark Crowmellshawn@pnet51.cts.com (Shawn Stanley) (02/14/89)
keith@Apple.COM (Keith Rollin) writes: >I would suspect that the support mentioned for ORCA Pascal is that it calls >the FP board directly. This would get around the overhead of making calls >through the Tool Dispatcher, which can be quite significant. Having a chip that >executes a math operations in a few uSecs would be useless if called through >a dispatcher that takes 100 uSecs. So it would be more practical with a faster machine? Heh. I think there are several advantages to making use of a math co-processor through the SANE tools. Since SANE is there to be used, and programs DO make use of it, hooking in the math co-processor would speed up those programs. Also, it's nice to have a standard to center around. I know someone who just recently got an accelerator board for his Mac Plus. Additionally, it has a math co-processor that is connected and used via SANE operations. He showed me the differences in speed, and I was very impressed. I don't really think it's all that worthless... UUCP: {uunet!rosevax, amdahl!bungia, chinet, killer}!orbit!pnet51!shawn INET: shawn@pnet51.cts.com