The internet is fertile soil for misunderstandings and social differences, which only matter because we are limited to vague text messages, typed at each other through a small remote window. And because we live in different cultures and classes, some might take ten pages to reach their point, while another might abruptly say "get on with it!". It is unfortunate that sometimes these differences get in the way of productive work and discourse.

Ultimately, we're all human. And that says a lot! 🤣

Hi georgel,

georgel wrote on 2021-08-20, 15:50:

The DOS32AWE is a DOS32/A DOS Extender modification which is capable of redirecting MIDI sound hardware accesses of DOS Extended applications running in protected mode to the real mode Creative's original AWEUTIL (when loaded as TSR) MIDI emulator.

I have a question about how you accomplished this using DOS32/A. The list of Technical Specifications on the DOS32/A page (via archive.org) lists the following item:

• protected mode applications run at CPL 0

That means that unlike with most other DOS extenders, games on DOS/32A run at the most privileged level (ring 0). But doesn't that make it impossible for the DOS extender to intercept I/O port access? As I understood it, port trapping works by having the application run at ring 3, and configuring the IOPL and TSS to trap access to specific I/O ports.

Did you modify the DOS32/A code to run the application at CPL 3? If not, how did you implement the port redirection?

digger wrote on 2022-02-03, 21:19:

I have a question about how you accomplished this using DOS32/A. The list of Technical Specifications on the DOS32/A page (via a […]
Show full quote

I have a question about how you accomplished this using DOS32/A. The list of Technical Specifications on the DOS32/A page (via archive.org) lists the following item:

• protected mode applications run at CPL 0

That means that unlike with most other DOS extenders, games on DOS/32A run at the most privileged level (ring 0). But doesn't that make it impossible for the DOS extender to intercept I/O port access? As I understood it, port trapping works by having the application run at ring 3, and configuring the IOPL and TSS to trap access to specific I/O ports.

Did you modify the DOS32/A code to run the application at CPL 3? If not, how did you implement the port redirection?

The AWE32 does "hardware-assisted port redirection" by triggering an NMI when a MIDI port is written. That's why AWEUTIL doesn't need EMM386. It seems typical DOS extenders don't reflect the NMI to real mode, as they reflect standard IRQs to real mode. All you have to do to get AWEUTIL work with protected mode software is reflecting NMIs (at least those caused by the AWE32 card) to real mode.

mkarcher wrote on 2022-02-04, 00:17:

The AWE32 does "hardware-assisted port redirection" by triggering an NMI when a MIDI port is written. That's why AWEUTIL doesn't need EMM386. It seems typical DOS extenders don't reflect the NMI to real mode, as they reflect standard IRQs to real mode. All you have to do to get AWEUTIL work with protected mode software is reflecting NMIs (at least those caused by the AWE32 card) to real mode.

Ah, thanks for that clear explanation! Doesn't the Gravis Ultrasound use NMI in a similar way, to get Sound Blaster and MPU-401 emulation working without EMM386, through the SBOS and/or MEGAEM TSRs? And would that mean that this same trick could be applied to make a "DOS32GUS" DOS extender as well?

GUS can output NMI for only SB stuff, it doesn't for its MIDI accesses.

digger wrote on 2022-02-04, 10:24:

mkarcher wrote on 2022-02-04, 00:17:

The AWE32 does "hardware-assisted port redirection" by triggering an NMI when a MIDI port is written. That's why AWEUTIL doesn't need EMM386. It seems typical DOS extenders don't reflect the NMI to real mode, as they reflect standard IRQs to real mode. All you have to do to get AWEUTIL work with protected mode software is reflecting NMIs (at least those caused by the AWE32 card) to real mode.

Ah, thanks for that clear explanation! Doesn't the Gravis Ultrasound use NMI in a similar way, to get Sound Blaster and MPU-401 emulation working without EMM386, through the SBOS and/or MEGAEM TSRs? And would that mean that this same trick could be applied to make a "DOS32GUS" DOS extender as well?

Adding to Tiidos comment that NMI feedback on the GUS is not used for MIDI output, Gravis seems to have given up on NMI feedback even for SB emulation by superseding SBOS (which is based on NMI feedback) by MEGAEM (which requires EMM386 and uses processor-based port trapping).

Tiido wrote on 2022-02-04, 10:33:

GUS can output NMI for only SB stuff, it doesn't for its MIDI accesses.

mkarcher wrote on 2022-02-04, 10:46:

Adding to Tiidos comment that NMI feedback on the GUS is not used for MIDI output, Gravis seems to have given up on NMI feedback even for SB emulation by superseding SBOS (which is based on NMI feedback) by MEGAEM (which requires EMM386 and uses processor-based port trapping).

I recall reading somewhere that the hardware-assisted emulation feature of the GUS was expanded in certain later board revisions so that it could also handle MPU-401 emulation. Newer versions of MEGAEM would automatically take advantage of it if a supported board revision was detected, and would otherwise fall back to the earlier EMM386-based emulation. I'll need to do some googling to find the article or TXT file where I read that. I believe it was mentioned in the GUS mailing list at some point.

Yeah, here it is, I believe. (It's an FTP link, so it might not directly download in newer browsers.)

Quoting the relevant part:

QUESTION: Mega-Em gives me a warning saying I have a pre 3.xx UltraSound board and Roland emulation will not work with […]
Show full quote

QUESTION: Mega-Em gives me a warning saying I have a pre 3.xx UltraSound
board and Roland emulation will not work with most protected mode
software. What gives?

ANSWER: Mega-Em is supporting your UltraSound card as best in can. However
the early revisions of the UltraSound were never meant to emulate
Roland sound devices and do not have the necessary logic to
provide protected mode emulation. Despite this Mega-Em will
still give Roland emulation for real mode software.

Given that TSRs that emulate hardware through (Q)EMM386's port trapping feature don't work with protected mode software, doesn't this imply that 3.xx GUS boards in fact do generate NMIs for MPU-401 emulation? Or is there a another way to perform hardware-assisted emulation?

EDIT: Actually, the question above the one I quoted (about OS/2 not being supported) explicitly mentions the dependence on NMI.

As for MEGAEM "superceding" SBOS, that was never really true. I remember still being dependent on SBOS as the only remaining fallback for protected mode games that didn't have native GUS support and didn't have native GUS patches available for them.
(And even with SBOS, there were a few stubborn protected mode games that would refuse to work with my GUS. I'm looking at you, Pizza Tycoon! 🤬)

I guess my GUS wasn't one of those later 3.xx revisions. Either that, or I was using an outdated version of MEGAEM.

Sorry for veering off-topic too much.

Back to my main question then: could a DOS32GUS utility be developed in the same vein as DOS32AWE, even if just for revision 3.xx GUS boards?

3.xx cards stop using the MIDI UART in the main GF1 chipset and use one in GF1D1 so I it seems this is the reason why it can work with the later cards then. 2.xx definitely do not have this available.

Tiido wrote on 2022-02-04, 13:13:

3.xx cards stop using the MIDI UART in the main GF1 chipset and use one in GF1D1 so I it seems this is the reason why it can work with the later cards then. 2.xx definitely do not have this available.

Ah, so the GF1D1 on the newer GUS revisions just makes it available on the regular I/O port 330h? In effect offering native compatibility? So the GUS still uses NMI only for Sound Blaster emulation then?

If so, why did the NMI trick on the GUS with the SBOS TSR work in protected mode games without requiring a patched DOS extender, like the AWE32 does?

I do vaguely remember that later versions of the DOS/4GW DOS extender (version 1.97 and higher, I believe?) included some improvements that made SBOS work better. Not sure if that had anything to do with NMI, though.

EDIT: apparently, those improvements had to do with secondary/high DMA handling. So I guess those related to improved native GUS support, and not NMI-based Sound Blaster emulation.

Rather it allows signalling of NMI on MIDI UART accesses, there is still no MPU401 compatibility natively. MIDI UART of GF1 is unused and one in GF1D1 is used instead.

I don't know any other details, I have only worked on reverse engineering the cards but not at all what their software does and can do 🤣

Tiido wrote on 2022-02-04, 10:33:

GUS can output NMI for only SB stuff, it doesn't for its MIDI accesses.

Tiido wrote on 2022-02-04, 16:20:

Rather it allows signalling of NMI on MIDI UART accesses, there is still no MPU401 compatibility natively. MIDI UART of GF1 is unused and one in GF1D1 is used instead.

Perhaps I misunderstood, but those two statements seem contradictory. Assuming the 3.xx board rivision, does or doesn't the GUS generate NMIs for MIDI access?

First comment was about GUS 2.xx, where there definitely is no NMI generation for MIDI accesses, only SB.

Then came the new info, and it probably makes sense. GUS 3.xx probably send NMIs when MIDI accesses are done can as it doesn't use MIDI UART for GF1 but instead uses one of GF1D1 chip that integrates all GF1 access logic.

Got it, thanks for clarifying.

That just leaves the question of why later versions of MEGAEM (used with GUS 3.xx boards) work with protected mode games without having to patch or replace their DOS extenders, but AWEUTIL still requires something like DOS32AWE to accomplish the same thing.

There's a possibility that it doesn't have to use NMI to do it but can also use a regular IRQ. NMI is just one of the IRQs in the selection list of all the IRQs that GUS can use.

Tiido wrote on 2022-02-05, 11:45:

There's a possibility that it doesn't have to use NMI to do it but can also use a regular IRQ. NMI is just one of the IRQs in the selection list of all the IRQs that GUS can use.

I think we can rule that out, since the MEGAEM.TXT file states the following:

Note that most protected mode software will not work with Mega-Em if the NMI is disabled.

So it's still unclear why AWEUTIL still requires additional DOS extender patching, and MEGAEM does not. No big deal, of course. It's just something I'm curious about. 🙂

IIIRC MEGAEM requires protected mode to be active when it's loaded, because it specifically checks which utility is being used (EMM386, QEMM, etc) and patches it in memory with hooks to itself. It's a very hacky way of doing things (it relies on privilege escalation!), but gives it free reign to intercept any interrupts/port accesses.

tl,dr; MEGAEM patches the protected mode handler itself.

jmarsh wrote on 2022-02-05, 20:37:

IIIRC MEGAEM requires protected mode to be active when it's loaded, because it specifically checks which utility is being used (EMM386, QEMM, etc) and patches it in memory with hooks to itself. It's a very hacky way of doing things (it relies on privilege escalation!), but gives it free reign to intercept any interrupts/port accesses.

tl,dr; MEGAEM patches the protected mode handler itself.

That's some pretty sophisticated hackery and software engineering work, though! Especially considering that they had to target multiple different EMMs to make it work for most customers.

Obviously, Gravis went the extra mile where Creative decided to call it a day.

Thanks for the info.

Do you think Gravis leveraged GEMMIS for this? That's the same mechanism that Windows 3.x would use to take over control of CPL0 from the EMM. Both Microsoft's EMM386 and QEMM supported that mechanism.

digger wrote on 2022-02-05, 21:04:

Do you think Gravis leveraged GEMMIS for this? That's the same mechanism that Windows 3.x would use to take over control of CPL0 from the EMM. Both Microsoft's EMM386 and QEMM supported that mechanism.

No, MEGAEM specifically does byte comparisons to know which memory manager is in use and then applies static patches/hooks. It complains about an unrecognized memory manager if a single byte doesn't match one of its known patterns.

georgel wrote on 2021-10-05, 18:25:

New version 1.7 of DOS32AWE released, the download link is in the first message. Finally Sim City 2000 is supposed to be working flawlessly. The bug is in the game which sometimes overwrites unallocated RAM . A spare buffer is dedicated now which handles such buggy behavior. Could be useful in other games too.

no way 😮
https://devblogs.microsoft.com/oldnewthing/20 … 224-00/?p=41363
https://www.joelonsoftware.com/2004/06/13/how … st-the-api-war/
https://www.joelonsoftware.com/2000/05/24/str … d-egg-problems/
"Windows 95? No problem. Nice new 32 bit API, but it still ran old 16 bit software perfectly. Microsoft obsessed about this, spending a big chunk of change testing every old program they could find with Windows 95. Jon Ross, who wrote the original version of SimCity for Windows 3.x, told me that he accidentally left a bug in SimCity where he read memory that he had just freed. Yep. It worked fine on Windows 3.x, because the memory never went anywhere. Here’s the amazing part: On beta versions of Windows 95, SimCity wasn’t working in testing. Microsoft tracked down the bug and added specific code to Windows 95 that looks for SimCity. If it finds SimCity running, it runs the memory allocator in a special mode that doesn’t free memory right away. That’s the kind of obsession with backward compatibility that made people willing to upgrade to Windows 95."

Looks like this story is indeed about simcity 2000
Jonathan Ross SimCity 2000 (1993) (IBM Programming) https://www.mobygames.com/developer/sheet/vie … veloperId,7014/