search

Baron-von-Riedesel / Jemm

Jemm386 and JemmEx are socalled EMMs ( Expanded Memory Managers ) or, more exactly, V86 monitors.
125 stars 11 forks source link

JEMM386 and using NODYN #10

Closed JayQ2K closed 3 years ago

JayQ2K commented 3 years ago

I get some strange results when using JEMM386: XMM without Int 2F/AX=4309h support

\JEMM386.EXE X=TEST NODYN: C400-C**4**FF excluded \JEMM386.EXE X=TEST: C400-C**8**FF excluded (so without NODYN the whole C400-C8FF range that EMM386 by default excludes is excluded by JEMM386 as well...does give you the warning though dynamic memory allocation is off) If anything would change in UMB reservations between the two syntax above, I would figure that without dynamic address allocation the exclusion range would be bigger since you would then need to reserve those address spaces. So this looks like reverse behavior? XMM with Int 2F/AX=4309h support \JEMM386.EXE X=TEST NODYN: C400-C4FF excluded \JEMM386.EXE X=TEST: C400-C4FF excluded So here the behavior is similar with or without the NODYN parameter.
JayQ2K commented 3 years ago

After further investigation, this could all come down to an XMM without Int 2F/AX=4309h support. UMA does not function as planned, requiring EMM to make wrong assumptions how the memory is structured. Just tested with 5.80pre9 and I see I am now required to include "I=TEST I=C500-EFFF" to ensure the UMB area becomes available for page framing and other upper memory activities. If I don't add these statements the complete C500-F7FF area remains in "blocked" state so the E400-EFFF area for page framing is unavailable and EMS fails.

I'm also clearing this with the DOSBox-X people as the problem seems to be more related to the internal XMM of DOSBox-X. It could however be something for the troubleshooting pages of the README file that is supplied with the JEMM 5.80 packages.

Baron-von-Riedesel commented 3 years ago

NODYN should have no effect at all for UMB detection. Use the /V option to see in detail what Jemm386 sees as potential UMBs: all pages marked 'U' are UMB candidates.

JayQ2K commented 3 years ago

If I use the internal XMM, all the areas are given an R (RAM). So it might be a complete different thing, but the automated scan has no way of identifying what memory can be used as UMB. So either the XMM doesn't identify which are 'Free XMS UMBs' or it has no way of telling that to the upwards driver (Jemm). Since any Himem(-alike) driver that is version 3 or up the identification should not be the problem, so my guess is that the obtained information by the XMM is not being handed over to a requesting EMM.

Baron-von-Riedesel commented 3 years ago

So either the XMM doesn't identify which are 'Free XMS UMBs' or it has no way of telling that to the upwards driver (Jemm).

That's a misunderstanding. The UMB API is a part of XMS, but the UMB functions of the XMM usually are just "stubs" because the XMM does not at all deal with memory below address 0x100000. The UMB functions are filled with live thru the EMM, which hooks the XMS entry "chain" for that.

JayQ2K commented 3 years ago

Exactly what I wrote...or at least tried to write. The EMM does at some point need to get information from the XMM on this matter. That does not seem to happen. Anyway, after some additional testing I found the exact same behavior with EMM386 when using specific command line syntax. Therefore I'll be closing this case, since it is definitely something that plays outside of the context of Jemm/ HimemX.