Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

RayeR

CZ,
13.01.2026, 16:43

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS (Announce)

For one of my retroPC with SB AWE64 I built SIMMConn2 adapter to expand the onboard DRAM (0,5MB) to 16MB using a common 72p EDO SIMM (max 28MB supported).
I was a bit disappointed that Creative's aweutil General MIDI emulation TSR that uses loaded Soundfont in RAM can work only for realmode programs (use NMI for port trapping).
But it seems there's modded DOS32A extender that can cooperate with aweutil to enable General MIDI emulation also for pmode programs :)
https://github.com/grepwood/dos32awe
Didn't try yet but soon :)
Maybe JEMM could adopt such feature...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
13.01.2026, 19:33

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Maybe JEMM could adopt such feature...

No idea how this could be done. IIRC, Jemm is a v86 monitor program...

---
MS-DOS forever!

RayeR

CZ,
13.01.2026, 22:53

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

I though about IO port trapping in pmode like in case of sbemu/vsbhda via qpiemu and forwarding to realmode aweutil replacing the need of DOS32AWE and enabling run such pmode games with JEMM loaded (DOS32AWE is not compatible with EMM/JEMM/QEMM as stated in readme).

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
14.01.2026, 08:49

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> I though about IO port trapping in pmode like in case of sbemu/vsbhda via
> qpiemu and forwarding to realmode aweutil replacing the need of DOS32AWE
> and enabling run such pmode games with JEMM loaded (DOS32AWE is not
> compatible with EMM/JEMM/QEMM as stated in readme).

Just looked a bit into the DOS32AWE "source code": it's an IDA disassembly, absolutely awful!

It's not explained what this program does to make pm games compatible with AWEUTIL, but I'm pretty sure that it doesn't enable port trapping - that's too complex to be added to a disassembly. Perhaps it just ensures that NMI is routed to real-mode? That's something that HDPMI does as well. Also possible is that it uses debug IO watchpoints - this could easily be checked ...

---
MS-DOS forever!

RayeR

CZ,
14.01.2026, 16:26

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Just looked a bit into the DOS32AWE "source code": it's an IDA disassembly,
> absolutely awful!

Yes I looked at src and looks like a DASM. AFAIK DOS32A is opensource now so he could modify and recompile it.

> It's not explained what this program does to make pm games compatible with
> AWEUTIL, but I'm pretty sure that it doesn't enable port trapping - that's
> too complex to be added to a disassembly. Perhaps it just ensures that NMI
> is routed to real-mode? That's something that HDPMI does as well. Also
> possible is that it uses debug IO watchpoints - this could easily be
> checked ...

Shoud I try hdpmi32i.exe -r -x instead?

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
14.01.2026, 20:12

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Shoud I try hdpmi32i.exe -r -x instead?

Why not - won't hurt at least.

Would be interesting to know why AWEUTIL doesn't like EMMs ...

Perhaps you can try to

1. install AWEUTIL
2. load Jemm386 from the cmdline

and see what error is displayed.

---
MS-DOS forever!

RayeR

CZ,
15.01.2026, 08:17
(edited by RayeR, 16.01.2026, 03:35)

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

I did some experiments. 1st to say that dos32awe doesn't work for me - it hangs exactly the same way as if I start the game without it. I tried Doom1, 2 and Blood. All hangs at sound init stage - Doom hangs at "calling DMX_Init".

When I started aweutil and hdpmi32i -r it hanged one step sooner at "I_StartupTimer()".

When I started aweutil and load jemm386 it crashed at "calling DMX_Init" http://rayer.g6.cz/1tmp/awejemm.jpg
Jemm can be also loaded before aweutil in autoexec, it doesn't interfere before, just crash when some pmode game using general midi is started.

When I started aweutil and load jemm386 and hdpmi32i -r it hanged one step sooner at "I_StartupTimer()".

I checked with cpustat util ran before and after aweutil loaded but nothing changed:
MSW: 10 (PG=0 AM=0 WP=0 NE=0 TS=0 EM=0 MP=0 PE=0); Real-mode CR0: 10 GDTR: 8f866,ffff, IDTR: 0,3ff LDTR: 0, TR: 28 CR2: 0 CR3: 39000 CR4: 0 (VME=0, PVI=0, DE=0, PSE=0, PAE=0, MCE=0, PGE=0, OSFXSR=0, OSXMMEX=0) FCW: 37f FSW: 0 DR0-DR3: 0 0 0 0 DR6: ffff0ff0 DR7: 400 EFL: 7206, ESP: 95a SS-DS-ES-FS-GS limits: ffff-ffff-ffff-ffff-ffff

