dosbox 0.73 update

[sava.chankov@…]

Update dosbox to 0.73. Apply with patch -R -p3 in ports/emulators/dosbox

[ryandesign (Ryan Carsten Schmidt)]

We like for changes to do one logical thing at a time. In particular, we want whitespace changes separated from functional changes.

I have committed some whitespace changes in r58063 and your updated descriptions in r58064. We'll want at least two more commits, one to remove the "universal_variant no" and one to update to 0.73. On Snow Leopard, I'm given to believe that libsdl-devel is currently preferred to libsdl, so the dependency should be rewritten in a way that both could satisfy (both in dosbox and libsdl_sound). But these changes will have to wait until I can get dosbox's dependencies to build on Snow Leopard, or until I try the whole thing on Leopard.

[ryandesign (Ryan Carsten Schmidt)]

Attached​ is a diff of the remaining proposed changes from your patch that I have not yet committed.

Why does your patch cause the NEWS file to no longer be installed?

[sava.chankov@…]

Replying to ryandesign@…:

Why does your patch cause the NEWS file to no longer be installed?

Because it's doesn't differ from ChangeLog since 0.55

[ryandesign (Ryan Carsten Schmidt)]

Replying to sava.chankov@…:

Replying to ryandesign@…:

Why does your patch cause the NEWS file to no longer be installed?

Because it's doesn't differ from ChangeLog since 0.55

Sounds like a good reason to me. :)

[ryandesign (Ryan Carsten Schmidt)]

