Yeah, with and without the patch they refuse to start with cycles higher than 3,000. They start normally with higher cycles using stable 0.74.

A little reminiscent of the Sierra SB driver initialization bug.

Here's a refinement of the previous patch that goes further in expediting response to the frequently used initialization commands while still delaying for known problem cases. In my tests it works with the usual suspects, and a few new ones, but as before it needs plenty of testing.

In any case, sending two reset commands in quick succession can serve no purpose

I agree it's pointless to send two ACKs in succession without waiting for a response of the first. I've noticed however that most programmers didn't understand why you would even bother trying to send two reset commands and not just one.

The reason is that a real MPU-401 will not return ACK after a reset command if it is returning from UART mode, as documented in Roland's MPU-401 technical reference manual, and as observed in reality. So if an MPU-401 driver wants to find out whether an MPU-401 is actually there, it must first send a reset command, wait for ACK; if ACK received, MPU-401 is found. However if no ACK is returned, either no MPU-401 is there, or it is merely returning from UART mode, so a second reset command must be sent which will then always be ACKed by a real MPU-401. I haven't checked the sources yet, but how does DosBox react when returning from UART mode?

Of course, Sierra's oldest version of MT32.DRV (the one that comes with SCI0 games) is smarter than all of us. If the MPU-401 fails to respond, the driver will show the message "MPU INPUT ERROR" on the MT-32's display; the message of course being transmitted through the MPU-401 ... 😀

NewRisingSun wrote:

Of course, Sierra's oldest version of MT32.DRV (the one that comes with SCI0 games) is smarter than all of us. If the MPU-401 fails to respond, the driver will show the message "MPU INPUT ERROR" on the MT-32's display; the message of course being transmitted through the MPU-401 ... 😀

It took me a moment to comprehend this, but it must have taken a certain form of programming genius for the driver to display an error message when the display proves that the functionality actually works. You are right though, We Are Not Worthy.

But in other terms, isn't this method (two resets) of MPU-401 detection another way of the programmer telling the user "We really don't trust that you can accurately identify your hardware in the setup program"?

isn't this method (two resets) of MPU-401 detection another way of the programmer telling the user "We really don't trust that you can accurately identify your hardware in the setup program"?

No, because "detection" in most cases is just an initialization. You can't use a device without initializing it first.

What I've tested so far with the newly posted patch and seems to be fine:

-Alien Breed
-Blood
-BloodNet
-Budokan
-Bureau 13
-Gods
-Hell: a Cyberpunk Thriller
-Innocent Until Caught
-Leisure Suit Larry 1
-Les Manley 2
-Police Quest 4 CD
-Rise of the Triad
-Strike Commander

The patch, indeed, fixes Hell and Bureau 13 when starting with cycles higher than 3,000, thanks Ripsaw 😀

Newly tested:
-Blue Force

The reason is that a real MPU-401 will not return ACK after a reset command if it is returning from UART mode, as documented in Roland's MPU-401 technical reference manual, and as observed in reality. So if an MPU-401 driver wants to find out whether an MPU-401 is actually there, it must first send a reset command, wait for ACK; if ACK received, MPU-401 is found. However if no ACK is returned, either no MPU-401 is there, or it is merely returning from UART mode, so a second reset command must be sent which will then always be ACKed by a real MPU-401. I haven't checked the sources yet, but how does DosBox react when returning from UART mode?

A condition was added in the last group of changes that prevents ACK if the interface is in UART mode after reset, but it doesn't consider if it was in UART mode before reset. Would have to ask Srecko if it was an oversight to not consider the prior mode there.

Does anyone know which games were fixed by commit 3791 (introduction of delayed reset)? Thanks