DOSBox-X branch

[Yesterplay80]

I'm using the latest 64 bit build from EmuCR of Dosbox-X.

IIRC, the dynamic core in 64 bit builds runs much slower than the one from 32 bit builds, at least in other builds.

[Dominus]

DOSBox-x has no dynamic core (but I think other cores are also affected by 64bit but in much lesser extend)

[Yesterplay80]

DOSBox-x has no dynamic core

It seems to have a dynamic core, it's just not maintained:

- Perhaps you're running the Lego game with dynamic core, which I haven't bothered to maintain because the changes underneath don't work well with it. Try running with normal core, to see if it works (but slowly).

[Dominus]

Ah yes, that could be as well. I just remembered that dynamic core is useless in DOSBox-x. And yes, if it is not disabled (as I thought it was), then it will be horribly slow as no upstream changes have been implemented

[mr_bigmouth_502]

Stupid question, but why is the dynamic core so slow on 64-bit DosBox builds? How can I force an Arch Linux system to build it in 32-bit?

[TheGreatCodeholio]

Stupid question, but why is the dynamic core so slow on 64-bit DosBox builds? How can I force an Arch Linux system to build it in 32-bit?

There is no dynamic core on 64-bit. The dynamic core is only enabled on 32-bit builds.

[mr_bigmouth_502]

Stupid question, but why is the dynamic core so slow on 64-bit DosBox builds? How can I force an Arch Linux system to build it in 32-bit?

There is no dynamic core on 64-bit. The dynamic core is only enabled on 32-bit builds.

Really? Why not?

[TheGreatCodeholio]

Stupid question, but why is the dynamic core so slow on 64-bit DosBox builds? How can I force an Arch Linux system to build it in 32-bit?

There is no dynamic core on 64-bit. The dynamic core is only enabled on 32-bit builds.

Really? Why not?

Assembly language written for 32-bit x86 mode generally does not work on 64-bit x86_64. Too many things change. This includes dynamically generated assembly made at runtime.

[SedrynTyros]

Hey, I see that Windows binaries are now being released again, which is awesome. Has graphics scaling been introduced yet a la OpenGL?

[TheGreatCodeholio]

Not that I'm aware. I've been able to bring on some help to make Win32 builds so I can focus on cleanup and other projects.

[Myloch]

they keep releasing dosbox-x builds on emucr.com with broken mt32 emulation. Even with you select proper mt32 settings in .conf file and you put needed roms, it keeps running with a crappy midi-like sound. Please investigate.

[TheGreatCodeholio]

I don't have the means to develop or test MT32 emulation. I'll need help with that. I have it open as an issue on Github.

[collector]

Perhaps ask sergm? I am pretty sure that he has a plain vanilla SVN DOSBox patch for the latest Munt. Not sure how much fussing you would have to do to get it to build with your fork.

[Myloch]

I redirected sergm here but I don't know if he gives a sxxt about the whole thing.

[hail-to-the-ryzen]

There is error logging from dos_mscdex.cpp:

Code: Select all

 MISC:MSCDEX: INT 2F AX=1510 BX=0000 CX=0003
 MISC:MSCDEX: Driver Function 03
 MISC:MSCDEX: IOCTL INPUT Subfunction 0C
 MISC:MSCDEX: Status : 0300


A sample of code that generated logs:

Code: Select all

#define MSCDEX_LOG LOG(LOG_MISC,LOG_ERROR)

MSCDEX_LOG("MSCDEX: Status : %04X",mem_readw(curReqheaderPtr+3));

I haven't verified if it is from cd audio playback, but the above 0x0C case is handled in code:

Code: Select all

case 0x0C :{/* Get Audio Sub Channel data */

Is it correct to change the LOG_ERROR to LOG_NORMAL in dosbox-x, at least for the functions supported in emulation?

Edit: verified that removing this logging does eliminate the sound pauses from the soundblaster and cd audio playing at the same time. Tested in only one game.

Edit 2: it's specific to dosbox-x. It seems that the logs occur whenever a mouse button is clicked. If the button is held down, then it continues to generate the above log. I wonder if the above CD related log is caused by a raising of an irq.

[TheGreatCodeholio]

There is error logging from dos_mscdex.cpp:

Code: Select all

 MISC:MSCDEX: INT 2F AX=1510 BX=0000 CX=0003
 MISC:MSCDEX: Driver Function 03
 MISC:MSCDEX: IOCTL INPUT Subfunction 0C
 MISC:MSCDEX: Status : 0300


A sample of code that generated logs:

Code: Select all

#define MSCDEX_LOG LOG(LOG_MISC,LOG_ERROR)

MSCDEX_LOG("MSCDEX: Status : %04X",mem_readw(curReqheaderPtr+3));

I haven't verified if it is from cd audio playback, but the above 0x0C case is handled in code:

Code: Select all

case 0x0C :{/* Get Audio Sub Channel data */

Is it correct to change the LOG_ERROR to LOG_NORMAL in dosbox-x, at least for the functions supported in emulation?

Edit: verified that removing this logging does eliminate the sound pauses from the soundblaster and cd audio playing at the same time. Tested in only one game.

Edit 2: it's specific to dosbox-x. It seems that the logs occur whenever a mouse button is clicked. If the button is held down, then it continues to generate the above log. I wonder if the above CD related log is caused by a raising of an irq.

Go ahead. The IDE emulation logs a bit too much only because I wrote it that way to verify things work as expected.

[hail-to-the-ryzen]

I set ide=false, but perhaps it is still active?

Isolated the issue between 4/5/15 and 5/30/15. The latter has the repeated logs. Tested several commits, and even though the atapi ones seem most plausible, it may instead be the normal core enhancements from that time interval.

Edit: the mouse button events will cause many of the mscdex logs to repeat (dozens each time). Turning off digital audio mostly solves the issue. I think the mouse events are leading to audio events which causes the excess logging. It's probably a bug in the game, but removing the logging seems sufficient.

Edit 2: confirmed that the game in fact causes the CD to "thrash" on certain mouse events. So the issue is internal to the game.

[Myloch]

I don't have the means to develop or test MT32 emulation. I'll need help with that. I have it open as an issue on Github.

yeah I saw that page: it seems that it was received quite harshly. I refuse to think I'm the only one who used mt32 dosbox implementation,in the good old days when it worked correctly, in ykhwong builds and (probably) old dosbox-x releases. It's a shame having it broken/discontinued now that the munt project made huge steps and emulation is very good. Maybe it would work if I find a recent Munt driver installation and I redirect to midi output->munt but personally I don't want to install another program just for that.
I suppose that me (and others like me) will be stuck to those old dosbox builds I mentioned.

[TheGreatCodeholio]

I don't have the means to develop or test MT32 emulation. I'll need help with that. I have it open as an issue on Github.

yeah I saw that page: it seems that it was received quite harshly. I refuse to think I'm the only one who used mt32 dosbox implementation, when it used to work correctly, in ykhwong builds and (probably) old dosbox-x releases. It's a shame having it broken/discontinued now that the munt project made huge steps and emulation is very good. Maybe it would work if I find a recent Munt driver installation and I redirect to midi output->munt but personally I don't want to install another program just for that.
I suppose that me (and others like me) will be stuck to those old dosbox builds I mentioned.

Sorry to hear that, but I can't develop the code very well if I don't have the means to test it.

I'm sorry that it bitrotted, but I'm confident that someone who wants it can replace the MUNT code to update it.

[Myloch]

I made a notification about the problem in the main munt topic, asking for a volunteer programmer to fix that, fingers crossed!