Harry Potter wrote on 2025-12-18, 19:32:

I believe that needs to be done via msdos.sys, but you can also get your desired options by pressing F8 while Windows is starting up.

Ah, I see. But yeah, the options are there with F5 and F8.

I still seem to be struggling at getting to grips with the ins and outs of EMS, XMS, and UMBs etc. I did read some articles/pages about them and how they work, though I’m still a bit confused with certain aspects.
For instance, installing Wolfenstein 3D, and trying to load it, it gives me a box saying that it needs more conventional memory, and for me to use a memory manager, like EMMS. However, with my custom boot menu set up the way it is, I’m getting that warning with EMMS386. So I have HIGHMEM, EMMS386 and UMB. Every time I check the memory though, it always lists my Upper at 0. And that’s with having my CD driver set to DEVICEHIGH.
With XMS, the game loads. There’s only a tiny bit more Conventional Memory than with EMS though. I think it’s gone from 512…? To 572K. So I’m confused as to what’s going on. Why, despite having EMS and Upper Memory enabled, the game won’t load, and why my Upper is always at 0. Or am I supposed to set a specific amount in the config file? At the moment it’s just DOS=UMB.

Thanks

Doesn't sound like you have emm386 set for UMBs at all.

Try at least this in config.sys:
device=c:\dos\himem.sys
device=c:\dos\emm386.exe noems highscan
dos=high,umb

The add LH in front of any drivers in autoexec.bat and in config.sys use devicehigh= for anything that's not himem or emm386

To understand PC memory and architecture, It helps to know "Where it came from", and why...

"In the beginning" computers were large rooms filled with racks of electronics, all connected to a "van sized" box full of electronics called the "Central Processor". Processors are classified by "bits" meanoing how many digital "bits" of data can be manipulated in one "cycle". These mainframe systems were often 32, 40, 64, 96 or more "bits".

IBM was a well known maker of these "Big Iron" systems.

As semiconductor technology improved, the needed circuitry could be made smaller, till a company "Intel" decided they could put a limited edition of a proceesor into a single-chip "microprocessor".

The first Intel offering was the 4-bit 4004. Very limited, I don't recall any significant functionality computer using the 4004 .. but it was a game changer in that it showed the ability to "program" functionality instead of hard-wireing...

There next offering was the 8-bit 8008. Much more capable/powerful, you can experience an 8008 computer via my MOD8 simulator.

Then Intel made the 8-bit 8080, more powerful and had a 16-bit memory "Address bus" which allowed it to have 64k of memory. Now enough to make a "real" computer, amd Ed Roberts of MITS created the "Altair" - considered by some to be the first "Personal Computere". You can experience it with my Altair simulator.

Then Intel made the 16-bit 8086 - kept similar to the 8080 to ease converting software. To allow more mamory, the address bus was expanded to 20 bita (1M).

IBM noticed and chose the 8086 to make the "IBM Personal Computer" - the early PC.

To keep it more 8080 like, Intel had introduced the concept of memory "segments" 16-bit registers which make the top 16-bits of the 20-bit memory address. This allowed the processor to still "logically" use 16-bit memory addressing but it could be moved aroung to any 16-byte boundary in the 1M 8086 address space.

There were separate segments for Code, Data and Stack as well as an Extra one for other cases where the code had to go outside it's available memory.

In the original 8086, memopry addressed computed as (segment*16)+Offset which happened to exceed 20 bits (can be as much as 64k-16) wrapped aroud to offset from 0. As still more advanced proceessors had "protected mode" and supported more than 1M of RAM, this became "confusing" - some CPUs would still wrap real mode addressed to offsets from 0, some would flag an error-interrupt, and some would allow access to the (64k-16 bytes) of memory ABOVE 1M ...

There's also Bill Gates famous quote "640k ought to be enough for anyone", about MicroSofts decision to limit DOS to 640K consegutive memory, with I/O devices etc. mapped abote.

Some systems could map actual memory into the area above 640k, and this along with the (64k-16) bytes accessable above 1M became known as various types of "High" memory. And given that there was no official standards on how to allocate or manage it, various "high memory" software drivers became common and required.

And... with more advanced processors and hardware which could be comfigured to access other memory above 1M - systems/drivers were defined to create XMS, EMS etc.

I hope this helps a little ... I've not gone into details, but knowing how it came to be might help understand specifics as you discover them.

EMM386 did the same on my Win98SE tower. UMBPCI and QEMM worked, though. You can find a link to UMBPCI at https://dosprograms.info.tt/indexall.htm under Utilities, and QEMM should be downloadable from[edit by Dominus - please don't post links to warezsites).

