You can try the stealth option of QEMM. QEMM is able to place the EMS frame overlapping with BIOS ROMs, for example at C000 on your system.

msdosdrv.txt says that the EMS page frame can live at the very top of dos memory. (8000-9000h)

Mx […]
Show full quote

Mx

Specifies the address of the page frame. Valid values for x are in the
range 1 through 14. The following list shows each value and its
associated base address in hexadecimal format:
1 => C000h 8 => DC00h 2 => C400h 9 => E000h 3 => C800h 10 => 8000h 4 => CC00h 11 => 8400h 5 => D000h 12 => 8800h 6 => D400h 13 => 8C00h 7 => D800h 14 => 9000h

Try this:

DEVICE=C:\WINDOWS\EMM386.EXE RAM I=B000-B7FF I=CA00-D7FF X=D800-D8FF X=E000-E7FF X=E800-E9FF X=EAFF-EFFF X=F000-FFFF FRAME=9000

This will clobber 64k of conventional memory, but will give you the EMS page frame with EMM386. Will give you around 64k of useful UMB (in 2 regions), and will tell the EMM to stay out of the affected area.

Just tried both QEMM and the modified EMM386 line:

- QEMM generates exception errors and prompts me to (T)erminate or (R)eboot (plus a load of stack pointer/segment information) as soon as it is loaded in config.sys (the entry was a simple "device=c:\qemm\qemm386.sys ram" with no other memory manager loaded)
- EMM386 complains that it is unable to set the page frame address
- EMM386 has loaded and enabled UMB (but of course no EMS) which appear to have still clobbered the SCP-55 enabler software

It's looking like if I want to have EMS for the few games that require it, I am going to lose Roland GM capability.

Does FRAME=NONE work? (For the few games you have that need it, that is)

Well...Specifying HIGHSCAN on EMM386's command line might buy you more memory, but it couldn't help your situation. 🙁 Have you tried UMBPCI? It helped me get UMBs and EMS on a Win98SE tower in Windows mode. You can find a link to it at https://dosprograms.info.tt/indexall.htm#utils.

wierd_w wrote on 2025-01-02, 11:20:

Does FRAME=NONE work? (For the few games you have that need it, that is)

I tried that with Dragonsphere and it dropped out to DOS and printed an error about not being able to access memory. With Bloodnet it started but then the graphics froze at the Microprose title screen.

So far I've gone through about 80 titles for compatibility testing on this laptop and have had mixed success without a pageframe or with emsmagic (Dune CD and DoTT are happy with the latter and the pageframe in base memory, for example - so I can load that on-the-fly as needed).

I guess I'll have to live with SB Pro music for those games that are not happy without a pageframe, or where the pageframe eats into base memory (by emsmagic).

Harry Potter wrote on 2025-01-02, 11:31:

Well...Specifying HIGHSCAN on EMM386's command line might buy you more memory, but it couldn't help your situation. 🙁 Have you tried UMBPCI? It helped me get UMBs and EMS on a Win98SE tower in Windows mode. You can find a link to it at https://dosprograms.info.tt/indexall.htm#utils.

Already using it in my non-EMS config.sys entry. I can load most of my PCMCIA drivers and everything else high, leaving me with 594KB of base memory and working SCP-55 general MIDI... that's enough for every non-EMS game I've tried so far.

It's looking like the upper memory area is simply too congested on this laptop to have PCMCIA working *and* an EMS page frame up there.

wierd_w wrote on 2025-01-02, 10:33:

DEVICE=C:\WINDOWS\EMM386.EXE RAM I=B000-B7FF I=CA00-D7FF X=D800-D8FF X=E000-E7FF X=E800-E9FF X=EAFF-EFFF X=F000-FFFF FRAME=9000

FRAME=9000 is dangerous when having BIOSes who reduce the amount of conventional memory. I have a RAID controller who takes 8 kB. Most of PS/2 mouse support take 1 kB too.
Just do this when "mem" shows a total conventional memory of 655360 bytes after booting without EMM386.

Did you try "I=CA00-DFFF"? I don't understand why Checkit 3 reported it as UNKNOWN, but EMM386 doesn't detect it. Also, "I=B000-B7FF" should buy you an extra 32k UMBs at the cost of mono modes which are almost never used anyway.

The issue is that there is not a contiguous 64kb chunk to put the pageframe into.

There is some strange stuff going on in the adapter region with the PCMCIA controller active. Not surprising, the area is INTENDED for memory-mapped IO shenanigans.

EMM386 checks to see if the memory is write protected or not, and says "Its RAM" if it is not, Then looks for the ROM identification prefix byte sequence to see if this is an option ROM or not. If it finds one, it says it is ROM. If it does not, it says it is "Possibly Available" or "unknown"

If it finds a bunch of FF bytes in a region and finds it is not writable, it thinks it is unallocated/free.

The issue as I understand it, is like this:

The PCMCIA controller on this laptop "Does Stuff" with the upper memory area.
There is a mysterious option rom related to this in this area, in a VERY inconvenient location, that the bios provides no means of relocating.

