bjt wrote:

I'm pretty sure these issues are timing dependent, as break-pointing the code invariably makes things work properly.

What kind of breakpoint do you mean, DosBox' debugger or on a real machine? Because a debugger on a real machine would have to EOI the Timer Interrupt, otherwise you couldn't use the keyboard in the debugger, and that EOI would then allow IRQ2 to occur as well. DosBox' debugger should not be affected by this at all, because it runs completely outside the emulated machine, if I understand it correctly.

Since the problem occurs with a real MPU-401 as well, just with a lower probability, DosBox might just leave this problem as it is and blame the programmers (and direct players to the GATEFIX utility). Or add a hack just for this one game. The latter could be justified if it doesn't break anything else. Swapping the ACK and version bytes would break any program that reads the version correctly, though not necessarily in a fatal manner. Since the problem seems to be that IRQ2 does not get serviced because IRQ0 is still being serviced, and everything else follows from that, how about the following hack:

1--- mpu401.cpp.old	2012-09-26 11:29:09 +0000
2+++ mpu401.cpp	2014-01-18 14:00:17 +0000
3@@ -210,6 +210,7 @@
4 			QueueByte(0);
5 			return;
6 		case 0xac:	/* Request version */
7+			PIC_WriteCommand(0x20,0x60,1);	// Hack for Frederik Pohl's Gateway
8 			QueueByte(MSG_MPU_ACK);
9 			QueueByte(MPU401_VERSION);
10 			return;

This fixes the second song in all attempts that I have tried, and I could not imagine how this would break any other game or application, which are not insane enough to read the MPU version in the timer handler.

NewRisingSun wrote:

What kind of breakpoint do you mean, DosBox' debugger or on a real machine? Because a debugger on a real machine would have to E […]
Show full quote

bjt wrote:

I'm pretty sure these issues are timing dependent, as break-pointing the code invariably makes things work properly.

What kind of breakpoint do you mean, DosBox' debugger or on a real machine? Because a debugger on a real machine would have to EOI the Timer Interrupt, otherwise you couldn't use the keyboard in the debugger, and that EOI would then allow IRQ2 to occur as well. DosBox' debugger should not be affected by this at all, because it runs completely outside the emulated machine, if I understand it correctly.

Since the problem occurs with a real MPU-401 as well, just with a lower probability, DosBox might just leave this problem as it is and blame the programmers (and direct players to the GATEFIX utility). Or add a hack just for this one game. The latter could be justified if it doesn't break anything else. Swapping the ACK and version bytes would break any program that reads the version correctly, though not necessarily in a fatal manner. Since the problem seems to be that IRQ2 does not get serviced because IRQ0 is still being serviced, and everything else follows from that, how about the following hack:

Copy code to clipboard

1--- mpu401.cpp.old	2012-09-26 11:29:09 +0000
2+++ mpu401.cpp	2014-01-18 14:00:17 +0000
3@@ -210,6 +210,7 @@
4 			QueueByte(0);
5 			return;
6 		case 0xac:	/* Request version */
7+			PIC_WriteCommand(0x20,0x60,1);	// Hack for Frederik Pohl's Gateway
8 			QueueByte(MSG_MPU_ACK);
9 			QueueByte(MPU401_VERSION);
10 			return;

This fixes the second song in all attempts that I have tried, and I could not imagine how this would break any other game or application, which are not insane enough to read the MPU version in the timer handler.

Tried the following code by adding the PIC_WriteCommand(0x20,0x60,1); line with the already there commands and it errored out on me when attempting to build the program in Visual C++ 2008 Express Edition saying it's not a function.

Error message:

11>..\src\hardware\mpu401.cpp(209) : error C3861: 'PIC_WriteCommand': identifier not found

But the gatefix program plays every song/music without issues thanks to ripsaw8080.

Testing this in DOSBox 0.74 with the Roland MT-32 Munt on my desktop PC. Time to test this on my Ultimate DOS PC with SoftMPU that is.

You also need to export PIC_WriteCommand from pic.h and pic.h, of course.