Edit: I fixed a typo in the second link. 😀

chronoreverse wrote on 2026-01-02, 19:52:

Doesn't sound like you have emm386 set for UMBs at all. […]
Show full quote

Doesn't sound like you have emm386 set for UMBs at all.

Try at least this in config.sys:
device=c:\dos\himem.sys
device=c:\dos\emm386.exe noems highscan
dos=high,umb

The add LH in front of any drivers in autoexec.bat and in config.sys use devicehigh= for anything that's not himem or emm386

Oh. 😮 Thanks for the suggestion. I'll try that once I'm on the PC. 😀

Harry Potter wrote on 2026-01-03, 00:12:

EMM386 did the same on my Win98SE tower. UMBPCI and QEMM worked, though. You can find a link to UMBPCI at https://dosprograms.info.tt/indexall.htm under Utilities, and QEMM should be downloadable from WinWorldPC.com.

Edit: I fixed a typo in the second link. 😀

I think I downloaded that a short while ago. Still haven't used it though. Is it supposed to be a better but lightweight alternative?

It is but only works on some systems.

DaveDDS wrote on 2026-01-02, 22:23:

To understand PC memory and architecture, It helps to know "Where it came from", and why... […]
Show full quote

To understand PC memory and architecture, It helps to know "Where it came from", and why...

"In the beginning" computers were large rooms filled with racks of electronics, all connected to a "van sized" box full of electronics called the "Central Processor". Processors are classified by "bits" meanoing how many digital "bits" of data can be manipulated in one "cycle". These mainframe systems were often 32, 40, 64, 96 or more "bits".

IBM was a well known maker of these "Big Iron" systems.

As semiconductor technology improved, the needed circuitry could be made smaller, till a company "Intel" decided they could put a limited edition of a proceesor into a single-chip "microprocessor".

The first Intel offering was the 4-bit 4004. Very limited, I don't recall any significant functionality computer using the 4004 .. but it was a game changer in that it showed the ability to "program" functionality instead of hard-wireing...

There next offering was the 8-bit 8008. Much more capable/powerful, you can experience an 8008 computer via my MOD8 simulator.

Then Intel made the 8-bit 8080, more powerful and had a 16-bit memory "Address bus" which allowed it to have 64k of memory. Now enough to make a "real" computer, amd Ed Roberts of MITS created the "Altair" - considered by some to be the first "Personal Computere". You can experience it with my Altair simulator.

Then Intel made the 16-bit 8086 - kept similar to the 8080 to ease converting software. To allow more mamory, the address bus was expanded to 20 bita (1M).

IBM noticed and chose the 8086 to make the "IBM Personal Computer" - the early PC.

To keep it more 8080 like, Intel had introduced the concept of memory "segments" 16-bit registers which make the top 16-bits of the 20-bit memory address. This allowed the processor to still "logically" use 16-bit memory addressing but it could be moved aroung to any 16-byte boundary in the 1M 8086 address space.

There were separate segments for Code, Data and Stack as well as an Extra one for other cases where the code had to go outside it's available memory.

In the original 8086, memopry addressed computed as (segment*16)+Offset which happened to exceed 20 bits (can be as much as 64k-16) wrapped aroud to offset from 0. As still more advanced proceessors had "protected mode" and supported more than 1M of RAM, this became "confusing" - some CPUs would still wrap real mode addressed to offsets from 0, some would flag an error-interrupt, and some would allow access to the (64k-16 bytes) of memory ABOVE 1M ...

There's also Bill Gates famous quote "640k ought to be enough for anyone", about MicroSofts decision to limit DOS to 640K consegutive memory, with I/O devices etc. mapped abote.

Some systems could map actual memory into the area above 640k, and this along with the (64k-16) bytes accessable above 1M became known as various types of "High" memory. And given that there was no official standards on how to allocate or manage it, various "high memory" software drivers became common and required.

And... with more advanced processors and hardware which could be comfigured to access other memory above 1M - systems/drivers were defined to create XMS, EMS etc.

I hope this helps a little ... I've not gone into details, but knowing how it came to be might help understand specifics as you discover them.

Thanks for the lengthy explanation. Some I get the general gist of, though the part about memory addresses and offsets still confuses me. ^^;

