What OS are you using? What do you need this key for? (keyb.com?)
For linux/windows maybe try usescancodes=true in dosbox.conf

> What OS are you using?

the binary runs on win98se

> What do you need this key for?

seems a strange question to me. for example for output redirection. currently I have to press alt+np6 and alt-np2 to get the ">" key

> For linux/windows maybe try usescancodes=true in dosbox.conf

I tried adding this entry to the [sdl] and [dosbox] section, but it didn't change the behaviour.

wd forgot to mention that you would need
http://cvscompile.aep-emu.de/dosbox.htm
and then please try again. (and if it fails again add that usescancodes=true)

> I created the binary from current cvs

I assume he builds it himself already. But you might want to compare
it against some prebuilt version.

> > What do you need this key for?
> seems a strange question to me.

This key isn't used normally, as the default dosbox keyboard layout is US.
That's why i asked if you really need this KEY or just the > and <
(which you should find between the keys "M" and the right shift,
that is SHIFT+, and SHIFT+. with a german layout, unless something's really wrong).

downloading the binary from cvscompile.aep-emu didn't change anything.

> which you should find between the keys "M" and the right shift,
> that is SHIFT+, and SHIFT+. with a german layout, unless something's
> really wrong).

I forgot to mention that I'm loading a (mini) german keyboard driver in dosbox (which intercepts Int 15h, ah=0x4Fh). So between 'M' and the right shift key there is no more "<" and ">".

"<" and ">" on german keyboards are on the "102-key", and pressing this key currently produces no make or break codes at all. It doesnt matter if I add "usescancodes=true" to the [sdl] section or not.

> I forgot to mention that I'm loading a (mini) german keyboard driver

This is quite relevant information as then you definitely need the 102 key.

You could try to add some logging that displays what SDL code is
returned for this key (sdl_mapper.cpp).
Search for the "class CKeyBindGroup : public CBindGroup" in sdl_mapper.cpp,
look into the function "bool CheckEvent" there should be an out-commented
"LOG_MSG". Just uncomment it, recompile it and when running dosbox
watch the console window.

this returns the values:

key type 2 is 3c [5c 56] ;pressing the key
key type 3 is 3c [5c 56] ;releasing the key

looks good and tells me that it is not SDL which causes the problem-

(no difference if I add "usescancodes=true" or not in dosbox.conf)

Those codes are fine, try the freedos keyb and see if the key
works there (so the 120 key works like on a regular german
keyboard including alt-gr+120key)

with keyb it works nicely with CVS versions. 0.63 release doesn't work correctly with keyb.

But here the FreeDos keyb.exe doesn't work. And it is impossible to work, because no key codes arrive at int 15h, ah=4Fh, which usually is called very early in the IRQ 1 handler. In fact, pressing 102-key does not even produce any data at keyboard port 60h (which is the lowest possible level).

How does keyb.exe not work? Any error message?
Why nothing happens for you there is a mystery to me.
(anything else you do differently? like a self compiled sdl.dll or something like that?)

> How does keyb.exe not work?

well, keyb.exe works of course, but nothing happens when the 102-key is pressed.

> like a self compiled sdl.dll or something like that?)

No, I don't use a self-compiled sdl.dll . Btw, it has already been proved that sdl is not the problem. Dosbox is somewhere swallowing the key, and yes, possibly I'm doing something differently/wrong, but I don't know what. That's why I'm asking.

Did you change something in the mapper? Try to delete mapper.txt,
and use the aep-build with default settings.

For your own build: In keyboard.cpp, function KEYBOARD_AddKey add
some LOG_MSG that displays the keytype, this is one of the next
functions that is called.

after renaming mapper.txt the 102-key works. Thanks for this hint!

then I installed a fresh copy of dosbox.0.63 (6.12.2004) to see what I stupidly may have changed there but it wasn't installed. And I cannot remember where I get my mapper.txt from. I attached it so someone possibly could tell me what the problem is in there.

Well the less-than key is missing from the mapper.txt, which means it
has no effect. To generate a valid mapper.txt, delete the old file (as
you did), start dosbox, press ctrl-F1 and klick on SAVE. This is not
really necessary because if mapper.txt is missing, dosbox'll use the
standard set, but you can compare those files at wish.

yes, it works fine without the mapper.txt file

btw, while analyzing the problem with a simple tool which hooks into int 15h, ah=4fh I noticed that keys "caps lock" and "num lock" are handled a bit strange. Once pressed, dosbox doesn't seem to realize that the key has been released again and continues to generate make codes (which then arrives at int 15h) until any other key is pressed.

that is correct
sdl doesn't pass numlock capslock release codes to dosbox.
so we cheat a bit by releasing them (in the bios area) on every key

then I installed a fresh copy of dosbox.0.63

curios, does it work with 0.63 for you? I couldn't get the correct < keys with it (when loading keyb.exe).

No, with dosbox 0.63 I get a "#" if I press the 102-key (didn't use keyb.exe, I used my own tiny driver)