MiSTer FPGA Forum

In a Spanish keyboard (105 keys), the key to type < and > does not work.

In MiSTer, this key produces scancode 62h, which I don't think is bound to any character.

In DOSbox, it produces scancode 56h which correctly produces the < character (and the > character with shift). That scancode precedes F11 (57h) and F12 (58h).

I don't know if this is an issue with main, or with this core in particular. I guess these scancodes are produced by the 8042 emulation, so I'd say the issue is likely to be core-specific. But since I'm not familiar with the USB protocol for keyboards, I may be wrong.

This website sort of documents it, although the physical location nowadays is most often to the right of the left SHIFT, rather than next to ALT:
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html

Is this easy to fix?

I'm not 100% sure but I believe the issue might be here:

https://github.com/MiSTer-devel/Main_Mi ... t.cpp#L387

These appear to be Scan Code Set 2 codes; see www.quadibloc.com/comp/scan.htm for a quite thorough reference of them.

If that's indeed the origin of the keys that ao486 receives, as I suspect, this patch might work:
56h is the wrong key. 61h is the correct Set 2 code for that key.

I reported Set 1 scancodes in the previous post because I didn't configure the emulated 8042 to report Set 2 to read the scancodes. The Set 2 scancode for this key is 61h (which is translated to Set 1 scancode 56h by the 8042).

Sorry but I left GitHub and I'm not going to return, so I can't submit a PR.

Sorgelig, if you can confirm that this is how it works, would you please apply this fix? It affects all users of ao486 with international 102/105 key keyboards.

Edit: Oops, this was reported as issue 7. The report gets it right: https://github.com/MiSTer-devel/ao486_M ... -584850501

Code: Select all

-       NONE, //86  KEY_102ND
+       0x61, //86  KEY_102ND

BUT... the patch gets it wrong: https://github.com/MiSTer-devel/Main_Mi ... 52aaa07e8a

Code: Select all

-	NONE, //86  KEY_102ND
+	0x56, //86  KEY_102ND

This is not what can be easily fixed unlike it looks so..
To overcome this problem, there is keyboard remap (in menu core) where you can remap some keys system wide. But it has some limits.
It's really a good way to get US international keyboard as cores expect pretty much exact scancodes.

Sorgelig wrote: ↑Mon Jun 22, 2020 10:46 am This is not what can be easily fixed unlike it looks so..

I think you must be misunderstanding something here.

The scancodes are the same in any international keyboard as in a US keyboard. However, the US keyboard is a 101-104 key type. but many international keyboards are 102-105 key types. They have one more key. The new key can't be typed in a US keyboard because it doesn't exist. And no matter the country of the keyboard, the scancode of that key is always the same, when it exists.

Once in the ao486 emulation, I can type KEYB SP and use the Spanish layout. However, I can't press < or > because that key is not working. You seem to want to force me to stay with a U.S. layout inside the emulated machine, and be unable to type local accents like á or ñ, in other words, you would be asking me to limit what I can do with the emulated computer. Imagine I tell you that you need to be restricted to using a French keyboard, and to remember that you have to press Q when you want an A and so on, or to use shift every time you want to type a number in the top row. You would be pissed off, wouldn't you?

Please reconsider your position. Issue 7 shows that I was on the right track. However, unfortunately the guy that submitted the PR made it wrong and entered the wrong scancode. All I ask is for it to be fixed. He is British, I am Spanish. For him, set 2 scancode 0x61 is translated by the 8042 to set 1 scancode 0x56 which is translated by KEYB.EXE to character \, while for me, set 2 scancode 0x61 would be translated by the 8042 to set 1 scancode 0x56 (so far everything the same) which whould be translated by KEYB.EXE to character <.

I repeat, THE SCANCODES ARE THE SAME for everyone, but only when the key EXISTS. In a 101-key keyboard there is no key 102, but in ALL 102-key keyboards the scancode for key 102 is the same, and the correct code for it is 0x61.

Once in the emulator, it's KEYB.EXE that determines the layout, and therefore how a scancode will translate to a character. That's completely apart.

(Note: 104-key keyboards are 101-key keyboards plus LGUI, RGUI, MENU; similarly, 105-key keyboards are 102-key keyboards plus LGUI, RGUI, MENU)

I'm fine to change that scancode as it seams not really used. I'm talking in general that cores are expecting US international keyboard regardless your wish.

Thank you very much for doing that.

I've made a program in Python that patches the binary, so I could test it, and it works. Usage: python patch-mister-kb.py <name_of_Main_binary>

for example: python patch-mister-kb.py MiSTer_20200618

You seem to persist in your misunderstanding. I repeat, the scancodes (which are what the cores receive) are the same in all keyboards. But truly international keyboards (i.e. those for many countries except the US) have one more key, and that key needs the correct code in order to work with ao486. US=104 keys, International=105 keys. That extra key is important in the keyboard of every country other than the US, for the ao486 core, because that core uses ALL of the keys. Most cores only use a subset and then it doesn't matter, but ao486 is special in that sense.

pgimeno wrote: ↑Mon Jun 22, 2020 4:45 pm every country other than the US

I like this maximalism. No, not every country. Russia doesn't use that key. Taiwan doesn't use that key. Both countries are using standard US international keyboard.

I was obviously referring to countries which have their own keyboard layout.

That's besides the point, though. The point is that 105-key keyboard users can now use the extra key normally, so thanks!

Japanese 109-key keyboards will probably still have keys that don't work, but I'll leave that up to someone who is familiar with those keyboards and their scancodes.