> RBIL sort of implies that all sizes should work, but dword is broken > and the byte/word distinction is only partially explained in RBIL?
In my actual testing, the only thing that works properly is Bytes. > Have you seen apps which make use of the QPI way, apart from > SoftMPU? No, I haven't. But they could exist. I've ran across a dozen or so implementations of the MS API. Many of them are just "test" programs, though, and I never kept track of them. My USBJSTIK (for USB joysticks/gamepads) is a "real" implementation of the MS API. Is your implementation a superset of QPI? Or MS style? Both? Just MS. Qualitas provided a superset of the MS API also, and mine is a superset of the Qualitas superset. > 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? :-) As I think you are aware, I do a pretty good job of commenting my code so just reading the comments (especially the comments in the test program which tests all the features) will give you a good idea of what's going on. BTW, the test program is written for NASM. > 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 :-) I really don't think that's a good idea, but maybe could be convinced otherwise. I don't think a "willy nilly" approach to this is a good idea -- it needs to be centralized so that there ends up only being one API. I know lots of folks don't like the idea of a "centralized" approach to something like this, but I think it's needed here. > 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. I know you would, Eric, and I do appreciate everything you do. That's perhaps a little premature for now, though. I think I might be willing to publish the test program right away, though (without documentation). > To be honest, I am not aware of JLM (loadable protected mode > drivers) beyond the demo KEYB provided by Japheth. I'm not aware of any "real" JLMs either (other than test programs), but there may be some out there. > 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?) My goal is simply be to not break existing JLM compatibility, though I don't see JLMs as the way to go in the future. That would particularly apply if Bob ever did publish the source code for QEMM since JLMs are strictly a JEMM thing. > 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. The problem is that even where there are BIOS-level APIs for things (like keyboards, joysticks, mice, and even serial ports) the BIOS API's aren't always used (and in the case of joysticks and serial ports, are almost never used). To maintain compatibility with as many old programs as possible, I/O and, at least in some cases, DMA virtualization is required. > Of course, a BIOS would probably use SMM for port level > virtualization, which is not a style which user drivers like yours > can use. Exactly. That would need to be implemented by the BIOS (or EFI/UEFI) -- the can be only one SMM "manager". As you know, BIOS implementations of USB only address keyboards, mice, and/or disks. I've never seen a BIOS that supports USB COM ports, joysticks, sound cards, or Ethernet, though some Virtual Machines do. > But all of those would not yet be used by any other software ;-) The use of these is to set up a "virtualization layer" so other programs that don't understand the newer hardware can still work. E.g., a program can in fact be "talking to" a USB keyboard when it believes it is "talking to" a PS2 keyboard even when it is accessing the keyboard at the hardware (I/O port) level. > Thanks once again for your low level coding! Eric Thank You!!! _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
