🚀 go-pugleaf

I have recently finished writing a control program for a series of
electrical devices that are controlled by a relay box being controlled
by a second parallel port adapter in my machine.  Since this program
has been running (5 days now), my OS/2 system has died with a Trap 000E
three times.  The program runs 24 hours a day, the trap is unpredictable.

There are two semi-interesting aspects to this program: 1) it does a pile
of trigonometric function calls (like 500+ a minute; calls limited to
sin, cos, asin, acos, tan, & atan) on a 33/386 without a math
co-processor.  2) Every minute it output a single control byte to the
parallel port via a Turbo-C BIOSPRINT call.

The second parallel port is jumpered to run WITHOUT interrupts.  After
reading the INFTXT.ZIP file pulled from watson, I got the impression 
this definetly is not standard practice under OS/2.  Apparently OS/2
demands that LPT1 by configured as IRQ 7 and LPT2 be IRQ 5.  IRQ 5 is
my bus mouse port...  However, the program does appear to work for 
extended periods of time.  It never seems to die when anybody is around
the machine.  To complicate the IRQ world (but to be fair and give you
all the whole picture), I have a Sound Blaster also configured for IRQ 7.
I've been running under the assumption that I would just not be able to
use the SB and Printer at the same time.

Anyhow, does anybody have any suggestion as too what might be going on?
I've theorized that the OS/2 Math Co-Processor simulation routines might
have a subtle bug.  The other possiblity is wrapped up in the IRQ issues.
Does anybody know how I can disable the Co-Processor simulation and just
let Turbo-C's routines do the work?  Oh, yeah, this program is running
in a DOS box.
--
Kevin Carpenter       Internet:  kncarp@nicsn1.monsanto.com
Monsanto Company 
St. Louis, Missouri, U.S.A.
Opinions expressed are those of the author, not the company he works for.