It's the keyboard layout.


Too many symbols per key
Can you justify this? There's only 3 which is exactly as many as the on the Pandora's number row, and I've never heard anyone complain that that has too many symbols. With that in mind, it seems to me it is pretty well settled that three characters is entirely reasonable for a single key. If you disagree can you explain why?
tab key second class citizen
At least by having the tab and fn on opposite sides it's a much better position than on the Pandora. It's a reasonable compromise to a deficiency of keys. So a question: looking at that keyboard, if not Fn-Space, where would you put the tab? What current primary key would you displace?
 
Too many symbols per key
Can you justify this? There's only 3 which is exactly as many as the on the Pandora's number row, and I've never heard anyone complain that that has too many symbols. With that in mind, it seems to me it is pretty well settled that three characters is entirely reasonable for a single key. If you disagree can you explain why?
tab key second class citizen
At least by having the tab and fn on opposite sides it's a much better position than on the Pandora. It's a reasonable compromise to a deficiency of keys. So a question: looking at that keyboard, if not Fn-Space, where would you put the tab? What current primary key would you displace?
3 per key certainly works if you look at individual keys, but if a large proportion of the keys have 3 labels, the overall impression of the keyboard will be that it looks quite cluttered.

Tab and Fn on opposite sides is practical for repeated Tab presses, but not for a single Pandora-style button mash. A dedicated Tab is better still, and much more useful than dedicated backtick/tilde.
 
As far as I understand, it is perfectly possible to let DOSBox/qemu/whatever work fine with any mapping, in the sense that if I want to put ~ as Meta+Q or : at Meta+K, those symbols are actually produced. This is a matter of correct configuration and/or porting, and to some extent this will have to be done anyway, since we don't have a normal full-size keyboard no matter how closely we try to imitate one.

Another issue is related to the assumptions that emulated DOS/Windows programs make about how your keyboard looks like. They could very well assume that 9 0 - = backspace are adjacent keys, five in a row, and in some way rely on that. Or they could use the numeric keypad for something (e.g. 8-direction movement). They could make all kinds of assumptions that all boil down to the user having a standard US-QWERTY keyboard. A slightly larger fraction of those assumptions become true if _+{}|:confused: are on Shift + -=[]\;/. So in that sense, yes, "compatibility is improved". But that is in my opinion a rather weak sense of the word "compatibility". Because even in the days of DOS, other keyboards existed than US-QWERTY. German QWERTZ keyboards and French AZERTY keyboards also existed in the 1980s. So at least for applications and games that had some kind of international popularity, their assumptions would rather be general things like a numpad being available and F-keys being dedicated keys (assumptions we cannot satisfy anyway, at least not simultaneously), than specific things like [ is on the right and Shift+[ is {.

Not to say that there were plenty of applications and games that just assumed US-QWERTY, and they were just broken if you had a different keyboard. I remember games that use WASD for movement, which is not funny on an AZERTY keyboard :) But the only way to really enjoy such games like they were intended, is by attaching a US-QWERTY keyboard to your Pyra. The improvement you get from putting _+{}|:confused: on Shift + -=[]\;/ is rather tiny compared to all the things that are still 'wrong': no dedicated -=[]\;/ keys for example, no numpad, no dedicated F-keys, lots of missing keys. A game that puts player one at WASD and player two at PL;' is not going to work well on the Pyra keyboard, no matter what you do, unless you attach a real keyboard. There is no way around that, besides doing game-specific remappings.
 
As far as I understand, it is perfectly possible to let DOSBox/qemu/whatever work fine with any mapping, in the sense that if I want to put ~ as Meta+Q or : at Meta+K, those symbols are actually produced. This is a matter of correct configuration and/or porting, and to some extent this will have to be done anyway, since we don't have a normal full-size keyboard no matter how closely we try to imitate one.

Another issue is related to the assumptions that emulated DOS/Windows programs make about how your keyboard looks like. They could very well assume that 9 0 - = backspace are adjacent keys, five in a row, and in some way rely on that. Or they could use the numeric keypad for something (e.g. 8-direction movement). They could make all kinds of assumptions that all boil down to the user having a standard US-QWERTY keyboard. A slightly larger fraction of those assumptions become true if _+{}|:confused: are on Shift + -=[]\;/. So in that sense, yes, "compatibility is improved". But that is in my opinion a rather weak sense of the word "compatibility". Because even in the days of DOS, other keyboards existed than US-QWERTY. German QWERTZ keyboards and French AZERTY keyboards also existed in the 1980s. So at least for applications and games that had some kind of international popularity, their assumptions would rather be general things like a numpad being available and F-keys being dedicated keys (assumptions we cannot satisfy anyway, at least not simultaneously), than specific things like [ is on the right and Shift+[ is {.

Not to say that there were plenty of applications and games that just assumed US-QWERTY, and they were just broken if you had a different keyboard. I remember games that use WASD for movement, which is not funny on an AZERTY keyboard :) But the only way to really enjoy such games like they were intended, is by attaching a US-QWERTY keyboard to your Pyra. The improvement you get from putting _+{}|:confused: on Shift + -=[]\;/ is rather tiny compared to all the things that are still 'wrong': no dedicated -=[]\;/ keys for example, no numpad, no dedicated F-keys, lots of missing keys. A game that puts player one at WASD and player two at PL;' is not going to work well on the Pyra keyboard, no matter what you do, unless you attach a real keyboard. There is no way around that, besides doing game-specific remappings.
Wow... after all of this you still don't understand the issue on DosBox/QEMU/others.

As far as I understand, it is perfectly possible to let DOSBox/qemu/whatever work fine with any mapping, in the sense that if I want to put ~ as Meta+Q or : at Meta+K, those symbols are actually produced.
That is 100% incorrect. DosBox/QEMU/others have no idea what ~ mapped to a key by itself is. They know that when they receive shift+` that they then need to produce a ~ character. ~ has no meaning by itself. This is because it is reading directly from keyboard actions. It doesn't run through an interpreter layer that can be remapped. It is reading key presses only based on the 'root' key. None of the following exist as direct mapping:~!@#$%^&*()_+QWERTYUIOP{}|ASDFGHJKL:"ZXCVBNM<>?

Those symbols can only be registered as shift +

`1234567890-=qwertyuiop[]\asdfghkl;'xcvbnm,./

If the symbols printed on the key tops match that pairing, then what you see on the key is what gets produced. If the symbols are scattered all over and key pairs broken, then shift+the root symbol is required to produce the desired symbol and what is printed for what would be a shifted symbol does -nothing-.

A game that puts player one at WASD and player two at PL;' is not going to work well on the Pyra keyboard
I once had a game called 'Rampage' that allowed 4 players on one keyboard.Player 1 WASD, Player 2 YGHJ, Player 3 UpLeft,Right,Down, Player 4 5123.

Putting 4 players around 1 keyboard was hilarious and great coed fun.

I have no expectation of THAT working on a 4.5" wide keyboard.

I just want the symbol printed and selected to be the symbol produced in all applications - including DosBox/QEMU/others. Positional mapping isn't as big of a deal for DosBox/QEMU/others, but retaining key pairs IS.

Positional mapping is more to the idea of retaining some positional semblance to a US English keyboard for the mental mapping of where to go to find things.
 
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.

Wb, Is a regular keyboard cluttered when it has 3 symbols per key on the numbers?
 
Last edited by a moderator:
Okay, so here's what I did... Don't laugh :)

I showed my mother(62) a couple of examples of keyboards people had made and asked her which she likes.

I then asked her what she would do...

This is what she came up with. :)

The language specific letters of the standard french and german keyboards should be on the exact same keys on the pyra keyboard where possible or otherwise near their original location. (except for ß as there's no room next to the number row)

I then filled in the remaining keys with the symbols and diacritics until all keys had an Fn label.

Ofcourse some great ideas from others were used aswel, like the F11 and F12 keys.

http://www.keyboard-layout-editor.com/#/layouts/e653fb76b8fbfe86f1d394ebd81308ef
 
Last edited by a moderator:
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.
 
http://www.dosbox.com/wiki/Language_File

 
http://www.dosbox.com/wiki/CONFIG

-writelang localfile

Write the current language settings to file. "localfile" is located on the local drive, not a mounted drive in DOSBox. The language file controls all visible output of the internal commands and the internal DOS
http://www.dosbox.com/wiki/KEYB

http://www.dosgamers.com/dos/dosbox-dos-emulator/keyboard-layout

What internationalization is it thats lacking?

It should be possible to make a new layout, wherever dosbox gets the layout-locale setting from.
 
Last edited by a moderator:
http://www.dosbox.com/wiki/Language_File

http://www.dosbox.com/wiki/CONFIG

-writelang localfile


Write the current language settings to file. "localfile" is located on the local drive, not a mounted drive in DOSBox. The language file controls all visible output of the internal commands and the internal DOS
http://www.dosbox.com/wiki/KEYB

http://www.dosgamers.com/dos/dosbox-dos-emulator/keyboard-layout

What internationalization is it thats lacking?

It should be possible to make a new layout, wherever dosbox gets the layout-locale setting from.
International keyboards and key pairing are two different things.  It will still expect the key pairings from those to exist and be consistent through that language's support.  The shifted values still need to pair with their un-shifted versions.

If you consider it to be 'simple' to 'fix DosBox', do it.  The Pandora version has been 'broken' since 2008.  Many very bright people have tried to fix it and failed.  Maybe you're smarter than them all.
 
Ok, I am sure to be out of the loop here.


And it is guaranteed that I do not have all the information, and my response will be somewhat niave, but there is one important point here.


Does ED (and comradekingu) want the Pyra to be as use able for the average user as possible?


If that is so, I think I may be fortunate in that


1) I have owned and used the Pandora for years, and have been involved in this community.


2) My level of technical know how puts me pretty close to the entry level required to enjoy these devices (with some online assistance).


So what I can or can not do could be regarded as the lowest common denominator that these devices should be aiming to cater for, yes?


Assuming that, let me now respond to the point of contention between Grench and comradekingu:


I grew up in the 80's. I grew up with Dos, and then Windows.


Of course I am interested in emulating software from those times and architectures.


So compatibility is important to me.


Dosbox on Pandora has irritated and frustrated me. I have waited since the beginning for it to be fixed somehow.


If it is so easy to fix, why has no one done it?


If the response is, because I care I should do it myself... Well sorry, then you simply do not care about users like me... because that is beyond my capabilities.


Exagear sounds very exciting to me... it will sound less exciting if a user like me will be frustrated by it.


I don't care about this to the exclusion of everything else, but I am simply making the point that if catering to users like me is of any importance at all, then:


'If you care, you fix it'... is not a response, it is outright dismissal.
 
Well, you could fit the demographic of "the lowest common denominator that these devices should be aiming to cater for", but are still not a representative sample of it. Your input can be useful, yes, but it's still an individual opinion, albeit from a group that's good to hear from.

That said, welcome to the discussion :)
 
