http://www.emucr.com/2013/05/ykhwongs-dosbox- … d-20130506.html

truth5678 wrote:

http://www.emucr.com/2013/05/ykhwongs-dosbox- … d-20130506.html

Thanks! This one seems even newer: http://www.emucr.com/2014/02/ykhwongs-dosbox- … d-20140127.html

Is emucr.com a trustworthy site?

<link no longer requested>

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

kalirion wrote:

Is emucr.com a trustworthy site?

Not 100% of the time. I have often heard about malware signatures reported amongst EmuCR downloads in general. Given the nature of emulation, it's possible some are false positives - but given their Chinese hosting, it's also possible some are not. Here's hoping that it was a problem in their past that they've solved.

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.

Awesome, thank you!

Edit: Would this be the right place for a bug report? Your build from this January has an issue with the GOG versions of Secret Agent and Crystal Caves - when the screen scrolls horizontally, the UI elements at the bottom stutter/jump around.

Merely replacing dosbox.exe with the one from http://ykhwong.x-y.net/downloads/dosbox/win/20140125.7z fixes the issue.

The site's back up and there is a January 3 2015 build available.

ykhwong, where have you been? 😀

kalirion wrote:

Your build from this January has an issue with the GOG versions of Secret Agent and Crystal Caves - when the screen scrolls horizontally, the UI elements at the bottom stutter/jump around.

Confirmed this issue. However, it doesn't occur in dosbox-x (July 19th build), so it must be a commit after that date. Also, the former solution is here to the shaking HUD problem: Crystal Caves Hud Shaking. So, assuming the current issue is related, then it should be a change to vga_draw.cpp, particularly in a commit that occurred after July 19th.

Edit: isolated the issue to this commit: https://github.com/joncampbell123/dosbox-x/co … f6d8174d2ba07b4. Removing that commit prevents the above issue.

I have an issue with this latest build. Some games no longer work correctly with General MIDI. The games start fine, but no music. I have tested several Doom engine games that all exhibit the same problem (Doom, Doom2, Hexen, Heretic). Managed to get music on Doom some times, but rarely. Other games like Apogee's Hocus Pocus and Wacky Wheels work fine with GM.

Both the regular DOSBox 0.74 and the last Daum build (Jan. 2014) work fine with GM. My setup is a Roland SC-55 connected with MIDI to USB adapter. But, this is probably not related to my setup, as I have also tested with the software based 'Microsoft GS Wavetable Synth' which shows the same problem. Anyone else having this issue?

For the time being I have reverted back to the January 2014 build.

Confirmed that General MIDI music will frequently not start (not initialize?) in Ykhwong's latest build (win32). This can be reproduced within a single dosbox session, even though "mixer /listmidi" shows a device active. Verified that the latest dosbox-x does not show this issue, and also ruled out SDL as a cause.

It may be worthwhile to examine any 3rd party MIDI patches, especially since the dosbox MIDI code was revised somewhat recently (by dosbox team). In addition, VS compiler optimizations could be turned off for ruling out the compiler as a cause.

Thank you for the bug info and solutions.
I will look through the issues sooner or later.

@ykhwong: nice to see you back here! I saw a new version is out: did you perhaps fix the frequency of ibm ps/1 audio emulation?

By the way, is there a way to suppress all these DOS_AllocateMemory/DOS_FreeMemory messages?

Myloch wrote:

@ykhwong: nice to see you back here! I saw a new version is out: did you perhaps fix the frequency of ibm ps/1 audio emulation?

In the ps/1 thread you asked for a "change to the source code to customize the frequency". Is that correct? That way you could test which frequency sounds best, otherwise do you have a sample at the supposed correct frequency to compare against real hardware?

Is this the line which specifies the clock frequency which should be a variable?

1SN76496Reset( &sn, 3579545, sample_rate )

If so, here are untested changes (a guide) toward a user specified clock frequency:

1In ps1.diff
2In class PS1SOUND:
3Bit32u clock_rate = section->Get_int("ps1clockrate");
4ps1.clockrate=clock_rate;
5
6change:
7SN76496Reset( &ps1.sn, 3579545, sample_rate );
8to:
9SN76496Reset( &ps1.sn, clock_rate, sample_rate );
10
11In dosbox.cpp
12Pint = secprop->Add_int("ps1clockrate",Property::Changeable::OnlyAtStart,3579545);
13Pint->Set_values(0,10000000);
14Pint->Set_help("Base clock frequency of the PS1 audio emulation.");
15
16In ps1sound.cpp
17add a line to struct PS1AUDIO
18int clockrate

Gamecollector wrote:

By the way, is there a way to suppress all these DOS_AllocateMemory/DOS_FreeMemory messages?

In dos_memory.cpp, there is a parameter to turn off those messages.

Change:

1#define DEBUG_ALLOC

To:

1// #define DEBUG_ALLOC

truth5678 wrote:

Confirmed that General MIDI music will frequently not start (not initialize?) in Ykhwong's latest build (win32).

Tested further, but no solution yet. I think it would be helpful to test this issue on non-win32 operating systems. It may provide insight.

I was able to replicate this issue on win32 by building dosbox-x with the newest version of the mt32 emulation. It displayed the issue across midi devices, leading to the possibility that it is a linker problem or an obscure bug. I also noted an issue where sound initialization fails in EF2000, but that is probably a separate issue and not so difficult to identify.

Edit: reproduced above issue in dosbox-x builds as far back as 1/22/14, before Ykhwong's properly working build from 1/27/14. I conclude that this is a linker issue (combined with early source code changes) which is causing the unreliable starting of midi music in some games. I can't confirm this yet, but it provides a guide so others save troubleshooting steps.

truth5678 wrote:

In the ps/1 thread you asked for a "change to the source code to customize the frequency". Is that correct?

That was an old post, a user found the technical sheet of the audiocard and after some private messages with jmk, we concluded that the source code needs to be changed from this:
SN76496Reset( &ps1.sn, 3579545, sample_rate );

To this:
SN76496Reset( &ps1.sn, 4000000, sample_rate );

I informed ykhwong about it one year ago however I don't know if he finally changed the code in the new build

The Great Hierophant suggested that clock frequency a couple of years ago:

The lowest frequency the chip can output using the 3.579MHz clock is 874.76Hz. Perhaps a comparison of the raw Silpheed music data would be instructive. Might it be that the PS/1 chip is using a 4.00MHz base frequency?

Has this clock frequency been verified by an expert like Great Hierophant? I'll check his blog because he has made available his knowledge of these kinds of devices. Otherwise, here is part of the pseudo-code which I posted above to implement a variable clock frequency for testing:

1SN76496Reset( &ps1.sn, 3579545, sample_rate );
2to:
3SN76496Reset( &ps1.sn, clock_rate, sample_rate );