Hmm...it is true, the accent doesn't work for "O" using either keyb la or keyb sp, not even using the DosBox promt
-------------
Hmm...Es cierto, no funciona la tilde para la "O" ni con keyb la ni con keyb sp, ni siquiera en el indicador de DosBox

It does the same thing when using CP 850.

-----------------------

Yo juraría que la página de códigos de España era la 850... pero da lo mismo, tampoco funciona.

same problem with layout pl214
it is not a problem of codepage as it works with pl457 with the same codepage.
It looks to be a problem of how Ó is being generated.
pl214 generates Ó this way: altgr+9 shift+o (doesn't work)
pl457 generates Ó this way: altgr+shift+o (works)
alt 224 also excludes codepage problem
I guess this problem should happen in all keyboard layouts in dosbox

it looks it is definitely some bug as there should either a one composed character appear (for example Ó) or two characters when composed is not possible (for example sth like this`O). But here nothing appears as if backspace was pressed instead of O.

You mean capital O, right?

It doesn't work for me either using codepage 437

=================================================

Quieres decir O mayúscula, ¿verdad?

Tampoco me funciona usando la página de códigos 437

ASCII character 224 (0xE0) is being mistaken as an extended key signal. After setting up a Spanish keyboard in MS-DOS 5, I can see that the diacritic keys placed in the BIOS key buffer do not have scan codes, and apparently an 0xE0 in the buffer with no scan code does not signal an extended key. Implementing this in dos_keyboard_layout.cpp appears to solve the problem, but maybe the solution is not really this simple...

1                 // search scancode
2                 for (Bit16u i=0; i<diacritics_length; i++) {
3                     if (diacritics[diacritics_start+i*2]==(layouted_key&0xff)) {
4                         // add diacritics to keybuf
5-                        BIOS_AddKeyToBuffer((Bit16u)(key<<8) | diacritics[diacritics_start+i*2+1]);
6+                        BIOS_AddKeyToBuffer((Bit16u)diacritics[diacritics_start+i*2+1]);
7                         return true;
8                     }
9                 }

testing with kbd i see two strange things:
1. why arrows, pgdn,up,home,end,del,ins also produces E0
2. why with keyb pl alt+shift+o produces 00E0, cause it looks that 00xx only appears when "alt xxx" is used for generating character.

why arrows, pgdn,up,home,end,del,ins also produces E0

Because they're extended keys.

Normal keys are written into the keyboard buffer as a scancode byte and a character byte, but extended keys need two scancode bytes, so the first pair has a character of 0xE0 to signify that the key is extended and that another pair follows. However, it appears that 0xE0 with a scan code of zero does not signify an extended key, which makes sense given that two scancodes are needed.

why with keyb pl alt+shift+o doesn't generate a scancode?

see ripsaw's diff

i don't understand a thing from it 😀

why with keyb pl alt+shift+o doesn't generate a scancode?

It's processed differently than the diacritic keys. The comments in the code refer to it as a "remapped" key, and the scancode (zero in this case) appears to come from the kl data:

1        // add remapped key to keybuf
2        if (is_keypair) BIOS_AddKeyToBuffer(layouted_key);

yeah i know it is generated differently but i was more interested why there is a difference in the same method of generation:

for example
alt+shift+n which makes Ń
alt+shift+c which makes Ć
alt+shift+s which makes Ś
generate scancodes
while
alt+shift+o which makes Ó
doesn't generate a scancode
Even though all of them are generated same way. It looks alt+shift+o is treated in some special way compared to for example alt+shift+n

It looks like the kl makes a special case for the key, because is_keypair is true for altgr+shift+o but not for the others. So it seems with remapped keys that the kl is forcing a scancode of zero with character 0xE0 for the purpose of preventing it from being seen as extended key. Dunno if there is a similar kl mechanism for diacritic keys.

I haven't tried setting up any other country keyboard types in real DOS, but for Spanish I could see that *all* diacritic keys have a scancode of zero, not just 0xE0.

I guess you can not do anything. thanks

----------------------------------------------------------------

Supongo que no se puede hacer nada. Gracias

A word of thanks to Ripsaw8080 for his patch. It solved a problem reported by a Spanish-speaking user of my WordPerfect application. This was a very frustrating problem, and Ripsaw's patch solved it instantly.

ripsaw8080 wrote:

It looks like the kl makes a special case for the key, because is_keypair is true for altgr+shift+o but not for the others. So it seems with remapped keys that the kl is forcing a scancode of zero with character 0xE0 for the purpose of preventing it from being seen as extended key. Dunno if there is a similar kl mechanism for diacritic keys.

I haven't tried setting up any other country keyboard types in real DOS, but for Spanish I could see that *all* diacritic keys have a scancode of zero, not just 0xE0.

I have tried msdos 6.2 with both polish layouts (had to take keybrd4.sys from win98se to enable the layout that allows alt-o).
And all diacritic keys:ąężźóńśćĄĘŻŹÓŃŚĆ have zero scancode in both layouts.
So it looks someone fixed in dosbox Ó made with alt-shift-o but didn't fixed the method of creating it with dead key.

Ó works ok here too with the diff.
I noticed you made 00 scancode to all characters made with dead keys, not only Ó. Although diacritic characters made with without deadkey still have scancode different from 00. Are there any disadvantages of making it 00 too (to match real hardware)?