TheGreatCodeholio wrote:Alright, looking around, it looks like the IBM PC never had a numeric equals sign key (that I can find). In fact almost every IBM PC keyboard I can find has no equals key on the numeric keypad. Do you mind if I just go ahead and map that to the same handling as the normal equals key?
No, because I would like the correct scan code to be passed, and that's 0x59 make, and 0xD9 break. The normal equals key doesn't even have a fixed scan code (every keyboard layout places it elsewhere, the Slovenian keyboard layout has equals at Shift+0, for example), and in any case this isn't about the key returning an equals sign, but about the key generating the correct scan code.
I'm still not sure what IBM PC scancodes F13-F24 would generate. The SDL library however does have SDL keycodes for F13 and up, so what I could do is modify the SDL mapper so that you can bind them to whatever you want. While I'm digging around in that part of the code, I've always wanted to add in the scan codes for DOSBox so that, on my Linux system, a Windows 95 virtual machine could respond to the Windows and Windows popup menu keys on my keyboard.
Well, the Apple F13-F16 (I think no Apple keyboard has F17-F24) keys generate 0x64/0xE4, 0x65/0xE5, 0x66/0xE6, and 0x67/0xE7.
As for the IBM ones, F13 is Shift+F1, F14 is Shift+F2, and so on, so basically the scan code would be 0x2A (0xAA for break) followed by the appropriate F1-F12 key code.
Edit: The scan codes for the Windows etc. keys: left Windows is 0xE0 0x5B (make) and 0xE0 0xDB (break), right Windows is 0xE0 0x5C (make) and 0xE0 0xDC (break), and Windows Popup Menu is 0xE0 0x5D (make) and 0xE0 0xDD (break).
At the same time, what DOSBox can listen for from the keyboard is controlled by the OS. Even if the OS gave raw scancodes, the SDL library is already one layer of translation. Then, understand that USB keyboards (especially Apple) use a different scan code system, so, that's another translation layer. It's very difficult to just "pass scan codes in" because there are already plenty of layers of translation going on. For emulation to work, DOSBox needs to translate the SDL library key codes to something that DOS/Windows will understand, or at least make sure the scan code doesn't conflict with something that DOS/Windows understands, or it doesn't work.
Well, I know Windows has the raw input messages, not sure if SDL implements that, though. Do you have any documentation about SDL that I could read to understand more about how SDL's keyboardh andling works?
Update: check the latest commit. There are bindings for F13-F24 though keyboard.cpp does not yet generate scan codes for them. And there are bindings in place now for numeric keypad =, Windows 95 keys, etc. I also found a copy of Windows 95 japanese locale which so far works fine in DOSBox-X though I don't understand a lot of the text. Looks like the DOS/V mode of Win 95 uses a driver that sacrifices the high bit of the attribute byte to use the 512-character mode of the VGA font RAM, since Scandisk and Edit lack the drop shadows you normally see in US versions.
Nope, the DOS/V display driver uses a VGA graphic mode where certain character combinations yield double-width Japanese characters, of which about 10000 (yes, that's ten thousand) or so are defined. All 16 colors are available. The 512-character mode is still not by far enough to write in Japanese, given the thousands of characters the Japanese language uses (of which 2000 are common usage, plus thousands minor characters used in personal and place names, and so on).
As for Japanese keyboards, can you confirm this page is correct?
http://www.stanford.edu/class/cs140/projects/ … cancodes-7.html
Yep, that page is correct.