I didn't notice any such problems with "dynamic" fpu, though distortions might be subtle and many games don't use fpu at all.

That option should btw. greatly improve FPU performance in that core with games like e.g, quake as it enables dynamic core caching of fpu execution.
What about normal/full core, do you notice distortions with those cores or just with dynamic one, did you check with/out other #define for using asm FPU (X86 ASM FPU or similar name AFAIR)?

The problem is only on dynamic core. Sorry, I meant to mention that in the first message. The distortions don't appear using the normal or full cores (of course they're just too darn slow for me to use, but it's good to verify that it's only the one core with the problem).

I tried disabling the x86 assembly fpu core (the C_FPU_X86 option in config.h), but that made no difference.

Out of curiosity I fired up Quake to see what sort of framerate difference I got with and without the dynamic FPU stuff. In my test I get an increase of about 3 frames per second when using the dynamic FPU code (from 25fps to 28fps, roughly). For me the extra little bit of performance in Quake is not worth all the other problems I'm seeing. But hopefully there's a better solution than having to disable it completely.

It was easy to narrow this bug down to a faulty fnstsw ax instruction.
Try this patch: http://session-x.net/dosbox_fnstsw_fix.patch
The problem was simply that dosbox zeroed out the high word of EAX when in fact it should only alter the low word (ax).

thanks that instruction is used a lot.
I'm sure wd will notice it when he gets back.

> For me the extra little bit of performance in Quake is not worth all the
> other problems I'm seeing

Don't use it then. And the framerate increase was somewhat higher, but
some parts have been back-ported to the regular x86 fpu core.

> It was easy to narrow this bug down to a faulty fnstsw ax instruction.

Yes you're correct. Thanks for the patch.
As the dyncore fpu is superceded by some other stuff, i'll leave it as
is for the moment.

Folken, What processor are you using?

It was easy to narrow this bug down to a faulty fnstsw ax instruction.
Try this patch:

Tried it, and it works like a charm! I'll let you guys know if I see any further issues, but so far it's looking pretty good. I tried a couple other programs that were giving me a bit of trouble, and the problems seem to be gone there too.

I've run into another issue. Same drill as before - bug happens with #define X86_DYNFPU, and doesn't happen without it or under normal/full core. Though I should also add that the bug happens both with and without the above fix by evo.

The bug happens in two different demos by Pulse, and pretty much same thing happens in both (so I'm assuming it's the same problem for both demos):
Sunflower: http://www.scene.org/file.php?file=/demos/gro … se/pls_sunf.zip
Tribes: http://scene.org/file.php?file=/demos/groups/ … se/tribesfi.zip

When the demos are run they first display a static screen while the demo loads. This can takes a few seconds. Then they go into a 3d scene. I get a few frames and then it simply stops rendering. If you wait in Tribes you'll get the odd frame here and there (on scene changes I think) but it'll quickly stop rendering each time. In Sunflower if you wait, part of the demo will display fine, but there are points where it'll stop rendering again.

There's a stack-wrapping missing in dyn_fpu_esc6(),
FCOMPP (that is case 0x03) should look like this:

1			gen_load_host(&TOP,DREG(EA),4); 
2			gen_dop_word_imm(DOP_ADD,true,DREG(EA),1);
3			gen_dop_word_imm(DOP_AND,true,DREG(EA),7);

( the DOP_AND line added).
I think i'll upload those fixes even though the dynfpu is obsolete,
unless you find more bugs 😀

wd wrote:

There's a stack-wrapping missing in dyn_fpu_esc6(), FCOMPP (that is case 0x03) should look like this: […]
Show full quote

There's a stack-wrapping missing in dyn_fpu_esc6(),
FCOMPP (that is case 0x03) should look like this:

Copy code to clipboard

1			gen_load_host(&TOP,DREG(EA),4); 
2			gen_dop_word_imm(DOP_ADD,true,DREG(EA),1);
3			gen_dop_word_imm(DOP_AND,true,DREG(EA),7);

( the DOP_AND line added).
I think i'll upload those fixes even though the dynfpu is obsolete,
unless you find more bugs 😀

Just out of curiosity, by what is it being superseded?

Code that directly uses the host fpu without translation.

Makes sense actually to do so.
Does DOSBox itself contain code that compiles into FPU instructions? I guess not, can't think of any place where it would make sense (unless some fancy scaler)

> Does DOSBox itself contain code that compiles into FPU instructions?

Yes, the timing (PIC_Ticks logic) mainly, which leads to a lot of dependent
code (sound blaster, pcspeaker, timer). That's the tricky part of it 😉

wd wrote:

Yes, the timing (PIC_Ticks logic) mainly, which leads to a lot of dependent
code (sound blaster, pcspeaker, timer). That's the tricky part of it 😉

Just wondering, maybe it's possible to replace it by 64 bit integer arithmetics, but I don't know about the accuracy needed.

Well it's already solved by some save/restore logic.
I tried to replace the floating point values by fixed point
Bit64s variables, but it requires changes to a very large
number of files, and didn't really work well, so that
idea was kicked.

Got a chance to try out the latest fix, and so far it looks pretty good. Those two demos are definitely fixed, and I haven't found any other problems yet - so hopefully that was the last bug (for now at least!).

could someone please compile a build of the latest cvs with the patch evo maid above and the change wd maid above as well... as i am a n00b when it comes to compiling stuff... i only compile zsnes because there is a ultra handy zget program to do it for you...

i would love to test performance difference between ykhwong's build and the official cvs.

ps. i have a...

processor: Pentium 4 CPU 630 3.00GHz
asus p5ld2 standard m/b
geforce 6600gt pcie vid card
win XP home

The changes are already present in the cvs, maybe the build from
rcblanke already includes them.
Speed comparisons should be valid even without those patches.

are the builds from rcblanke optimized for my processor? as i would like a copy optimized for my system so as to reduce the requirements to get games to run efficiently.

and are his builds made from official cvs only (as in no new additions or changes)?