What's your DOSBox version?

0.72, gulikoza build because of ATI

Maybe just get the cycles correct, instead of doing interesting assumptions
about the ems specs.
And when reporting things ALWAYS use the official dosbox releases.

Hi again,
I think there is nothing to do with cycles. Both scenarios work with same cycle settings. I don't think the build metters. Gulikoza's build has some patches for the graphics. The dosbox core should be the same. Trying to install Gravis Ultrasound Mega-Em in dosbox also complains about insufficient EMS support but not Dos 6.22. Also it's known that 1942 PAW uses quite a lot EMS for sound and there are the problems. Plain Dos 6.22 uses himem.sys with emm386. I don't know where are the problems, in which memory manager, but I think the dosbox EMS is not equal to EMM386 (LIM 4.0).
But of cource the solution with DOS 6.22 loaded from dosbox is perfect for me. By the way that's the first working solution in this case (1942 PAW digital sound). VDMSound didn't work either.

I think there is nothing to do with cycles.

Thinking!=knowing.

I don't think the build metters

Then there's no problem in using the official build when reporting stuff, right?

Trying to install Gravis Ultrasound Mega-Em in dosbox also complains about insufficient EMS support

That's a completely different issue and interesting enough has NOTHING
to do with EMS.

I think the dosbox EMS is not equal to EMM386 (LIM 4.0).

It's equal.

The game works perfectly fine with full, non-stuttering sound btw.,
default settings except for core=dynamic and cycles=10000 but that
might be different on your system of course.

Tried again with the official 0.72 release from the official dosbox site.
Default config, cycles 10000. Same cracking sound. Not the music, the digital sound. The tests in the install utility went ok. But I'm talking about the digital sound during the game. But from Your posts is evident You arn't that expert I'm looking for. So the discussion is useless. Sorry!

wd is one of the principal developers of DOSBox. You won't get anybody more expert than him. And, of course, he's right. Your problem doesn't sound like it has anything to do with EMS (especially the Mega-Em thing).

Sound breaking up is almost always caused by an incorrect cycles setting. Try adjusting the cycles and core to decrease CPU utilisation to allow for better sound processing. I've also found that playing around with DOSBox' mixer settings can help in this case. On my system, the I get excellent results with the values "rate=44100", "blocksize=4096", "prebuffer=20".

Sorry for my remarks about the competnce of wd. But felt his answers little bit arogant. Forget it. An attachmet shows the problem with mega-em.
It's memory menager problem. There is no such problems under plain DOS. In order to solve the sound problem I'v tried many times many adjustments. It is specific for this game: Microprose 1942: Pacific Air War. Try Yourself to play the game with digital sound enable with PCI card like SB Live! and You will see. The same was with VDMSound. Only plain dos worked fine, but plain DOS is not an option for me for many reasons. Any way I found Dosbox wonderfull. Keep going on. I also have a solution within the dosbox framework: booting the plane DOS disk image within dosbox. Only was interested to know what is the difference cousing that problems in this game. Thanks

When wd writes

That's a completely different issue and interesting enough has NOTHING to do with EMS.

you can believe him.

MegaEM relies on specific behaviour of emm386 (which is definitely not
in the LIM/EMS specs) that is connected to the v86 code. As dosbox does
not emulate emm386 but a real ems card (thus being able to stay in real
mode and not introduce all the crappiness of emm386 due to v86 mode),
MegaEM does not work "out of the box".

As Kippesoep noted, raising the buffer size and prebuffer amount is helpful
when the sound skips. But even without those settings the sound is clear
without any crackling and noise as you describe.

Come on wd, regardless of emm386 being crappy, it was the standard and most widely used and its behavior imitated by other memory managers so things work, not real ems cards only used on early systems like xt and at. It would seem to me to be in keeping with the goals of DOSBOX to mimic em386 like the alternative memory managers did for compatibility.

EMM386 was emulating EMS using the 386 processor's ability to remap memory. EMS cards really provided it, independent of XMS memory. That is the better way, as EMM386 had to run the processor in Virtual 8086 (v86) mode. In v86 mode, closely related to protected mode, there were some limitations on what a program can do, which means that there's quite a few programs that can't run with EMM386 loaded. In DOSBox, this is no problem, not to mention it is more efficient. The problem for Mega-Em not running is because of one of the side effects of EMM386: it also provides a VCPI interface. This is what the error message notes (and the note below: "compliant with LIM EMS 4.0 and VCPI.". VCPI is an alternative (actually more like predecessor) of DPMI, allowing DOS/real mode programs to access certain features of protected mode. So, this has absolutely nothing to do with EMS. I seem to recall DOSBox at one point provided VCPI and DPMI hosts, but this may have been removed for a reason I'm not familiar with. DPMI is commonly provided by programs such as CWSDPMI.EXE. I'm not aware of any such program for VCPI, but that is the part you should be looking for (or, if you're feeling adventurous, creating).

BTW, the reason Mega-Em needed VCPI was that it could intercept programs that wrote to certain hardware ports so that it could get those values (meant for an MT-32), do its magic and send them on to the Gravis UltraSound. This interception was not possible (or at least feasible) in real mode, as far as I know, but it is possible in protected mode. That is what the VCPI was used for, not for its memory management.

Lastly, I see no reason to run Mega-Em inside DOSBox. DOSBox is quite capable of taking the real MIDI output meant for the MT-32 and passing it on to Windows. If you install the MT-32 emulator in Windows, you get better compatibility (more authentic sound and reliability) than with Mega-Em.

dosbox provides vcpi but isn't in v86 mode. This probably confuses mega-em.
vcpi is for example used by origin games.

Whatever the shortfalls are, my argument is implement for the sake of compatibility, which is the often given reason for doing and not doing things in regards to coding DOSBOX, and if that means implementing some ugly thing emm386 does, so be it. As for mega-em, the reason is to get GUS playback for non GUS supported games, which some people prefer depending on the game.

and if that means implementing some ugly thing emm386 does, so be it

There surely won't be any attempt to blindly code something (there is not
a single proof up to now that the problem the poster has is faintly connected
to the ems implementation, and even if so that imitating some exact emm386
codebytes (which?) would fix it).

dosbox provides vcpi but isn't in v86 mode. This probably confuses mega-em.

Actually vcpi isn't visible for all games/apps except for jemm games,
so this is no issue (you have to enable the dosbox-internal vcpi host which
in turn enables v86 mode as a first step to getting megaem to work).

wd wrote:

Actually vcpi isn't visible for all games/apps except for jemm games, so this is no issue (you have to enable the dosbox-interna […]
Show full quote

dosbox provides vcpi but isn't in v86 mode. This probably confuses mega-em.

Actually vcpi isn't visible for all games/apps except for jemm games,
so this is no issue (you have to enable the dosbox-internal vcpi host which
in turn enables v86 mode as a first step to getting megaem to work).

Yeah you are right. I forgot about that check that was added

I'm not saying don't figure out what's missing between the current handling and emm386, just that whatever it is, whether it's a more complete VCPI handling or something else, if it makes programs happy,..