en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en en nl en en en en sv en en es en en en fr zh fr en en en zh en it en en en en fr en en en en en en en en cs en en en de en en en en en nl en en en en en en en en it en en en en nl en en en en en en it en en en en en en en en nl en en en en en en en en en en en en en nl en en en en en en en ko en eu en en en cs en en en en en en it en en en en nl en de en en en en it en en en en en en en en nl vi en en en en en pt en en en en en en en en de en en en en en en en en nl en en en en en en en en en de en en en en en en en en nl fr en en en en en en en en en en en en en de en en en fr en en en en en en en en en pt en en en en en en
By logging into your account, you agree to our Privacy Policy, personal data processing and storage practices as described therein.
Forgot password or user name?
Search in titles only Search in PowerBASIC for DOS only
You are not logged in. You can browse in the PowerBASIC Community, but you must click Login (top right) before you can post. If this is your first visit, check out the FAQ or Sign Up.
"No 8087" error message at run-time???
All Time Today Last Week Last Month
All Discussions only Photos only Videos only Links only Polls only Events only
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:
...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):
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?
loadhigh MODE COM RATE=32 delay=1
Join Date: Jan 2005
30 Jan 2005, 02:51 AM
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.
Join Date: Nov 2000
31 Jan 2005, 04:35 AM
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.
Join Date: May 1999
31 Jan 2005, 10:39 AM
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...
Join Date: May 1999
15 Feb 2005, 07:07 AM
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:
But when run on the 486sx, the same 4-byte single values are displayed as:
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.)
[This message has been edited by Tom Brodhead (edited February 15, 2005).]
Join Date: Nov 2000
15 Feb 2005, 08:06 AM
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.
Join Date: Jun 1999
15 Feb 2005, 08:14 AM
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.
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:
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.
Join Date: Jun 1999
15 Feb 2005, 08:52 AM
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.
Join Date: Oct 2002
3 Mar 2005, 12:44 PM
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?
Copyright © 1998-2022 PowerBASIC Tools, LLC - All Rights Reserved.
Powered by vBulletin® Version 5.7.0
Copyright © 2022 vBulletin Solutions, Inc. All rights reserved.
All times are GMT-5. This page was generated at 04:39 AM.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, and to analyze site activity. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.