Update: here is short expl. Of what dos32awe does. At least for some people on vogons it worked but not clear what version of dos32awe with what version of aweutil.

the NMI forwarding logic is part of the DOS32A-integrated DPMI server, so it won't be enabled if an external DPMI server is used.

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.

UPDATE2:
I found Vogons thread about dos32awe https://www.vogons.org/viewtopic.php?t=83065&hilit=dos32awe
and there's also explanation about the source, one user made changes to dos32a but didn't publish sources while other user then DASM (IDA) it and upload to github. There's another github project https://github.com/karcherm/dos32awe/tree/master that looks more sourcey but still DASM. Also it was noted that the limitation to run strictly under realmode was added to dos32awe later, some older versions didn't enforce it but because users had some issues with V86 it was blocked later. I will try some older and newer aweutil versions if it would work...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
16.01.2026, 04:19

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> the NMI forwarding logic is part of the DOS32A-integrated DPMI server, so
> it won't be enabled if an external DPMI server is used.[/i]
>
> 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.

Since it's apparently just "NMI forwarding" what's done: did you try AWEUTIL, HDPMI32 and DOS4GW (that is, without DOS32AWE)?

---
MS-DOS forever!

RayeR

CZ,
17.01.2026, 02:09
(edited by RayeR, 17.01.2026, 07:41)

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Since it's apparently just "NMI forwarding" what's done: did you try
> AWEUTIL, HDPMI32 and DOS4GW (that is, without DOS32AWE)?

I tried with HDPMI32 -r and HDPMI32I -r but for some reason Doom hangs at startup (init head up display text message). Even If I don't load aweutil at all. No matter what memory manager loaded, tried with himem.sys, jemmex and without. But it ramdomly works with cwsdpmi -r and aweutil but not usable, sometimes it hangs at Doom start sometimes a bit later up to 10s after game start. Until it hangs it plays sfx and MIDI fine.

I also found I made one mistake using aweutil.
I had
aweutil /s /em:gm
at one line in autoexec.bat and that is bad. It should be called separately.
usually good to place only aweutil /s in autoexec and call aweutil /em:gm later when loading game that needs MIDI emulation. Also because loading big soundfont take several time, huh 8MB takes 20s and it's not due to slow HDD (maybe it loads via slow PIO through ISA bus)...

After I fixed this the DOS32AWE started working as expected, Doom, Doom2 and Blood plays MIDI fine with loaded soundfont. With 8MB bank it sound better than with default 1MB ROM. Great, only one anoying thing remains that DOS32AWE contains artifical ban for v86 mode even if not strictly necessary because older version runs without this restriction but they vanished with the author...

---
DOS gives me freedom to unlimited HW access.

Khusraw

Bucharest, Romania,
17.01.2026, 07:52

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> After I fixed this the DOS32AWE started working as expected, Doom, Doom2
> and Blood plays MIDI fine with loaded soundfont. With 8MB bank it sound
> better than with default 1MB ROM. Great, only one anoying thing remains
> that DOS32AWE contains artifical ban for v86 mode even if not strictly
> necessary because older version runs without this restriction but they
> vanished with the author...

Have you tried https://github.com/karcherm/dos32awe?

---
Glory to God for all things

RayeR

CZ,
17.01.2026, 15:54

@ Khusraw

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Have you tried
> https://github.com/karcherm/dos32awe?

Yes, later. I found it can be perfectly recompiled compared to that DASM crap. So I replaced one conditional jump with unconditional and bypass the check. Now it loads with jemm fine. But one time it happened that shortly after starting play doom2 after first shot the game dramatically slowdown and sound became choppy. After exit doom and try run again it hanged so I have to reboot. Next try it runs fine for some minutes. So there may some random error occur. Without jemm I didn't observe such problem so the v86 check probably had some reason...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
19.01.2026, 12:04
(edited by Japheth, 19.01.2026, 12:15)

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> I tried with HDPMI32 -r and HDPMI32I -r

Don't use HDPMI32i - it runs the clients with IOPL 0, and DOS4GW is NOT compatible with this mode ( SBEMU/VSBHDA use silent hacks to make if run nontheless ).

> No matter what memory manager loaded, tried with himem.sys, jemmex
> and without. But it ramdomly works with cwsdpmi -r and aweutil but not
> usable, sometimes it hangs at Doom start sometimes a bit later up to 10s
> after game start. Until it hangs it plays sfx and MIDI fine.

Very interesting behavior - I couldn't resist to analyse...

The first problem ( which is known and can easily be fixed ) is that DOS4GW is a bit paranoid - it intercepts all exceptions and interrupts and won't route them to real-mode without good reason.

The more severe issue is how AWEUTIL traps MIDI port access. AFAIU that port access triggers an "I/O channel parity error"-NMI ( whatever that is supposed to mean ). This NMI happens AFTER the port access, though, and, what's worse, it may happen in priviledge level 0 ( it an IRQ happened just after the port access instruction ).

This second issue is a problem for HDPMI - it skips NMIs that happen in priviledge level 0. That's bad, because a) AWEUTIL needs the full MIDI output stream and b) this NMI requires some kind of acknowledge - as it seems, bit 3 of port 61h has to be switchen on & off?

A small adjustment in hdpmi made DOOM run with AWEUTIL and MIDI - in real-mode only (that is, with himem.sys, without EMM); a few notes weren't rendered.

---
MS-DOS forever!

RayeR

CZ,
20.01.2026, 01:19

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

Do you have some AWE32/64 for testing?
AFAIK it works a way called HW-assisted port forwarding/emu. aweutil sets the HW to generate NMI on ISA bus when port access occur (some HW IO address comparator) so it comes after, not before. As NMI was intended to have the highest priority so it can occur any time any ring... why is it problem in HDPMI? Something with reentrancy?

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
20.01.2026, 08:03

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Do you have some AWE32/64 for testing?

Yes, I digged out a P3 MB with ISA slot and an AWE32.

> AFAIK it works a way called HW-assisted port forwarding/emu. aweutil sets
> the HW to generate NMI on ISA bus when port access occur (some HW IO
> address comparator) so it comes after, not before. As NMI was intended to
> have the highest priority so it can occur any time any ring...

I assumed it happens just after the port access only ( or may be 2-3 instructions later ), but this simply isn't the case.

> why is it problem in HDPMI? Something with reentrancy?

Yes - some parts aren't reentrant: of course the mode switches must not be interrupted, but there are more places. But should be no problem to make a special variant that masks NMI while ring0 code is running.

I guess the same is true for Jemm...

---
MS-DOS forever!

RayeR

CZ,
20.01.2026, 13:14

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

Yes, NMI can be masked, sounds a good idea to mask it in critical parts of code. It should not fire too often to miss another one...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
21.01.2026, 21:54

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Yes, NMI can be masked, sounds a good idea to mask it in critical parts of
> code. It should not fire too often to miss another one...

Finally I decided to just protect the mode switching code parts. If NMIs occure in PL0 they are just routed to real-/v86-mode, making sure that all global vars used in that path are saved & restored.

This approach did limit the necessary modifications to a minimum - the downside is that the host must not be reentered from real-/v86-mode while the NMI is handled there. No problem with AWEUTIL, since it does its works with interrupts disabled.

I did some tests. Configuration: jemmex, aweutil /EM, (modified) hdpmi32.

- the DOOM family (DOOM, DOOM2, MBF, HACX): works fine
- Duke3D and Blood: no problems
- Descent: exception 06 in v86-mode ...

The preliminary JemmEx v5.86 needed a fix, but the old v5.85 works ok.

My AWE32 has 2 MB RAM only, so the sound was worse than what vsbhda is able to render...

---
MS-DOS forever!

RayeR

CZ,
23.01.2026, 18:59

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

Thank you for the mod. Can I test it? Is it available on your github?

I have built a SimmConn2 adapter for my AWE64 so I can easily expand RAM to 32 MB (currently use 16MB SIMM and load 8MB SBK soundfont).
https://rayer.g6.cz/hardware/retropc2.htm#SIMMCONN2

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
24.01.2026, 09:17
(edited by Japheth, 24.01.2026, 16:27)

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Thank you for the mod. Can I test it? Is it available on your github?

Not yet. As already mentioned, there's a known bug causing a crash - I'm not inclined to release this half-baked status.

But although the crash happens in v86-/real-mode, it's almost certain that HDPMI is responsible for it. So you can test DOS32AWE with the current Github status of Jemm. It is supposed to run stable if interrupted by NMIs. I guess the final v5.86 will be released in a few days.

> I have built a SimmConn2 adapter for my AWE64 so I can easily expand RAM to
> 32 MB (currently use 16MB SIMM and load 8MB SBK soundfont).
> https://rayer.g6.cz/hardware/retropc2.htm#SIMMCONN2

Cool. I guess I should also try to increase memory of my AWE32 to 8 MB - there might exist some old 486-MBs with 32-pin SIMMs on the attic.

Edit:the bug mentioned above wasn't in hdpmi, but in DOS4G/W or DESCENT itself. There's code like this:
mov eax,[var] mov edx,[esp+0x30] call XXXXX cmp edx,0 jz ... or byte ptr [eax+9],0x40 ;<--- eax is 0 on first call!

Since it's a flat zero-based memory model, the last instruction may trash IVT vector for NMI - the next NMI will then cause a fatal error in real-/v86-mode.

---
MS-DOS forever!

RayeR

CZ,
25.01.2026, 07:51

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

I tried with WIP JEMM from Github (compiled some hours ago).
Now Doom1 starts with JEMM+aweutil without exception but hangs soon within a minute during game play like with cwsdpmi before. Doom2 hangs sooner after a few notes play in game menu...

As DOS32AWE replaces DOS4GW it then can't trigger that bug...

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
25.01.2026, 08:47

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> I tried with WIP JEMM from Github (compiled some hours ago).

Jemm v5.86 is now final. Shouldn't make much difference, though.

> Now Doom1 starts with JEMM+aweutil without exception but hangs soon within
> a minute during game play like with cwsdpmi before. Doom2 hangs sooner
> after a few notes play in game menu...

HDPMI does now optionally support robust NMI handling.

However, I don't want to release another hdpmi binary - you'll have to create it on your own ( that little aptitude test also singles out pure gamers that report "it doesn't work"-errors ). You'll have to modify file HDPMI32.MAK:

AOPT = -nologo -c -Cp -Sg -D?32BIT=1 $(AOPTD) -I$(INC32DIR) -Fl$* -Fo$* -D?PE -D?WDEB386=1 -D?JHDPMI=1 -D?NMISAFE=1

Furthermore, another program is needed: since the DOS/4GW extender isn't exchanged, one has to ensure that NMIs are routed to real-mode. I named it AWEMIDI, can be downloaded from here.

Usage is somewhat similar to DOS32AWE, but more flexible - run "AWEMIDI -?" to see the options.

---
MS-DOS forever!

RayeR

CZ,
26.01.2026, 00:17

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

A bit of testing. I grab new JEMM 5.86 release and WIP HX-master
I enabled NMISAFE in HDPMI32.MAK as you suggested.
I hope I use the right compiled binary from subdir
Src\HDPMI\STD32\HDPMI32.EXE [36096B]

1st I noticed that with new JEMM I sometimes (every ~3-5th boot) get a random exception (00/06/2E) when loading aweutil soundfont after boot. When loading jemm after aweutil it didn't happen but not tried many times. I din's see this yesterday with my JEMM WIP build.

I'm not sure about proper loading sequence and where the loading order matters, I loaded the max config like this:
1) jemmex (in config.sys) then from cmdline: 2) aweutil SF 3) hdpmi32 -r 4) awemidi game.exe

Here are some tried combinations:
jemm only : doom hangs soon after game start during play
jemm + awemidi : doom hangs at startup on black screen after switch to gfx mode
jemm + awemidi -2 : doom hangs in game menu after few notes play
jemm + hdpmi -r +awemidi -2 -doom hangs in game menu after few notes play
jemm + dos32awe : doom runs ok

jemm only : doom2 hangs soon after 1st note
jemm + awemidi : doom2 hangs at startup on black screen after switch to gfx mode
jemm + awemidi -2 : doom2 hangs at startup on black screen after switch to gfx mode
jemm + hdpmi -r +awemidi -2 : doom2 hangs at startup on black screen after switch to gfx mode
jemm + dos32awe : doom2 runs ok

* dos32awe - modified version with disabled v86 ban

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
26.01.2026, 03:29
(edited by Japheth, 26.01.2026, 03:40)

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> jemm only : doom hangs soon after game start during play
> jemm + awemidi : doom hangs at startup on black screen after switch to gfx
> mode
> jemm + awemidi -2 : doom hangs in game menu after few notes play
> jemm + hdpmi -r +awemidi -2 -doom hangs in game menu after few notes play
> jemm + dos32awe : doom runs ok

:-D

That doesn't sound like you managed to create the proper HDPMI variant. The file size is no clear indication since it's a PE file with section alignment.