Last edited by a moderator:
Thanks :)


It's just that I was asked to contribute before, even though I didn't believe I was qualified.


It was stated that as I use a Pandora, and will be buying a Pyra... My opinion and contribution matters.


If it really doesn't matter, that's okay too.


But I feel Grench has a point that hasn't been fully responded to / resolved in a satisfactory manner.


Personally, I wouldn't mind if some custom layout was auto loaded when running dosbox or Exagear that fixed the issues. Can this be done?
 
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....
 
Here is a layout with the punctuation you need for natural language all on the left:

http://www.keyboard-layout-editor.com/#/layouts/fb9f7d7dbe0e66f38f70fd7a01896878
I'm not reading all these posts, there's way too many. Anyway, this one I think looks pretty good, but I have a suggestion regarding the compositor key.

Instead of Meta+Enter, why not move the two Brightness keys onto the same:

Brightness: Brightness Up

Shift+Brightness: Brightness Down

Meta+Brightness: F11

Composite: Composite

Meta+Composite: F12

Won't having a dedicated composite key appeal to the diacritic crowd? Also, the brightness is rarely adjusted in such a manner that it requires two dedicated keys IMO

Edit: Fixed my really shocking grammer and made things a bit clearer
 
Last edited by a moderator:
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 :).
 
Back
Top