Page 1 of 1

EMM386 parameters

Posted: Tue Sep 22, 2020 1:19 am
by vorvek
Hello, I've been checking the forums to see what people have been using to deal with expanded memory under DOS. I've seen a few examples, and I've tried with my usual settings, but I keep getting problems in games that I assume are related to my configuration.

If I load EMM386.EXE simply as "DEVICE=C:\DOS\EMM386.EXE" it will complain about not being able to set a frame page. In my real 486, I use the following config, that so far has given me no issues:

Code: Select all

DEVICE=C:\DOS\EMM386.EXE AUTO RAM M3 A=64 H=128 D=256 HIGHSCAN X=B800-C7FF I=C800-EFFF I=B000-B7FF NOTR
ao486 didn't seem to like it, so I searched the forums and currently I have it set up as this:

Code: Select all

DEVICE=C:\DOS\EMM386.EXE RAM FRAME=C800 D=64 X=A000-C7FF I=D000-EFFF NOTR
However, as I mentioned, it seems that many of the games I try end up crashing after a few minutes, or at specific points, with what looks like various memory errors. Is there a recommended set of parameters for MiSTer?

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 5:09 am
by throAU
With FreeDOS I ended up using FRAME=E000 and it seems fine so far, I'm not sure where you got frame=c800 from but if it overlaps something else in memory that could be the cause of your crashes.

Try replacing frame=c800 with frame=e000 in your emm386 configuration and see if it helps? Different OS, but I copied that address from someone else who was using it with EMM386 on MS-DOS :D

I'm not at home at the moment but can maybe check tomorrow for the rest of my parameters for the JEMM memory manager in FreeDOS.

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 9:24 am
by vorvek
I'd appreciate it. I haven't had much luck with JEMMEX with the core, but I only gave it a quick test a couple of versions ago.

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 9:48 am
by chimaera
I have done some testing with JEMMEX but I havent found any real advantage over EMM386. In fact, I had som compability issues with JEMMEX/JEMM386. One example is Win3.11 that has problems with sound when using JEMM.

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 1:29 pm
by Sorgelig
X=CE00-CFFF must be added

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 1:48 pm
by vorvek
Sorgelig wrote: Tue Sep 22, 2020 1:29 pm X=CE00-CFFF must be added
Is A000-CDFF usable in ao486?

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 6:06 pm
by Sorgelig
You need to learn base 1MB memory map of PC. A000-BFFF is video memory area. It may vary depending on video mode. C000-C7FF is VGA ROM. How EMM386 handles it - i don't know.

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 7:03 pm
by HMPoweredMan
I'm currently at 615k conventional memory at boot. Is there even a benefit to optimizing further?
Is there more that can be done to optimize performance?

Re: EMM386 parameters

Posted: Tue Sep 22, 2020 7:31 pm
by guddler
If it were me I’d leave it there until such time as you come to run something that won’t. Part of my job used to be to optimise the PCs in production to squeeze as much free base memory out of them as possible but that was 25+ years ago and I’ve forgotten pretty much all of it by now.

I do know that we didn’t use qemm. I remember we did try it but the gain simply didn’t justify the cost or the complexity. I got far more free memory out of migrating all the systems to OS3 Warp if memory serves me right. Over 700k free because it didn’t have the same limitation that DOS had.

I wonder what the requirements for that would be? That would be a nostalgia trip and a half!

[edit] OS/2 Warp? Hell I can’t even remember the name now!!

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 2:35 am
by vorvek
Well, I've tried every address I could think of, I couldn't get a proper page frame working. Jemmex gave me the same sort of problem, and QEMM, as some others have mentioned in the forum, doesn't currently work with the core (in my case it fails during the second run of OPTIMIZE). I get plenty of conventionaal memory (617KB), but that's it. I guess I'll let a few versions go by and give it another try in the future. I hope my MiSTer isn't broken.

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 6:06 am
by throAU
Yeah to clarify the only reason I'm using JEMM is because I'm running FreeDOS and it is included by default.

I figured I hadn't used FreeDOS before, and its free (and still developed :D) so I'd see how I go :)

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 7:27 am
by Cebion
Isn't 617 k way more than needed? What is your goal, do you have any problem with a problem with a specific game?!

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 7:32 am
by CapnChaosDK
I only know of one game that is really hungry for conventional mem and that is Dune 2, with all sounds effects and music it consumes around 620. Then that should also be doable with small CD driver and CTmouse, that is the only things you need and that be stays i UMB.

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 10:59 am
by flynnsbit
I've got mine to 628k and I am working on a tiny vhd version I will post somewhere.

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 2:56 pm
by vorvek
Cebion wrote: Thu Sep 24, 2020 7:27 am Isn't 617 k way more than needed? What is your goal, do you have any problem with a problem with a specific game?!
I don't want more memory, I want to set a frame page, that many games do require. For example, One Must Fall 2097 will crash as soon as I pick a robot (but will play the demo combat fine).

