Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page

Japheth

Germany (South),
18.02.2026, 08:38
(edited by Japheth, 18.02.2026, 09:04)

AweMidi - a Dos32Awe alternative (Announce)

Hello,

it's done finally: after quite a long struggle with NMIs in v86-mode there's now AweMidi available, another approach to make protected-mode games compatible with Creative's AWEUTIL tool in "MIDI synthesizer emulation" mode ( option /EM ):

If you own an AWE32/AWE64/SB32, you can download and try it: AweMidi

Compared to Dos32Awe, there are several benefits:

- it works with and without v86-mode
- the DOS/4G(W) extender is not replaced by DOS32A
- may work with games that are written with other extenders than DOS/4G(W)

There's no source code available, since AweMidi consist of just a preliminary JemmEx v5.87 and a special, "NMI-safe" variant of HDPMI32.

---
MS-DOS forever!

Japheth

Germany (South),
23.02.2026, 08:13

@ Japheth

AweMidi - a Dos32Awe alternative

So far I tested it with my AWE32 on 3 machines:

- P3, 500 MHz, Slot 1, 512 MB: everything works smoothly
- P1, 200 MHz, Socket 7, 128 MB, Dallas chip with dysfunc battery: works well, but DOS/4G apps need JemmEx ( or rather: JHDPMI ).
- AMD5x86, 133 MHz, 64 MB: AWE32 is very noisy, but at least MegaMid works; all DOS-extended apps caused exceptions ( both DOS/4G and HDPMI ) - however, this happened even without AWE32 being activated, so probably a memory issue; didn't invest too much time to elaborate...

---
MS-DOS forever!

RayeR

CZ,
02.03.2026, 06:45

@ Japheth

AweMidi - a Dos32Awe alternative

It finally works for me, thank you.
(if HDPMI32N.EXE is not loaded Doom hangs within few seconds, with HDPMI32N.EXE it plays several minutes)

What JHDPMI.DLL does? There's note "increases HDPMI32n's DPMI compliance" - how? As HDPMI is already DMPI 1.0 compliant?

BTW Last time when I recompiled JEMM from github (around 22.2.) I got such error from jload when loading QPIEMU.DLL:
JLoad: 'QPIEMU.DLL' isn't a PX binary
something wrong with compiled QPIEMU.DLL, when I loaded older version it didn't complain. Compiled QPIEMU.DLL had MZ header and looked valit at 1st look...

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

Japheth

Germany (South),
02.03.2026, 14:34

@ RayeR

AweMidi - a Dos32Awe alternative

> What JHDPMI.DLL does? There's note "increases HDPMI32n's DPMI compliance" -
> how? As HDPMI is already DMPI 1.0 compliant?

It hooks IRQs while they are handled by the monitor, that is, before any IVT hooker will get control. So HDPMI is ensured to be the first to handle an IRQ, and it doesn't have to fiddle with the real-mode interrupt table at all.

HDPMI is NOT a full DPMI 1.0 host - still lacks a few things...

> BTW Last time when I recompiled JEMM from github (around 22.2.) I got such
> error from jload when loading QPIEMU.DLL:
> JLoad: 'QPIEMU.DLL' isn't a PX binary
> something wrong with compiled QPIEMU.DLL, when I loaded older version it
> didn't complain. Compiled QPIEMU.DLL had MZ header and looked valit at 1st
> look...

IIRC Jload checks for "PX" instead of "PE" - this can be fixed by running patchpe.exe.

---
MS-DOS forever!

RayeR

CZ,
02.03.2026, 18:32

@ Japheth

AweMidi - a Dos32Awe alternative

> It hooks IRQs while they are handled by the monitor, that is, before any
> IVT hooker will get control. So HDPMI is ensured to be the first to handle
> an IRQ, and it doesn't have to fiddle with the real-mode interrupt table at
> all.

