|
Post by itdude on Jan 25, 2020 1:10:18 GMT 1
I've been testing vDos in a business environment. So far I love it! But have one issue to be solved before purchasing:
Multi-Edit 7 (a text editor) runs perfectly except it doesn't recognize numbers on the keyboard number pad. Without number lock, keys function as expected. With number lock on, the keys are recognized only as shift versions rather than numbers (shift-end, shift-down, etc.). It works correctly in DOSBox, but I'd prefer to use vDos. Does anyone know what the problem could be? How does the vDos keyboard handling or keyboard layout/codes differ from DOSBox?
Thanks for your help!
|
|
|
Post by Jos on Jan 25, 2020 4:36:16 GMT 1
Here you go (simplified): - A key is pressed or released.
- The UART connected to the keyboard sends an IRQ signal to the CPU.
- At a convenient moment the CPU grants that IRQ, interrupts the code it executes and jumps to the routine/code assigned to INT 9h.
- That routine retrieves the key number from the UART (1 = Esc, 2 = ‘1’, etc.).
- The routine sets keyboard state modifiers like Shift, Ctrl, CapLocks in the BIOS data area. If another key is pressed, translates that key number (considering the set BIOS keyboard states) to an ASCII value (needs KEYB for non US keyboards), and puts that and the key number in the 16 entries circular BIOS keyboard buffer.
- The CPU and UART are told the IRQ has been dealt with, and the routine lets the CPU return to the code that was interrupted.
Finally a DOS program calls BIOS Int 16h to get the keyboard state or fetch the ASCII value of the key stored in the BIOS keyboard buffer. Mostly it doesn’t care about the (inconsistent) key number. DOSBox nor vDos communicate with the actual UART/keyboard, they can’t, and get/retrieve messages from Windows like a key being pressed. DOSBox essentially dismisses all information Windows already gathered, like the keyboard state and ASCII code, and only passes on the key number to the simulated UART. That then requires a simulated Int 9h executed to update the keyboard modifiers and keyboard buffer. vDos forgoes executing Int 9h, and uses the Windows message information to directly update the BIOS data. As long a program doesn’t install/use its own Int 9h routine, the end result (getting the keyboard state or a pressed key) will mostly be the same. Though DOSBox will need a keyboard driver for non US keyboards. While the keyboard modifiers may get out of sync with those of Windows, since it only sends keyboard messages to the application in focus. The keyboard UART nor Int 9h are simulated by vDos since Windows already did all the nasty work of translating key numbers to ASCII (and Unicode) values. But that also means (mainly TSR) programs implementing (hooking into) Int 9h don’t (fully) work. Or programs that - for whatever reason - hook into the Int 9h routine themselves, like MS DOS EDIT. Jos
|
|
|
Post by itdude on Jan 26, 2020 19:39:50 GMT 1
Thank you for the info! Do you have any ideas for a possible workaround I could try? You're much more of an expert in this area than I am.
Brainstorming here... Say we have a standard 101 key US keyboard. It would be fine to permanently lock the number pad to numbers since we have the extended arrow pad and navigation keys available to use. Given that the program recognizes the num-locked keys as a shifted key, would it be possible to use a "driver" like keyb or xkeyb to map the shift-number pad keys to numbers, and leave the extended keys alone?
|
|
|
Post by Jos on Jan 26, 2020 20:52:12 GMT 1
I’m afraid you’re out of luck with vDos. Multi-Edit will install/use its own keyboard driver. You can eventually check this by starting vDos with the log option (“…\vDos.exe /log”). The generated vDos.log file would have an entry like Int 9 => XXXX:XXXX. vDos however doesn’t generated an (emulated) Interrupt 9, so that driver/code will never be executed, as isn’t a driver installed by keyb or xkeyb. Often bypassing a programs keyboard driver isn’t that an issue, but that of Multi-Edit seems to handle CapsLock in a BIOS incompatible way. It will set and expect an internal flag of its own indicating CapsLock is off/on, not that of the BIOS. Attached SCODE.COM will display the keycodes vDos generates. Jos Attachments:SCODE.COM (2.97 KB)
|
|