> Maybe on some machines USB has IRQ uses which are not reliably > enabled during HLT? Maybe even NMI/SMI?
Hard to say exactly what the problem might be, though I don't suspect it has anything to do with HLT, NMI, or SMI. It is interesting (and encouraging, at least to me), though, that it only seems to affect USBKEYB and not any of the other USB programs, including the host controller driver. > Also interesting that some BIOSes are not fully compatible with DOS > keyboard (layout drivers). The incompatibilities aren't related to the keyboard layout drivers as such. They are related to the way my programs simulate keystrokes (the way the my programs insert a value in AL when the BIOS issues an IN AL,60h to request a scancode from the keyboard hardware). What my programs do, in SOME cases, is call the INT 09 code stored in the IVT with the CPU's trap flag set. When the INT 09 code issues an IN AL,60h OpCode, my programs skip over the OpCode and instead insert the scancode they're trying to simulate into AL. You can download the source code for USBKEYB and review exactly how this works. For some reason, this doesn't work with all BIOS's. > If I had to guess, I would say MKEYB uses int 15 and KEYB uses 40:xx. I think a lot of KEYB programs use INT 15.4Fh. I personally don't know of any that use the BDA. BTW, INT 15.4Fh will only work properly for certain keys (the letter and number keys). It usually won't work properly for things like Ctrl, Alt, Shift, PrintScreen, Pause, number pad keys, etc., if anybody ever wanted those keys to work differently than they normally do. MS KEYB doesn't use either INT 15.4Fh or the BDA. It COMPLETELY REPLACES the BIOS INT 09 handler with a new one, that process all possible keystrokes (including things like Pause, SysReq, PrintScreen, and Ctrl-Alt-Del). It doesn't simply process the keys that are different than the default BIOS handler for a particular keyboard language layout, which is what the other KEYB programs do. The other KEYB programs are not, in any way, equivalents of MS KEYB. > When reading about the wish to map the mouse wheel to keystrokes on > BTTR forum, I immediately thought about MOUSKEYS and was happy to see > in the docs that it is actually by you (many many years ago). Maybe > you could still add wheel support to it in 2011? :-) I saw that on the BTTR forum as well. I do intend to add support for wheels in the next version of MOUSKEYS, though I doubt that it will happen this year. BTW, I would also like to see CTMOUSE expanded to support the IntelliMouse2 protocol (two wheels and five buttons). If CTMOUSE did that, the next version of MOUSKEYS would support the extra buttons and wheels as well. USBMOUSE already supports the extra wheels and buttons for USB mice that have them. > So in short, you have my vote for the idea to add QPI... I/O traps > int 67.1axx or RM386 int 67.5dex I/O trapping or (preferred by me > AND imho the easiest variant) MS EMM386 int 2f.4a15 I/O > virtualization to JEMMEX. The last is I think is the only reasonable one to implement, since it is already supported by both the MS and Qualitas EMM's. This could be implemented as an optional JLM by Japheth instead of including it natively in the EMM the way MS did, though I think the control interface should still be INT 2F.4A15h. Qualitas made some expansions to the original MS standard, and I think it could be expanded even more to make it even more useful. E.g., right now the standard will only support I/O port numbers >= 100h, and I think that limitation should be eliminated. Doing so would allow yet another method of simulating keystrokes in my programs. > See RBIL Intlist part 2F4A15BX0000 "Install I/O virtualization > handler". I've already implemented this in the USB joystick driver (USBJSTIK), and it seems to work pretty well, though I've only tested with MS EMM386. The one problem it does have, though, is that the I/O virtualization does not work with applications that access the I/O ports while in protected mode (e.g., DPMI). That could bring up a long debate about DOS DPMI applications and their general lack of concern for compatibility with modern (i.e., virtualized) hardware like USB, but I won't go there from here. See the following link, where you can download a paper and some sample code from written by Bob Smith, one of the founders of Qualitas, regarding the INT 2F.4A15 interface: http://www.programmersheaven.com/mb/x86_asm/376018/376018/virtualize-io-in-dos/?S=B20000 > PS: For the KEYB issue, as probably only few BIOSes are affected, > some separate "proper int16 and int 15.4f implementation" driver > would be a good idea, I would not suggest to put that into a default > KEYB itself. It would certainly be possible to create a separate "INT 09 BIOS Replacement" program, rather than including it in KEYB. I do think the "appropriate" place for it is probably in the KEYB program, though, just like the MS implementation. It could be an option that is only installed if the user requested or some kind of auto-test determined that it would be beneficial, though. ------------------------------------------------------------------------------ Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
