theelf wrote on 2026-02-10, 20:44:

About “there’s no way,” I know, but with computers I learned something: never say never, and asking doesn’t hurt anyone, jejea. It’s no big deal, I just use a multiboot menu and that’s it. But i like a clean boot with all in one

There can be a way to make it work: Someone might patch g2mmc.sys to support more memory (i.e. fully support rev C).

EDIT: possibly this driver already exists. https://vogonsdrivers.com/getfile.php?fileid=2163 contains HT18C.SYS

mkarcher wrote on 2026-02-10, 22:40:

theelf wrote on 2026-02-10, 20:44:

About “there’s no way,” I know, but with computers I learned something: never say never, and asking doesn’t hurt anyone, jejea. It’s no big deal, I just use a multiboot menu and that’s it. But i like a clean boot with all in one

There can be a way to make it work: Someone might patch g2mmc.sys to support more memory (i.e. fully support rev C).

EDIT: possibly this driver already exists. https://vogonsdrivers.com/getfile.php?fileid=2163 contains HT18C.SYS

yup, i dissasembled the driver, and i can see the problem for sure is that is limited to 256 pages, 256x16k is 4mb

In the asm i get from ida, i can see there is a internal table to control this, 512 byts, filled by word that are 2bytes, then the problem is not only raise the pages but this table too

About the files, G2MMC.SYS and HT18.SYS are duplicated, this is the one i use now. There is another SEEMSG2.SYS is older and dont work good

thanks!

theelf wrote on 2026-02-11, 00:23:

yup, i dissasembled the driver, and i can see the problem for sure is that is limited to 256 pages, 256x16k is 4mb

That in itself shouldn't be a problem if you install 8MB in the system, and use 1MB conventional, 3MB extended (XMS) and 4MB EMS. You don't need the EMS driver to support more than 4MB of EMS, but you do need the EMS driver to know how to configure the chipset for a split at 4MB and how to access the second 4MB via the EMS engine.

mkarcher wrote on 2026-02-11, 00:42:

theelf wrote on 2026-02-11, 00:23:

yup, i dissasembled the driver, and i can see the problem for sure is that is limited to 256 pages, 256x16k is 4mb

That in itself shouldn't be a problem if you install 8MB in the system, and use 1MB conventional, 3MB extended (XMS) and 4MB EMS. You don't need the EMS driver to support more than 4MB of EMS, but you do need the EMS driver to know how to configure the chipset for a split at 4MB and how to access the second 4MB via the EMS engine.

yes, thats the problem, after using the HT18 drive, for example, if i have 8mb ram, and set 2mb ems, i get 2mb ems and 1mb xms, thats all, no 2mb ems and 5 xms

thanks

theelf wrote on 2026-02-11, 09:05:

yes, thats the problem, after using the HT18 drive, for example, if i have 8mb ram, and set 2mb ems, i get 2mb ems and 1mb xms, thats all, no 2mb ems and 5 xms

I took a look at that driver. It does indeed not support 4MB modules at all, but it would support 8MB of RAM if you had 8 1MB modules (obviously, this is only possible if a board has 8 memory slots). I'm examining possibilities to expand the driver to support 4MB modules as well.

The EMS driver (g2mmc.sys) seems quite well structured. It has a generic EMS driver core and some harware specific parts. Currently, it seems like the generic part assumes a contigouus set of "physical page numbers" that can be handed over to the chipset specific part. This kind-of works if you don't support 4MB SIMMs, but the driver already needs to get slightly creative. The hardware uses the physical page numbers 0..127 for the 128 pages of the first bank (assuming a pair of 1MB SIMMs). If a pair of 256K SIMMs is installed instead, the memory is mirrored 4 times. Page numbers 0..31 cover the whole 512KB address range provided by a pair of 256K SIMMs, and page numbers 32..63, 64..95, 96..127 cause the same memory to be visible as page numbers 0..31 do. The EMS driver handles that by marking pages 31..127 as "allocated" during initialization if bank 0 contains a pair of 256K SIMMs. The same is true for bank 1, which gets accessed by physical page numbers 128..255, bank 2 which gets accessed by physical page numbers 256..383 and bank 3 which gets accessed by page number 384..511. The driver only uses a single bit per page to mark it as allocated/free, so the 96 "wasted" page numbers in case of a 256K pair just waste 96 bits, which is 12 bytes. This is no problem.

On the other hand, if you install 4MB SIMMs in a bank, that bank suddenly needs to get four times as many pages. Bit 9 in the mapping registers is already used as "mapping enable" bits, so the two extra bits are located in bits 10 and 11. A single pair of 4MB SIMMs in bank 0 thus uses the physical page numbers 0..127, 1024..1151, 2048..2175 and 3072..3199. So the bitmap containing the allocation status of all those pages needs to have 3200 entries, which is 400 bytes, and probably the scan for free pages when allocating EMS will get slow. Nevertheless, it should still work within the driver framework. I'll see whether I can hack something up that actually supports the C revision correctly.

