[comp.sys.mac.apps] Excel on LC...the FPU question

limoges@ac.dal.ca (04/20/91)

Hi,

Just want to clear up a small thing about Excel. You DO NOT need a math
coprocessor! If you have one installed though, Excel will take advantage of
it. I own Excel 2.2, and it has worked fine on my SE, and gives me no trouble
now with my IIsi, which has the NuBus card with the FPU.

There is a small problem if you have a 68030 Mac and no FPU: Excel 2.2 checks
only for the 68030, and assumes that there is an FPU, which is not always
the case, as with a stock IIsi. The fix is to get a corrected release of
Excel (I think it's called 2.2a or something like that), or run PseudoFPU. I
don't know if this problem is also present with the LC.

Hope this clears the air, Bertrand Limoges

alex@eniac.seas.upenn.edu (Edmund Davis) (04/26/91)

In article <4497@ac.dal.ca> limoges@ac.dal.ca writes:
>Hi,
>
>Just want to clear up a small thing about Excel. You DO NOT need a math
>coprocessor! If you have one installed though, Excel will take advantage of
>it. I own Excel 2.2, and it has worked fine on my SE, and gives me no trouble
>now with my IIsi, which has the NuBus card with the FPU.
>
>There is a small problem if you have a 68030 Mac and no FPU: Excel 2.2 checks
>only for the 68030, and assumes that there is an FPU, which is not always
>the case, as with a stock IIsi. The fix is to get a corrected release of
>Excel (I think it's called 2.2a or something like that), or run PseudoFPU. I
>don't know if this problem is also present with the LC.
>
>Hope this clears the air, Bertrand Limoges


In fact, the same problem occurs on the LC.  Until the new macs came
out, Microsoft (among other) assumed that any machine with a 68020 or
better would certainly have an FPU.  Apple cut the FPU from the LC
and IIsi in order to bring the price down.
In summary, you have three choices:

--buy an fpu
--download FPU INIT from sumex
--call Microsoft and get the free upgrade

alex
----
Edmund A. Davis			     Internet:	alex@eniac.seas.upenn.edu
ACIUS Registered Developer	   Compuserve:	70471,3342
			              US Mail:	233-F So. Melville St.
(215) 386-3305					Philadelphia, PA 19139

jcav@quads.uchicago.edu (john cavallino) (04/26/91)

In article <42004@netnews.upenn.edu> alex@eniac.seas.upenn.edu (Edmund Davis) writes:
>In fact, the same problem occurs on the LC.  Until the new macs came
>out, Microsoft (among other) assumed that any machine with a 68020 or
>better would certainly have an FPU.  Apple cut the FPU from the LC
>and IIsi in order to bring the price down.

{$SETC __flame__=TRUE}

And Microsoft and the others were inexcusably wrong to do so.  Since there
have been Macintosh FPUs there have been supported ways to use the OS to
check for their presence.  Apple has ALWAYS said "check for specific
functionality".  I believe it is also true that Apple at one time said all
machines with >= 68020 would have FPUs, but since the specific FPU check is
just as easy as the specific processor-type check, there really is no excuse.

{$SETC __flame__=FALSE}

(yes, I'm a Pascal weenie.  So sue me :-)

jcav@quads.uchicago.edu (john cavallino) (05/01/91)

In article <1991Apr25.213253.21845@midway.uchicago.edu> jcav@quads.uchicago.edu (john  cavallino) writes:
>In article <42004@netnews.upenn.edu> alex@eniac.seas.upenn.edu (Edmund Davis) writes:
>>In fact, the same problem occurs on the LC.  Until the new macs came
>>out, Microsoft (among other) assumed that any machine with a 68020 or
>>better would certainly have an FPU.  Apple cut the FPU from the LC
>>and IIsi in order to bring the price down.
>
>{$SETC __flame__=TRUE}
[my tirade deleted]
>{$SETC __flame__=FALSE}
>
>(yes, I'm a Pascal weenie.  So sue me :-)

I have just received a mail message from a member of the Excel development
team, explaining exactly why version 2.2 barfs on the new machines with
68020+ processors but no FPUs.  It's apparently >MUCH< simpler and less
sinister than paranoid people like me thought.  They made NO FPU
assumptions based on CPU type.  Excel 2.2 DOES call SysEnvirons and DOES
attempt to look at the "hasFPU" field, but it tests the field using a TST.W
instead of a TST.B, which leads to it assuming that all Color Quickdraw
machines have an FPU (the "hasColorQD" field is in the adjacent byte).  This
is a bug, not a design error.  I would be the last to say the Microsoft is
without sin, but in this case my flame was unjustified.  And anyway, they
fixed the problem in a free upgrade.  :-)


-- 
John Cavallino                      |     EMail: jcav@midway.uchicago.edu
University of Chicago Hospitals     |    USMail: 5841 S. Maryland Ave, Box 145
Office of Facilities Management     |            Chicago, IL  60637
B0 f++ w c+ g+ k s(+) e+ h- pv (qv) | Telephone: 312-702-6900