Because of this, there are no 64kb chunks of free address to create a page frame in.

megatron-uk wrote on 2025-01-02, 11:15:

- QEMM generates exception errors and prompts me to (T)erminate or (R)eboot (plus a load of stack pointer/segment information) as soon as it is loaded in config.sys (the entry was a simple "device=c:\qemm\qemm386.sys ram" with no other memory manager loaded)

What about

1device=c:\qemm\qemm386.sys FRAME:C000 ST:F

The suggestion is to avoid providing UMBs by QEMM, just use it to provide a page frame at C000, using the stealth method "F", which is more conservative than "M". Furthermore, IIRC, you can try to use "OPTIMIZE" to find a configuration of QEMM that doesn't crash your system.

Wont that clobber the VGA rom?

wierd_w: QEMM's Stealth modes allow one to put UMBs where ROMs are by trapping accesses to such ROMs, switching them in upon access then switching RAM back in upon exit.

mkarcher wrote on 2025-01-02, 12:37:

What about […]
Show full quote

megatron-uk wrote on 2025-01-02, 11:15:

- QEMM generates exception errors and prompts me to (T)erminate or (R)eboot (plus a load of stack pointer/segment information) as soon as it is loaded in config.sys (the entry was a simple "device=c:\qemm\qemm386.sys ram" with no other memory manager loaded)

What about

Copy code to clipboard

1device=c:\qemm\qemm386.sys FRAME:C000 ST:F

The suggestion is to avoid providing UMBs by QEMM, just use it to provide a page frame at C000, using the stealth method "F", which is more conservative than "M". Furthermore, IIRC, you can try to use "OPTIMIZE" to find a configuration of QEMM that doesn't crash your system.

I tried that combination and got the following:

"QEMM386: Disabling StealthROM because QEMM could not locate the ROM handler for INT 13 76"

The entries in config.sys up to that point were:

1device=c:\essolo.sys
2device=c:\jemm\himemx.exe
3device=c:\qemm\qemm386.sys frame:c000 st:f

Thanks for the options everyone. It just looks like a no-go unless the game in question will tolerate no page-frame, or will run via emsmagic (hit and miss, so far). I'll have to tolerate booting without PCMCIA + Roland MIDI for those games which demand a full EMS implementation.

megatron-uk wrote on 2025-01-02, 14:39:

"QEMM386: Disabling StealthROM because QEMM could not locate the ROM handler for INT 13 76"

This means that QEMM has issues finding the BIOS entry points for hard drive stuff (Int13 & IRQ14). You can ask QEMM to ignore these interrupts, as they do not touch the C000 area (which is for graphics only). Try adding XSTI=13 XSTI=76 X=E000-FFFF to the QEMM command line. I assume that without "RAM", the exclude parameter is not needed, as QEMM is only supposed to touch the page frame area, but I added it just to be safe.

megatron-uk wrote on 2025-01-02, 14:39:

[…]
Show full quote

Copy code to clipboard

1device=c:\essolo.sys
2device=c:\jemm\himemx.exe
3device=c:\qemm\qemm386.sys frame:c000 st:f

QEMM has its own internal XMS implementation. You generally do not need to load any kind of HIMEM before QEMM. Nevertheless, I don't think HIMEM is the cause of the trouble here. I suppose ESSSOLO.SYS is only for initialization of the sound card, so this will be fine, too.

Tried with the updated qemm options and now the error about the interrupt handlers is gone - it says "Qemm available memory 6......" (approx 64MB I am guessing) for a fraction of a second, but then the system reboots before it gets to the next line of attempting to start loading the PCMCIA drivers.

I think we should put this one to bed; it's clearly not worth it. Out of 119 games tested so far, only five have required EMS:

- Bloodnet (800kb EMS): doesn't work with emsmagic. I'll need to boot and play in SB Pro mode without GM music.
- DoTT (2048kb EMS): seems to work with emsmagic (dynamically loaded/unloaded after game) with page frame in base memory. Working fine in SB + GM music mode.
- Dragonsphere (800kb EMS): doesn't work with emsmagic (crash after intro). I'll need to boot and play in SB Pro mode without GM music.
- Dreamweb (3072kb EMS): doesn't work with emsmagic, but doesn't have MIDI music anyway so is fine to play in SB Pro mode.
- Dune CD (unknown? EMS): works with emsmagic with page frame in base memory. Working fine in SB + GM music (via GS2MT32 emulattion) mode

So far that's only 2 titles without MIDI music I'm losing out on. I can put up with that for the moment. If I get all the way through the list (some ~400 titles) and it starts to be a significant percentage that I lose out on GM music (if you think about it, it has got to be a small percentage of games needing EMS *and* supporting GM - rather than MT32), then it might need some more time investing.

When/if you get back to it, try including the area between CA00 and DFFF as UMBs. On my Win98SE tower, QEMM's MANIFEST reported similar, and I added the first 32k of the area to the available RAM in EMM386 successfully--the upper 32k in the range didn't work.