Ddraw renderer is worse (screen artifacts with One Must Fall 2097) etc...

Artifacts in other video renderers, like for openglnb? I've noted artifacts but it not yet known where the problem lies, so testing will help toward solution.

ykhwong wrote:

The website could be temporarily unavailable due to the maximum daily web traffic limit.
As I manually reset the traffic, it should work now.

Hello，I used the version"20150103" to play blood , music card is general midi ,but the dosbox give me a "src\sound.cpp(576) could not detect mpu-401". Is this a bug? And...what should I do ？

PS：I used to use the version"20140127" to test，music card is also general midi , blood is playable but it's no midi sound(not all）

bright0085 wrote:

Hello，I used the version"20150103" to play blood , music card is general midi ,but the dosbox give me a "src\sound.cpp(576) could not detect mpu-401". Is this a bug? And...what should I do ？

PS：I used to use the version"20140127" to test，music card is also general midi , blood is playable but it's no midi sound(not all）

That's a duplicate bug report from that posted earlier in the thread: ykhwong's latest build?. I've tested that issue extensively and reported further on it in the dosbox-x thread. I also had suggested a workaround in the other thread (SVN builds). The suggestion is to run an older build and I specified a version to test.

Edit: I ran further tests on the midi issue. I originally said it is likely a linker error, and I can't rule that out yet. But, it is possible that another initialized device is interfering. It is difficult to test without having each separate patch in Ykhwong's build, so I'll leave the issue to others. 😀 It may also originate from an early change in dosbox-x, but these changes don't cause an issue in my tests so far, so I'm considering that there may be a combination of this early change along with a past patch in Ykhwong's. I also don't know if any special linker parameters are used.

truth5678 wrote:

Artifacts in other video renderers, like for openglnb?

Surface, overlay and direct3d - lower part of the OMF quit text isn't drawn. You can see it whan you scroll the screen with Enter.
Openglnb - same as ddraw. Plus OMF runs in 800x600 mode (both fullresolution and windowresolution are original).
DOSBox 0.74 works ok except overlay (DOSBox ctd after you press Enter in the OMF intro).
DOSBox SVN r3890 works ok woth all renderers.

Here is information on changing the video output setting: Re: Help with Output setting. I had same artifacts in Ykhwong's, too, but you may test different output settings and also the latest dosbox-x build to confirm.

truth5678 wrote:

bright0085 wrote:

Hello，I used the version"20150103" to play blood , music card is general midi ,but the dosbox give me a "src\sound.cpp(576) could not detect mpu-401". Is this a bug? And...what should I do ？

PS：I used to use the version"20140127" to test，music card is also general midi , blood is playable but it's no midi sound(not all）

That's a duplicate bug report from that posted earlier in the thread: ykhwong's latest build?. I've tested that issue extensively and reported further on it in the dosbox-x thread. I also had suggested a workaround in the other thread (SVN builds). The suggestion is to run an older build and I specified a version to test.

Edit: I ran further tests on the midi issue. I originally said it is likely a linker error, and I can't rule that out yet. But, it is possible that another initialized device is interfering. It is difficult to test without having each separate patch in Ykhwong's build, so I'll leave the issue to others. 😀 It may also originate from an early change in dosbox-x, but these changes don't cause an issue in my tests so far, so I'm considering that there may be a combination of this early change along with a past patch in Ykhwong's. I also don't know if any special linker parameters are used.

still no midi music...... 😵 hope the bug can be fixed soon ,thanks for your help

In the 2013 build, too?

truth5678 wrote:

In the 2013 build, too?

Yes ,but when I used the version"20120701"，it worked.

I tested the July 2013 build and the midi works. It has been used a lot and we would know if a major emulation was defective in that build. You must have another issue which makes it difficult to test the current build.

Gamecollector wrote:

Surface, overlay and direct3d - lower part of the OMF quit text isn't drawn.
Openglnb - same as ddraw. Plus OMF runs in 800x600 mode (both fullresolution and windowresolution are original).

Test in dosbox-x as mentioned earlier. This will help isolate the cause in the source code.

DOSBox-X surface, ddraw, openglnb - works ok with OMF2097.
Ddraw: "Failed to create ddraw surface, back to normal surface".
Overlay - ctd.
Plus there is something about "Illegal read from 658ddf9/658ddf8, CS:IP 0:0".
P.S. I hope link from this post is the actual version.

