It's automatically loaded in MS-DOS 7.1 but if you explicitly set it to DEVICEHIGH it can load high. Although 619K is enough to run any program so it doesn't matter that much at this point. You can add back in your other startup programs and then rebuild the menus based on the working startup files.

chronoreverse wrote on Yesterday, 13:52:

It's automatically loaded in MS-DOS 7.1 but if you explicitly set it to DEVICEHIGH it can load high. Although 619K is enough to run any program so it doesn't matter that much at this point. You can add back in your other startup programs and then rebuild the menus based on the working startup files.

Can't seem to shift it. I've tried DEVICEHIGH in config.sys above the first instance of DOS, within it, and using LH in autoexec.bat.

All DEVICEHIGH must come after the XMS and UMB drivers (respectively HIMEM.SYS and EMM386.EXE for you). I wouldn't bother and frankly, most of the time you could even not have it on at all (edit MSDOS.SYS after running "attrib -r -h -s msdos.sys" and add the line "DoubleBuffer=0" under Options).

DustyShinigami wrote on Yesterday, 17:41:

chronoreverse wrote on Yesterday, 13:52:

It's automatically loaded in MS-DOS 7.1 but if you explicitly set it to DEVICEHIGH it can load high. Although 619K is enough to run any program so it doesn't matter that much at this point. You can add back in your other startup programs and then rebuild the menus based on the working startup files.

Can't seem to shift it. I've tried DEVICEHIGH in config.sys above the first instance of DOS, within it, and using LH in autoexec.bat.

'doublebuffer=true'

Might be getting called in msdos.sys.

I've tried both suggestions. Doublebuffer=True is indeed in MSDOS.SYS. Putting that to 0 and adding it to config.sys instead gives me an 'unrecognised command error' on boot. I've tried disabling it in MSDOS.SYS, putting DEVICEHIGH and the path for DBLBUFF.SYS after HIMEM and EMM386, but it no longer appears in the mem checker at all rather than in the Upper Memory.

Did some quick tests and it looks like DBLBUFF can't be loaded high. So leave out the lines in config.sys and autoexec.bat, then just set it off in msdos.sys since you're unlikely to need it.

The only way to avoid loading DBLBUFF and IFSHLP is to use DOS=HIGH,UMB,NOAUTO

But you also need to make sure you change FILES/STACKS/LASTDRIVE/FCBS to FILESHIGH/STACKSHIGH/LASTDRIVEHIGH/FCBSHIGH to load those into high memory manually as this is usually done automatically with auto high memory

You need IFSHLP for Windows so there's almost never a reason to use NOAUTO (and you'll always use a bit more conventional memory with NOAUTO even if you've loaded everything HIGH explicitly). As mentioned before, DBLBUFF can be turned off just by adding DoubleBuffer=0 into MSDOS.SYS

Okay, I'll turn it off. If it concerns older HDD controllers then, yeah, I'm unlikely going to need it. Thanks, guys. 😀

One question I have, and this concerns other memory managers like what was suggested earlier - like UMBPCI - do those also affect pickier games, such as the LucasArt's classics? I've read those games are fussy with EMS, so was wondering if other managers cause the same problem with them? Or are they more compatible?

Generally speaking, if those pickier games are affected by EMM386 (and equivalents) then it's more specifically the use of V86 instead of real mode causing problems and UMBPCI's advantage is that it leaves the system in real mode so it can help avoid that issue. My advice is to not worry about it until you actually run across such a game and just have a boot menu for EMS on and EMS off for now. Unless you're planning to play Ultima 7 since it cannot have EMM386 running at all.

To be fair, I find it fun to play around with this so I have mine set up to use UMBPCI and not load EMM386 at all normally. Instead, my game launch batch files use JEMM386 to load EMS as needed and then unload after the game exits.

chronoreverse wrote on Today, 16:19:

Generally speaking, if those pickier games are affected by EMM386 (and equivalents) then it's more specifically the use of V86 instead of real mode causing problems and UMBPCI's advantage is that it leaves the system in real mode so it can help avoid that issue. My advice is to not worry about it until you actually run across such a game and just have a boot menu for EMS on and EMS off for now. Unless you're planning to play Ultima 7 since it cannot have EMM386 running at all.

To be fair, I find it fun to play around with this so I have mine set up to use UMBPCI and not load EMM386 at all normally. Instead, my game launch batch files use JEMM386 to load EMS as needed and then unload after the game exits.

Okay. Well, I have a boot menu for EMS and one with it disabled and only HIMEM enabled. I’ll probably add one eventually to load UMBPCI. I read about it staying in Real Mode.

