Scali wrote:

It would be nice if MDA mode also emulates that MDA only has 4k of video memory (as opposed to the 32k/64k of Hercules).
MDA memory wraps that 4k around in the range of B0000-B7FFF, where Hercules has a full 32k there without wraparound, and another optional 32k from B8000-BFFFF when no CGA card is installed.

It already does. According to the current implementation, machine=hercules already limits memory to 4KB unless a bit is flipped to enable the rest of the memory. machine=mda prevents setting that bit, therefore 4KB limit.

TheGreatCodeholio wrote:

It already does. According to the current implementation, machine=hercules already limits memory to 4KB unless a bit is flipped to enable the rest of the memory. machine=mda prevents setting that bit, therefore 4KB limit.

Hm, I'd have to check that (I have an original Hercules GB102 card), but I don't think Hercules has that behaviour.
Afaik the first 32k is always enabled, and there is no wraparound, even in textmode (you just get 8 pages of text instead of just 1). The second 64k is enabled by setting a bit.

Thanks for all the work, Codeholio! This is my new version of DOSBox to use. Loving that xbrz scaler 😀

I have a feature request, if you'll allow it- (optional) faux stereo sound for Adlib mono soundtracks. See my older post for details (Adlib stereo in DOSBox?), but basically the DOSBox for DS utility from a while back, DSx86, was able to implement stereo Adlib sound by modifying DOSBox's code. I'm sure Patrick would be happy to provide it if asked for, otherwise I'm sure knowledgeable minds can recreate it.

Much in the same way a scaler can provide output more to one's taste in 2018/9, stereo sound in the Adlib games can sound really, really good. I would much rather play Duke Nukem II on my HD laptop than my tiny DS, though! 😉

Once again, thanks for your hard work and the great results. Fast and beautiful, and just seamless.

Scali wrote:

TheGreatCodeholio wrote:

It already does. According to the current implementation, machine=hercules already limits memory to 4KB unless a bit is flipped to enable the rest of the memory. machine=mda prevents setting that bit, therefore 4KB limit.

Hm, I'd have to check that (I have an original Hercules GB102 card), but I don't think Hercules has that behaviour.
Afaik the first 32k is always enabled, and there is no wraparound, even in textmode (you just get 8 pages of text instead of just 1). The second 64k is enabled by setting a bit.

So then the emulation is wrong in src/hardware/vga_draw.cpp and src/hardware/vga_other.cpp concerning Hercules graphics emulation?

Patch to incorporate (minimally) the DOSBox-X mixer code into DOSBox SVN (attached).[OLDER PATCH, scroll down for newer patch]

EDIT: This is against SVN revision r4180 "qbix79 | 2018-12-28 04:19:13 -0800 (Fri, 28 Dec 2018)"

EDIT: This will temporarily break Sound Blaster direct DAC output until the Sound Blaster code incorporates the DOSBox-X method. The new mixer lacks the "stretched" audio output function.

EDIT: This is from the dosbox-svn repository on github: git diff -r master..feature-20181230-0016-dosbox-x-mixer

so the interpolation is always done ? How are equal sample rates treated now ?
(The last set of commits of harekiet to the mixer file)
As that part i saw being removed from my quick overview.

Qbix wrote:

so the interpolation is always done ? How are equal sample rates treated now ?
(The last set of commits of harekiet to the mixer file)
As that part i saw being removed from my quick overview.

If the sample rates match, then the fractional part should always be zero and interpolation will result in the same sample going in. Otherwise, the fractional part will count as needed to interpolate between sample rates.

The lowpass filter should not filter unless the mixer channel has called on the mixer to apply a lowpass filter.

The mixer is written so that, if no calls are made to the mixer channel to change lowpass filtering or slew rate, interpolation will happen in the same way it does now in DOSBox SVN: Linear interpolation.

but what if the input rate is equal to the output rate ? (as those commits improved the behaviour of that)

Qbix wrote:

but what if the input rate is equal to the output rate ? (as those commits improved the behaviour of that)

