That certainly fixes the crash, though maybe there should be some logic
in the pause code that avoids the transition to MODE_DMA_PAUSE if there
is nothing playing.

I'm no expert on SB emulation (in fact I know next to nothing about SB emulation), but I'm inclined to assume you're right. I've made and tested another patch, which also works for this particular program:

v0.74, sblaster.cpp
function DSP_DoCommand(), line 900:

===ORIGINAL===
case 0xd0: /* Halt 8-bit DMA */
// DSP_ChangeMode(MODE_NONE);
// Games sometimes already program a new dma before stopping, gives noise
sb.mode=MODE_DMA_PAUSE;
PIC_RemoveEvents(END_DMA_Event);
break;

===PATCHED===
case 0xd0: /* Halt 8-bit DMA */
// DSP_ChangeMode(MODE_NONE);
// Games sometimes already program a new dma before stopping, gives noise
if (sb.mode == MODE_DMA || sb.mode == MODE_DMA_MASKED) {
sb.mode=MODE_DMA_PAUSE;
PIC_RemoveEvents(END_DMA_Event);
}
break;

It's possible that only one, or neither, of the modes I'm testing for is the 'correct' one from which one could go to the PAUSE state. I don't know enough about the SB core to make an informed call; this is just what seemed reasonable to me though I'm sure someone on the dev team knows the right setup.

Still... I'm willing to bet there is at least one buggy SB script out there that relies on being able to switch from <random> to paused?

I'd use sb.mode!=MODE_NONE for that, but not sure in what state the soundblaster
or the emulation should be if there's a "pause" then "continue" call when there's been
no previous playing. Maybe this was/can be used as sort of initialization, though in the
current code it would definitely be broken. Harekiet may know.

Thanks for the details on this.

Hi! Few months ago I tried to run a newer version of DOS Game Wizard (2.80 I think, can't remember exactly, I got the last GW version) and it crashed to me too. So, I'm very interested in this fix, will this be incorporated to the next version of Dosbox 0.75?

Probably yes.

Thanks wd. When aprox we will have Dosbox next version (0.75)?

No idea, if you can compile dosbox from sources you can apply either patch.

You also might try contacting one of the enhanced SVN build maintainers and seeing if they might be interested in incorporating this patch into their build(s).

Please, add this fix to the new Dosbox version incoming...

There is no incoming dosbox version.

jomalin, you really need to learn patience. And you really need to learn to read.
wd already responded that it is likely that this patch makes it into the next version of DOSBox. Everything said about it.
Bumping threads in this way is not welcomed...

If you don't want to set up the build environment and do it yourself, I can send you the binary I created (assuming you trust it and if you don't mind not having the optional features).

As we can see in DosBox changelog:
http://source.dosbox.com/dosboxsvn.txt

Now it seems that this fix will be integrated into the next DosBox version:

2011-04-19 19:46 c2woody

* [r3696] src/hardware/sblaster.cpp: fix sb halt/continue sequence
when no transfer in progress (thanks to tcostin, fixes some
GameWizard crash)

Thanks tcostin and c2woody

Looks like both the EmuCR vanilla and Ykhwong enhanced SVN builds should have that fix already included now too, as the latest builds of each at the time of this post are based on SVN r3706 and r3704 respectively.

and the reason why GW 2.20 hangs in DOSBox is because of a bug in GW. It has a protection layer but someone forgot to encrypt a section of the file, so when it gets "decrypted", it actually gets encrypted and can't run.

That usually happens if you didn't install the application in dosbox.

In this case, it's just a plain .zip with no installer. Both executables inside the archive are damaged like that. Part of it is encrypted and part of it isn't.

I don't know what zip you have and where this is from, but the regular version
comes with a full installer that cross-crypts parts according to bios data and thus
only runs on the respective PC/dosbox installation.