Eddy and Co (1995): Sound in X, not Staging

[Python-Exoproject]

Are you using the latest Dosbox-Staging Version?

• I have checked releases and am using the latest release.

Different version than latest?

81.1

What Operating System are you using?

Windows 11

If Other OS, please describe

No response

Relevant hardware info

No response

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

In Staging 81.1 and 80.1 there is no sound for the game, however in Dosbox X there is

Steps to reproduce the behaviour.

Explain how to reproduce

1. Play game in Staging

Download URL of affected game or software

No response

Your configuration

No response

Provide a Log

No response

Code of Conduct & Contributing Guidelines

• Yes, I agree.

[Python-Exoproject]

Maybe related to #3511

[codengine]

Works properly on my machine with SB16 and DosBox Staging 0.81.1 without any modifications.

[johnnovak]

Works properly on my machine with SB16 and DosBox Staging 0.81.1 without any modifications.

@codengine
Could you share your config or setup steps with @Python-Exoproject?

[codengine]

Sure, here is my config:
dosbox-staging.zip

I just extracted the game, ran "SETUP.EXE" and configured for SoundBlaster, afterwards just EISMANN.EXE.

My setup is Windows 10 22H2 on a Ryzen 5950.

[johnnovak]

Great stuff @codengine 👍🏻

[Python-Exoproject]

This is really interesting. Using your provided conf file made no difference for me. I noticed from the conf that you were using 82.0alpha so I tried that with no luck. I grabbed a copy of the game from TDC and ran setup with no luck.

What is different between our systems that would matter to the emulated environment? Im on Windows 11 but that shouldnt have an effect on you getting sound while I dont.

Its very likely to me that whatever it is also explains our differing results on Cyber Raiders. Any thoughts @johnnovak?

[codengine]

Because my computer crashed I had to reinstall and am now using Windows 11, so if it doesn't run well now, we know it could be related to the OS :)

Can you list your full specs and also attach your config?

[johnnovak]

Your host machine should make absolutely zero difference if you guys are both using Windows. Unless you both use cycles = max, of course—that could make a difference.

@codengine Can you please upload your zipped game folder somewhere? Before you do that, please tweak your local dosbox.conf in the game folder until the game runs fine when you start it with dosbox --noprimaryconf.

If you don't use local per game configs, please include the primary config in the ZIP.

[codengine]

Even after installing Windows 11 the game works perfectly fine.
https://streamable.com/wbfktq

Here is the game that I used:
https://www.mediafire.com/file/ocrl321jlubqxxr/EDDY.zip/file

My config is here #3640 (comment) and I'm not using per-game configs.

[johnnovak]

Nice one @codengine, great stuff! 🎉 Pinging @Python-Exoproject about the update.

[Python-Exoproject]

This has me stumped @johnnovak. Ive used the provided game files, provided conf, no luck. Ive tried a completely default launch of Staging external to exodos using the proved files, no luck. What of importance could be different between our setups?

I have no sound in ECE, vanilla, Staging, or Daum. X however provides sound. Ive attached my logs from when I ran the provided files and conf inside exodos framework in case it helps.

Do you get sound?

[interloper98]

(deleted my comment: I thought the problem might be that both SB16 and GUS were active at the same time, but now I see @codengine also is doing this in his conf, too). 😌

[Python-Exoproject]

Ive tried both in and out of exodos, those logs are from when I tried within which is the extra confs that load but it made no difference. All the other settings are from codengine's conf including the GUS. He said that conf works for him and provided video of it doing so, so I used it as is

[codengine]

@Python-Exoproject Could you attach the configs (base + game specific) that you were using? Moreover, which command line did you use?

[Python-Exoproject]

I did say that I used the conf provided by you @codengine, but here it is as requested along with the other exodos specific conf used in that particular log and the stock base staging conf we use in exodos. As mentioned though, I did try outside of the exodos framework with just your conf with the same results.

confs.zip

To run the game I used eismann.exe

[Python-Exoproject]

Im hoping some others will test the game so we can see if it working for you or not working for myself is the anomaly. I know exo and one of our discord users "CriticalCid" had the same results as I did with no sound outside of Dosbox X which is why we moved it from ECE to X.

[codengine]

@Python-Exoproject Just to make sure: You did run SETUP before launching the game, did you?

[Python-Exoproject]

I tried our exodos copy and both with your files directly unchanged and your files after running setup.

[interloper98]

Im hoping some others will test the game so we can see if it working for you or not working for myself is the anomaly.

Volunteer tester reporting for duty. Planning to try this on my win 11 system today. Will report back.

[codengine]

Now its getting really strange. I tried it on a laptop from 2013 with Win10, used exactly the same setup and all I hear is a short "crackle" at the start and then - nothing. Wtf?

My main computer has a SoundBlaster AE-7 in case that matters. The notebook has some Realtek Stuff I think.

[codengine]

Tried it on a second laptop (newer one, Windows 11) same result: With my config & stock config no sound, but instead of a cracke I get a "pop" and thats it then.

[interloper98]

Got some testing done with this one - this game is a blast, @Python-Exoproject. Wound up tweaking a bunch of stuff and zipped my results, so hopefully you guys can reproduce it too.

1. Extract EddyCo.zip some where. I've extracted it to C:\games\DOS\, and it creates an EddyCo folder.

2. Browse to your build of DOSBox Staging and open a command prompt. Run it with:

   dosbox.exe --noprimaryconf --working-dir C:\games\DOS\EddyCo

   Here's how that looks (see the console window at the top of my screenshot):

   

   And a recording:

   EddyCo.mp4

