Hi Volkert,
> Firstly, JEMM doesn't have a port trapping API that is compatible with > Microsoft's EMM386 memory manager. Yes, JEMM can offer similar > functionality using JEMM Loadable Modules (JLMs), but the programming model > of JLM is considerably different than the API in EMM386, or even QEMM's QPI. I support the wish to support I/O port trapping in JEMM. See RBIL int 2f ax=4a15 bx=0 for more details. > This is a problem particularly for the popular SoftMPU TSR. How about letting the SoftMPU maintainers write a patch for JEMM? This TSR simulates a MIDI device. Other related software includes VSB, the virtual sound blaster. > The SoftMPU developers don't want to take on the burden of having to > develop and support a JEMM version, in parallel to their EMM386/QEMM386 > version. They prefer to work with a common codebase. See the comment at > https://www.vogons.org/viewtopic.php?p=332252#p332252 Understandable, but fixing JEMM is easier than writing another EMM386. > The second limitation of JEMM is its lack of support for the GEMMIS > specification. This means that it is not compatible with Windows 3.x Given that Windows already ships with MS EMM386, this seems to be a limited problem. Also, I suspect that having GEMMIS compatible state data structures would make JEMM less able to optimize for modern CPU. GEMMIS is a lightweight API which gives Windows access to internal EMM386 state so it can completely replace EMM386 itself on the fly while running in 386enhanced mode. > The maintainer of JEMM doesn't consider GEMMIS worth the effort to > implement, unfortunately. See this discussion: > https://github.com/Baron-von-Riedesel/Jemm/issues/5 See my comment above. > As an additional argument: it is possible that GEMMIS was adopted by > software outside of Windows as well, namely in the demo scene. That sounds rather exotic, given that they can more easily run their DOS extenders on DPMI, VCPI or raw hardware. > More info on that here: http://dgi_il.tripod.com/gemmis.txt Thanks for the link! > But going back to my main point: there is no full open-source drop-in > replacement for EMM386, as far as I know. Life is hard. Help to make the existing solution JEMM better ;-) > Perhaps these features could themselves be implemented as JLMs? At least for I/O dispatch, there might be a chance? Regards, Eric PS: I think JEMMEX and JEMMEX are far ahead of any other open source EMM386 style drivers. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
