ANI problems
5 messages in this thread
I'm having trouble running ANI on a DTK m'board equipped with an Intel
386/33 and a ULSI 387/33 co-processor. If the 387 is on the menu ends up
at the top of the screen, and when I try to invoke the "GRID" command the
code crashes–leaving the message "Abnormal program termination, Divide
overflow, CS:EIP=000Ch:00018a04h". So far the only "fix" is to run
NO87=<alpha> before invoking ANI.
Support through my delaer—who hasn't the time to be a messenger boy—is
something less than spectacular.
Comments and—especially—suggestions very much appreciated.
Stephen,
You've already caught onto the problem. Either use the NO87 (which
doesn't affect Animator Pro otherwise), or change out the math chip for an
Intel.
Kevin Krell – Computer Support Associates
[/exit
Are you saying that the ONLY access to the 387 chip ANI makes is to put the
menu and command lines on screen? Seems like a waste of resources.
Stephen/exit
Stephen,
Apparently there is only a test if a math coprocessor is present.
Programs written in the POCO language can have access, but nothing in the
software uses it out of the box.
Kevin Krell – Computer Support Associates
The majority of AA Pro is written to use high speed integer functions that
are much faster than the fastest math coprocessor. Basically, AA Pro is
just a big pixel engine that moves bytes of data around. There really are
no floating point functions for it to require a math co. The C
interpreter, however, does make use of a math co when floating point math
is used and emulates one if there isn't any present. This is so that if
anyone wanted to write a floating point intensive application in poco (like
a ray tracer) they could have access to the machines resources.
The use of floating point in the menu initialisation code was an oversight
of sorts, but because the menu initialisation is only done once per program
session, it wasn't considered a major problem. There is nothing special
about what its doing, by the way, just some division operations. Pretty
standard C code stuff, I'm surprised the math co couldn't handle it. It
may just be overly subseptible to Protected Mode operation.
-GB-