Regarding removal of "universal_variant no". I assume you did this because the comment said it was added because libsdl was not universal, and it is now. I have done some testing on Leopard now and cannot get dosbox to build universal. In a MacPorts prefix where universal_archs is x86_64/i386, I could not build libsdl (#20235). Then I tried in a new MacPorts prefix with universal_archs set to ppc/i386, and couldn't build speex (#21537). Installing speex-devel got me past that, but dosbox itself failed with what looks like assembly language errors:

core_dyn_x86/../../fpu/fpu_instructions_x86.h: In function 'void FPU_FLD_F32(PhysPt, Bitu)':
core_dyn_x86/../../fpu/fpu_instructions_x86.h:1136: error: unknown register name 'eax' in 'asm'
core_dyn_x86/../../fpu/fpu_instructions_x86.h: In function 'void FPU_FLD_F32_EA(PhysPt)':
core_dyn_x86/../../fpu/fpu_instructions_x86.h:1141: error: unknown register name 'eax' in 'asm'

I'll attach the full debug log​.

Were you in fact able to build dosbox universal? If so, with what OS and Xcode version, on what Mac, with what set of architectures in universal_archs?

[ryandesign (Ryan Carsten Schmidt)]

Well, my tests were with dosbox 0.72. Let me try again with 0.73.

[ryandesign (Ryan Carsten Schmidt)]

Ok, the issue persists with 0.73.

[ryandesign (Ryan Carsten Schmidt)]

I updated dosbox to 0.73, took out the NEWS File, and removed the patches in r58073. From your patch that just leaves the universal issue.

[sava.chankov@…]

Although #20235 was closed today, I couldn't get libdl 1.2.14 to compile 64 bit. I provide a patch for i386 ppc universal variant - it built on Core 2 Duo. I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it. Besides, why doesn't MacPorts consider platform declarations when building universal binary for that platform?

The other patch I attached removes zlib as dependency - it's actually dependency of libpng.

[ryandesign (Ryan Carsten Schmidt)]

Replying to sava.chankov@…:

I provide a patch for i386 ppc universal variant - it built on Core 2 Duo.

But your patch would disable the FPU and dynamic x86 stuff even in the Intel portion of a universal binary. We should either disable it always, even on non-universal builds, or presumably this code is useful, so we should enable it always on Intel, even in a universal binary.

I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it.

I can test it on my Power Mac G4.

Besides, why doesn't MacPorts consider platform declarations when building universal binary for that platform?

Well, it just doesn't. "platform powerpc" is executed when building on powerpc, regardless what architectures the build is going to be for, and similarly with "platform i386". Universal builds happen all at once -- there aren't separate configure and build phases that get run for each architecture. Unless you use the muniversal portgroup. Then they are run separately, and you do have the chance to pass separate arguments for each architecture. So maybe using muniversal is the way we should go with the dosbox port.

The other patch I attached removes zlib as dependency - it's actually dependency of libpng.

Sounds good; changed in r58183.

[sava.chankov@…]

Replying to ryandesign@…:

Replying to sava.chankov@…: But your patch would disable the FPU and dynamic x86 stuff even in the Intel portion of a universal binary. We should either disable it always, even on non-universal builds, or presumably this code is useful, so we should enable it always on Intel, even in a universal binary.

Yes, it should be enabled on Intel, disabled only on PowerPC. I couldn't find any documentation how to pass different configure args for every arch using muniversal group. Do you know how to do it?

I've got the feeling that configure arguments for platform powerpc should be the same as variant universal, because the FPU code is newly added to 0.73 - however I don't have access to an old Mac with PowerPC and can't test it.

I can test it on my Power Mac G4.

Please, test it.

[ryandesign (Ryan Carsten Schmidt)]

The powerpc platform variant seems to be completely unnecessary; dosbox figures out on its own that it shouldn't enable the FPU or dynamic x86 bits when building on PowerPC.

Have not tested universal yet.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ryandesign@…:

The powerpc platform variant seems to be completely unnecessary

Removed in r58322.

[domiman@…]

For Dosbox on Snow Leopard it would be much more usefull if you could choose a variant that builds 32-bit and keeps FPU and dynamic x86 enabled. Does libsdl_sound build for you? I'm still stuck at physfs...

[domiman@…]

with the current portfile dosbox 0.73 compiles fine, BUT opposed to the official OS X release, the macports build has severe stability issues. A simple benchmark (search the vogons forums for pcpbench) makes Dosbox crash with a segmentation fault. This is not good.

[ryandesign (Ryan Carsten Schmidt)]

Replying to domiman@…:

For Dosbox on Snow Leopard it would be much more usefull if you could choose a variant that builds 32-bit and keeps FPU and dynamic x86 enabled.

Are you saying FPU and dynamic x86 are automatically disabled when building 64-bit?

It is not MacPorts custom to provide variants to build for different architectures. But you can set build_arch to i386 in macports.conf if you want to build i386.

Does libsdl_sound build for you? I'm still stuck at physfs...

No problem building physfs here. If you're unable to, please file a ticket.

No problem building dosbox on Snow Leopard, except that I'm building universal, and dependency speex doesn't build universal, so I had to use speex-devel instead, which is recommended anyway at this point, since the developers of speex no longer recommend using their latest stable release.

[ryandesign (Ryan Carsten Schmidt)]

Replying to domiman@…:

with the current portfile dosbox 0.73 compiles fine, BUT opposed to the official OS X release, the macports build has severe stability issues. A simple benchmark (search the vogons forums for pcpbench) makes Dosbox crash with a segmentation fault. This is not good.

Ok. Why is this? We are just compiling the source they provide. If their source causes such crashes, they should fix their source.

[nerdling (Jeremy Lavergne)]

But do they provide 64-bit binaries? Sounds like they simply provide 32-bit, avoiding the issue.

$ file /Volumes/DOSBox 0.73/DOSBox.app/Contents/MacOSDOSBox 
DOSBox: Mach-O universal binary with 4 architectures
DOSBox (for architecture ppc750):	Mach-O executable ppc
DOSBox (for architecture ppc7450):	Mach-O executable ppc
DOSBox (for architecture ppc970):	Mach-O executable ppc
DOSBox (for architecture i386):	Mach-O executable i386

[domiman@…]

Cc Me!

[domiman@…]

sorry, I wasn't Cc'ed so I missed the answers. I think the crashes are because some parts of their emulation is not yet fit to be built on 64-bit and is therefore automatically disabled when you built Dosbox in 64-bit and therefore crashes when in the emulation the core gets selected automatically (core=auto is default since 0.73).

And since they provide only 32-bit version they avoid the issue.

So far the issue remains, that when Dosbox is built in 64-bit it is unstable.

Before I report that issue with it crashing to the Dosbox devs, can you tell me what to do to manually compile the dosbox CVS in 32-bit? The normal procedure to build it on my own I know (autogen, configure, make), I just don't know how to make it build in 32-bit.

[nerdling (Jeremy Lavergne)]

Replying to domiman@…:

Before I report that issue with it crashing to the Dosbox devs, can you tell me what to do to manually compile the dosbox CVS in 32-bit? The normal procedure to build it on my own I know (autogen, configure, make), I just don't know how to make it build in 32-bit.

You might try adding configure.build_arch i386 to the portfile you want to be 32-bit.

[domiman@…]

I kind of resolved this with the Dosbox developers. As we tested their dynamic CPU core is not compatible with 64bit OS X (works on 64bit Linux), so for a 64bit port of Dosbox you'd need to pass --disable-dynamic-core to ./configure. This would prevent the crash but without dynamic core Dosbox is much slower, especially in the "newer" build games like Blood (in a DOS benchmark the socre with dynamic core is 50, the score without is 3.5). So my recommendation is to build it in 32bit (just like you do for other ports that have problems in 64bit, like Wine). In 32bit I have no problems with Dosbox, both with the 0.73 release sources or actual SVN of Dosbox.

[ryandesign (Ryan Carsten Schmidt)]

Forced 32-bit in r61050. Thanks for researching that.