Since dosbox-x works for OMF2097 and not Ykhwong's then it may be a change specific to Ykhwong's newest build. However, the major change to video was from dosbox-x. So, one possible reason is the build process, such as directx components used. Another reason, more likely, is that the dosbox-x import was not compatible with the other components specific to Ykhwong's. I noted the same.

Try Direct3D for testing.

I think I have the midi bug isolated!

I built dosbox-x (version ae0c1003bf; 1/15/14) and there is no midi bug. Yet in the 1/25/14 build there is the bug. I'll leave it to others to confirm, but this suggests that the midi problem is in the dosbox-x commits between 1/15 and 1/25/14.

It was also noted that that time frame saw a lot of BIOS related commits.

Edit: dosbox-x (version 4d0e86801f4b6; 1/18/14) shows no midi bug either.

Edit2: there is a good possibility that the midi bug is in a dosbox-x commit between 1/18 and 1/25/14. However, dosbox-x does have working midi. So, the other possibility is that Ykhwong's build has an incomplete port of dosbox-x. At least this will provide a guide for others to find the exact cause.

In the case of dosbox-x, I isolated a midi bug to a 1/20/14 commit (linewise=true by default). I have a build from that time which produces a midi bug where linewise=true but plays midi normally where linewise=false.

There is a pre-built dosbox-x binary from 4/26/14 that does not show the above behavior, but I can't draw a conclusion until building that version with mingw32.

On June 27th, the linewise option was removed entirely; so, the newest Ykhwong's build does not have the option to run linewise=false and test the above fix.

It is possible that the midi bug related to the linewise setting on 1/20/14 is different from the midi bug in the recent version of Ykhwong's. However, it is a place to start. Also, even if there are multiple ways to result in the midi bug (where the midi music frequently does not start playing), the above shows that other parts of the emulation may influence the midi music.

It suggests that Ykhwong could try reverting dosbox-x import to 1/20 or 4/26 and test the linewise modes and midi playback. Then, it would be possible to move forward in commits from that point, one month at a time.

Edit: test with this build: http://hackipedia.org/Projects/DOSBox-X/dosbo … 83e1c-win32.zip. That's the same version as imported to Ykhwong's.

truth5678 wrote:

test with this build: http://hackipedia.org/Projects/DOSBox-X/dosbo … 83e1c-win32.zip. That's the same version as imported to Ykhwong's.

Tnx for this link.
All outputs work ok with OMF2097. The only "bug" is - if [render]/char9=true then DOSBox uses the 800x600 fullscreen mode for text.

Isolated the midi bug further. 😀 It's actually not in the linewise video code, but in the menu for the linewise option. Removed all references to "linewise" from the menu and the midi played as expected. This is for the January 2014 build of dosbox-x. Also, tried January 2015 build of dosbox-x, but there is no reference to linewise, so I removed the whole menu from source code and it worked as expected. It suggests that the menu is interacting with the emulation to cause the midi to fail, at least in these specific dosbox-x tests.

There have been other conflicts between the menu and emulation in the past during dosbox-x development, so it may be a good idea to have a switch to remove the menu entirely, if only for testing during development.

I am hopeful that removing the menu code from Ykhwong's build will restore full midi functioning, but I only have the dosbox-x builds to test with.

Edit: to test for midi bug -> run Ykhwong's build of dosbox with cycles=max, test the midi, then change to cycles=25000, and then test the midi again. It seems like fixed cycles avoids the midi bug, but the actual cause may be in the menu code or elsewhere.

In an older build of dosbox-x, it is possible to avoid a midi bug by removing the menu, but the latest version required more extensive edits to the menu and gui code.

truth5678 wrote:

Isolated the bug within the menu code itself. I believe, not positive yet, that the cycles updating in the menu bar is causing the midi bug. To test this, run Ykhwong's build of dosbox with cycles=max, test the midi, then change to cycles=25000, and then test the midi again. It seems like fixed cycles avoids the midi bug, but I believe it's actually the menu bar updating the cycles.

If not, then I will continue exploring the menu code for hints.

I forget the details, but you should be able to test that by using the DOSBox command line command to revise the cycles independently of the menu.

kolano wrote:

I forget the details, but you should be able to test that by using the DOSBox command line command to revise the cycles independently of the menu.

The cycles setting is available in the dosbox configuration file. If you have trouble setting it or finding the option, please see the information here:
http://www.dosbox.com/wiki/Dosbox.conf#cycles … cle_limit.22.5D

Also, some basics on midi usage is here: DOSBox and MIDI music. I hope this helps. 😀