Can't you just leave it so people have a reason to get the real thing 🤣

Mau1wurf1977 wrote:

Can't you just leave it so people have a reason to get the real thing 🤣

the real thing tends to be expensive and rare, alternatives are always welcomed 😊

Edit: program to provide "Gateway workaround" is available below this post. Therefore, no further reason to provide a dosbox binary because the former is a much better solution.

Until a real solution is found for the problem, the attached program will work around it, and no special build of DOSBox is required. Put the program in the game directory and run it instead of GATE.EXE to start the game. Specify any parameters for Gateway on the program's command line, and please note that it's pointless if you don't include the "MT32" parameter. The workaround appears to be effective in Gateway versions 1.0.0 and 1.1.0 (as reported by the in-game "version" command) in official DOSBox 0.74 and SVN. It will probably work for any other versions of the game if they aren't too dissimilar to the tested versions, but I don't know if it will be effective for SoftMPU. Assembler source is included with the program.

Yep that works under real DOS/SoftMPU too.

Sad to say, I will probably implement a similar workaround in SoftMPU (I already turn features on/off based on which game is running). I can't see myself getting the time to properly debug this anytime soon.

bjt wrote:

Yep that works under real DOS/SoftMPU too.

Sad to say, I will probably implement a similar workaround in SoftMPU (I already turn features on/off based on which game is running). I can't see myself getting the time to properly debug this anytime soon.

I, myself, am making a bug fix by applying the patch file I made on page 2 of this thread, but the patch.exe file hates the line of code.
I recently installed another program called TortoiseUDiff (part of tortoiseSVN) and I might as well check to see if the patch file I made will, in fact, work with the program by applying it to the newly created dosbox.exe file with Visual C++ 2008 Express Edition, and I'll post back to see if the fix works. If it does, I'll send you the program on here and you can test it yourself and you can use the code for that in your SoftMPU program.

So, everyone, brace yourselves, and happy beta testing.
-bjwil1991

Not sure if I misunderstood you but FIRST apply the patch to the source and then built a dosbox.exe.
You can also apply a patch manually by editing the source files referenced in the patch and deleting the lines with a - and adding those with a +... 😉

bjwil1991 wrote:

I recently installed another program called Tortoise UDiff...

So, everyone, brace yourselves, and happy beta testing.

Dominus wrote:

Not sure if I misunderstood you but FIRST apply the patch to the source and then built a dosbox.exe.
You can also apply a patch manually by editing the source files referenced in the patch and deleting the lines with a - and adding those with a +... 😉

I tried to apply the patch file with TortoiseSVN (TortoiseMerge) by right-clicking on the patch file, and when I selected the directory, this error popped-up:

1'C:\Development\dosbox-0.74\src\hardware' is not a working copy

bjwil1991 wrote:

I tried to apply the patch file with TortoiseSVN (TortoiseMerge) by right-clicking on the patch file

This feels like part of the problem. Do you lack a familiarity with command-line?

Anyhow, as he said, it's only like a two-line patch (open it in your favorite text editor, you'll see it's human-readable), you can always apply it manually. Remove that line, replace this line.

The other Legend games suffer from this problem too? Just wondering.

bloodbat wrote:

The other Legend games suffer from this problem too? Just wondering.

Gateway II: Homeworld plays all of the music without issues. Only the first one does. If you have a 100% Roland MPU-401 compatible card* or an actual Roland MPU-401 card in your old PC, the music would play normally in every Legend Entertainment game.

*Midiman MM 401 has issues with Legend Entertainment Frederik Pohl's Gateway (like DOSBox and SoftMPU made by bjt)

bjwil1991 wrote:

bloodbat wrote:

The other Legend games suffer from this problem too? Just wondering.

Gateway II: Homeworld plays all of the music without issues. Only the first one does. If you have a 100% Roland MPU-401 compatible card* or an actual Roland MPU-401 card in your old PC, the music would play normally in every Legend Entertainment game.

*Midiman MM 401 has issues with Legend Entertainment Frederik Pohl's Gateway (like DOSBox and SoftMPU made by bjt)

I'll rephrase it: do the other Legend games suffer the same problem under DosBox using Munt?

bloodbat wrote:

bjwil1991 wrote:

bloodbat wrote:

The other Legend games suffer from this problem too? Just wondering.

Gateway II: Homeworld plays all of the music without issues. Only the first one does. If you have a 100% Roland MPU-401 compatible card* or an actual Roland MPU-401 card in your old PC, the music would play normally in every Legend Entertainment game.

*Midiman MM 401 has issues with Legend Entertainment Frederik Pohl's Gateway (like DOSBox and SoftMPU made by bjt)

I'll rephrase it: do the other Legend games suffer the same problem under DosBox using Munt?

I might as well test all of the games to see whether or not they work. If they do, then DosBox with Munt is 100% working. I'll post back details using the following categories:

