If you need more information

OS and cpu architecture as well as the cores you tried

I use Windows XP, servicepack 2, on a Dell Computer. I don't know what you mean by 'cpu architecture' and 'cores' (I am only a naive user). I ran the program in DOSBox and in a Windows XP window, by clicking on the program's exe icon. Maybe you can point me to the information about cpu architecture and cores?

Jan.

Well i guess it's an x86 or an x86_64 processor then.
Try setting core=dynamic in your dosbox.conf and test the program again.

Thanks a lot! I get the right results now.

So I quess it was no bug at all, but there are just different settings for different processors?

Regards,

Jan.

The dynamic core has some special capabilities of using the host floating
point unit, it's still not fully correct but the best thing to try.
If you have some short sample program maybe you can upload it, maybe somebody
wants to check if it's fixable for the regular fpu emulation.

It's a freeware program, so I can upload the program and the source code. Where can I upload?

Jan.

here ?
else try on rapidshare or so

OK, I hadn't noticed. Here they come.

Jan.

Ok this is intentional, dosbox goes for speed first with the fpu emulation
for the normal core under x86.

wd wrote:

Ok this is intentional, dosbox goes for speed first with the fpu emulation for the normal core under x86.

Are there any programs that actually use the fpu and are not bothered by this approach? Perhaps this is a very special case, but the value seems so way off, that say a 3D calculation would also go dramatically wrong?

JAL

I don't know if many programs run into this problem. I noticed the false answers because I also did the calculations in a spreadsheet. I was writing an article and I wanted to be absolutely sure I had the numbers right and understand what happens during the calculations. I think most people won't do that, because they assume the outcomes of the program are OK. The program I uploaded is widely used and I think that a growing number of people will get to use DOS emulaters, because running DOS programs in a window under Windows XP or other Windows OS is much less user friendly.

Jan.

in general the emulation is quite accurate. I thought that the regulars cores used the asm fpu core as well. I must be mistaken though

I think this should be documented. Somewhere in the documentation should be a notice that the "normal" and "simple" core use short-cuts that can make certain calculations wrong.

Shouldn't perhaps the normal core always use correct FP? What games are there that are recent enough to require a FP unit (i.e., won't run on a 486SX and below), yet are not resource-hungry enough to require dynamic core?

I guess the number of _games_ is very limited that fits this description. So game compatibility wouldn't suffer if normal core FP became slower, wouldn't it?

I think this should be documented.

No, the only documentation is that dosbox is for GAMES and not for
scientific/commercial apps.

Shouldn't perhaps the normal core always use correct FP?

You'll never get a "correct" fpu (see fpu exceptions).
The "more" "wrong" fpu thing that kicks in here is the WEAK_EXCEPTIONS
thing in fpu_instructions_x86.h
On non-x86 (ie. x86_64, different archs, ...) you'll always get 64 bit precision
anyways.

wd wrote:

I think this should be documented.

No, the only documentation is that dosbox is for GAMES and not for
scientific/commercial apps.

Sorry, but I disagree. This has nothing to do with the strategic decision about DOSBox development, but with correct programming practice. If an emulator is knowingly and intentionally wrong, that fact MUST be recorded somewhere, because in 5 years no one might remember that fact anymore. This specific case has only appeared for non-games up to now, but there is no guarantee that it will stay that way.

