VOGONS

Common searches


DOSBox-X branch

Topic actions

Reply 1240 of 1866, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 1241 of 1866, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 1242 of 1866, by Yesterplay80

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

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 1243 of 1866, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

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

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for OS X (10.4-10.14 ppc/intel 32/64bit) codesigned for gatekeeper
DOSBox SVN with SDL2 snapshot for OS X (10.7-10.14 intel 64bit) codesigned for gatekeeper

Reply 1244 of 1866, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie

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?

My NEW(ish) desktop:
p8cqsw-2.png

Reply 1245 of 1866, by TheGreatCodeholio

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1246 of 1866, by mr_bigmouth_502

User metadata
Rank Oldbie
Rank
Oldbie
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?

My NEW(ish) desktop:
p8cqsw-2.png

Reply 1247 of 1866, by TheGreatCodeholio

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1249 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1250 of 1866, by Myloch

User metadata
Rank Member
Rank
Member

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.

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 1251 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1252 of 1866, by collector

User metadata
Rank l33t
Rank
l33t

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.

The Sierra Help Pages -- New Sierra Game Installers -- Sierra Game Patches -- New Non-Sierra Game Installers

Reply 1253 of 1866, by Myloch

User metadata
Rank Member
Rank
Member

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

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 1254 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

There is error logging from dos_mscdex.cpp:

 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:

#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:

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.

Reply 1255 of 1866, by TheGreatCodeholio

User metadata
Rank Oldbie
Rank
Oldbie
hail-to-the-ryzen wrote:
There is error logging from dos_mscdex.cpp: […]
Show full quote

There is error logging from dos_mscdex.cpp:

 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:

#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:

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.

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1256 of 1866, by hail-to-the-ryzen

User metadata
Rank Member
Rank
Member

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.

Reply 1257 of 1866, by Myloch

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

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 1258 of 1866, by TheGreatCodeholio

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

DOSBox-X project: more emulation better accuracy.
DOSLIB and DOSLIB2: Learn how to tinker and hack hardware and software from DOS.

Reply 1259 of 1866, by Myloch

User metadata
Rank Member
Rank
Member

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

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"