Crash with certain Sierra/Dynamix and Lucasarts Games

[maxtherabbit]

When USBUHCI(L) is loaded, I get crashing in the following titles:
Day of the Tentacle
Fate of Atlantis
The Incredible Machine
Island of Dr. Brain
Hoyle's Classic Card Games

Simply loading the base UHCI driver is enough to trigger the crash, it occurs regardless of whether the mouse/keyboard drivers are also loaded.

Interestingly, disabling digital audio in the games allows them to work with USBUHCI(L) loaded. Without USBUHCI(L) loaded, the games all work fine with digital audio enabled. I'm using a Soundblaster at 0x220 Int 5 DMA 1 HDMA 5, standard setup. Occurs with both a bog standard SB16 as well as an AWE64.

Common theme of all the ill-behaved games is they are all running in real mode

[Bret]

I don't have any of those games installed, so can't help with any of them specifically. But crashes are almost always a conflict of some sort -- usually either memory or IRQ. It's unlikely you have an actual memory address conflict, though that is possible if your memory manager isn't configured properly. The USBUHCI drivers don't use DMA like the sound hadrware does, so that's unlikely (though not impossible) for it to be the conflict. However, the PCI hardware (which is what the USB controllers use) accesses memory using a method called bus mastering, which is different than how DMA accesses memory (which uses a special hardware chip). The programs themselves access memory through the CPU which is different than how either DMA or PCI does it. All of those methods must be coordinated properly to make sure memory doesn't get screwed up. And when you have a memory manager (like EMM386) in the mix you also have things like Virtual DMA that can mess things up even more.

A couple of things to try. First of all, make sure that the USB controllers are not using IRQ 5 like your sound controller is using. You can verify this with USBUHCI(L) or USBHOSTS.

The other thing to try right up front would be a different memory manager. For example, if you're using MS HIMEM.SYS/EMM386.EXE, try a different/updated version of those (from a newer version of DOS), or try JEMM, or try other combinations of memory managers -- there are a few different ones available from the FreeDOS site.

Another possibility is that your just don't have enough memory. You say the programs run in real mode, but if you have a memory manager installed you may actually be running in V86 (Virtual 80x86) mode even though you think you're running in real mode. If you don't have a memory manager installed and USBUHCI(L) is installed in regular (conventional) memory, it may be using enough memory that your games simply don't have enough memory left to run, in which case you may need to install memory manager so you can free up some conventional memory. At least theoretically, the game should quit with an error message instead of crashing if it doesn't have enough memory, but I'm not sure how those games work.

So, play around with and without different memory managers and see if that helps at all.

[maxtherabbit]

according to USBUHCIL, my host is being assigned IRQ 10, so no issue there

Only memory managers I use are HIMEM.SYS and UMBPCI.SYS, so no EMM386 and no V86 mode. The crash occurs regardless of whether I load UMBPCI.SYS or not.
When UMBPCI.SYS is loaded, USBUHCIL loads high, so lack of conventional memory should not be a factor, since the behavior is the same in either case.

If I boot completely clean with nothing loaded but HIMEM.SYS and run the game it works. If I run USBUHCIL (but still a clean boot otherwise) prior to the game, it crashes. It doesn't crash right away, it's somewhat random when it will occur, but it always seems to coincide with a digital sound sample being triggered to play.

Could it be an instance of USBUHCIL trying to poll the USB hardware in the middle of an ISA DMA transaction?

[Bret]

It is possible there is some sort of conflict going on with the DMA, especially since you are using UMBPCI. I personally don't use it because it's always been "flaky" when I've tried. Plus, with a "real" memory manager like EMM386 the computer actually runs faster and provides much more available upper memory. UMBPCI only works where the motherboard has compatible Shadow RAM and doesn't allow, for example, use of the B000-B7FFFh range reserved for monochrome video. I prefer JEMM when it works, but I have had a couple of computers where I had to use something beside JEMM.

Try using something like JEMM or EMM386 instead of UMBPCI and see if it helps. Also, though I don't think this is the problem, it could be an I/O address conflict. If USBUHCI assigned an I/O address for the USB controller it could have used 220h which conflicts with the sound card. It shouldn't have done it, and the BIOS probably assigned an I/O address instead of USBUHCI, so that's very unlikely. But worth a check anyway.

[maxtherabbit]

As I've mentioned twice now, the behavior is identical if I do not load UMBPCI

[Bret]

I understand, but try loading a memory manager and see if it helps. At least on relatively modern CPU's, things run faster when a memory manager is loaded (CPU's are optimized for protected mode and don't really like running in real mode). It's possible it's a timing or similar issue that a memory manager can arbitrate properly since memory managers trap and virtualize several hardware-related things such as memory and I/O access.

[maxtherabbit]

I did at one point try Day of the Tentacle with EMM386 (the game can use EMS, I think to buffer speech data from the CD) and the crashes persisted. I can try to test the other affected titles with EMM386 as well.

In general I've found that older real mode software has more likelihood to balk at EMM386 and the use of V86 mode than UMBPCI. I'm a fan of running real mode software in real mode whenever possible. But that is really a conversation for a different time.

The system in question is a Pentium Pro, so while you are correct that it is optimized for protected mode, the prevalence of legacy real mode software that existed at its release would have virtually guaranteed that it handle real mode properly.

[maxtherabbit]

just went back and retested Island of Dr. Brain with EMM386 in lieu of UMBPCI, same thing

also verified the I/O address with USBUHCIL /host - it was Dxxx something or another

[Bret]

I'm at a loss right now for any more ideas to try. It's not just one program that has the issue, but an entire "class" of programs that probably all used the same compiler or libraries or something. Even though I could download at least some of the games, I don't have any computers with DOS-compatible sound cards. If the problem really is related to sound somehow (which it seems to be), the only troubleshooting I could do would be in a Virtual Machine and I wouldn't trust any results I got from a VM to tell us anything about your problem anyway. Every VM I've tried is "screwy" in some fashion and never works quite like real hardware, and VM's are notorious for not working at all with games.

Sorry.

I still am working on the programs and have a lot of things I'd like to do and fix, though have very little time to spend on them. One thing I'd eventually like to do is create a virtual SoundBlaster that uses USB sound devices. I think it would actually be possible to do that, but that doesn't help you at all right now.

[maxtherabbit]

OK I understand, thanks

[oneworldrentalUSA]

I have this as well. The vanilla game runs fine and it crashes as soon as you move into the DLC area.
There are almost no reports about that on the internet so I believe it's a Navi specific issue.
All you can do is to report about the issue directly to AMD:
AMD Issue Reporting Form
https://www.amd.com/en/support/contact-email-form


One World Rental USA