Currently, I only have a preliminary understanding of the driver, so no sucess of that approach is guaranteed, but from what I've seen up to now, it seems that driver does not have a 256-entry list of pages.

mkarcher wrote on 2026-02-11, 21:08:

I took a look at that driver. It does indeed not support 4MB modules at all, but it would support 8MB of RAM if you had 8 1MB mo […]
Show full quote

theelf wrote on 2026-02-11, 09:05:

yes, thats the problem, after using the HT18 drive, for example, if i have 8mb ram, and set 2mb ems, i get 2mb ems and 1mb xms, thats all, no 2mb ems and 5 xms

I took a look at that driver. It does indeed not support 4MB modules at all, but it would support 8MB of RAM if you had 8 1MB modules (obviously, this is only possible if a board has 8 memory slots). I'm examining possibilities to expand the driver to support 4MB modules as well.

The EMS driver (g2mmc.sys) seems quite well structured. It has a generic EMS driver core and some harware specific parts. Currently, it seems like the generic part assumes a contigouus set of "physical page numbers" that can be handed over to the chipset specific part. This kind-of works if you don't support 4MB SIMMs, but the driver already needs to get slightly creative. The hardware uses the physical page numbers 0..127 for the 128 pages of the first bank (assuming a pair of 1MB SIMMs). If a pair of 256K SIMMs is installed instead, the memory is mirrored 4 times. Page numbers 0..31 cover the whole 512KB address range provided by a pair of 256K SIMMs, and page numbers 32..63, 64..95, 96..127 cause the same memory to be visible as page numbers 0..31 do. The EMS driver handles that by marking pages 31..127 as "allocated" during initialization if bank 0 contains a pair of 256K SIMMs. The same is true for bank 1, which gets accessed by physical page numbers 128..255, bank 2 which gets accessed by physical page numbers 256..383 and bank 3 which gets accessed by page number 384..511. The driver only uses a single bit per page to mark it as allocated/free, so the 96 "wasted" page numbers in case of a 256K pair just waste 96 bits, which is 12 bytes. This is no problem.

On the other hand, if you install 4MB SIMMs in a bank, that bank suddenly needs to get four times as many pages. Bit 9 in the mapping registers is already used as "mapping enable" bits, so the two extra bits are located in bits 10 and 11. A single pair of 4MB SIMMs in bank 0 thus uses the physical page numbers 0..127, 1024..1151, 2048..2175 and 3072..3199. So the bitmap containing the allocation status of all those pages needs to have 3200 entries, which is 400 bytes, and probably the scan for free pages when allocating EMS will get slow. Nevertheless, it should still work within the driver framework. I'll see whether I can hack something up that actually supports the C revision correctly.

Currently, I only have a preliminary understanding of the driver, so no sucess of that approach is guaranteed, but from what I've seen up to now, it seems that driver does not have a 256-entry list of pages.

Thanks a lot for taking the time to dig into the driver and explain how it works. That really helps. I think I understand the limitation with the 4MB SIMMs now, sadly my board only have 4xsimm, then or 4mb or 16mb, and it probably explains why the driver locks up when I try to load it with only 4mb modules installed. 2x1mb + 2x4mb the driver dont hang, but still only 4mb limit

Maybe there could be some way to make the driver handle those extra pages, or maybe just ignore part of the RAM so it can still run with larger modules

Thanks again for looking into this.For now, 4MB is OK, and with a menu, i can have everything workins. Of course have the chance to use 16mb ram will be great jeje

theelf wrote on 2026-02-11, 09:05:

yes, thats the problem, after using the HT18 drive, for example, if i have 8mb ram, and set 2mb ems, i get 2mb ems and 1mb xms, thats all, no 2mb ems and 5 xms

thanks

Hi, @theelf,
You can try to use XMS2EMS.SYS driver in combination with HIMEM.SYS and EXMS86.SYS.

XMS2EMS is an open source driver and in its assembly code the comments claims this:

1; XMS2EMS is an EMS 3.2 expanded memory manager (EMM) that uses extended
2; memory managed by HIMEM.SYS to store data written to expanded memory.
3; Its syntax is:
4;
5;       DEVICE=XMS2EMS.SYS [memory] [/H=nnn]
6;
7; where "memory" is amount of expanded memory to be created (in kilobytes)
8; and "nnn" is the number of handles desired (range=8 to 255, default=64).
9; If the amount of expanded memory to be made available to the system is not
10; specified, XMS2EMS defaults to 256K. The maximum that XMS2EMS supports is
11; 8192 (8MB), the minimum 256K.