1--- pic.h.old	2013-01-15 12:10:02 +0000
2+++ pic.h	2014-01-18 13:58:32 +0000
3@@ -60,4 +60,5 @@
4 void PIC_RemoveSpecificEvents(PIC_EventHandler handler, Bitu val);
5 
6 void PIC_SetIRQMask(Bitu irq, bool masked);
7+void PIC_WriteCommand(Bitu port,Bitu val,Bitu iolen);
8 #endif]

1--- pic.cpp.old	2013-11-11 22:10:04 +0000
2+++ pic.cpp	2014-01-18 13:59:50 +0000
3@@ -622,3 +622,7 @@
4 	test = new PIC_8259A(sec);
5 	sec->AddDestroyFunction(&PIC_Destroy);
6 }
7+
8+void PIC_WriteCommand(Bitu port,Bitu val,Bitu iolen) {
9+	write_command(port,val,iolen);
10+}

FYI, it's easier to use the generic port write function, and mpu401.cpp already includes inout.h, too.

IO_Write(0x20,0x40);

I'm not crazy about the hack, though, as it opens up the possibility of recursive execution of the timer handler. That may not actually happen, or it may only happen with low cycles, but it's a fact that Gateway is executing a considerable amount of code from its timer handler, and some of it waits for hardware responses.

ripsaw8080 wrote:

IO_Write(0x20,0x40);

IO_Write(0x20,0x60). 0x40 would be "no operation". 😀

ripsaw8080 wrote:

I'm not crazy about the hack, though, as it opens up the possibility of recursive execution of the timer handler.

I cannot disagree with that completely, although bjt reported that the keyboard input potentially locks up on a real system as well, indicating that the game's interrupt handling is not really well-programmed as it is. So the problem you are describing might exist even without the hack.

By the way, is there a way in DosBox' debugger to set an I/O access breakpoint? I've only seen code, memory and interrupt breakpoints in the debugger's help and wondered why there was no I/O variant. (Or is there one and I just don't see it?)

There are no port access breakpoints in the DOSBox debugger, and I don't recall anyone asking about the feature before. Breakpoints for when memory is read, though, that comes up from time to time. I just put in log messages on port read/write functions, and include CS:IP where the access occurred if need be. It can be quite useful to compile your own debugger build for that kind of thing.

NewRisingSun wrote:

You also need to export PIC_WriteCommand from pic.h and pic.h, of course. […]
Show full quote

You also need to export PIC_WriteCommand from pic.h and pic.h, of course.

Copy code to clipboard

1--- pic.h.old	2013-01-15 12:10:02 +0000
2+++ pic.h	2014-01-18 13:58:32 +0000
3@@ -60,4 +60,5 @@
4 void PIC_RemoveSpecificEvents(PIC_EventHandler handler, Bitu val);
5 
6 void PIC_SetIRQMask(Bitu irq, bool masked);
7+void PIC_WriteCommand(Bitu port,Bitu val,Bitu iolen);
8 #endif]

Copy code to clipboard

1--- pic.cpp.old	2013-11-11 22:10:04 +0000
2+++ pic.cpp	2014-01-18 13:59:50 +0000
3@@ -622,3 +622,7 @@
4 	test = new PIC_8259A(sec);
5 	sec->AddDestroyFunction(&PIC_Destroy);
6 }
7+
8+void PIC_WriteCommand(Bitu port,Bitu val,Bitu iolen) {
9+	write_command(port,val,iolen);
10+}

Applied the code, and testing this right now on my desktop with the Roland MT-32 Munt program. The songs are playing perfectly!
Also added the code in the mpu401.cpp file:

1case 0xac:   /* Request version */
2PIC_WriteCommand(0x20,0x60,1);   // Hack for Frederik Pohl's Gateway
3QueueByte(MSG_MPU_ACK);
4QueueByte(MPU401_VERSION);
5return;

I'll attach the files, including the Munt installation file, the MT-32 ROM files, and instructions. Now, if my DOS PC wouldn't have a keyboard lockup, I'll be happy.

DOSBox-SVN-GATE
[fix] Missing music using the Roland MT-32/Munt while playing Frederik Pohl's Gateway

Edit: Click on DOSBox-SVN-GATE.zip > Download for the patched DOSBox.

Edit 2: Version went from 0.741beta to SVN-GATE for less confusion (thanks Stiletto)

Edit 3: Removed the ROM files as requested by Dominus.

Edit 4: All of the files, including the archive file are completely virus-free and have been scanned on a virus-free computer with the best protection against threats on both the desktop and virtual firewall (pfSense with Squid and Dansguardian*)
* checks for viruses when surfing the web, uploading and downloading files on my Desktop, using the virtual firewall as the safe Internet connection (disabled the TCP/IP v4 on my Gigabit NIC w/ TCP/IP v6 enabled for computers with IPv6 enabled to access my desktop).

Edit 5: Changed the code as requested by ripsaw8080.

NewRisingSun wrote:

What kind of breakpoint do you mean, DosBox' debugger or on a real machine?

Real hardware. Surely the debugger could use polling keyboard input?

It could, but that's very unlikely. Which debugger are you using?

bjwil1991 wrote:

Now, if my DOS PC wouldn't have a keyboard lockup, I'll be happy.

Your DOS PC has a keyboard lockup because your Windows PC has a self-compiled DosBox with a hack for Gateway?

ripsaw8080 wrote:

I just put in log messages on port read/write functions, and include CS:IP where the access occurred if need be. It can be quite useful to compile your own debugger build for that kind of thing.

But it's quite a hassle to compile my own debugger build just because I want to quickly find out what a game does to the interrupt controller, which Sound Blaster DSP commands it uses and so on. I had hoped there would be something like a "BPIO 20" or, like BPINT AH, "BPIO 22C 14". If I were to invest the time to add such a feature, do you think it would be accepted into SVN?

NewRisingSun wrote:

bjwil1991 wrote:

Now, if my DOS PC wouldn't have a keyboard lockup, I'll be happy.

Your DOS PC has a keyboard lockup because your Windows PC has a self-compiled DosBox with a hack for Gateway?

When I run the gatefix program made by ripsaw8080, the keyboard doesn't respond, except the num lock, and caps lock keys work, and I have to hard restart the DOS PC mainly because the keyboard locks up when using the program, while the original gate.exe file doesn't cause keyboard lockups.

DOSBox, on the other hand, doesn't cause my keyboard to lockup since I have the autolock set to false. On a real DOS PC, it's the opposite.

bjwil1991 wrote:

Version 0.741beta[/url]
[fix] Missing music using the Roland MT-32/Munt while playing Frederik Pohl's Gateway

Edit: Click on Version 0.741beta for the patched DOSBox.

Please don't number unofficial versions following the official version numbering scheme. People could confuse it as being an official version.

Stiletto wrote:

bjwil1991 wrote:

Version 0.741beta[/url]
[fix] Missing music using the Roland MT-32/Munt while playing Frederik Pohl's Gateway

Edit: Click on Version 0.741beta for the patched DOSBox.

Please don't number unofficial versions following the official version numbering scheme. People could confuse it as being an official version.

Alright. Gonna fix that...

Edit: fixed it (see my post above)

Would introduce some slowness fix the problem ?(e.g wait 1000 instructions before raising irq 2, when asking the version number)

Qbix wrote:

Would introduce some slowness fix the problem ?(e.g wait 1000 instructions before raising irq 2, when asking the version number)

This would be an interesting fix... May I please see the code so that I can compile the program myself and for others, like you guys and fellow DOSBox users to compile the program as well?

Nope, delaying won't change the fact that IRQ2 can't fire because IRQ0 is in service. It's certainly a game bug to rely on an MPU IRQ in code that runs from the IRQ0 handler; however, the code path that leads to the condition doesn't always occur, and appears to depend on timing factors.

The idea was that the irq 0 would be finished because of the delay.

The test that reads the MPU version will have long since failed by then.