Hi everyone,
I am using the menu in config.sys and autoexec.bat on a regular basis but for some reason, most of the games run on my standard configuration with:
Today I tried to use EMM386.EXE NOEMS to see if that brings something. The result was Cannon Fodder 2 went into a black screen even before it started and the computer beeped one time. I dont know why it froze this way.
This is a P90 with 16 MB of RAM and a IDE Flash Module as HDD.
Now to my question. I remember that, with my 486SX25 I had to do use multiple different configurations to let Al Qadim and other games run. But on the P90 it seems to run with the above configuration. Is that because I have so much RAM for these old games or am I just lucky that the configuration is leaving sufficient memory for the games which I select to play?
Also, I see a lot of examples where they use options with reserved memory blocks and so on to archive a certain system state.
Does that only enable games to start if they want more memory or do these options also have impact on the performance of the games? I means there are also BUFFERS, FILES and STACKs options and I am not sure if I should play around with all of these if this brings nothing but to start more thirsty games which I have not yet found.
Do you know if there is a post or a collection of these config.sys and autoexec.bat variants with some description like "use this one if you have the following need" or "this runs game X perfectly"?
Well...if you're looking for more DOS memory, you can find CuteMouse and more efficient CD-ROM drivers along with other stuff at https://dosprograms.info.tt/indexall.htm#utils. You can also try QEMM. It gives more memory than EMM386. BTW, most DOS games use only Conventional memory. Maybe your P90 has more Upper memory to put drivers, or maybe you have fewer things to load at start-up.
Joseph Rose, a.k.a. Harry Potter
Working magic in the computer community
According to this post (Cannon Fodder 2 problem) that game requires EMS, so it's no shock that the NOEMS option caused you problems.
The reason to pass NOEMS is to free the EMS page frame and obtain 64KB more upper memory blocks. If you have so much loaded "high" in config.sys and autoexec.bat that UMBs are full in the EMS configuration, NOEMS could free more conventional memory.
You shouldn't blindly pass I= options to EMM386. They might not pertain to your system, or the video mode you game uses (especially with that B000 one).
After getting your system into a configuration where the games you want to run work, you could post MEM output here and get a second opinion as to whether you're in a reasonable configuration or not. (e.g., there was another thread where the poster was in a sub-500KB free conventional memory range, while there are others with 615KB or so free and frustrated they don't have even more...)
Interesting thread. I'd love if there was a wiki page or something with all these types of details, I just go on blind faith sometimes with my configs based on what other people have done but I never took the time to understand what each thing was doing.
If this is dos 6.22, please run msd after pressing F5 on boot to skip config.sys and autoexec.bat, then post a pic of the memory browser page.
We can get an inkling of what includes might be possible, or where to forcibly place the ems pageframe, to squeeze the most out of your specific system.
Keep in mind that you don't really need the absolute last kb you can have (except if it's because of compulsiveness or experimentation).
Many people didn't even have a menu, but a EMM386 line with NOEMS active and a second one below it with RAM commented out and just enabled one or the other. By the time MSDOS with menu capabilities was released the games requiring EMS were fewer and fewer. The cases where just switching from NOEMS to RAM wasn't enough and you needed to manually exclude things from loading were even more rare.
Of course if today you have a broad range of games you want to be able to play on the same PC a menu option for a tailored EMS configuration makes more sense that back then.
I will post my config.sys and autoexec.bat soon. With what was said above, it looks (to me) more like the challenge to get the memory free was to be able to start the games. The games performance seems to no be impacted by how your config.sys and autoexec.bat were loading things. If it starts, it runs with what CPU, RAM, HDD, GPU speed can provide right?
First configuration is for UNISOUND testing. Second configuration is for Windows 3.1. Last configuration is my main standard configuration with "standard" drivers. The Soundblaster Vibra 16C has a Serdashop MIDI X16GS attached to the wavetable.
Question: What is the impact of these 4 and when to use what best? I think there is a more significant difference, the older the computer is.
Files and Buffers:
1FILES=40 2BUFFERS=30
Question: Same in the gaming context. Does it make sense to even have them?
Unknown parameters:
1STACKS=9,256 2FCBS=4
Question: Same for those. Looks like some people have them in their configs but it is never explained why.
If I look up those parameters in DOS documentations, they make no sense for DOS gaming.
Windows 3.1: If you look at my Windows 3.1. config and autoexec configurations, do you have some recommendations? Windows runs great, I just want to see if I missed something or if things could get removed.
Sorry for the big number of questions, I want to understand my system a bit better but I have several "gaps" to fill. And I really appreciate all the help here from all of you. Thank you.
About EMM386, I don't remember what 4096 does, but NOEMS disables EMS memory to gain 64k more UMBs, HIGHSCAN performs an extra check for more UMBs, and I=B000-B7FF uses the 32k mono buffer for more UMBs. BTW, you can find more efficient drivers at https://dosprograms.info.tt/indexall.htm#utils, and QEMM is good at buying more UMBs. Gry them out! BTW, I like DOS memory configurations. May I see yours? Just type "mem/c>c:\memc.txt" and "mem/d>c:\memd.txt" and attach the resulting files. 😀
Joseph Rose, a.k.a. Harry Potter
Working magic in the computer community
First configuration is for UNISOUND testing. Second configuration is for Windows 3.1. Last configuration is my main standard configuration with "standard" drivers. The Soundblaster Vibra 16C has a Serdashop MIDI X16GS attached to the wavetable.
Question: What is the impact of these 4 and when to use what best? I think there is a more significant difference, the older the computer is.
Files and Buffers:
1FILES=40 2BUFFERS=30
Question: Same in the gaming context. Does it make sense to even have them?
Unknown parameters:
1STACKS=9,256 2FCBS=4
Question: Same for those. Looks like some people have them in their configs but it is never explained why.
If I look up those parameters in DOS documentations, they make no sense for DOS gaming.
Windows 3.1: If you look at my Windows 3.1. config and autoexec configurations, do you have some recommendations? Windows runs great, I just want to see if I missed something or if things could get removed.
Sorry for the big number of questions, I want to understand my system a bit better but I have several "gaps" to fill. And I really appreciate all the help here from all of you. Thank you.
The 4096 argument tells emm386 to supply a maximum of 4mb (4096k) of EMS memory.
The basic educational primer:
The original IBM pc/xt used an 8 bit processor, that had a 24bit address bus. It could only address/work with, 1MB of address space.
To keep things reasonably simple, they put the system rom bios code at the very top of this memory (F000-FFFF), and the system's RAM at the very bottom. (0000-9FFF, iirc).
The space between is the 'Adapter ROM region', and has historically been used for specific devices for memory mapped IO, and for option roms.
Such devices include display adapters of various kinds, like monochrome, CGA, EGA, and VGA cards.
VGA cards supply backward compatability with older display hardware types (monochrome, cga, ega) and thus appear logically as if all 3 of those old technologies are present.
Monochrome display adapter uses the memory between address B000 and BFFF, as does CGA.
EGA/VGA uses the memory between A000-AFFF.
VGA uses C000 to CBFF or CFFF, for the VGA rom bios. *SOMETIMES* there is a valid 'hole' in the memory map at CC00-CFFF that you can include as UMB, but this is very video rom specific, and is one of the reasons I need to see what your system's raw memory map (without ANY drivers loaded) looks like.
D000-EFFF is then 'usually free', and was *intended* to be the address range for things like disk controllers, NIC cards, and bespoke memorymapped IO applications.
Later, with the 286, this was expanded, and the CPU could see more than 1mb of address.
The old 8bit mode became known as 'real mode', and the newer mode was called 'protected mode'
Legit, actual DOS lives in real mode, and retains the 1mb limitation. Various 'dos extenders' were written, to permit DOS programs to work with memory above 1mb, by putting the cpu into either 'unreal mode' (a colloquialism for the 'unofficial/not officially supported' state of a 286 that has been switched to protected mode, then been issued the LOADALL instruction to force it back into using segment:offset addressing. The 286 has no official way to return to actual real mode other than a soft reset/reboot. Thus, 'unreal mode') or v86 mode (for 386 or better).
However, BEFORE either of those, there were memory hungry use cases that needed more ram to work with, despite the lack of address space to stick it in.
This is when/why/how EMS became a thing.
EMS is one of those 'bespoke memory mapped IO' applications, in that it works by claiming a 64kb 'window' of address space, and uses a mapper chip (in the original EMS hardware designs) and an IO port address, to permit programs to page in and out of a significantly larger pool of ram, through that window. The LIM (Lotus, Ibm, Microsoft) EMS specification created a standardized API for software to use, (and for hardware to follow), to be able to see, query, and work with, such RAM.
In addition to EMS, there were also some RAM cards that simply provided RAM inside these unused addresses. This memory, when present, is called 'upper memory.'
EMM386 is an EMS emulator. (It does more than that, but predominantly, it's an EMS emulator.) Instead of a hardware mapper chip, it makes use of the integrated MMU baked into 386 and newer CPUs, and v86 mode, to remap RAM above 1mb, in and out of the 64kb window.
It is this use of the MMU that allows it to also provide upper memory, by simply mapping RAM from above 1mb, into the adapter rom region.
The nomenclature for the 'window' needed to access EMS specification memory, is 'EMS Page Frame'.
When you tell emm386 to not create this page frame, with the NOEMS argument, the space that the page frame occupied (64kb in size) becomes free to use as UMBs instead.
DOS does not normally use or mess with RAM above 9FFF, (top of conventional / 640k memory), and needs to be TOLD to use such memory. That's what 'DOS=HIGH,UMB' *does*. It tells DOS that more than 1mb of RAM is present, And to use the high memory area (the memory just ab.ove 1mb) and these blocks of RAM for program, and TSR applications, so that conventional memory remains clear/available to user programs.
The INCLUDE statement, 'I=XXXX-XXXX', tells ezmm386 to specifically claim the address range specified, and use the MMU to map RAM from above 1mb into that address range, then tell DOS about it / to use it as upper memory.
Again, the *intended use* of the adapter rom region, is as a place for ROM, and memory mapped IO. Things can be living there already, and may be 'very much' already being 'used' One can expect things like USB keyboard/mouse ROM routines, AHCI/SATA disk controllers, etc, to be living there, and as such, those things should never be mapped over with general purpose ram.
The EXCLUDE statement, is used to tell EMM386 about these things, and is basically telling emm386 to NEVER touch that address.
The ROM statement, tells EMM386 to copy the data from such a system ROM, into RAM, THEN, map that ram in, righ at the same location the ROM chip was using. This is able to speed up whatever programs were using that rom routine, as the system RAM is much faster to access, than the ROM chip out on the peripheral bus.
Since the areas used to create UMBs are dependent upon what ROMS, and where they are placed, are present, I need to see your memory map PRIOR to EMM386 mapping things in and out.
That's why I requested a screenshot of MSD's memory browser window, without EMM386 running.
You have a very nice and clean upper memory area, with a single contiguous block between C800 and EFFF. That's around 160kb in size, very nice, and quite spaceous.
Which grabs the 32k from the framebuffer, grabs 64k starting at C800 for the pageframe, then leaves a very large contiguous block after that, up through F7FF. (Aparently your BIOS doesnt mind getting parts of it clobbered. This is atypical, but if the system is reliable with reclaiming that area and doesnt do stupid squirrely shit, that's another 32k clawed back.)
*edit
(Broke up the includes pedantically to prevent emm386 complaining about region overlap.)
If it's stable, option 2 is preferable. UMB is less fragmented, and more useful.
If your bios does not already shadow the vga bios, adding
ROM=C000-C7FF
To either one can net you a slight boost on video performance, especially in VESA modes.
You have a very nice and clean upper memory area, with a single contiguous block between C800 and EFFF. That's around 160kb in size, very nice, and quite spaceous.
Which grabs the 32k from the framebuffer, grabs 64k starting at C800 for the pageframe, then leaves a very large contiguous block after that, up through F7FF. (Aparently your BIOS doesnt mind getting parts of it clobbered. This is atypical, but if the system is reliable with reclaiming that area and doesnt do stupid squirrely shit, that's another 32k clawed back.)
*edit
(Broke up the includes pedantically to prevent emm386 complaining about region overlap.)
If it's stable, option 2 is preferable. UMB is less fragmented, and more useful.
If your bios does not already shadow the vga bios, adding
ROM=C000-C7FF
To either one can net you a slight boost on video performance, especially in VESA modes.
Thanks weird_w
So I tried you recommendation and did the following:
First attempt: DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF I=C800-EFFF FRAME=E000 NOTR
Result: Not much of an improvement
Second attempt: DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF I=C800-CFFF I=D000-EFFF I=F000-F7FF FRAME=C800 NOTR
Result: Not much of an improvement
Third attempt: DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF I=C800-EFFF FRAME=E000 ROM=C000-C7FF NOTR
Result: Not much of an improvement
Fourth attempt: DEVICE=C:\DOS\EMM386.EXE RAM I=B000-B7FF I=C800-CFFF I=D000-EFFF I=F000-F7FF FRAME=C800 ROM=C000-C7FF NOTR
Result: Somehow this one feels a bit faster than the others, but I cannot describe how
In cannon fodder you sometimes experience that the game slows down during shooting and you hear that because the shooting sounds start to sound a bit draggy/slower. This happens less with the last configuration but I am not sure if this also does not happen with the 3 other configs above and I just felt it was slightly better with the last one. Also, Cannon Fodder 2 has the reputation of being a bad port from Amiga and I have never played anything on the Amiga so I have no comparison. But when I look at the the Youtube videos, it seems there are entire sets of sound effects are missing on the PC.
Again, thank you very much for the help and I hope I adjusted my config.sys correctly.
The last one is shadowing the video rom, and has the page frame near the top of UMB (and thus is less likely to have memory fragmentation).
Arguably, some very tiny performance increase might be squeezed by attempting to align the includes to the sizes of structures, and to 32k or 64k boundaries (because of how EMM386 works).
Eg, since the pageframe is at C800, making the include that supplies this block be contiguous (eg, I=C800-D7FF), then trying to shore things up to align at 32k/64k boundaries (I=D800-DFFF I=E000-EFFF I-F000-F7FF).
Is it really worth it? Probably not.
Additionally, shadowing the system bios (rom=F800-FFFF) might also net a modest improvement for things like disk IO.