To check that you succeeded: open any of the .lst files in STD32 (Switch.lst or pagemgr.lst) and search for ?NMISAFE. You should finally find this line:

?NMISAFE . . . . . . . . . . . . Text 1

Btw, the "-2" option is meant to be used for DESCENT - I'm now pretty sure that it's a bug in this game only, not in the DOS/4G extender.

The loading sequence is:
1. JemmEx in config.sys
2. AWEUTIL
3. optional: HDPMI32 (optional with -r and/or -x2 switches)

Then either
4. awemidi.exe
5. <game binary>
or
4. awemidi <game binary>

---
MS-DOS forever!

RayeR

CZ,
27.01.2026, 08:47

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> To check that you succeeded: open any of the .lst files in STD32
> (Switch.lst or pagemgr.lst) and search for ?NMISAFE. You should finally
> find this line:
>
> > ?NMISAFE . . . . . . . . . . . . Text 1 >

Yes, it's there...
Y:\HX\Src\HDPMI\STD32\PAGEMGR.lst 7036: ?NMI2RM . . . . . . . . . . . . Number 1h 7037: ?NMISAFE . . . . . . . . . . . . Text 1 7038: ?NOCR3CACHE . . . . . . . . . . Number 0h

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
27.01.2026, 18:25

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Yes, it's there...
> > Y:\HX\Src\HDPMI\STD32\PAGEMGR.lst > 7036: ?NMI2RM . . . . . . . . . . . . Number 1h > 7037: ?NMISAFE . . . . . . . . . . . . Text 1 > 7038: ?NOCR3CACHE . . . . . . . . . . Number 0h >

Ok, seems good.

I found a potential problem with hdpmi: is usually uses IRETD when control is given to the client (switching from PL0 to PL3). That works fine, usually, but may be a problem with NMIs, because IRET(D) - according to the x86 docs - allows another NMI to be triggered. So it might be necessary to implement an IRETD-free path for NMIs ...

However, pondering about that - Jemm also uses IRETD to switch to v86-mode ( there is no other way to do that ), and it seems to be no problem there...

---
MS-DOS forever!

Japheth

Germany (South),
29.01.2026, 19:23
(edited by Japheth, 30.01.2026, 11:31)

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> I found a potential problem with hdpmi: is usually uses IRETD when control
> is given to the client (switching from PL0 to PL3). That works fine,
> usually, but may be a problem with NMIs, because IRET(D) - according to the
> x86 docs - allows another NMI to be triggered. So it might be necessary to
> implement an IRETD-free path for NMIs ...

Turned out that this is not a problem...¹⁾

But there is a very low-level issue, though, related to port 0x61. Because of this, DOS32AWE patches the installed AWEUTIL TSR, and AWEMIDI has to patch it as well. This makes it run stable - but in v86 mode only, so Jemm is required.

Updated both HDPMI source and AWEMIDI

The patched AWEUTIL version is 1.35.

-----------------
1): Well, it actually is a problem. AWEUTIL acknowledges the NMI by toggling bit 3 of port 61h. Once that is done, the next IRET - which is the first after the NMI has occured - will reactivate NMIs. That's what happens in real-mode. In v86-mode - or, more generally, in protected-mode - this strategy cannot work, because quite a few IRETs had already happened before the AWEUTIL code is finally reached.
To make AWEUTIL work in v86- and protected-mode, it has to be made reentrant, at least the (tiny) part between the acknowledgement and the IRET.

---
MS-DOS forever!

Japheth

Germany (South),
05.02.2026, 11:30
(edited by Japheth, 05.02.2026, 11:44)

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> Turned out that this is not a problem...¹⁾
> ...
>
> -----------------
> 1): Well, it actually is a problem. AWEUTIL acknowledges the NMI by
> toggling bit 3 of port 61h. Once that is done, the next IRET - which is the
> ...

Ok, finally it works. However, all my previous theories about the reasons are moot - it's a simple DOS/4G(w) bug that may cause a freeze.

This also makes tool AWEMIDI obsolete¹⁾ - except for DESCENT, which still has its peculiar bug of trashing NMI IVT entry; but since DESCENT supports SB AWE32 natively for music, there's perhaps no longer a reason to supply AWEMIDI.

To test:
- download the current github status of HDPMI (and JEMM, if v86-mode is to be tested)
- modify hdpmi32.mak, adding -D?NMISAFE=1
- create the binaries
- run HDPMI32.EXE
- run game binary

