mkarcher wrote on 2022-04-02, 11:57:

Basic inspection shows: That's true. This AWEUTIL seems to rely on processor-based port-trapping instead of NMI feedback. Probab […]
Show full quote

Tiido wrote on 2022-03-31, 16:15:

Here are the files that CT1920 CD installs : http://www.tmeeco.eu/BitShit/PCschit/CT1920.zip
There's AWEUTIL.EXE instead of normal AWEUTIL.COM, with much bigger size. I imagine it has some protected mode component to trap IO writes and whatnot.

Basic inspection shows: That's true. This AWEUTIL seems to rely on processor-based port-trapping instead of NMI feedback. Probably, the goldfinch doesn't support NMI feedback at all. Actually, that makes a lot of sense, because contrary to the SB AWE32 which allocates ports for an MPU401 interface, the goldfinch only decodes the EMU8K ports.

Relying on VM86 port trapping doesn't mean this AWEUTIL works fine with protected mode games, though. It's more like the opposite: As long as no central DPMI server is present, protected mode games switch between EMM386 based real mode emulation and their own protected mode kernel which is unrelated to EMM386. So there is not EMM386-based port trapping in protected mode at all. AFAIK this matches the MEGA-EM specification: No protected mode support. The only generic way to get port trapping into a protected mode application is to provide an external protected mode kernel that will be used instead of the protected mode kernel bundled with the game. Nearly all games support interacting with external protected mode kernels using the DPMI specification. This is necessary to work inside the Windows DOS box, because you can't run a second protected mode kernel while Windows (no matter whether 3.1 or newer) is running.

So in fact there are two approaches to get port trapping (or other low-level extensions) into a protected mode game: Provide DPMI (that's what Windows 95 does to provide Soundblaster and MPU401 emulation in the DOS box), or replace the game-bundled protected mode kernel with a custom one (that's the approach of DOS32AWE).

Were someone to develop such a DPMI host, is there any reason this version of AWEUTIL would not work on a normal AWE card?

maxtherabbit wrote on 2022-04-02, 14:38:

Were someone to develop such a DPMI host, is there any reason this version of AWEUTIL would not work on a normal AWE card?

There should be no technical reason for this version of AWEUTIL to not work on a normal AWE card - unless that AWEUTIL performs some kind of detection to tell AWE-enabled soundblasters and the CT1920 apart. It won't hurt to try it, and if there is a detection function, it's technically possible (although not covered under the license for AWEUTIL) to remove that detection function.

Even without a DPMI host, this AWEUTIL should work for real-mode games. A custom DPMI host that interacts with this AWEUTIL that's already loaded, could extend support to protected mode games.

Whoa, DOS32AWE is exactly what is needed to implement fully software sound cards emulation https://github.com/volkertb/temu-vsb/issues/4