Eiffel vs. SHIFT + Fn scancodes collision

[mikro]

When reviewing some SDL stuff, I have noticed that there's a support for some special key combinations. When you press e.g. SHIFT + F1, evnt_keybd(), Cnecin(), Bconin() etc do not return 0x2a (left shift) followed by 0x3b (F1) but return 0x54 instead.

While this is odd (does someone know what is the reason for this?), the interesting thing is when you start implementing Eiffel scancodes, e.g. mouse wheel up/down, Win/Menu keys etc. They are all well defined in Eiffel documentation but there's a catch: for example 0x54 (our SHIFT + F1 from above) is actually ... NUMLOCK. Similarly, SHIFT + F2 = 0x55 = Eiffel END etc.

Luckily, I still have an Eiffel connected to my CTPCI Falcon so I was very curious what happens there if I press SHIFT + F1: it generated 0x54 and so did NUMLOCK. Huh.

Does anyone know how to differentiate between those two states? When hooking up on IKBD this doesn't not happen (SHIFT + F1 = SHIFT scancode + SHIFT scancode) so it seems to be forced by the OS (on all layers as it would seem) for some mysterious reason.

[czietz]

My best guess would be that, given that VDI defines more function keys than just F1 - F10, Atari decided to implement F11 - F20 as combination of Shift + Fn:

f11.png

[ThorstenOtto]

That is something done on the bios level (ie. the value you read from ibkd is 0x3b, not 0x54, that is why is does not happen in your own routine). EmuTOS does the same: https://github.com/emutos/emutos/blob/e ... #L612-L618

IIRC that was done to support some GSX standard. For the same reason, scancodes for Alt + 1-0 are also a bit strange (some of them are even >= 0x80)