Did you check the interrupt mask in the PIC at that point ?

After the first song stops playing, the game tries twice to get the MPU version with command 0xAC, and then seems to give up. Both attempts are framed by reset commands, and the curious thing is that it only reads *one* data byte after writing the version command, so it's only seeing the ACK that comes before the version data byte. I tried removing the ACK before the version data byte in command 0xAC, and sure enough the game starts playing additional songs. Going further, I changed the version command to queue an ACK *after* the version data byte, and the game then reads both the version data byte and the ACK before starting the next song.

does this mean that the Gateway game that we considered to be a "true intelligent mode mpu test" is just bad written?

Nothing is conclusive at this point. Need to check with MPU documentation (and Srecko, if he's around) regarding the order of data and ACK.

Edit:
The MPU-401 Technical Reference Manual doesn't specifically mention ACKs in regard to the commands that return a data byte, but a code example makes it clear that an ACK should precede the data.

The code in Gateway appears to contradict the techref's example because it stops reading data into its buffer when an ACK is read, and if no data was read for the version command then the resulting error condition prevents further playing.

There is an article here that describes problems between the Midiman MM-401 and the Legend Entertainment games (like Gateway): http://nerdlypleasures.blogspot.com/2010/03/t … land-mt-32.html. Other posts suggest that the Legend games are using MPU commands not widely used.

Also, a post about timing issues in Legend games: MT-32 and Legend games (Gateway, etc.) ; and the ability to change the IRQ like so: gate mt32 5

Perhaps MUNT would help debug, too?

keropi wrote:

does this mean that the Gateway game that we considered to be a "true intelligent mode mpu test" is just bad written?

Badly written by not taking future DOS emulators in mind, maybe 😀

It does work on the real thing, so it likely does something that is rare and hasn't been implemented / catered for in DOSBox.

Mau1wurf1977 wrote:

keropi wrote:

does this mean that the Gateway game that we considered to be a "true intelligent mode mpu test" is just bad written?

Badly written by not taking future DOS emulators in mind, maybe 😀

It does work on the real thing, so it likely does something that is rare and hasn't been implemented / catered for in DOSBox.

I don't know, wasn't Gateway a game I tried once on a MM401 and it failed? Along with Laser Squad that led to the ACPI problem that you have experienced as well?
The fact that it happens to work on a roland mpu doesn't necessarily mean that it's written OK... if you look at ripsaw8080's edited post you'll see that Gateway does at least one thing that it shouldn't do... with all the driver mess (tilakat's patches if you remember is a good example, sure games "worked" before the patched drivers, but did they REALLY work as they should? nope...) it's not really a surprise if Gateway just works because of voodoo 🤣 🤣 🤣

ripsaw8080 wrote:

The code in Gateway appears to contradict the techref's example because it stops reading data into its buffer when an ACK is read, and if no data was read for the version command then the resulting error condition prevents further playing.

Thanks for looking into this. I've tested it on a Roland MPU-IPC-T and can confirm that commands A0h to AFh return ACK followed by data, so it's interesting that the same behaviour in DOSBox causes an error condition.

Changing the version command to return the version first fixes the music under SoftMPU too.

On real hardware, some other code must be clearing the ACK first.

Srecko posted: http://sourceforge.net/p/dosbox/patches/42/ ; "I still have to look at "legend entertainment" games which send undocumented commands and data strings to mpu-401". The other thread at vogons mentions status bit6 always 0, indicating "ready to receive data"; could the driver expect bit6=1 during the ack?

bjt wrote:

On real hardware, some other code must be clearing the ACK first.

AFAICT, the only thing that might intervene between writing the command and reading the ACK is an interrupt, but there is a CLI instruction explicitly preventing that.

On the other hand, I've only looked at the issue under a microscope, so to speak, I haven't really looked at the bigger picture. It's possible that the code path never reaches the problem area on a real MPU-401, for some reason...

keropi wrote:

I don't know, wasn't Gateway a game I tried once on a MM401 and it failed? Along with Laser Squad that led to the ACPI problem that you have experienced as well?
The fact that it happens to work on a roland mpu doesn't necessarily mean that it's written OK... if you look at ripsaw8080's edited post you'll see that Gateway does at least one thing that it shouldn't do... with all the driver mess (tilakat's patches if you remember is a good example, sure games "worked" before the patched drivers, but did they REALLY work as they should? nope...) it's not really a surprise if Gateway just works because of voodoo 🤣 🤣 🤣

It's a game to test full Roland MPU401 compatibility. MM401 isn't fully compatible either. It's a handful of games though 😀