There's more stuff like that, like the technical reason why FFE doesn't work. While I know that "there was something intentional", and you explained it to me, and I am satisfied with that, I'm not able to correctly reproduce and explain the facts. This is simply wrong, because you can't have any project member have some important, static (i.e., something that won't change but is simply a well-thought fact) knowledge that's not written down. Decisions need to be documented, even more so when a single expert (in this case you) does them.

There are people out there, who actually try to understand what's going on. This is open source software after all. And a simple text file called LIMITATIONS, for example, won't cost you more than 5 minutes to set up and fill with the most important facts encountered in real life. The cost vs. gain ratio is clearly in favour of a little documentation. And as a side-effect, you will get a few support requests less, since there are people out there who read documentation.

wd wrote:

You'll never get a "correct" fpu (see fpu exceptions). The "more" "wrong" fpu thing that kicks in here is the WEAK_EXCEPTIONS th […]
Show full quote

Shouldn't perhaps the normal core always use correct FP?

You'll never get a "correct" fpu (see fpu exceptions).
The "more" "wrong" fpu thing that kicks in here is the WEAK_EXCEPTIONS
thing in fpu_instructions_x86.h
On non-x86 (ie. x86_64, different archs, ...) you'll always get 64 bit precision anyways.

What's the practical implication? Do you mean 64bit vs. 80bit, i.e. non-x86 can't get full math accuracy at all? And how serious is the performance impact of the WEAK_EXCEPTIONS thing?

because in 5 years no one might remember that fact anymore

Bad luck i guess.

who actually try to understand what's going on

They can ask or read the code. It's open source.

a simple text file called LIMITATIONS

This file would not fit on a cdrom for sure.

i.e. non-x86 can't get full math accuracy at all?

Right. The fpu was created with portability in mind, that is only using
math.h functions which use at max 64bit storing (double). I tried to
create a fast fpu thing for x86 (sort of dynamically recompiling fpu opcodes)
some time ago, but it ended up in a precise fpu (x86 only) which is the
fpu_instructions_x86.h thing used by default on x86. Even later the precision
was improved for one part (WEAK_EXCEPTIONS undefined) and weakened
(WEAK_EXCEPTIONS defined) whereas the latter is defaulted.

A nice test to see the flaws of the non-80bit precise store operations
is carmageddon, you'll get black stripes in the graphics (the missing 16 bits 😀 ).

And how serious is the performance impact of the WEAK_EXCEPTIONS thing?

Dunno, with architectures heading towards x86_64 it doesn't matter
too much anyways.

wd wrote:

because in 5 years no one might remember that fact anymore

Bad luck i guess.

Well, a commercial project would never accept such an answer, and IMHO since we're talking about open source, quality standards are higher than "well, at least it runs for now".

wd wrote:

who actually try to understand what's going on

They can ask or read the code. It's open source.

Right, my point: it's open source. Bad documentation can't be excused there, because the questions are going to be asked anyways.

wd wrote:

a simple text file called LIMITATIONS

This file would not fit on a cdrom for sure.

Well, I'm not asking for a scientifically proven Ph.D. thesis on rocket schience, but a higher level view which has relevance for users, not just developers. You know, like the difference between a CVS log and the list of changes published in the release announcements. The first few entries could be (please excuse the inaccuracies, I'm not the expert here):

- FPU core only works with 64 bit accuracy on most platforms. Affected games: Carmageddon, ... [rationale: portability]
- x86 platform has 80bit FPU, but has simplified exception model. Affected games: none so far, but several apps (use dynamic core instead). [rationale: performance]
- protected mode core can't handle recursive initialization. Affected games: Frontier: First Encounters (use jjffe instead) [rationale: not needed, since the only affected game has a source port]
- VGA emulation does not render with scan line accuracy. Affected games: Lemmings, Kellogs, many demos, ... [rationale: performance, this is not a game-stopping issue]
- No direct I/O port acces. No games affected, but some apps. [rationale: all game-relevant hardware is emulated fully]

You see what I mean? A simple high-level list containing short explanations, affected games, workarounds and reasoning, why the limitation is present. No rocket science to write, and takes just a minute to update.

wd wrote:

A nice test to see the flaws of the non-80bit precise store operations
is carmageddon, you'll get black stripes in the graphics (the missing 16 bits 😀 ).

I never played that game, but asking hypothetically: Is there any way to get such games working correctly on non-x86? Would dynrec on x86_64 use 80bit?

You see what I mean?

Yeah, feel free to do that. I (and Qbix+Harekiet+etc.) neither have the time to,
nor do i get money for that.

can't be excused there

I don't excuse for anything. If you can do it better, do it.

Would dynrec on x86_64 use 80bit?

No, it uses the math lib, but a bit more decoding in the recompiling stage
than the normal core would do (see dyn_fpu.h).
The softfloat lib would be something to use for full precision, but think most
stuff that uses it ignores the exceptions as well.

As much of a hacker as [I thought I was, read sig link #2], I don't have the time and/or patience to compile every program I use (or even half); I go with pre-compiled executables, and thankfully DOSBox (like most good freeware) comes with one. I understand about portability, but I think most people will be running it on machines fairly similar (basically) to what DOSBox emulates, and anyway you pick the program and you wouldn't pick one you can't use. I would think it wouldn't be too difficult to have the pre-compiled IA-32 version use the native floating point support-- in fact, it should make it faster and more versatile, since it's not abstracting FP operations and then translating them into what they were in the first place.
I also think this may qualify as documentation, since the FAQ directs you here at the beginning (I'd be willing to bet that's how janvangastel found this place in the first place, that's how I did), but I also think DOSBox deserves "proper" documentation. It is a wiki, which are known for being a way for "regular people" to spread knowledge.
That note about the black stripes makes me think FP should always be taken seriously (no matter how painful it is 😉).
I was under the impression IA-64 had native IA-32 emulation, or simulation, or something; am I wrong?