Looking over the code, freq_f == 0 when the channel is first made. If a call is made to SetFreq that matches the mixer's output rate, then it will have freq_f == 0 at every sample, freq_f += freq_n will set it to freq_d, and roll over so that on the next sample freq_f == 0 again. Without any special calls, the "slew rate" equals the sample rate (becomes linear interpolation just like SVN does now) so freq_fslew == freq_f. The interpolated sample is result = last + ((delta * freq_fslew) / freq_d). If freq_fslew == 0 at every call, then no interpolation is done.

However if the sample rate does not match at first, then changed to match later, the SetFreq code updates freq_f to preserve whatever interpolation state was there across the sample rate change, so at that point, interpolation will always happen.

If you're concerned about that, you could modify SetFreq after the patch to set freq_f = freq_fslew = 0 instead of recomputing it from the change in sample rate.

EDIT: See DOSBox-X src/hardware/mixer.cpp line 264, MixerChannel::SetFreq

I think these lines could be removed from SVN code in the mixer-X patch:

1#define FREQ_SHIFT 14
2#define FREQ_NEXT ( 1 << FREQ_SHIFT)
3#define FREQ_MASK ( FREQ_NEXT -1 )
4
5#define TICK_SHIFT 14
6#define TICK_NEXT ( 1 << TICK_SHIFT)
7#define TICK_MASK (TICK_NEXT -1)

hail-to-the-ryzen wrote:

I think these lines could be removed from SVN code in the mixer-X patch: […]
Show full quote

I think these lines could be removed from SVN code in the mixer-X patch:

Copy code to clipboard

1#define FREQ_SHIFT 14
2#define FREQ_NEXT ( 1 << FREQ_SHIFT)
3#define FREQ_MASK ( FREQ_NEXT -1 )
4
5#define TICK_SHIFT 14
6#define TICK_NEXT ( 1 << TICK_SHIFT)
7#define TICK_MASK (TICK_NEXT -1)

I think it's better if the patch modifies as little as possible.

If DOSBox SVN approves of this patch, then they can remove the unused functions, variables, defines, etc.

I agree entirely but it may make it easier for their team to see the modifications.

hail-to-the-ryzen wrote:

I agree entirely but it may make it easier for their team to see the modifications.

It's easier to see modifications if the patch changes less of the code. More modifications like that will only add to the noise.

I agree. The mute function code added with the patch is also unused.

hail-to-the-ryzen wrote:

I agree. The mute function code added with the patch is also unused.

In DOSBox SVN, yes. In DOSBox-X it's tied to a menu command.

Patch to incorporate (minimally) the DOSBox-X mixer code into DOSBox SVN (attached) revised to remove "mute" function. [OLDER PATCH, scroll down for newer patch]

EDIT: This is against SVN revision r4180 "qbix79 | 2018-12-28 04:19:13 -0800 (Fri, 28 Dec 2018)"

EDIT: This will temporarily break Sound Blaster direct DAC output until the Sound Blaster code incorporates the DOSBox-X method. The new mixer lacks the "stretched" audio output function.

EDIT: This is from the dosbox-svn repository on github: git diff -r master..feature-20181230-0016-dosbox-x-mixer

Patch to incorporate (minimally) the DOSBox-X mixer code into DOSBox SVN (attached) revised to remove "mute" function, and working Direct DAC Sound Blaster output taken from DOSBox-X and adapted to SVN.

EDIT: This is against SVN revision r4180 "qbix79 | 2018-12-28 04:19:13 -0800 (Fri, 28 Dec 2018)"

EDIT: This is from the dosbox-svn repository on github: git diff -r master..feature-20181230-0016-dosbox-x-mixer

Some ideas for SVN patches from -X (history of commits per file):

1CGA bug fixes in vga_draw.cpp and vga_dac.cpp
2signed integer overflow in dbopl.cc
3ems/xms fixes to vanilla memory arrangement (ems.cpp, xms.cpp, dos_memory.cpp)
4INT 10h AH=1Ch save and restore code
5mpu401.cpp fixes
6SSE renderer fix in RENDER_StartLineHandler