"No 8087" error message at run-time???

[Tom Brodhead]

I've written a DOS program compiled with version 3.5 of the PowerBasic compiler. It compiles perfectly, and runs on all DOS machines that I've loaded it on. However, one end-user receives this message when he executes the program:

No 8087

...and the program won't run. I don't know how to interpret what is presumably a run-time error message.

I compile the program with these switches (es.bas is the name of the source file):

pbc /ce/g386/Fnpx/lb-/lp-/ls- es.bas

I've asked him for specs on his computer and OS set-up; here's what he reported:

===============
The machine uses an Intel 486 SX at 25 MHz, 8 Mb RAM (but who cares with DOS), DOS 5. The socket for math co-processor Intel 487SX (or what they used to call OverDrive) is empty. I do not know about the chip, actually I never knew, but I think that in these times there were not many choices, were they?

Config.sys :

device=c:\windows\himem.sys
device=c:\windows\emm386.exe auto noems
dos=high, umb
country=033,437,c:\dos\country.sys
buffers=20,0
files=20
stacks=0,0

Autoexec.bat :

@echo off
prompt $p$g
PATH = c:\;c:\windows;c:\dos;c:\score
SET TEMP=c:\temp
c:\windows\smartdrv.exe
c:\mouse\mouse.exe
loadhigh KEYB FR,437,c:\dos\keyboard.sys
loadhigh MODE COM RATE=32 delay=1
loadhigh MODE LPT1:,,B
loadhigh c:\dos\dosshell

=======================

Please help!

Many thanks,
--Tom


------------------
Tom Brodhead

[Frank Cox]

Fnpx is your problem.

The 486sx has no numeric co-processor built-in. That's the difference between a 486sx and a 486dx (which does).

You need to compile your program with -femu and not -fnpx for it to work on that machine.



------------------

[Davide Vecchi]

As a side note,

8 Mb RAM (but who cares with DOS)

, PB/DOS 3.5 VIRTUAL arrays can use up to 32 MB of EMS, so those 8 MB aren't necessarily useless.

------------------
Davide Vecchi
[email protected]

[Tom Brodhead]

I've recompiled the program with the -femu switch and sent it along to the user. I'm waiting for his reply to see if it does the trick...

------------------
Tom Brodhead

[Tom Brodhead]

An inexplicable problem is now confronting me with this.

The -femu switch allows the EXE to be executed on my client's 486sx machine. But then a different problem emerges: the program fails to read disk data correctly. As an experiment, I added print statements to the program to see what values it was retrieving from files it read. My client ran the program twice: once on the 486sx, and then again on a PentiumII/Win98 machine. The program works flawlessly on the PentiumII/Win98 machine, but retrieves erroneous values from disk when run on the 486sx machine.

My program reads singles from a file and stores them into an array.

Specifically, when run on the PentiumII box, my program correctly collects these 4-byte single values from disk:

4.34427E-39
4.350784E-39

But when run on the 486sx, the same 4-byte single values are displayed as:

0.504327E-41
1.155651E-41

Simple singles--like 4.0, 5.0, etc.--are read correctly. But these two behemoths are read incorrectly only on the 486sx.

Any ideas, anyone? Is there some other test I could perform to narrow down the problem? (This problem is complicated by the great distance I am from the client; not having a 486sx myself, the best I can do is add diagnostic print statements to the program, compile with the -femu switch, and send to him; he then send the screen displays to me by e-mail.)

--Tom


------------------
Tom Brodhead

[This message has been edited by Tom Brodhead (edited February 15, 2005).]

[Davide Vecchi]

I have a 386 with DOS 3.2; if you want you can send me test programs and i'll be sending you their output.

If you assign the failing values directly to vars by typing them as literals, rather than reading them from disk, does the problem occur anyway ? It sounds strange to me that the problem is related to file access.

Are you sure the 2 values are within the range of SNG datatype ? I can't check now nor do i remember, however there is a given amount of digits this datatype can hold, and if the values are outside the range it might be that the real 8087 and the emulator handle the error condition in 2 different ways.

------------------
Davide Vecchi
[email protected]

[Paul Dixon]

Tom,
possible things to try.
Use the following before running the code to set the environment variable to tell PB that there is no FPU or it'll still try to use it if there is one.

SET 87=NO

Hopefully, this'll stop your PC from using the FPU so you can see the problem on your machine.


Are you aware that the limit of single precision FP numbers is 1.18x10^-38 to 3.40x10^38 ? So your numbers are beyond the range of an 8087 FPU single precision number.

The 8087 does not follow the ecxact same specification as later FPUs (the spec wasn't finished when the chip was released) so it's possible that the emulation code is treating this out of range value in a different way to your FP hardware.


It's a long time since I used DOS FP without the hardware but I recall the Proedure version being better than the Emulation version (faster). Try that option instead. You can set it in your source code by using:

$FLOAT PROCEDURE

at the start of your code.


If they don't help, cut down the code to the smallest chunk that demonstrates the problem. I threw out my 486sx before Christmas but I have a 386 I could test it on and someone else may have a 486sx.

Paul.



------------------

[Paul Dixon]

Tom,
the problem is as I mentioned. I can replicate it on my computer.
If I write the value 4.34427E-39 to file with a FPU present, the number is below the normal range of numbers allowed for a single but modern FPUs allow de-normalized numbers to be used at lower precision than usual.
If that value is read back with a FPU then the correct value is read back.
If that value is read back with NO FPU but EMULATION or PROCEDURE then the number read back is 0.504327E-41
Setting the environment variable "SET 87=NO" before running your code will allow you do demonstrate the problem yourself.

It looks like the software emulating the FPU in not handling de-normalised numbers correctly. I suspect this is because the original 8087 that is being emulated didn't handle them at all but just set to zero any value below 1.18x10^-38.

Paul.

------------------

[Ron Shaw]

I've ran across a similar problem before, when trying to retrieve
exact number values, I needed to use a larger precision data type.
The computer would round values automatically otherwise. The
computer might need the extra memmory space created by the larger
precision type for the decimal places values?

------------------
mailto:[email protected][email protected]</A>