-----------------------------------
1) the tool may still be needed/useful for real-mode, patching AWEUTIL in memory. I tested v86-mode only.

---
MS-DOS forever!

RayeR

CZ,
12.02.2026, 04:32
(edited by RayeR, 12.02.2026, 06:06)

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

No luck...
With newly compiled hdpmi32 -r
it still hangs at Doom start on textmode screen just after
"HU_Init: Setting up heads up display." message
http://rayer.g6.cz/1tmp/doom_under_hdmpi32.jpg
After a minute it ends with disk read error (messed up some INT13h services? Disk is std. IDE on PIIX3 primary channel).
I found it's some incompatability of HDPMI32 and my system, it behaves the same when I don't load aweutil and even when I skipped entire config.sys & autoexec.bat. Also with older HDPMI32 without NMI handling enabled. Do you use some special instruction o hack that may not work on a Pentium Pro system (i440FX chipset, 192MB RAM)? As I mentioned before running doom under cwsdpmi -r don't cause such problem.

So awemidi didn't change anything with it.
BTW here's a bit newer AWEUTIL 1.36
http://rayer.g6.cz/1tmp/AWEUTIL.COM

I didn't test with new JEMM coz I have some problem with compiling (older sources compiled OK, nmake same as wmake -ms)
Y:\JEMMSRC>wmake -ms Open Watcom Make Version 2.0 beta Dec 2 2024 02:29:45 (32-bit) Copyright (c) 2002-2024 The Open Watcom Contributors. All Rights Reserved. Portions Copyright (c) 1988-2002 Sybase, Inc. All Rights Reserved. Source code is available under the Sybase Open Watcom Public License. See https://github.com/open-watcom/open-watcom-v2#readme for details. src\JEMM32.ASM(504) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(505) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(508) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(510) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(519) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(520) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(521) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM(522) : Error A2172: Initializer magnitude too large: src\JEMM32.ASM: 2812 lines, 1 passes, 16 ms, 0 warnings, 8 errors Error(E42): Last command making (build\JEMM386\jemm32.obj) returned a bad status

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
12.02.2026, 09:59

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> No luck...
> With newly compiled hdpmi32 -r
> it still hangs at Doom start on textmode screen just after
> "HU_Init: Setting up heads up display." message

Ups - I wasn't aware that you're still interested in this topic. I have a (rather) stable version running - runs demos overnight without problem. But with NMI you can never be sure...

The current binaries can be found here:

They expect an AWEUTIL v1.35!

> I didn't test with new JEMM coz I have some problem with compiling (older
> sources compiled OK, nmake same as wmake -ms)

Yes - newest Jemm requires JWasm v2.21 - actually, that's why I made a v2.21 pre-release. And hey, don't complain! there's a hint in Jemm's Makefile :-D :

# Tool Default (recommended) Alternatives #----------------------------------------------------------------- # Assembler JWasm Masm v6.1 or better (+Bin2Inc) # OMF Linker JWlink OW Wlink, MS Link (link16.exe) # COFF Linker JWlink OW Wlink # Make MS Nmake OW Wmake # # since v5.87, JWasm must be v2.21+, Masm must be v8+ #

although I have to admit that the hint has turned out to be not quite correct - Masm doesn't need to be that new...

---
MS-DOS forever!

RayeR

CZ,
14.02.2026, 05:05

@ Japheth

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

Yes... I'm a bit busy and just leaving to vacation so I'll try next weekend.
with AWEUTIL 1.35 (I did with this ver. last test)
I din't look in Jemm's makefile, after upgrade jwasm it compiles fine.

---
DOS gives me freedom to unlimited HW access.

Japheth

Germany (South),
17.02.2026, 16:08

@ RayeR

DOS32AWE - RAM wavetable MIDI possible for PM games under DOS

> ... so I'll try next weekend.

The final status: there were 2 problems, both fixed:

1. The (well-known) issue that DOS/4G doesn't route NMIs to real-mode.

2 The already mentioned problem with IRET in v86-mode. This has turned out to be rather tricky to fix. It was a futile approach trying to patch AWEUTIL - both Jemm and HDPMI have to care for it.

So the AweMidi.exe binary has become obsolete, AweMidi just consists of a preliminary JemmEx v5.87 and a preliminary HDPMI32 variant ( HDPMI32n.exe ).

---
MS-DOS forever!

Back to index page

23173 Postings in 2182 Threads, 404 registered users (0 online)
DOS ain't dead | Admin contact

powered by my little forum