11. Computer Game Name
22. Missing Music (Y/N)
33. If Yes, symptoms will be posted (ex: where the music is missing after the first set)
44. If No, then the game is 100% compatible with both DosBox with Munt and SoftMPU (made by bjt with the help of the DosBox team)

I just tried the game on a real DOS machine with a Roland SCC-1, which has a real Roland MPU-401 interface. The second song fails to play if I keep the first room description at "MORE" waiting for a keypress. Running the game again but this time immediately pressing a key to finish the message and allowing the prompt to appear resulted in the second song playing once the first song finished.

From looking at my own disassembly as well as ripsaw's description of the problematic code sequence, it seems that this is one of those "how did this ever work at all?" situations.

NewRisingSun wrote:

I just tried the game on a real DOS machine with a Roland SCC-1, which has a real Roland MPU-401 interface. The second song fails to play if I keep the first room description at "MORE" waiting for a keypress. Running the game again but this time immediately pressing a key to finish the message and allowing the prompt to appear resulted in the second song playing once the first song finished.

From looking at my own disassembly as well as ripsaw's description of the problematic code sequence, it seems that this is one of those "how did this ever work at all?" situations.

I had a similar problem of It Came from the Desert not working with a true Roland MPU-401 box on my 486, but I believe SoftMPU allowed it to work. I don't recall it sparking my interest to any great extent because I believe that Cinemaware games should be played on an Amiga and not on second rate ports for the PC.

Gateway's music code does seem extremely brittle. For example, if the game fails to get the MPU version at the end if a song, it will leave the MPU IRQ masked. This has predictably fatal results on an AT machine where PS/2 mouse, IDE etc. are cascaded.

I've also had keyboard input lock up at the end of a song when using an MPU-IPC-T.

I'm pretty sure these issues are timing dependent, as break-pointing the code invariably makes things work properly. The issue seems to be how the timer handler interacts with the main game loop. Machine speed may be a factor.

Having done some more experiments with the Roland SCC-1, I find that there can be situations in which not all commands are properly ACK'd. For example, sending FF to reset but then immediately sending AC yields only one ACK byte on the real MPU-401 but two in DosBox. (DosBox also incorrectly ACKs reset when returning from UART mode, because the "do not send ack in UART mode" code checks for UART mode after it has already been cleared by MPU401_Reset().)

I have attached a few self-written programs that check the ACK behavior in various contrived situations. Source is included so I won't have to explain in detail what each program does. RACE1/RACE2 check how many bytes are returned when writing command "get version" directly after "reset" without waiting, RACE1A/RACE2A the same but with waiting between the two commands. RACE1/RACE1A poll the MPU while RACE2/RACE2A use an interrupt service routine. UARTACK and UARTVER check the behavior from/in UART mode.
Here is the DOALL's output from the Roland SCC-1 with a real MPU-401:

1race1
2FE 15
3race1a
4FE FE 15
5race2
6FE 15
7race2a
8FE FE 15
9uartack
10Correct! A real MPU-401 does not ACK reset after UART.
11uartver
12Correct! A real MPU-401 does not return version in UART mode.

And here is DosBox' output:

1race1
2FE FE 15
3race1a
4FE FE 15
5race2
6FE 15
7race2a
8FE 15
9uartack
10Wrong! A real MPU-401 does not ACK reset after UART.
11uartver
12Wrong! A real MPU-401 does not return version in UART mode.

I'm not saying that this is necessarily the reason for Gateway's problems (given that it sometimes fails with a real interface as well), but it does show that DosBox does not behave like a real MPU-401 in some (arguably contrived) situations.

I find the same code to get the MPU version in other Legend games, but so far I've only seen the sequential playing of separate songs in Gateway. For example, the first in-game song in Eric The Unready just loops endlessly (not restarting, looping). Anyone know if the other Legend games play songs sequentially?

I have to wonder what the Legend developers were trying to accomplish with this roundabout way of reading the MPU version. It can be done easily without relying on a hardware interrupt. Nothing is actually done with the version number, so it's like the subroutine in question is just a test for MPU-401 compatibility.

BTW, I've coded the "no reset ACK when returning from UART mode" behavior to test with, but I've not seen any game case where it makes a difference, including Gateway. The code if anyone is interested in testing results:

1         case 0xff:    /* Reset MPU-401 */
2+            {
3             LOG(LOG_MISC,LOG_NORMAL)("MPU-401:Reset %X",val);
4             PIC_AddEvent(MPU401_ResetDone,MPU401_RESETBUSY);
5             mpu.state.reset=true;
6+            MpuMode old_mode=mpu.mode;
7             MPU401_Reset();
8-            if (mpu.mode==M_UART) return;//do not send ack in UART mode
9+            if (old_mode==M_UART || mpu.mode==M_UART) return; //do not send ack in (or returning from) UART mode
10+            }
11             break;

Will there be similar issues later in the game? Not just at the beginning? A pain to test this...