OK, it may be useful also for other programs. Many years ago I tried to code some simple mp3 covox player in DJGPP where I installed my timer ISR in pmode via std DPMI functions. But as IRQ might be triggered also in RM it could cause some unwanted delays (I heard some drops - covox-LPT doesn't have any HW buffer). So maybe if I try to run my program under such DMPI host it would play more smooth...

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

RayeR

CZ,
09.03.2026, 04:28

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

BTW I found a problem with JEMM (5.87 but older version too) on one Pentium M laptop, 2GB RAM, i855 chipset - when JEMMEX is loaded with XMSHANDLES=60 and more (from config.sys, 1st driver loaded) it crashes or reboot. I had copied config.sys from other machine with XMSHANDLES=64 where it worked without problems but triggered problem on this laptop. Any idea what can cause this? I lowered XMSHANDLES=56 and here's XMSSTAT output:
XMS call address: e500:90 XMS version: 3.0, driver version: 3.82 HMA handled by XMS host, HMA is allocated v2 free memory largest/total (kB): 65535/65535 v3 free memory largest/total (kB): 1833280/1833280, highest addr: 7ffcffff XMS handle table at e500:cc, handle cnt/size=56/10 XMS handle array at e500:d4 no handle region size(kB) locks flags ------------------------------------------------------------ 1 d4 000110000- 00013ffff 192 0 2 used 2 de 000140000- 01017ffff 262400 1 2 used 3 e8 010180000- 07ffcffff 1833280 0 1 free ------------------------------------------------------------ 2095872 free handles: 53 no free UMBs available

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

Japheth

Germany (South),
09.03.2026, 12:54

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> Any idea what can cause this?

> I lowered XMSHANDLES=56 and here's XMSSTAT output:
> > XMS call address: e500:90 > XMS version: 3.0, driver version: 3.82 > HMA handled by XMS host, HMA is allocated > v2 free memory largest/total (kB): 65535/65535 > v3 free memory largest/total (kB): 1833280/1833280, highest addr: 7ffcffff > XMS handle table at e500:cc, handle cnt/size=56/10 > XMS handle array at e500:d4 >

segment e500 seems pretty high. Perhaps there's just not enough free address space above c000?

Run memstat.exe ( without loading Jemm ).
Loading Jemm with NORAM option may also give a hint...

---
MS-DOS forever!

RayeR

CZ,
09.03.2026, 15:00
(edited by RayeR, 09.03.2026, 18:21)

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

Ok I'll try. Forgot mention that I tried with fail-safe option X=A000-FFFF but didn't help. This should avoid using bios holes...

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

RayeR

CZ,
10.03.2026, 02:12

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> Run memstat.exe ( without loading Jemm ).
conventional memory (Int 12h): 639 kB XBDA at segment 9fc0, size 0 kB Int 15h, ah=88h, extended memory: 0 kB Int 15h, ax=E801h: ext. memory below 16 MB: 15360 (0x3c00) KB ext. memory above 16 MB: 32509 64 KB blocks = 2031 MB [1000000-7ffcffff] Int 15h, eax=E820h: address range size type ---------------------------------------------------- 000000000-00009fbff 9fc00 1 (available) 00009fc00-00009ffff 400 2 (reserved) 0000e0000-0000fffff 20000 2 (reserved) 000100000-07ffcffff 7fed0000 1 (available) 07ffd0000-07fff0bff 20c00 2 (reserved) 07fff0c00-07fffbfff b400 4 (ACPI NVS) 07fffc000-07fffffff 4000 2 (reserved) ---------------------------------------------------- available: 2047 MB, ACPI: 45 kB, rsvd: 0 MB, total: 2047 MB

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

Japheth

Germany (South),
10.03.2026, 08:44

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> > Run memstat.exe ( without loading Jemm ).
> address range size type
> ----------------------------------------------------
> 000000000-00009fbff 9fc00 1 (available)
> 00009fc00-00009ffff 400 2 (reserved)
> 0000e0000-0000fffff 20000 2 (reserved)
> 000100000-07ffcffff 7fed0000 1 (available)
> 07ffd0000-07fff0bff 20c00 2 (reserved)
> 07fff0c00-07fffbfff b400 4 (ACPI NVS)
> 07fffc000-07fffffff 4000 2 (reserved)
> ----------------------------------------------------
> available: 2047 MB, ACPI: 45 kB, rsvd: 0 MB, total: 2047 MB
> [/code]

If memstat reports e0000-fffff as reserved and the XMS handle table is located in segment e500, then you somehow had forced JemmEx to do so ( because as default it respects reserved regions ). Perhaps by using UMBPCI?

---
MS-DOS forever!

RayeR

CZ,
10.03.2026, 14:20

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

Ah, this is because added I=TEST later but the problem was also without it. I'll try xmsstat again with just X=e000-ffff. I don't combine jemm with umbpci.

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

RayeR

CZ,
11.03.2026, 03:44

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

Output of xmsstat with X=e000-ffff, handles table moved at 29a:cc
XMS call address: 29a:90 XMS version: 3.0, driver version: 3.82 HMA handled by XMS host, HMA is allocated v2 free memory largest/total (kB): 65535/65535 v3 free memory largest/total (kB): 1800664/1800664, highest addr: 7ffcffff XMS handle table at 29a:cc, handle cnt/size=59/10 XMS handle array at 29a:d4 no handle region size(kB) locks flags ------------------------------------------------------------ 1 d4 000110000- 000139fff 168 0 2 used 2 de 00013a000- 010179fff 262400 1 2 used 3 e8 01017a000- 012159fff 32640 1 2 used 4 f2 01215a000- 07ffcffff 1800664 0 1 free ------------------------------------------------------------ 2095872 free handles: 55 no free UMBs available

Crash when increased to XMSHANDLES=60 (59 is OK)
http://rayer.g6.cz/1tmp/jemmex.jpg

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

Japheth

Germany (South),
11.03.2026, 07:51

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> Crash when increased to XMSHANDLES=60 (59 is OK)

Here's a jemmex with debug log on initialization: https://drive.google.com/file/d/1CRQj2eTvvmZcmh4eFmmtTIDx2GdugySA/view?usp=drive_link

You'll have to press SPACE after each line. Report the last line that's displayed - that may be a valuable hint.

---
MS-DOS forever!

RayeR

CZ,
12.03.2026, 01:54
(edited by RayeR, 12.03.2026, 02:40)

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

The last step was JemmEx loaded: http://rayer.g6.cz/1tmp/jemmex-stepping.jpg

Later I found that even with lower number of xmshandles (stepped down by 48, 32, 24, 16) it cause crash when start some DJGPP compiled programs (that loads cwsdpmi).
Also I randomly found an old backup copy of JEMMEX 5.78 from year 2012 on that HDD and it runs stable on this machine, even with xmshandles=64. Maybe xmshandles problem is just a side effect of some other issue introduced in newer versions. Here's xmsstat with that old ver, XMS handle table located at diff.addr, also regions addr. differs...
XMS call address: d000:64 XMS version: 3.0, driver version: 3.29 HMA handled by XMS host, HMA is allocated v2 free memory largest/total (kB): 65535/65535 v3 free memory largest/total (kB): 1833240/1833240, highest addr: 7ffcffff XMS handle table at d000:a0, handle cnt/size=64/10 XMS handle array at d000:a8 no handle region size(kB) locks flags ------------------------------------------------------------ 1 a8 000110000- 000149fff 232 1 2 used 2 b2 00014a000- 010189fff 262400 1 2 used 3 bc 01018a000- 07ffcffff 1833240 0 1 free ------------------------------------------------------------ 2095872 free handles: 61 no free UMBs available

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

Japheth

Germany (South),
12.03.2026, 08:11

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> The last step was JemmEx loaded:
> http://rayer.g6.cz/1tmp/jemmex-stepping.jpg

Ok, that's an important info. It tells that JemmEx isn't crashing - the error occurs in v86-mode, after JemmEx has installed itself successfully - "JemmEx loaded" is displayed at the very end of this initialization.

Try MS-DOS "single-step" mode (shift-f8) to see if the Exc06 indeed happens in Jemm...

---
MS-DOS forever!

RayeR

CZ,
12.03.2026, 14:03

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> Try MS-DOS "single-step" mode (shift-f8) to see if the Exc06 indeed happens
> in Jemm...

Yes, I already did config F8 stepping but the jemmex crashed immediatelly after I confirmed its load line and it didn't displayed prompt for the next line so I though it's in jemmex. But maybe the crash is triggered by disk/file access when DOS tries to load next line from config.sys (or its memory buffer, running msdos 6.22 on fat16).

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

Japheth

Germany (South),
12.03.2026, 15:18

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> Yes, I already did config F8 stepping but the jemmex crashed immediatelly
> after I confirmed its load line and it didn't displayed prompt for the next
> line so I though it's in jemmex.

It might happen when DOS tries to allocate UMBs supplied by Jemm? Does the crash disappear if you do NOT set "DOS=UMB"?

---
MS-DOS forever!

RayeR

CZ,
12.03.2026, 16:36

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

OK, DOS=HIGH,UMB is the 1st line (before JEMM), I'll try...

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

bretjohn

Rio Rancho, NM,
12.03.2026, 23:35

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> OK, DOS=HIGH,UMB is the 1st line (before JEMM), I'll try...

FWIW (For What It's Worth), CONFIG.SYS isn't strictly processed sequentially. CONFIG.SYS is processed in "subgroups", and only within each subgroup are things processed sequentially. In addition, different DOS's don't necessarily process subgroups in the same order (e.g., I know FreeDOS and MS-DOS do things differently).

You can test this by single-stepping through the boot process by pressing F8 (at least in MS- and FreeDOS) as things are first starting. Compare the order the lines are processed by single-stepping to the order they are in the actual CONFIG.SYS file and you will probably see they are different. For example, the DOS=HIGH,UMB line is the first thing processed in MS-DOS (at least in the version I tested) even though it isn't the first line in my CONFIG.SYS file, and the first thing processed in FreeDOS is the SHELL= line even though it isn't first line in the CONFIG.SYS file, either.

AUTOEXEC.BAT, like all batch files, is processed sequentially, but CONFIG.SYS is not.

RayeR

CZ,
13.03.2026, 02:30

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> It might happen when DOS tries to allocate UMBs supplied by Jemm? Does the
> crash disappear if you do NOT set "DOS=UMB"?

Unfortunatelly no change when removed.

>bretjohn
I didn't know about out of order execution of config.sys but MSDOS 6.22 do it sequentially.

I went back in time and found that the JEMM behavior changed since version 5.79 (crashing, 5.78 no)

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

Japheth

Germany (South),
13.03.2026, 08:43

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> Unfortunatelly no change when removed.

I'm not sure if this is "unfortunate" - it would still have been puzzling if the crash had vanished. There's now a strong indication that a return address stored on the stack may get corrupted - the bytes displayed at [CS:IP] in your crash screenshot are a valid part of Jemm, but they definitely belong to 32-bit protected-mode and should never run in v86-mode.

> I went back in time and found that the JEMM behavior changed since version
> 5.79 (crashing, 5.78 no)

Hm, ok - but v5.78 is from 2012, and there were lots of changes for v5.79. You could try to create JemmExL.exe ( the "legacy" variant ). That variant disables a significant part of those changes. I have a 2 GB machine with ACPI available, so I probably will test the current JemmEx myself...

---
MS-DOS forever!

Japheth

Germany (South),
13.03.2026, 15:07

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> I have a 2 GB machine with ACPI available, so I probably will test the current JemmEx myself...

The bug was disappointingly easy to find and fix - good old DEBUG was sufficient.

Here's a (hopefully) fixed JemmEx: https://drive.google.com/file/d/13tjH7etB_XVvYX6UUaSR71wK5c4ZAnb4/view?usp=drive_link

---
MS-DOS forever!

RayeR

CZ,
14.03.2026, 02:47

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> Here's a (hopefully) fixed JemmEx:
> https://drive.google.com/file/d/13tjH7etB_XVvYX6UUaSR71wK5c4ZAnb4/view?usp=drive_link

Thank you for the fix, now it seems to run OK.
I observed one difference in behavior. Old JEMMEX allocated EMS page frame at E000 which seems to be used by BIOS. As I don't usually run EMS programs it didn't caused any problem. Newer JEMMEXes allocated EMS page frame at D000 which occupy all free UMB so then not available for drivers and TSR. I had to add FRAME=NONE (or NOEMS) to use D000 segment for UMB. I=TEST gives some little chunks in E000-FFFF region but too small to load bigger TSR in...

Why the bug was not triggered on other systems? Something specific here? Nobody else reported such problem for years...

BTW does this JEMMEX contains also NMI fixes for AWE64 so I can have a single version?

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

Japheth

Germany (South),
14.03.2026, 03:57

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> I observed one difference in behavior. Old JEMMEX allocated EMS page frame
> at E000 which seems to be used by BIOS. As I don't usually run EMS programs
> it didn't caused any problem. Newer JEMMEXes allocated EMS page frame at
> D000 which occupy all free UMB so then not available for drivers and TSR. I
> had to add FRAME=NONE (or NOEMS) to use D000 segment for UMB. I=TEST gives
> some little chunks in E000-FFFF region but too small to load bigger TSR
> in...

Yes, newer jemms respect reserved regions reported by int 15h ax=e820h

> Why the bug was not triggered on other systems? Something specific here?
> Nobody else reported such problem for years...

It only happens if jemm isn't allowed to move its resident part into the upper memory region ( by using option NOHI or X=A000-FFFF ). So it's not really a show-stopper...

> BTW does this JEMMEX contains also NMI fixes for AWE64 so I can have a
> single version?

Yes.

---
MS-DOS forever!

RayeR

CZ,
16.03.2026, 21:57

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> Yes, newer jemms respect reserved regions reported by int 15h ax=e820h

What could happen with old JEMM when it use E000 page frame? Memory corruption? I expect problems only with such old programs that really use EMS...

> It only happens if jemm isn't allowed to move its resident part into the
> upper memory region ( by using option NOHI or X=A000-FFFF ). So it's not
> really a show-stopper...

Aha, I would guess that it's not so uncommon that whole E000-FFFF is used by BIOS and then only D000 segment remains (JEMM prefers use it as page frame instead UMB by default)...

> > BTW does this JEMMEX contains also NMI fixes for AWE64 so I can have a
> > single version?
> Yes.

Cool, will be official release soon? :)

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

Japheth

Germany (South),
17.03.2026, 12:05

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> What could happen with old JEMM when it use E000 page frame? Memory
> corruption? I expect problems only with such old programs that really use
> EMS...

Those old versions still will check if the address region is usable. Problem are ROMs that may be mapped in dynamically - i.e. "legacy" support for USB drives.

> Cool, will be official release soon? :)

