Hi Bret,
> I've been working on adding an implementation of I/O port trapping to > JEMM using the EMM386/QEMM API (INT 2F.4A15). I have it basically working. Great news! > As far as the I/O port trapping, MS did a really crummy job of implementing > it. > Bob Smith of Qualitas found this out as he was implementing it in QEMM. > E.g., the MS implementation only supports byte I/O (not Word or DWord)... RBIL sort of implies that all sizes should work, but dword is broken and the byte/word distinction is only partially explained in RBIL? > The description in RBIL is incomplete and doesn't even detail the > de-installation > procedure. Qualitas' implementation fixed the MS problems and expanded its > features > (but I've never actually seen or tested the Qualitas implementation). Have you seen apps which make use of the QPI way, apart from SoftMPU? > I've added even more features in the JEMM implementation. Is your implementation a superset of QPI? Or MS style? Both? How understandable is the API by reading source comments, as no docs are there yet, so software beyond your USB drivers can start to use the extra features? :-) > If anybody wants to do it, I'll send you the code I've got so far and try to > explain my thinking. I would suggest that you publish your code so people can look around in it and ponder adding it to JEMM. Maybe even Japheth himself would want to test it in the current state already :-) Of course I would be happy to absorb some of your thoughts and put them into some text file if you think that helps, in comparison to you providing a readme yourself. > One of the main things missing is supporting JLMs (JLOAD needs > to be fixed to make it compatible). To be honest, I am not aware of JLM (loadable protected mode drivers) beyond the demo KEYB provided by Japheth. Also, is your goal to provide I/O trapping accessible by JLM, or is there a general compatibility problem which breaks all JLM as soon as the I/O trapping (your style, QPI or MS style?) would be invoked? I assume JEMM could block the respective other feature while either JLM or I/O trapping are in use, without bothering most users at all :-) > The main reason I started working on it was to support my > USB drivers, and in particular the ability to virtualize > the following kinds of USB devices: > > Keyboards > Mice > Joysticks/Game Pads > Serial/COM ports > Sound Cards > Ethernet Cards > Parallel ports (maybe -- these aren't as critical as Serial/COM ports) Apart from the sound cards (although even those have VESA/AI) you can probably virtualize all of those at the BIOS level or packet driver level without too much compatibility loss with common apps or drivers. Of course, a BIOS would probably use SMM for port level virtualization, which is not a style which user drivers like yours can use. Also, you already mentioned that packet drivers are no good abstraction level for USB LAN. https://en.wikipedia.org/wiki/System_Management_Mode#Problems > A couple of the things I've added in my JEMM implementation are > support for ports below 100h (though each port can only have a > single "manager" or "virtualizer") and IRQ virtualization (which > requires manipulation of ports 20h and 70h). One thing that I > think still definitely needs to be added is DMA virtualization But all of those would not yet be used by any other software ;-) Thanks once again for your low level coding! Eric _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