Segments and offsets because memory still had to be addressed using 16 bit values in the 8086, but there was a 20 bit wide address bus to allow for more memory (1MB total — largest 20 bit number is 1,048,575). Total memory you could address with a 16 bit bus is 65536 bytes, or 64KB. Hence the splitting into multiple 64KB segments, and 16 bit offsets within those segments, so you choose which segment you want to address with one 16 bit hex value, then you choose the offset with another 16 bit hex value. This scheme gets you 4GB theoretical addressing space, but since the address bus is only 20 bits wide in actuality, only the last four bits of the segment value get used.

So a segment offset combo might look like this:

3000 0F7D

Only that first digit of the segment is getting used here, so you can ignore the others and see that this refers to memory location 30F7D. That’s a 20 bit hex value for the 20 bit address bus, but split into two 16 bit values, one to tell the processor which segment to use, and the other to actually manipulate locations in memory.

When writing assembly code this is how you do it, you select which segment to use, and then subsequent reads or writes to memory all use that segment. It’s a little more complex than that since the CPU can work with up to four segments at once for different purposes, but that’s the gist of it.

This is how all “conventional memory” in DOS works. You get a maximum of 1MB because that’s the maximum 20 bit address.

But obviously people started wanting more than 1MB. On the 8088/8086, this wasn’t strictly possible, but you could get around it by designing a special expansion card with extra memory on it, and using one of the conventional memory segments as a “window” or “page” into that expansion card’s memory. You would tell the card which 64KB chunk of memory the page was to point to, and then access the card’s memory using the same 16 bit offset within the page as you would use with conventional memory, except since you’re not selecting a “segment” with the address bus any more, but with a command sent to an expansion card, you can have up to 65536 “segments”. This is what is meant by EMS. It’s really an idiosyncratically 8088/8086 thing, since it solved the specific problem of the limited 20 bit address bus.

The 286 changed things by adding four more bits to the address bus. Now you could directly address up to 16 MB of memory using the CPU. But for reasons I can’t remember and/or don’t understand right now, you couldn’t access that memory without a driver to “unlock” it, which in the case of DOS was HIMEM. This is what is meant by XMS.

EMM386 was a compatibility solution to emulate the presence of an EMS card on a system where it didn’t make sense to have an EMS card (like a 386, which had a 32 bit address bus, 4GB of addressable memory!) to make programs written for earlier 8088 systems happier. It maps EMS into XMS memory, so you’re really only using XMS in that case. True EMS is always on a dedicated expansion card.

The 8080 has a 16 bit address bus .. meaning it could access:

0=1 1=2 2=4 3=8 4=16 ... 16=65536

bytes of memory, the 8086 has 20 bits = 1M of memory

but ... Intel wanted to maximize 8080 compatibility, and have memory addresses = 16 bits (2 bytes even)

So they made "segments" = 16-bit segment register sets top 16 bits of the 20:

0=16 1=32 2=64 ... 16=1M

To make byte addressable "normal" memory , the address used in a program is added to the segment register to get the full 20 bit address. Thereby the convention segment:offset

segment = 16-byte block of memory between 0 and 1M
offset = 1 byte effective memory address between 0-65535 added to the segment address.

keenmaster486 wrote on 2026-01-03, 13:37:

Segments and offsets because memory still had to be addressed using 16 bit values in the 8086, but there was a 20 bit wide addre […]
Show full quote

Segments and offsets because memory still had to be addressed using 16 bit values in the 8086, but there was a 20 bit wide address bus to allow for more memory (1MB total — largest 20 bit number is 1,048,575). Total memory you could address with a 16 bit bus is 65536 bytes, or 64KB. Hence the splitting into multiple 64KB segments, and 16 bit offsets within those segments, so you choose which segment you want to address with one 16 bit hex value, then you choose the offset with another 16 bit hex value. This scheme gets you 4GB theoretical addressing space, but since the address bus is only 20 bits wide in actuality, only the last four bits of the segment value get used.

So a segment offset combo might look like this:

3000 0F7D

Only that first digit of the segment is getting used here, so you can ignore the others and see that this refers to memory location 30F7D. That’s a 20 bit hex value for the 20 bit address bus, but split into two 16 bit values, one to tell the processor which segment to use, and the other to actually manipulate locations in memory.

When writing assembly code this is how you do it, you select which segment to use, and then subsequent reads or writes to memory all use that segment. It’s a little more complex than that since the CPU can work with up to four segments at once for different purposes, but that’s the gist of it.

This is how all “conventional memory” in DOS works. You get a maximum of 1MB because that’s the maximum 20 bit address.