One Lucas game I’ve played so far where EMS could be an issue is with Fate of Atlantis. I’ll be playing it for a few minutes and everything just freezes. Music plays, but gets stuck in a loop and I can’t move the mouse cursor.

Might just be the CPU being too fast. Try something like Throttle or CPUSpd to downclock, set throttle states or even disable cache.

chronoreverse wrote on Today, 17:24:

Might just be the CPU being too fast. Try something like Throttle or CPUSpd to downclock, set throttle states or even disable cache.

Could be, yeah. I’ll try that in a sec. Gonna test XMS first.

Also, as my EMS is set to NOEMS, I’m guessing that means I’ve not been in Protected Mode? That I’ve not been using EMS this whole time? 😅

Protected Mode, V86 and Real Mode are not directly related to EMS as you can have virtual or physical EMS in all three.

However, if you have EMM386 loaded, your DOS session is automatically in V86. EMM386 uses Protected Mode to provide both virtual EMS and UMB but makes your DOS session run in V86. With NOEMS, then EMM386 will only provide UMB (for DEVICEHIGH and LH). If you use UMBPCI for UMB then you can load EMM386 (or JEMM386 since it can unload itself) only if you need EMS.

This can conflict with games that can't run in V86 while needing EMS but luckily there's an alternate way to have virtual EMS in real mode: EMS Magic. Version 2.1 is free so you can try it out (although I haven't had any luck with getting it to work and only an older version works for me. None of the games I play conflicts with JEMM386 EMS though so I just use that now).

As for Protected Mode, generally games will switch to that mode and then back out on their own. There are subtleties with VCPI and DPMI but you really only need to deal with it if it comes up in the rare occasion it does and there is plenty of information in the forums with the details.

chronoreverse wrote on Today, 19:30:

Protected Mode, V86 and Real Mode are not directly related to EMS as you can have virtual or physical EMS in all three. […]
Show full quote

Protected Mode, V86 and Real Mode are not directly related to EMS as you can have virtual or physical EMS in all three.

However, if you have EMM386 loaded, your DOS session is automatically in V86. EMM386 uses Protected Mode to provide both virtual EMS and UMB but makes your DOS session run in V86. With NOEMS, then EMM386 will only provide UMB (for DEVICEHIGH and LH). If you use UMBPCI for UMB then you can load EMM386 (or JEMM386 since it can unload itself) only if you need EMS.

This can conflict with games that can't run in V86 while needing EMS but luckily there's an alternate way to have virtual EMS in real mode: EMS Magic. Version 2.1 is free so you can try it out (although I haven't had any luck with getting it to work and only an older version works for me. None of the games I play conflicts with JEMM386 EMS though so I just use that now).

As for Protected Mode, generally games will switch to that mode and then back out on their own. There are subtleties with VCPI and DPMI but you really only need to deal with it if it comes up in the rare occasion it does and there is plenty of information in the forums with the details.

Wow. A lot to get my head around here. 😅 I’m very new to the world of EMS and V86 etc. I will need to play around with UMBPCI soon.

Also, disabling the L2 cache and trying HIMEM didn’t work for Fate of Atlantis. I’m still getting freezes. Tried CPUSPD as well.

It doesn't look like that game needs EMS or XMS at all so you could try booting with just himem.sys or no memory manager at all to see if it still has the freeze. Another possibility is the CuteMouse driver. Could try a different version or Microsoft Mouse 9.00 (mouse.exe).

I try to use mouse.exe unless I'm on a system that has very few UMBs (or I need them for something memory intensive) just to avoid hard to diagnose issues.

chronoreverse wrote on Today, 20:05:

It doesn't look like that game needs EMS or XMS at all so you could try booting with just himem.sys or no memory manager at all to see if it still has the freeze. Another possibility is the CuteMouse driver. Could try a different version or Microsoft Mouse 9.00 (mouse.exe).

I try to use mouse.exe unless I'm on a system that has very few UMBs (or I need them for something memory intensive) just to avoid hard to diagnose issues.

Yep, I've tried all of those. Himem, plain DOS with only a CD-ROM driver, I've tried CuteMouse 1.9, 2.04A, and 2.1. I'll have to try the regular mouse.exe next. The Monkey Island Ultimate Talkie Edition is the other game I'm having similar problems with. I did read that the type of mouse could be an issue, so I may have to look into getting a serial mouse.

Good luck! Half the fun of retrogaming is detective work to find out why things aren't working haha!

I use Cutemouse 1.9.1 [DOS] and I don't have these problems with these programs. Unless you think your particular hardware has a problem with Cutemouse I would focus on other possibilities.

I need to see what IRQ the mouse is set to. See if it's conflicting with anything. I have 1.9. Not sure if that's the same or if 1.9.1 is different...? I'll try (re)downloading it to see.