I wanted to download ykhwong latest build, but his site seems to be down - http://ykhwong.x-y.net/. Does anyone know if there's another place to find it?
Alternatively, any other good DOSBox builds which have good support for direct3d filters (or at least openglhq)?
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.
"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen
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.
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.
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.
Last edited by Spaz on 2015-01-08, 08:46. Edited 1 time in total.
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.
@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
Last edited by truth_deleted on 2015-01-08, 23:55. Edited 4 times in total.
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.
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
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
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: