HuckleCat wrote:

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.

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

Dominus wrote:

DOSBox-x has no dynamic core 😉

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

TheGreatCodeholio wrote:

- 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).

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

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?

mr_bigmouth_502 wrote:

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.

TheGreatCodeholio wrote:

mr_bigmouth_502 wrote:

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?

mr_bigmouth_502 wrote:

TheGreatCodeholio wrote:

mr_bigmouth_502 wrote:

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.

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

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.

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.

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.

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.

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

There is error logging from dos_mscdex.cpp:

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

A sample of code that generated logs:

1#define MSCDEX_LOG LOG(LOG_MISC,LOG_ERROR)
2
3MSCDEX_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:

1case 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.

hail-to-the-ryzen wrote:

There is error logging from dos_mscdex.cpp: […]
Show full quote

There is error logging from dos_mscdex.cpp:

Copy code to clipboard

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

A sample of code that generated logs:

Copy code to clipboard

1#define MSCDEX_LOG LOG(LOG_MISC,LOG_ERROR)
2
3MSCDEX_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:

Copy code to clipboard

1case 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.

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.

TheGreatCodeholio wrote:

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.

Myloch wrote:

TheGreatCodeholio wrote:

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.

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