What's the initialization issue, does the program hang or does it continue with no music?

The program hangs at the signon screen when it's about to initialize the music. Sorry that I didn't see that question prior.

Okay, one last try before I sleep for now...

I've changed it this time to just send the "change to UART mode" command directly without waiting for any status, because I read somewhere that it was not really necessary to reset to intelligent mode.

Again, let me know how it works on real MPU and on AWEUTIL with NOXMS (I'm really stupefied by how the aweutil hack just suddenly stopped working...)

Still persist, however I have found a workaround on DOS only with the real MPU-401 when I run the 1.00 version first then the ones that you posted recently as an attempt to fix this.

I'm also surprised that AWEUTIL suddenly stopped working (had to replace the PSU yesterday due to having issues with the power LED), I think we could forget about this for now until the initialization routine is solved. The MIDI emulation on Windows works very well anyway.

Gmlb256 wrote on 2021-09-28, 04:17:

Still persist, however I have found a workaround on DOS only with the real MPU-401 when I run the 1.00 version first then the ones that you posted recently as an attempt to fix this.

I couldn't resist coding a bit more after you said that you actually run the 1.00 version and then the new ones... so I made a build that uses the 1.00 init code with the current playback code. Let me know if the init issue is fixed. (Really sleeping this time.)

As for the AWEUTIL problem, does DOSMID still work on the same computer? I'm practically copying DOSMID's protocol at this point.

ericvids wrote on 2021-09-28, 04:48:

I couldn't resist coding a bit more after you said that you actually run the 1.00 version and then the new ones... so I made a build that uses the 1.00 init code with the current playback code. Let me know if the init issue is fixed. (Really sleeping this time.)

Sorry for the very late replay, was also sleeping around. 😀

Still need that workaround of loading the 1.00 prior to avoid program hanging at init. 🙁

ericvids wrote on 2021-09-28, 04:48:

As for the AWEUTIL problem, does DOSMID still work on the same computer? I'm practically copying DOSMID's protocol at this point.

I can still use DOSMid and AWEUTIL still works without problems, strange that yours doesn't.

Gmlb256 wrote on 2021-09-28, 12:18:

Still need that workaround of loading the 1.00 prior to avoid program hanging at init. 🙁

This one is practically a copy of the 1.00 mpu protocol code. At this point I'm just testing whether it's that or some other part of my code that's causing problems. It probably won't work with AWEUTIL at all, but I really have to make sure at this point that it's not stupid indeterministic code.

Got the new EXE and still isn't fixed. I now also tried with NOAL (No AdLib) this time for disabling the entire sound system except PC speaker and still hangs with this parameter.

Curiously enough I don't see any condition if the music is enabled on mpuStop and mpuRestart routines as SD_MusicOff still call them even if I disabled the music. I also see mpuInit getting initialized regardless if NOAL is set or not.

That's what I'm afraid of.

But if you run 1.00 first, does this executable crash or not? (I still couldn't wrap my head around that)

ericvids wrote on 2021-09-28, 13:20:

But if you run 1.00 first, does this executable crash or not? (I still couldn't wrap my head around that)

No. Also I don't see mpuInit on that version when looking at the commits but it's just a memory allocation routine.

Edit: I see the memory allocation routines at midiStart on older commits.

Gmlb256 wrote on 2021-09-28, 13:13:

Curiously enough I don't see any condition if the music is enabled on mpuStop and mpuRestart routines as SD_MusicOff still call them even if I disabled the music. I also see mpuInit getting initialized regardless if NOAL is set or not.

Wow, I think you found the exact problem. Can you try this one now?

ericvids wrote on 2021-09-28, 13:38:

Wow, I think you found the exact problem. Can you try this one now?

It's working!!! 😀

I can even also run that EXE with AWEUTIL. Thanks! 👍

Gmlb256 wrote on 2021-09-28, 13:48:

ericvids wrote on 2021-09-28, 13:38:

Wow, I think you found the exact problem. Can you try this one now?

It's working!!! 😀

I can even also run that EXE with AWEUTIL. Thanks! 👍

Whew! Glad it's fixed... mpuStop() was trying to send midi stop notes even before the mpu was initialized (which explains why it worked after executing 1.00 once).

I'll push a bunch of new EXEs to github in a while (have to check all other versions)...

As for savegame compatibility with the Activision EXEs, I've decided to drop it because, you know what, id software didn't care themselves, why should I? =))) (Seriously, their savegame code is so volatile that even just relocating the data segment itself can break it... and a relocation WILL happen if any mod adds or removes enough code. In fact, that relocation happened when they compiled the SoD Activision EXE and commented out some lines that the original open source release does not account for.)

