EMM incompatibility problem in DOSBox-X #7
Comments
Yes, most likely the program expects/uses some undocumented (parts of the) EMM386 API - for example, the "device driver" API, reading/writing from/to file EMMXXXX0. |
Baron-von-Riedesel
changed the title
|
I know Jemm leaves about 8MB of EMS active when using the NOEMS switch. Is there a way to completely disable EMS support, but leave VCPI on? This more alignes to EMM386 behavior and also gives me an extra opportunity to check out whether MEGAEM works under that configuration. MEGAEM does not need EMS, but only VCPI. |
AFAIK, this "feature" was implemented to COPY exactly what MS EMM386 does. |
|
If behavior has not changed in recent versions then there is a difference. Maybe EMM386 is not acting according to specs, but you can based on the NOEMS switch completely disable the activation of EMS in EMM386. Besides 5.79, I've also tested this on 5.80-pre9. Both show the same behavior. |
|
Attached screenshot is output when I launch. The mostly is pretty much what I'm talking about. |
Well, I just tried MS EMM386 v4.95 with NOEMS parameter. And, believe it or not, I'm able to allocate EMS pages ( using FD DEBUG.COM) with the XA command - so quite apparently EMS is not "completely disable"d, |
|
I should have phrased it differently. Disabling EMS itself would, by virtue
of running an EMS driver be a bit weird.
But that I can reserve pages with the XA parameter is something completely
different. Because it's fine that I can. But if I don't there are
effectively no EMS pages reserved (which to me would be the proper way to
describe the NOEMS switch) while under JEMM there are reserved pages when
using the NOEMS switch.
So that I can is nice, but when using the same NOEMS switch the behavior of
different.
If I can make JEMM not reserve those 8MB with the XA switch, that's also
fine. But at the moment the behavior is different.
Op di 29 jun. 2021 05:31 schreef Andreas Grech ***@***.***>:
… Maybe EMM386 is not acting according to specs, but you can based on the
NOEMS switch completely
disable the activation of EMS in EMM386.
Well, I just tried MS EMM386 v4.95 with NOEMS parameter. And, believe it
or not, I'm able to allocate EMS pages ( using FD DEBUG.COM) with the XA
command - so quite apparently EMS is not "completely disable"d,
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APGFQT4T5Q46YFCSXQHLVV3TVE5CDANCNFSM4X4FXFGA>
.
|
I'm afraid I understand your new phrasing even less than your old. Please use tool EMSSTAT supplied with Jemm, and run it twice (with MS EMM386 loaded and with Jemm386 loaded) and then tell me what "reserved pages" you mean. |
|
According to the readme that is supplied with JEMM, the following is stated about NOEMS:
For EMM386 the following is stated on NOEMS:
FreeDOS EMM386 mentions:
Also I found this: If you take a look at the statistics programs (MEM, EMSSTAT) there will be memory showing up as EMS when running EMM386, which actually is XMS, but wrongly identified. Since the CPU switch into Virtual 8086 mode this however shows as EMM. Attached 2 files with output of EMM386 and JEMMEX on a 32MB system. What you'll notice is that the EMM386 one states it has NOEMS switched and almost 32MB EMS (again, actually XMS that is identified as EMS), but the JEMMEX one has around 8MB EMS with NOEMS switched. So whether it was planned behavior, there is a difference in execution between the two Expanded Memory Managers. I cannot really explain the 32MB vs. 8MB in any other way for now. |
Yes, this difference is "intentional" ; actually, Jemm did inherit this from FD EMM386. IMO this difference is irrelevant. |
|
OK. So to get this straight JEMMEX 'reserves' about 8MB as incorrectly identified EMS en the rest remains identified as XMS, while EMM386 incorrectly identifies all memory as EMS, while it actually all is XMS. As a background, afaik LIM EMS 4.0 can trick an application into thinking the system has EMS available for running an application, while it actually immediately gets handed over to XMS for execution. Only some very old applications actually need the NOEMS switch removed to have 'real' expanded memory. NOEMS switch instructs EMM386 not to create an EMS page frame in the upper memory area, meaning more UMB left of application addressing. |
Actually, the amount of EMS is not "reserved", neither by Jemm nor MS EMM386 - the memory is (usually) allocated dynamically from the XMS memory pool. So if an application allocates all free XMS memory, there will be no free EMS memory left either ( that's why the MIN option exists ). |
|
That's why I used reserved in quotes. It wasn't to describe what is happening in the background, but mainly to describe what you see when using e.g. MEM or EMSSTAT with NOEMS switched. But that didn't really answer the part of when requiring over 8MB expanded memory for an application what would then happen. |
Changed a DOSBox-X setup I have to work with JEMMEX from the JEMM579B package.
Set the following parameters to false: XMS, EMS, UMB as all these are managed by JEMMEX.
Checking memory statistics I have a good amount of Conventional memory free and about 31MB of EMS.
When trying to run MEGAEM (v3.10, it's a Gravis UltraSound part) I get the following message:
ERROR: EMM incompatibility problem: EMM internal structure not recognized.
Tried the HIMEMX (v3.36, both X and X2 executables)/ JEMM386 combination, but that lead to the same issue.
When using EMM386 (v4.49)/ HIMEMX I don't get this problem and MEGAEM gets installed into memory. Therefore it seems JEMMEX does something different in structuring its memory blob then EMM386.
Tried the NOEMS options for both EMM386 (MEGAEM still works) and JEMMEX (same issue as above).
What am I missing in configuring that the above error shows up? Or is there programming wise something different that MEGAEM simply can't interpret correctly?
The text was updated successfully, but these errors were encountered: