Yep, tried that already. The real MPU returns ACK followed by version.

I also tried changing MPU401_TIMECONSTANT in SoftMPU so the whole of the first song plays before fade out, but the second song still doesn't play.

I may be able to set up a remote debug session with 386SWAT on the real hardware. Ripsaw, any pointers on finding the subroutine so I can breakpoint it?

I don't know if there are others, but the version of Gateway that I have is from The Lost Adventures of Legend collection. The subroutine starts at offset 0x4F01 in GATE.RTL, and a breakpoint on INT 21h AH=25h AL=(IRQ+8) can find it.

Here's ripsaw's specific fix for Legend's Gateway:

1--- src/hardware/mpu401_orig.cpp	2014-01-07 14:27:05 -0500
2+++ src/hardware/mpu401.cpp	2014-01-07 14:30:58 -0500
3@@ -210,8 +210,8 @@ static void MPU401_WriteCommand(Bitu por
4 			QueueByte(0);
5 			return;
6 		case 0xac:	/* Request version */
7-			QueueByte(MSG_MPU_ACK);
8 			QueueByte(MPU401_VERSION);
9+			QueueByte(MSG_MPU_ACK);
10 			return;
11 		case 0xad:	/* Request revision */
12 			QueueByte(MSG_MPU_ACK);

I tried to condition the fix on a dosbox.conf variable, but it would require knowledge of the whole code base. Given Gateway plays music correctly with Soundblaster, then perhaps the above patch could be specifically employed where choosing the MPU-401 option. I haven't tested the AdLib music option.

Edit: Munt's MT32 emulation is not a certain solution to running MIDI for this game; suggest using Soundblaster or the above workaround in dosbox code.

I've never really considered that a fix for the issue. It's a game-specific workaround at best.

The 0.74 build with integrated MUNT that I have exhibits the issue, so if a more recent build you've made is working then that could be interesting. Did you choose the single-, sync-, or async- threaded build?

I chose the single threaded option and uploaded a build here: www.vogons.org/viewtopic.php?f=29&t=37138#p336237. I tried it 2x and it seemed to work for me.

Your SVN build with integrated MUNT appears to have the same issue: the the first song fades out after about 2 minutes 15 seconds and no other songs start playing.

The MT-32 emulation should be fairly passive, without much feedback into DOSBox's workings. If subsequent songs are playing for you but not for me, that would be very curious, and I'd have to wonder if config, control ROM, or host factors could cause that.

I initially couldn't work MT32 mode either (tried several times). In fact, I was able to run mididevice=win32 mode yesterday, but couldn't reproduce it afterwards.

It turns out the factor wasn't MT32 (which did seem odd), it was the mouse. 😀 If the mouse is initially captured by the GATEWAY dosbox window (clicking in the window), and then never activated again (no mouse movement nor clicking), then the music will usually play normally in either MT32 (or even win32) mode in-game. I also verified the mouse isn't active by typing commands in the GATEWAY game window (ie, Look, Wait, Activate) and kept focus active on the dosbox window.

Edit: this result is difficult to reproduce, but best bet is the dosbox+mt32 executable and a new installation of GATEWAY. I tried switching off to another dosbox(+patches) version which caused problems (I wonder if RESTART.DAT is storing any prior information).

Edit3: mt32 mode is more reliable that win32 mode and it possibly win32 mode is changing restart.dat (and causing the 2nd song to subsequently fail somehow).

It also seems to help to set autolock=false in dosbox.conf. And running the game like so: gate mt32 2

I think we have a solution that works! It is "autolock=false". This enables MIDI playback in both win32 and mt32 modes, regardless of dosbox version.

Edit: above is not reproducible in other systems and not useful toward a solution.

so maybe an irq related problem. As that is the only thing that autolock can influence.

My analysis is that the issue is indeed related to IRQs, but it may be a matter of what conditions lead to the "play next song" routine being called from within the timer handler rather than being called outside the timer handler as it is for the first song.

Autolock makes no difference here. I've put in logging for when the PIC declines to activate IRQ 2 because IRQ 0 is active, and so far the issue has occured every time.

That's a shame. I tested the autolock/false about 4x, in a sequence of runs, but apparently these successes are not very reproducible (and therefore not useful). It's difficult to know which other factor in my system is allowing MIDI to work (at least on a few runs), but the autolock and mouse must be indirectly affecting the cause of the MIDI issue (related to IRQ 0). I'll edit the prior posts to reflect this and to suggest music via Soundblaster or a build with the workaround in dosbox code. 😀

OK, got the debugger running on a second VGA in my DOS machine.

The IRQ 2 handler writes 0001h at 949h in the current segment. After the ISR returns the code will bail out if 949h is 0000h.
If it does find 0001h, it reads the buffer and decrements 949h.

In the error case, 949h is always 0000h. So either IRQ 2 doesn't fire, or it does but something else consumes the buffer before we check 949h.

There's definitely a race condition as if I breakpoint the subroutine anywhere before interrupts are re-enabled, everything works as expected. Yes, it's a heisenbug 😈

Do you know a good way to check whether we're inside the timer ISR? The debugger says no interrupts are in service but I don't trust it 100%. If you step out of the subroutine do you eventually get to an IRET?

I think you mean 494h, and that word value is the "number of bytes in buffer".

The IRQ 2 handler calls the "write byte to buffer" subroutine, and it will only call it for one byte of available data.

The "write byte to buffer" subroutine increments 494h each time it is called.

The subroutine that writes the version command with interrupts disabled calls the "write byte to buffer" subroutine for each byte of data it reads until it reads an ACK.

When the version number is checked there is an error condition if 494h is zero because it indicates the buffer is empty.

I don't know about other environments, but in DOSBox the thing that prevents the IRQ 2 handler from executing is the PIT declining to activate IRQ 2 because IRQ 0 is active. I can see this happening easily because I put a log message in DOSBox's PIT code for the specific condition, and that message appears right after I step the POPF that enables interrupts.

You can tell if the subroutine has been called from the IRQ 0 handler by stepping out. It's several levels down in the call stack, but you'll eventually get back to the IRQ 0 handler and its EOI and IRET. Also, if you look at the stack you will see the IRQ 0 handler's return IP of 00C7h followed by the CS.

truth5678 wrote:

Here's ripsaw's specific fix for Legend's Gateway: […]
Show full quote

Here's ripsaw's specific fix for Legend's Gateway:

Copy code to clipboard

1--- src/hardware/mpu401_orig.cpp	2014-01-07 14:27:05 -0500
2+++ src/hardware/mpu401.cpp	2014-01-07 14:30:58 -0500
3@@ -210,8 +210,8 @@ static void MPU401_WriteCommand(Bitu por
4 			QueueByte(0);
5 			return;
6 		case 0xac:	/* Request version */
7-			QueueByte(MSG_MPU_ACK);
8 			QueueByte(MPU401_VERSION);
9+			QueueByte(MSG_MPU_ACK);
10 			return;
11 		case 0xad:	/* Request revision */
12 			QueueByte(MSG_MPU_ACK);

I tried to condition the fix on a dosbox.conf variable, but it would require knowledge of the whole code base. Given Gateway plays music correctly with Soundblaster, then perhaps the above patch could be specifically employed where choosing the MPU-401 option. I haven't tested the AdLib music option.

Edit: Munt's MT32 emulation is not a certain solution to running MIDI for this game; suggest using Soundblaster or the above workaround in dosbox code.

I made a patch file called gate.diff with the lines of code, tried to patch the dosbox.exe file, and it gives me this error:

1C:\Users\Ben\Desktop\GetGnuWin32\bin>patch -p0 < gate.diff dosbox2.exe
2patching file dosbox2.exe
3patch: **** malformed patch at line 11:         case 0xad: /* Request revision *
4/
5
6
7C:\Users\Ben\Desktop\GetGnuWin32\bin>

:::NOTE:::
dosbox2.exe is the copy of the file for testing purposes.

You use diff files to patch the source of Dosbox and from that patched source you compile Dosbox. It's not meant to patch the binary

Welp, I'm doing my best to compile the DOSBox program, but when I run the autogen.sh, it says:

1Ben@W8PRO-PC /dosbox-0.74
2$ ./autogen.sh
3Generating build information using aclocal, autoheader, automake and autoconf
4This may take a while ...
5./autogen.sh: line 8: aclocal: command not found
6./autogen.sh: line 9: autoheader: command not found
7./autogen.sh: line 10: automake: command not found
8./autogen.sh: line 11: autoconf: command not found
9Now you are ready to run ./configure.
10You can also run ./configure --help for extra features to enable/disable

running the ./configure file:

1Ben@W8Pro-PC /dosbox-0.74
2$ ./configure
3checking build system type... i686-pc-mingw32
4checking host system type... i686-pc-mingw32
5checking for a BSD-compatible install... /bin/install -c
6checking whether build environment is sane... yes
7checking for a thread-safe mkdir -p... /bin/mkdir -p
8checking for gawk... gawk
9checking whether make sets $(MAKE)... yes
10checking whether make sets $(MAKE)... (cached) yes
11checking for gcc... gcc
12checking whether the C compiler works... no
13configure: error: in '/dosbox-0.74':
14configure: error: C compiler cannot create executables
15See 'config.log' for more details

I have the latest G++ and GCC (might be the issue...)

You need autoconf and automake

Got those in the dosbox source folder along with the version numbers, and the autogen.sh file gives minimal errors, but requires the others to be in the same directory, and 2 m4 files are missing while the others are copied over to the /bin directory (where the m4.exe command resides); I did install the older versions of GCC and G++ 4.5.2 (conflict messages popped up, but I deleted the conflicting files and all is well).

The configure file still gives me the same error... Getting kind of close here. Once I figure out the problem and fix it, then I might as well have you, and the rest of the DOSBox team, including bjt and myself beta test the dosbox program with the patch in place. Question: do I put the patch file in the DOSbox-0.74 folder or in the src folder within the dosbox-0.74 folder?

It doesn't matter where the diff is located. You just point at it and at the source with the patch command.
However you are compiling Dosbox is not relevant to the thread, so I suggest making a new topic with your compile problems (and in there be more descriptive on how you are doing it).

I'm planning to spend some more time debugging this, I just haven't had a chance yet 😒