The first line (under c:\) should say 'Free Pascal Compiler...)
Apparently columns 3, 4, 7, 8, 11, 12, etc are ok. The other
two are scrambled

Works fine here (dosbox 0.73 under vista, free pascal 2.4.0). Anybody else under linux who can try that please?

I don't know if this helps as my "current" environment is very different from the op, but here is dosbox .73 on Puppy Linux 1.09ce (xorg 6.8.1, kernel 2.4.29)

Almost looks like some kind of interleaving or endianness issue going on inside of DOSBox.

I see that there are characters such as ` and @ that are in the corrupted screenshot but not in the uncorrupted one.

I'd expect the colours/attributes to be scrambled as well then.

The first line where it has "$FP HUL XER JON" instead of the 2.4.0 version number does not appear to be anything like an endian issue... it's like the % format identifiers in a printf have been mis-processed or something. Do other apps and games work correctly on the same system?

Yesterday I spent some time debugging this problem. I found the reason and submitted a bug report with more details here:

https://sourceforge.net/tracker/?func=detail& … 551&atid=467232

There's not much way round that besides using a full-softfloat implementation which is quite the worst thing to do anyways.

I recall that lately here was a patch to enable the dynamic fpu on 64 bit linux. maybe try that one

Possible workaround, with a smaller overhead than a full soft float implementation:

You could duplicate the FPU stack (full and double precision). Have fild push to both, and fist(p) pop from the full precision stack only if no other FPU operation occurred in the mean time.

wd wrote:

There's not much way round that besides using a full-softfloat implementation which is quite the worst thing to do anyways.

Besides Microsoft compilers, are there any other major compilers currently in use for building DOSBox that offer no native support for an 80 bits or larger "long double" type, and/or lack the basic math functions for long double?

In case you have a 128-bit type but not 80 bits, a few (ugly) bit-shifting macros should be enough to convert between 80 bits and 128 bits, no? True, it'd probably end up as an #ifdef mess but still might help with problems such as the one described in this thread.

If some compiler or library just doesn't offer functions such as square root, trigonometrics and logarithms with better than 64 bit precision - I'd assume that compatibility with many programs might be improved even if you use 80 bits just for elementary arithmetics in the emulated FPU and leave the special functions in 64 bit precision.

Probably there's some mistake in my thinking or else you'd have done this already, but I'd love to know where I go wrong...

if no other FPU operation occurred in the mean time.

That's exactly the problem. But maybe it works for the compiler thing.

More accurate approach: tag each FPU register as pristine or tainted.

But I would be surprised if FPU operations were performed during a memcpy.

At least one game very well does operations on it (to have screen masks).