Conf settings

# Eddy & Co needs > 4.5 MB of RAM, normal core, and only uses SB's DMA
# for music & effects. It doesn't use MIDI, the PC Speaker, GUS, or even
# the SB's OPL chip - so turn them all off. It has its own DPMI manager,
# so let it manage its own extended memory (ems & xms = off).
# Frame rate gets perfectly smooth at 60 fps, so set that.
#
# Run SETUP.EXE, Configure the Sound Card with IRQ 7, DMA 1, port 220.
# It writes a new EISMANN.INI file containing:
#
# [SB]
# Adr=544
# DMA=1
# IRQ=7
#
# [SOUND]
# Driver=SB

[dosbox]
memsize = 8
startup_verbosity = quiet
dos_rate = 60
automount = on

[cpu]
core = normal
cycles = 8000

[sblaster]
sbtype = sb16
oplmode = none
irq = 7
dma = 1
sbbase = 220

[midi]
mpu401 = off
mididevice = none

[gus]
gus = off

[speaker]
pcspeaker = off

[ipx]
ipx = off

[ethernet]
ne2000 = off

[voodoo]
voodoo = off

[dos]
ems = off
xms = off
umb = off

[autoexec]
@ECHO OFF
MIXER sb 50 r50 c50 /NOSHOW
C:
EISMANN.EXE > NUL

[codengine]

@interloper98 Nice that it works for you, but that still doesn't explain why it works for me at least on my main machine, even with vanilla/unmodified config?

I did not have the settings configured that you pointed out yet it worked fine?

[interloper98]

@interloper98 Nice that it works for you, but that still doesn't explain why it works for me at least on my main machine, even with vanilla/unmodified config?

I did not have the settings configured that you pointed out yet it worked fine?

Yes, I'm not sure.

I first tested your conf with --noprimaryconf, but I also got not sound, even performing an installation and re-appling the sound settings.

So perhaps it was an order of operations thing?

It absolutely needs the normal core, so perhaps some initial steps on your side got dosbox to use the normal core prior to launching the game.

In any event, I think my conf should (hopefully) be 100% reproduceable on all the platforms.

---

I think dosbox selects the normal core for real mode applications, so my only hunch is that running setup prior to launching the game (all within the same dosbox instance) might have been how you got the normal core. But then subsequently launching the game directly (without setup) would have selected the dynamic core - leading to faulty sound. (Just a guess.. 🤷 🙂 )

[codengine]

I'll do some more tests on my laptops tomorrow.
The thing is: I ran setup on the too before starting the game, so I guess this can be ruled out.

But let's see!

[johnnovak]

Okay, gents @codengine @interloper98 @Python-Exoproject , here are my results:

With @interloper98's ZIP file, the game just works fine, and there is sound at the title screen and in-game.

Now the fun part: if I delete the dosbox.conf and just run with --noprimaryconf, it still works fine 😎 So I'm not runnin setup, just start the game with the exe. I'm not quite sure what was going on before, but let's all test using that ZIP going forward to rule out any random variations.

Even though the game seems to work fine with the stock defaults, restricting the cycles is still a good idea, as always. So I recommend the following minimal config:

[cpu]
core = normal
cycles = 8000

Tested on macOS with 0.81.1 and latest dev build.

Also a pro tip for younger players: always test with --noprimaryconf to rule out any weird changes you might have made to your primary config months ago you've forgotten about. Otherwise it's quite possible to confuse the hell out of yourself 😄

Also, reflecting on @interloper98's below remark:

It absolutely needs the normal core, so perhaps some initial steps on your side got dosbox to use the normal core prior to launching the game.

It's a protected mode game, and it runs with fine on the dynamic core, at least on macOS. But the dynamic core code is different on x86 and ARM (I'm on an ARM M1 Mac), so maybe you've ran into an x86 dynarec bug (or difference; hard to say what is a legitimate CPU emulation "bug").

When the real mode -> protected mode switch happens, the dynamic core will be active with the stock defaults, so it should not matter at all if you run any number of real mode programs before launching a protected mode game.

[interloper98]

@johnnovak - re-tested w/ core = dynamic, and indeed the sound still works. Which is baffling me; because initially I got some pops like @codengine mentioned. I'm not sure what's going on now :-) It appears this game has also thrown me for a loop!

I guess we just need need confirmation from Linux-land that core = dynamic is also OK?

[johnnovak]

@johnnovak - re-tested w/ core = dynamic, and indeed the sound still works. Which is baffling me; because initially I got some pops like @codengine mentioned. I'm not sure what's going on now :-) It appears this game has also thrown me for a loop!

I guess we just need need confirmation from Linux-land that core = dynamic is also OK?

My guess is you need specific settings for the setup utility to do its job correctly, perhaps. Which is super weird if true.

If you have time you could try setting the game up from scratch again using the stock defaults to get the "bad results". Then do a binary compare of the resulting C drive to the known-good state in your ZIP. Maybe the game' setup writes a botched config when the cycles value is "too high" or something. Very unusual if that's the case! 😅

[Python-Exoproject]

Ok so with the information above Ive done some more testing and confirmed the magic dust (at least for my system) is core=normal. Even going back to the eXoDOS files and conf all I need to do is change the core to normal and it works.

[codengine]

I think we all learned something through that game, which is nice! Thanks @ALL!

[Python-Exoproject]

Yeah thanks for all the assist guys, glad to get it resolved - these sorts of issues that only happen for some people really get under my skin :-)