Hi Eric, On Sun, Aug 8, 2021 at 8:20 PM Eric Auer <e.a...@jpberlin.de> wrote:
> > How about letting the SoftMPU maintainers write a patch for JEMM? > If they're not interested in maintaining a fork of their own project, I think it will be very unlikely to convince them to contribute such a patch to JEMM. Also, Japeth (Baron-von-Riedesel on GitHub) expressed skepticism w.r.t. any submitted patches for this, in the same GitHub issue thread I linked to earlier. > This TSR simulates a MIDI device. Other related software includes > VSB, the virtual sound blaster. > VSB doesn't even work with Microsoft EMM386, since it uses QEMM's QPI API for port trapping. It works only with QEMM, or with no 386 memory manager loaded at all. I opened a GitHub issue with a feature request for QPI support in JEMM earlier, but when I was told that would be a non-starter, I closed it again. > Understandable, but fixing JEMM is easier than writing another EMM386. > It turns out that writing another EMM386 reimplementation from scratch might not be necessary after all. Do you remember this thread from 2012? I see you participated in it as well: https://sourceforge.net/p/freedos/mailman/freedos-devel/thread/4F2097D2.5060500%40sudleyplace.com/#msg28740668 In point 4 of his opening post, Bob Smith (sudleyplace on GitHub) mentioned that with enough interest, he would be willing to "release the source code for Qualitas MAX (a.k.a. 386MAX)". In that same thread in 2012, BretJ mentioned that 386MAX supports the same I/O port trapping API as the one offered by Microsoft EMM386. Also, 386MAX supports GEMMIS. So this might be the ideal solution for both these problems! :) I'll try to reach out to him to ask him if he would still be willing to release the source code. > 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. > Like I said, it would still be annoying to have to switch between boot profiles, since JEMM offers certain advantages too. It would be great to just have one good open-source EMM manager that would work with all of this. :) As for your suspicion that GEMMIS support would limit JEMM in terms of optimally supporting modern CPUs, I would like to get some clarity about this. Perhaps Japeth and/or others here can confirm whether or not this is the case. > That sounds rather exotic, given that they can more easily > run their DOS extenders on DPMI, VCPI or raw hardware. > Yeah, that was my thought too. Why not just use a DOS extender or something? > > More info on that here: http://dgi_il.tripod.com/gemmis.txt > > Thanks for the link! > You're welcome. :) It's cool to have this spec documented, regardless of whether this ultimately makes it into an open-source EMM386 replacement or not. By the way, DOSBox apparently has built-in GEMMIS support already, so there is at least one open-source implementation out there. As to how suitable that code would be for reuse in a memory manager, that is of course another question. :) > > 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 ;-) > I'd love to! But as I said before, my low level coding skills are too limited. I'd love to assist and learn, though. Also, we would have to convince Japeth to accept a patch, even if it proves feasible to write one. > > Perhaps these features could themselves be implemented as JLMs? > > At least for I/O dispatch, there might be a chance? > Yeah, I'd like to know this too. Does anybody else here have a clue? > PS: I think JEMMEX and JEMMEX are far ahead of any other open > source EMM386 style drivers. > Yeah, I was aware that there was an older EMM386 replacement that has since been replaced by JEMM(EX). I guess it would be a lot more effort to dust that off and extend it with such functionality, than to enhance JEMM. But how well do you think 386MAX would compete with it, if it were to become open source?
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