Getting ~600KB is usually enough. Dragon Lore for example requires 592KB free + mouse + CD-ROM, and I don't think I've ever played a game that requires more, although I'm pretty sure there are a few. I mean, I don't care if I got 700KB+ of free conventional memory, if I cannot run anything I want because it crashes :lol:

Now, the fact that some memory management software works, and some doesn't, makes me think that ao486 needs a bit of extra polishing somewhere, and that that might be the reason I cannot find any working address for my frame page. If nobody else has an issue with this, it might be my DE10, or my DOS installation (which is just a barebones DOS 6.22, Spanish version with vide-cdd, cutemouse and unisound).

In any case, I've spent quite a few hours trying to make it work, and haven't been able to. And at this point, having a real 486DX2 @66 Mhz, and a Pentium MMX 200MHz for anything Windows 95 and earlier, I'm just giving up and letting the core mature a bit more. Maybe in a few months I won't have these issues. I'm fine with that.

Re: EMM386 parameters

Posted: Thu Sep 24, 2020 4:24 pm
by zomgugoff
vorvek wrote: Thu Sep 24, 2020 2:56 pm I don't want more memory, I want to set a frame page, that many games do require. For example, One Must Fall 2097 will crash as soon as I pick a robot (but will play the demo combat fine).

Getting ~600KB is usually enough. Dragon Lore for example requires 592KB free + mouse + CD-ROM, and I don't think I've ever played a game that requires more, although I'm pretty sure there are a few. I mean, I don't care if I got 700KB+ of free conventional memory, if I cannot run anything I want because it crashes :lol:

Now, the fact that some memory management software works, and some doesn't, makes me think that ao486 needs a bit of extra polishing somewhere, and that that might be the reason I cannot find any working address for my frame page. If nobody else has an issue with this, it might be my DE10, or my DOS installation (which is just a barebones DOS 6.22, Spanish version with vide-cdd, cutemouse and unisound).

In any case, I've spent quite a few hours trying to make it work, and haven't been able to. And at this point, having a real 486DX2 @66 Mhz, and a Pentium MMX 200MHz for anything Windows 95 and earlier, I'm just giving up and letting the core mature a bit more. Maybe in a few months I won't have these issues. I'm fine with that.
I've had similar failings with different memory managers, but emm386 seems to be the most compatible. Here is the line I'm currently using for DOS 6.22:

device=c:\dos\emm386.exe 15264 RAM D=256 FRAME=E000 X=A000-C7FF X=CE00-CFFF I=D000-EFFF NOTR

The somewhat odd amount of extended memory specified is the most EMM386 reports it can use. I also tried excluding A000-CFFF, but I had issues, so there are 2 exclusions. I still have issues with any CD driver when loaded, so I try not to use it unless I'm installing/playing something that needs it, but I found SHSUCD to be usable for most CD games I play.

OMF2097 works just fine.

Re: EMM386 parameters

Posted: Fri Sep 25, 2020 12:12 pm
by luishg
vorvek wrote: Thu Sep 24, 2020 2:56 pm If nobody else has an issue with this, it might be my DE10, or my DOS installation (which is just a barebones DOS 6.22, Spanish version with vide-cdd, cutemouse and unisound).
Hi Vorvek,

I agree, something is happening with this core regarding compatibility.

Perhaps is my impression. But computers from this era (having quite different configurations) had a very clear compatibility behaviour. I mean, you would expect to get working any game over minimun requirements. I felt that any of my DOS games would work on my computer firends -meeting requieremet-.

I had several configurations based on 286, 386, 486, and you would not find so much games not working between them. Now we have a quite large list of old games crashing. Yes, you would need some more power to play at full speed, or perhaps you needed more memory or some random crashes... but not this kind of very different games not even working, from the older ones to the late 486 games or those using DOS4GW.


I see people talking about how bad most of these games were programmed, how you can use other memory management programs, more modern tools like DOS32 replacements or even freeDOS or DOS7.1, so this is not a problem of the core, OK. But we should aim to compatibility, not speed, response, new features or running OSs designed for other processors. Arcade or console cores have their own performance metrics to be compared, but DOS should be more a matter of having a real low level compatible machine for DOS sofware (I cannot imagine someone then not being able to run memmaker) and we are not there yet.