Ideally they would have just programmed for UART MPU, so yes, in that sense it could have been programmed much better!

The code I was looking at before is part of a subroutine called to start playing a song. The subroutine does this:

1) set up an IRQ 2 handler that reads any available data into a buffer
2) unmask IRQ 2 on the PIC
3) disable interrupts
4) write the "get version" command
5) read any available data into the buffer until an ACK is read
6) enable interrupts
7) check the version that was read

It seems that step 5 is intended to read the ACK, and the fact that it reads any data leading up to the ACK is not significant because there is no data there under normal conditions. The version data is read by the IRQ handler, with the IRQ firing after step 6 and before step 7.

IRQ 2 fires for the first song, but not for subsequent songs, and the difference is that the subroutine is called from the timer (IRQ 0) handler for the subsequent songs. It makes sense to have the timer handler notice that playing has stopped and then start the next song; however, IRQ 2 cannot fire because IRQ 0 is still active... or is there some way that it can? The MPU in DOSBox actually uses IRQ 9, so I wonder if the cascade between IRQ 9 and 2 is involved.

Mau1wurf1977 wrote:

It's a game to test full Roland MPU401 compatibility. MM401 isn't fully compatible either. It's a handful of games though 😀

So all this trash talking of the MM401 being "buggy" in other posts wasn't correct, it is the Legend games that are at fault?

@ripsaw: The IRQ 2 ISR could only interrupt the timer handler under the following conditions:

- EOI has already been sent to the primary PIC
- Neither IRQ 0 or 1 have been raised (or they are masked)

Does the subroutine allow any time for IRQ 2 to fire or does it check the buffer right after issuing STI?

On real hardware IRQ 2 would be raised by the MPU when the version command completes, and the ISR would run on STI (as long as the conditions above were met).

Perhaps the interrupt fires too late under DOSBox... I use the Sound Blaster DSP to generate a HW interrupt which probably takes some time too.

EDIT: IA-32 manuals have the following to say about STI:

After the IF flag is set, the processor begins responding to external, maskable interrupts after the next instruction is executed.

So I wasn't quite correct earlier, the IRQ 2 ISR would trigger after the instruction following the STI.

vetz wrote:

Mau1wurf1977 wrote:

So all this trash talking of the MM401 being "buggy" in other posts wasn't correct, it is the Legend games that are at fault?

No the MM401 struggles with other games as well 😀 Legend games being the best ones. The other games that struggle with the MM401 I find rather boring.

There seems to be two threads running in one here...

@bjt: There are several instructions after interrupts are enabled (a POPF in this case) and before the version data is checked. This is enough for the MPU IRQ to fire and the data to be read, but it only fires for the first song where the subroutine is NOT called from the IRQ 0 handler. IRQ 0 is in service and EOI has not been signaled on the PIC when the subroutine is called from *within* the IRQ 0 handler. The MPU IRQ is not delayed, the PIC simply does not allow it to interrupt IRQ 0.

Understood. I thought maybe EOI had been sent already.

Well this is very interesting. I can only think that for some reason, the subroutine is called from the main execution loop on real hardware. It clearly can't work when called from the timer ISR.

I notice that on both DOSBox and SoftMPU, the first song plays slightly too slowly. However, the length of time that elapses before the song fades out is fixed. As a result the song fades out before it is finished, whereas on real hardware it plays until the end.

Could this code path we're seeing (end of song subroutine called from timer ISR) be a result of this? If we tweak the interrupt generation timer so that the song plays through to the end before fade, would the end of song subroutine be called from main execution loop?

Just throwing ideas out there...

EDIT: Decreasing MPU401_TIMECONSTANT in mpu401.cpp will increase song tempo so that the whole song plays before fade.

I did read a prior post that suggested Legend Entertainment games are sending data after the interrupt fires (rather than before as other games). However, if I understood ripsaw's post properly, the problem is in IRQ 0. The first song is triggered by the IRQ 2 routine, but the second song has a different trigger which involves IRQ 0. This must be unusual as far as these early MPU (intelligent mode) games go, otherwise there would be other reports of this.

The songs play correctly in the dosbox+mt32 build I posted in the MT32 general emulation subforum, where mt32 emulation is active. I assume the MIDI is handled differently in this case.

Edit: tested SVN (no mt32 emu) with MPU401 on IRQ 5, but no changes to PIC. Didn't fix the song issue.

bjt can you test what your real mpu reports if you ask for the version ?
Does it give the VERSION version and then the ack ? As ripsaws analysis of the game seems to indicate ?
Don't trust a programming guide, check the real thing 😀