More testing with the new EXE and expanded memory manager loaded. It's becoming less about XMS and it crashes/reboots (depending whether QEMM or EMM386 is used) when exiting the game, I did this without AWEUTIL to make sure. Without EMM it works fine.

Gmlb256 wrote on 2021-09-28, 18:37:

More testing with the new EXE and expanded memory manager loaded. It's becoming less about XMS and it crashes/reboots (depending whether QEMM or EMM386 is used) when exiting the game, I did this without AWEUTIL to make sure. Without EMM it works fine.

Hold on, it crashes with an EMM manager? And it works better without EMM, meaning, with just the 640k lower memory?

Wolf3D itself might not like emulated EMS after all. 🙁 Does it also do that with the vanilla EXEs?

In any case, the recommendation for playing with AWEUTIL still remains as just using NOXMS, then? (And using an EMM is not recommended?)

ericvids wrote on 2021-09-28, 19:33:

Hold on, it crashes with an EMM manager? And it works better without EMM, meaning, with just the 640k lower memory? […]
Show full quote

Gmlb256 wrote on 2021-09-28, 18:37:

More testing with the new EXE and expanded memory manager loaded. It's becoming less about XMS and it crashes/reboots (depending whether QEMM or EMM386 is used) when exiting the game, I did this without AWEUTIL to make sure. Without EMM it works fine.

Hold on, it crashes with an EMM manager? And it works better without EMM, meaning, with just the 640k lower memory?

Wolf3D itself might not like emulated EMS after all. 🙁 Does it also do that with the vanilla EXEs?

In any case, the recommendation for playing with AWEUTIL still remains as just using NOXMS, then? (And using an EMM is not recommended?)

Decided to test once again with unnecessary TSRs removed from my configuration for a better conclusion to these questions. Seems that I'm opening a can of worms with this.

With EMM386 loaded wolfdosmpu works fine without any crashes (when not many TSR are loaded) but with QEMM it crashes with XMS enabled regardless of the MIDI setup. The vanilla executables works fine without anything unusual.

Gmlb256 wrote on 2021-09-28, 20:11:

Decided to test once again with unnecessary TSRs removed from my configuration for a better conclusion to these questions. Seems that I'm opening a can of worms with this.

With EMM386 loaded wolfdosmpu works fine without any crashes (when not many TSR are loaded) but with QEMM it crashes with XMS enabled regardless of the MIDI setup. The vanilla executables works fine without anything unusual.

I was trying to address XMS/EMS problems once and for all by looking at the possibility of forcing the engine to reserve the memory needed for wolfdosmpu in main RAM before starting wolf3d's own XMS/EMS memory manager ... unfortunately when I tried this, it would not go past the title screen even in DOSBox. It seems like asking for 64k up-front leaves wolf3d with not enough main memory to run.

In any case, can you test this build? It is a version with NO midi support, but still reserves the memory and goes through the motions of "playing" midi without actually sending anything to the mpu. I want to know whether it's the mpu communication itself that's causing the crashes, or the memory management.

ericvids wrote on 2021-09-29, 07:42:

I was trying to address XMS/EMS problems once and for all by looking at the possibility of forcing the engine to reserve the memory needed for wolfdosmpu in main RAM before starting wolf3d's own XMS/EMS memory manager ... unfortunately when I tried this, it would not go past the title screen even in DOSBox. It seems like asking for 64k up-front leaves wolf3d with not enough main memory to run.

In any case, can you test this build? It is a version with NO midi support, but still reserves the memory and goes through the motions of "playing" midi without actually sending anything to the mpu. I want to know whether it's the mpu communication itself that's causing the crashes, or the memory management.

Tested WOLFTEST.EXE with both EMM386 and QEMM. With QEMM it still crashes at exit without the NOXMS parameter, EMM386 works fine as long that not many TSR are loaded (especially with AWEUTIL loaded).

At this point, the game could easily be updated by the programmers to use MIDI and BP could inject his files of the score compositions that reflect the quality of proper MIDI. It sucks that we have to use these workarounds and hacks to enjoy the game as it should be enjoyed.

RetroGamer4Ever wrote on 2021-09-29, 14:20:

At this point, the game could easily be updated by the programmers to use MIDI and BP could inject his files of the score compositions that reflect the quality of proper MIDI. It sucks that we have to use these workarounds and hacks to enjoy the game as it should be enjoyed.

Not many people had a real MIDI device at the time due to prohibitive cost (they were aimed at professional users), so the developers has to resort using the FM synth initially even though they are ill suited for MIDI. In addition to this there was a lack of talented programmers and composers that could properly take advantage of the FM synth chip but where it does you can get some impressive music in games such as Tyrian, Dune and Cybersphere.