But obviously people started wanting more than 1MB. On the 8088/8086, this wasn’t strictly possible, but you could get around it by designing a special expansion card with extra memory on it, and using one of the conventional memory segments as a “window” or “page” into that expansion card’s memory. You would tell the card which 64KB chunk of memory the page was to point to, and then access the card’s memory using the same 16 bit offset within the page as you would use with conventional memory, except since you’re not selecting a “segment” with the address bus any more, but with a command sent to an expansion card, you can have up to 65536 “segments”. This is what is meant by EMS. It’s really an idiosyncratically 8088/8086 thing, since it solved the specific problem of the limited 20 bit address bus.

The 286 changed things by adding four more bits to the address bus. Now you could directly address up to 16 MB of memory using the CPU. But for reasons I can’t remember and/or don’t understand right now, you couldn’t access that memory without a driver to “unlock” it, which in the case of DOS was HIMEM. This is what is meant by XMS.

EMM386 was a compatibility solution to emulate the presence of an EMS card on a system where it didn’t make sense to have an EMS card (like a 386, which had a 32 bit address bus, 4GB of addressable memory!) to make programs written for earlier 8088 systems happier. It maps EMS into XMS memory, so you’re really only using XMS in that case. True EMS is always on a dedicated expansion card.

This is something I'll need to re-read a few times, I reckon. :p

chronoreverse wrote on 2026-01-02, 19:52:

Doesn't sound like you have emm386 set for UMBs at all. […]
Show full quote

Doesn't sound like you have emm386 set for UMBs at all.

Try at least this in config.sys:
device=c:\dos\himem.sys
device=c:\dos\emm386.exe noems highscan
dos=high,umb

The add LH in front of any drivers in autoexec.bat and in config.sys use devicehigh= for anything that's not himem or emm386

What exactly does the Highscan switch do? Made the changes you suggested and now I have UMBs working. Thanks. Only 42K of 147K has been used so far. And now I have 27K used of 637K in Conventional Memory. 😀

Highscan tells EMM386 to perform an extra scan for UMB memory. I don't know how it works, though. BTW, I'm curious: may I see the output from "mem/c/p"? I may be able to help you optimize your memory config. 😀

Harry Potter wrote on 2026-01-03, 23:32:

Highscan tells EMM386 to perform an extra scan for UMB memory. I don't know how it works, though. BTW, I'm curious: may I see the output from "mem/c/p"? I may be able to help you optimize your memory config. 😀

Sure. I had a feeling you might. 😄

Thank you. 😀 Why aren't SHSUCDX and SBEGO loaded high? Also, I'm curious: what does SBEGO do? I may want it. 😀

Harry Potter wrote on 2026-01-03, 23:56:

Thank you. 😀 Why aren't SHSUCDX and SBEGO loaded high? Also, I'm curious: what does SBEGO do? I may want it. 😀

I thought they were? Will have to double check those.

SBEGO is basically SBEINIT for the Sound Blaster. To stop it from putting the command back into autoexec and initialising it, I had help tricking the computer into loading a dummy SBEINIT and rename the original to SBEGO as and when I want to use it for a game. 😀

EDIT: Yeah, so SBEGO is only called when I need it, so there’s no point setting that to High. For my EMS boot (DOS1), I have SHSUCDX set to LH in autoexec.bat. Well, assigning the driver anyway. The actual loading of the program doesn’t happen unless I load a game via a custom BAT file.

Okay. BTW, I have a problem with my Win98SE tower's sound card in DOS mode: it doesn't even register in my games. 🙁 I don't think it's a true SoundBlaster but am wondering if maybe a DOS-based driver can get it to work. Where can I download your SB drivers?

Harry Potter wrote on 2026-01-04, 00:56:

Okay. BTW, I have a problem with my Win98SE tower's sound card in DOS mode: it doesn't even register in my games. 🙁 I don't think it's a true SoundBlaster but am wondering if maybe a DOS-based driver can get it to work. Where can I download your SB drivers?

What SB card do you have? Mine's the Live Value CT4670. I was fortunate that mine came with the original driver CD. If you have the same, or similar model, I'd be happy to make an image of it. 😀 They may even be on Internet Archive.

DustyShinigami wrote on 2026-01-04, 00:38:

EDIT: Yeah, so SBEGO is only called when I need it, so there’s no point setting that to High. For my EMS boot (DOS1), I have SHSUCDX set to LH in autoexec.bat. Well, assigning the driver anyway. The actual loading of the program doesn’t happen unless I load a game via a custom BAT file.

It's always worth loading high anything that's a TSR, even if you only use it on occasion. LH and DEVICEHIGH everything, DOS will just load it into conventional memory if upper and high memory is not available. The only exception is if there's a known compatibility issue or if it has self-managed high memory management (e.g. smartdrive).