VOGONS


First post, by jcoppens

User metadata
Rank Newbie
Rank
Newbie

Hello guys,

I ran into trouble using DOSemu and FreePascal, so I thought giving DosBox a try. While in DosEmu there seem to be problems with resources, Dosbox does another, quite strange trick:

Just the text output from 'fpc', which lists the command line options, shows scrambled on the screen. I tried several options for the screen modes, no luck. I'll attach a screenshot of the window, as it's difficult to describe.

I'd appreciate suggestions!
John

(Running Linux, kernel 2.6.33, X-windows 7.5, DosBox 0.73, fpc 2.4.0)

Attachments

  • dosbox.png
    Filename
    dosbox.png
    File size
    21.9 KiB
    Views
    5456 views
    File comment
    Screenshot of the first page of the help, which appears when running 'fpc'.
    File license
    Fair use/fair dealing exception

Reply 3 of 14, by fluxit

User metadata
Rank Newbie
Rank
Newbie

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)

Attachments

  • dosbox.png
    Filename
    dosbox.png
    File size
    16.61 KiB
    Views
    5415 views
    File license
    Fair use/fair dealing exception

Reply 4 of 14, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

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.

Reply 6 of 14, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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?

Reply 9 of 14, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

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

Water flows down the stream
How to ask questions the smart way!

Reply 10 of 14, by Zorbid

User metadata
Rank Member
Rank
Member

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.

Reply 11 of 14, by TeaRex

User metadata
Rank Member
Rank
Member
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...

tearex