Grench, you do know DosBox has support for other things than US layout? Qemu isnt an issue, and there are more ways to fix old broken software than there is to fix a broken layout.
If only a person could make such statements and 'make it so'. Reality appears to differ with your viewpoint.
Maybe this shows the actual interest in obsolete difficult to use software, especially where there are much better more playable retro experiences to be had....
( Wait, wait, wait, I remember this game... I can still play too... /me clears his throat and builds up a really trolly snarl...
"So, lets just leave out the keyboard entirely then? After all those "oh so very playable" console games never needed one, eh (after all, games targeted at 10 year olds can hardly place high demands on... well, anything really?-). I'll take Wasteland over you Zelda anytime, yeah?"
"Oh yeah?"
"YEAH!"
"OH YEAH?!"
*fisttime!*
)
Oh the glory days of computers vs. consoles... takes me back to the schoolyard... Lets do Amiga vs. Atari next...
So much for the fun, now I'll try to explain the DOSBox problem and I assume QEMU suffers from the same:
Assume you got symbol ~. That's keycode 49, state 0x1 (0x1 meaning SHIFT is down).
Then you got symbol `. That's keycode 49 (YES, SAME), state 0x0 (meaning no SHIFT).
With me so far? Fear not, you soon won't be ;-).
So, keycode and state are interpreted by X to mean a character, this is called a keySYM, instead of "code". You can tell X to map CODES to whatever SYM you want, like ½ instead of ~ like in some international keyboards. So, depending on your mapping keySYM for keyCODE 49 with SHIFT can be ½. Or it can be ~ like in the US.
Whatever, in this example we now got ~ from X.
Apps can use either keySYMs (portable across platforms) or keycodes (you pretty much need to know the target platforms, they're not as arbitrary as they seem, but still are).
Most apps use keySYMs for the obvious reason of portability.
So that ~ is passed to SDL, then to DOSBox (in the Pandora, SDL actually does the keycode-->~ mapping, but I'm "guessing" how it might go in Pyra, so...).
DOSBox checks that the keySYM ~ is mapped to a PCkeyCODE in a PC... in a PC that SYM is mapped... tada: nowhere (by default). So let's ignore it, such a key does not exist in the US layout which is used as a "base" in DOSbox! Similarly ½ does not exist --> ignore it.
However, keySYM "`" would be mapped to PCkeyCODE 41 (<-- note, DOS has different numbering from X). The keymapper can be used to do more such mappings: You can map a XkeySYM to mean a PCkeyCODE. PCkeyCODEs always represent a BUTTON, not symbol.
So, DOSBox passes the PCkeyCODE 41 to DOS, which then looks what DOS character that CODE should be mapped to. In the US it produces a `... except if, at the same time, DOSBox tells DOS SHIFT is down, in which case it produces a ~.
OR, no matter what nationality you have set X to, if you have loaded a SW keymap in DOS, then SHIFT+` produces a ½!!!
If this is not confusing enough, you can also set ~ to mean the `-key. Then pressing the Fn combination for ~ will produce `, and pressing shift-Fn-~ will produce ~. But because DOSBox only allows you to map unaltered keys (no shift, no alt, etc.), you CANNOT MAP ~ to directly be SHIFT-` in DOSBox. Not with the existing mapper.
So, Comradekingu, you say, "fix DOSbox". That's just it: What _exactly_ is the better mechanism for this in your opinion? If you can't code it, then at least specify it, technically? Simply saying "so it produces the symbol I happen to want" is not specs. Where do you want the surgery done, where can it be without causing trouble? DOSBox is actually easy - full source. How about QEMU? Load DOS in that - the DOS layer is now closed source! Definitely no surgery there? Code a custom Win3.1 kbd-driver? In this day and age? Oh please...
The only way to fix this that I know of, is what has been done on the Pandora: Make the keySYM ~ produce a "Shift down + `" in DOSbox. That's not issueless. Lesser problem: what if the user is pressing the SHIFT trigger down at the same time? Is that then a `? Bigger problem: after you've laboriously encoded the whole ****ing keyboard into DOSBox, what happens? Someone loads the SW keymap. And suddenly your ~ is a ½ and everything else is completely messed up too, because now you really have to deal with not just doubleshifts, but also doublealtgrs. Once again keys on Pandora keyboard have different symbols from what appears on screen.
The DOSBox team cannot fix this either: it is a PC emulator. It HAS to emulate keyboard buttons, not letters!
And that messed up "fix" is supposing you got the inclination to waste your time on something as boring as remapping keys, while at the same time there are more technically INTERESTING challenges to take. No, what happens is pretty much what happened to me: I fixed this issue by switching the device to a keyboard layout that is fully PC101 compatible... Pretty much only numbers and QWERTY now do what they say on my Pandora.
And then I proceeded to the interesting bits: boxed joystick (PC joysticks are not "circles", they are "boxes" - fix in SDL), pan following mouse cursor at 800x640 resolution (playing original Wonderland is cool now). And so on. It's not like the Pandora devs are actually PAID for their work, so the work has to have some mental arithmetic to it. Creating doubleshift-maps for every keycombination is anything but. And here's the kicker: because I've totally diverted from Saxxon env. pretty much nothing I've done for myself is easily transferrable to Saxxon now, even if someone wanted to spoon the puke I call code for the useful bits...
Rant done, long DOSbox explanation given, proceed
.