:-D The current v5.86 was released just a few weeks ago. Two fixes for relatively minor issues don't justify any updates, IMO.

---
MS-DOS forever!

RayeR

CZ,
17.03.2026, 13:39

@ Japheth

JEMM(EX) and too much XMSHANDLES problem

> Those old versions still will check if the address region is usable.
> Problem are ROMs that may be mapped in dynamically - i.e. "legacy" support
> for USB drives.

Does this mean that it reports page frame at E000 but when some program tries to use EMS it will be refused to access that memory and effectively same result like if I use FRAME=NONE option?

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

Japheth

Germany (South),
17.03.2026, 17:46

@ RayeR

JEMM(EX) and too much XMSHANDLES problem

> > Those old versions still will check if the address region is usable.
> > Problem are ROMs that may be mapped in dynamically - i.e. "legacy"
> support
> > for USB drives.
>
> Does this mean that it reports page frame at E000 but when some program
> tries to use EMS it will be refused to access that memory and effectively
> same result like if I use FRAME=NONE option?

No. With "mapped in dynamically" I didn't mean the CPU's paging mechanism - this will always work.

---
MS-DOS forever!

Back to index page

23235 Postings in 2190 Threads, 405 registered users (0 online)
DOS ain't dead | Admin contact

powered by my little forum