aVd wrote on 2026-02-22, 06:28:

Hi, @theelf, You can try to use XMS2EMS.SYS driver in combination with HIMEM.SYS and EXMS86.SYS. […]
Show full quote

theelf wrote on 2026-02-11, 09:05:

yes, thats the problem, after using the HT18 drive, for example, if i have 8mb ram, and set 2mb ems, i get 2mb ems and 1mb xms, thats all, no 2mb ems and 5 xms

thanks

Hi, @theelf,
You can try to use XMS2EMS.SYS driver in combination with HIMEM.SYS and EXMS86.SYS.

XMS2EMS is an open source driver and in its assembly code the comments claims this:

Copy code to clipboard

1; XMS2EMS is an EMS 3.2 expanded memory manager (EMM) that uses extended
2; memory managed by HIMEM.SYS to store data written to expanded memory.
3; Its syntax is:
4;
5;       DEVICE=XMS2EMS.SYS [memory] [/H=nnn]
6;
7; where "memory" is amount of expanded memory to be created (in kilobytes)
8; and "nnn" is the number of handles desired (range=8 to 255, default=64).
9; If the amount of expanded memory to be made available to the system is not
10; specified, XMS2EMS defaults to 256K. The maximum that XMS2EMS supports is
11; 8192 (8MB), the minimum 256K.

thanks a lot for your answer, yes i already tested, like emm386 emm286, and other ems simulators, but all have some kind of incompatiblities, and none of them work for example with Lemmings 2

thanks!

theelf wrote on 2026-02-22, 22:54:

thanks a lot for your answer, yes i already tested, like emm386, and other ems simulators, but all have some kind of incompatiblities, and none of them work for example with Lemmings 2

thanks!

Hi,
Do you mean EMM286.EXE instead of EMM386.EXE?

I saw your CONFIG.SYS configuration here:

theelf wrote on 2026-02-10, 08:41:

right now this is my config.sys in the 286, hope to do better, but this is best i could do […]
Show full quote

right now this is my config.sys in the 286, hope to do better, but this is best i could do

Copy code to clipboard

1DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z
2DEVICE=C:\DOS\HIMEM.SYS
3DEVICE=C:\DOS\QRAM\QRAM.SYS R:1
4DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$
5DOS=UMB,HIGH
6BUFFERS=42
7FILES=30
8LASTDRIVE=G
9DEVICEHIGH=C:\DOS\CDMKE.SYS /P:260 /Q

DEVICE=C:\DOS\G2MMC.SYS /M=3000 /Z <--- this give me EMS for me Headland HT18
DEVICE=C:\DOS\QRAM\QRAM.SYS R:1234 <-- this give me 32k of UMB from EMS
DEVICE=C:\DOS\EXMS86\EXMS86.SYS Q$ <--- and this give me back XMS

You can try something like this in CONFIG.SYS:

1DEVICE=C:\DOS\HIMEM.SYS
2DEVICE=C:\DOSXMS2EMS.SYS <amount_of_EMS_RAM_u_need_in_kB>
3DEVICE=C:\DOS\QRAM\QRAM.SYS R:1
4DOS=UMB,HIGH

HIMEM.SYS <--- for XMS
XMS2EMS.SYS <-- for EMS
QRAM.SYS <--- for UMBs

Or you can use HIMEM.SYS in combination with EXMS86.SYS:

1DEVICE=C:\DOS\HIMEM.SYS
2DEVICE=C:\DOS\EXMS86.SYS $ !!
3DEVICE=C:\DOSXMS2EMS.SYS <amount_of_EMS_RAM_u_need_in_kB>
4DEVICE=C:\DOS\QRAM\QRAM.SYS R:1
5DOS=UMB,HIGH

HIMEM.SYS <--- for HMA, A20
EXMS86.SYS $ !! <--- for XMS taking over the HIMEM.SYS and 64kB UMB setup instead of EMS page frame
XMS2EMS.SYS <-- for EMS
QRAM.SYS <--- for UMBs

There are other alternatives to QRAM.SYS for UMBs like USE!UMBS.SYS.

Other combinations with different settings and different drivers/managers are also possible, but I think there are not much options for creating EMS memory in combination with XMS on 80286 PC and that's why I suggested to try the XMS2EMS.SYS driver/manager. You can download it from minus zero degrees site.

There's also The Last Byte Memory Manager package, but seems like it's shareware with time limit in its free usage.

Good luck and please share your further experience in pursuit of XMS+EMS combo on your 80286 PC!