Hi Eric, On Mon, Aug 9, 2021 at 1:36 AM Eric Auer <e.a...@jpberlin.de> wrote:
> > Hi Volkert, > > which worries does Japheth have regarding accepting I/O trap patches? > He wrote: *"My experiences - so far - with patches from unknown people are "mixed". So I'm rather sceptical."* Source: https://github.com/Baron-von-Riedesel/Jemm/issues/5#issuecomment-770343181 As for my suggestion to implement this in the form of a JLM (and the question whether that would even be possible), he hasn't replied to that yet. > What are the pros and cons of supporting the QEMM API for I/O traps, > compared to the MS EMM386 API? I think SB Live PCI soundcard drivers > only support the MS API? How hard would MS API support for VSB be? > Wasn't there a limitation in the MS API that didn't allow lower I/O ports (under 100 or something?) to be trapped? If so, then EMM386 would not be capable of intercepting I/O to the 8257 DMA controller. Then again, how would the SB Live PCI drivers be able to work without DMA port trapping? 🤔 Assuming that DMA port trapping wouldn't be an issue, my guess is that adapting VSB to EMM386 would be doable, at least for someone with sufficient experience with x86 assembly language programming. After all, SoftMPU supports both MS EMM386 and QEMM without too much trouble. I'd need some serious help to adapt VSB to work with the EMM386 API, though. So far, I haven't even been able to get the code to successfully assemble with the Open Watcom assembler yet. My first priority has been to eliminate the dependence of VSB on TASM. Some assistance or even a remote pair programming session would be cool. I'm sure I would learn a lot from it. Feel invited to convey our interest via his github :-) Some more thumbs-up responses there might help, though. :) > I guess Japheth would not want to spend too much time reading specs, > maybe you can extract possible constraints from the GEMMIS specs and > then just ask Japheth whether those would bother JEMM performance? > I can try. I could use some help with that, though. > > By the way, DOSBox apparently has built-in GEMMIS support already > > At least DOSEMU does not, it supports DPMI instead, which is okay > for Windows. Makes me wonder whether DPMIONE can help to run Win3 > better within FreeDOS, for example with 386enh and multiple DOS > windows at improved stability beyond Jeremy's recent updates? > This other thread on GitHub might interest you: https://github.com/sudleyplace/DPMIONE/issues/1 > I do not know more about it now than in 2012, seems like a not widely > used EMM386 replacement, but if the quality is similar to 386SWAT and > DPMIONE, I would be quite optimistic :-) > Good point. Perhaps we should just play with 386MAX a little, to see how well it works with various stuff. For instance, does SoftMPU even work as-is with 386MAX right now, considering its supposed compatibility with EMM386? That should be easy and fun to try out. Ditto for Windows 3.1 under FreeDOS, combined with Jeremy's patches. On Mon, Aug 9, 2021 at 1:36 AM Eric Auer <e.a...@jpberlin.de> wrote: > > Hi Volkert, > > which worries does Japheth have regarding accepting I/O trap patches? > What are the pros and cons of supporting the QEMM API for I/O traps, > compared to the MS EMM386 API? I think SB Live PCI soundcard drivers > only support the MS API? How hard would MS API support for VSB be? > > > > 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)". > > Feel invited to convey our interest via his github :-) > > > 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. > > I guess Japheth would not want to spend too much time reading specs, > maybe you can extract possible constraints from the GEMMIS specs and > then just ask Japheth whether those would bother JEMM performance? > > > By the way, DOSBox apparently has built-in GEMMIS support already > > At least DOSEMU does not, it supports DPMI instead, which is okay > for Windows. Makes me wonder whether DPMIONE can help to run Win3 > better within FreeDOS, for example with 386enh and multiple DOS > windows at improved stability beyond Jeremy's recent updates? > > > But how well do you think 386MAX would compete with it, if it were to > > become open source? > > I do not know more about it now than in 2012, seems like a not widely > used EMM386 replacement, but if the quality is similar to 386SWAT and > DPMIONE, I would be quite optimistic :-) > > Regards, Eric > > > > _______________________________________________ > Freedos-devel mailing list > Freedos-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-devel >
_______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
