wd wrote:

Much of the stuff you mention is already fixed as of the commit of yesterday.

Which parts have been fixed?

I'll check it out later this evening...

Thanks for the info,

dvwjr

numlock on+shift-numpad
numlock on+ctrl-cursorkeys
numlock not xoring shift-behaviour

I just look over your code fixes to the DosBox CVS. Quick work!

While I was looking at your fixes, I notice the following code and thought that the following section might need a few changes for Scancode Set 1 consistancy. Just a suggestion from looking at the Microsoft Keyboard Scan Code Specification document.

From 2006-02-12 version of DosBox file Bios_keyboard.cpp:

1Line 411	if(flags1&0x40) {                                                             /* CAPSlock
2Line 412		if(flags1& 0x03) {                                                    /* Either SHIFT
3Line 413			/*cancel shift */  
4Line 414			if(((asciiscan&0x00ff) >0x46) && ((asciiscan&0x00ff) <0x55))  /* range 0x47 to 0x54
5Line 415				asciiscan=scan_to_scanascii[scancode].normal; 
6Line 416		} else {
7Line 417		/* add shift */
8Line 418   		if(((asciiscan&0x00ff) >0x61) && ((asciiscan&0x00ff) <0x7a))  /* range 0x62 to 0x79
9Line 419				asciiscan=scan_to_scanascii[scancode].shift; 

Thanks for your time,

dvwjr

That'd make the behaviour for the capital "A" wrong
(caps lock+shift), which has the ascii code 0x41.
Or did i miss something?

wd wrote:

That'd make the behaviour for the capital "A" wrong
(caps lock+shift), which has the ascii code 0x41.
Or did i miss something?

😳
This will teach me to never compose messages late at night. Please ignore the code fragment in the message above, it has nothing to do with what I was going to insert in the message 'code' area. That is just another text buffer where I was playing around with the MinGW C complier output for its range checking ASM output... I did not check the text in the short compose area of this forum software which scrambles visual end of line markers for long text lines. My apologies for being sloppy.

Now for what I should have written last night... I got to thinking about the keyboard behavior of the IBM model M keyboard under DOS 6.22 and the WinXP NTVDM emulation. I used the ScanCode utilility I found to look at the behavior of the keyboard scancode/input system to compare it to how DOSBOX was responding. Sounds good, but I fell into a trap - I assumed that my test environment described the way the keyboard system worked in all cases - and I was wrong.

When this message thread began and I injected myself into the investigation I tested for one of TWO valid keyboard environments and the DOSBOX developers changed the DOSBOX behavior to match the apparent MS-DOS standard. However, something about my previous use of a PC-AT 84-key keyboard made me get an old one out of storage with an old IBM PC/AT with DOS 3.30. It turns out that the use of the SHIFT key DOES negate the functionality of an active NUMlock key for the eleven keys on the numeric keypad of the 84-key IBM PC-AT keyboard, while it does no such thing to the same keys on the modern day 'enhanced' 101+ keyboard

So for Scan Code Set 1 consistancy for both the "enhanced" 101-key and "normal" 84-key keyboards here is the following code suggestion:

From 2006-02-12 version of DosBox file Bios_keyboard.cpp:

1Line 378	if(flags1 &0x08) {                                             /* ALT
2			Bit8u token = mem_readb(BIOS_KEYBOARD_TOKEN);
3			token= token*10 + scan_to_scanascii[scancode].alt;
4			mem_writeb(BIOS_KEYBOARD_TOKEN,token);
5		} else if (flags1 &0x04) {                                     /* CTRL
6			add_key(scan_to_scanascii[scancode].control);
7		} else if (flags1 &0x3) != 0) || ((flags1 &0x20) != 0) ) {     /* Either SHIFT or NUMlock */
8			if ( (flags3 &0x10 != 0) && (flags1 &0x20 != 0) )      /* 101-key keyboard with NUMlock ON */
9			 add_key(scan_to_scanascii[scancode].shift);	
10			else if ( (flags3 &0x10 == 0) && (flags1 &0x20 != 0) ) /* 84-key keyboard with NUMlock ON  */
11			 add_key(scan_to_scanascii[scancode].normal);
12			else add_key(scan_to_scanascii[scancode].shift);
13		} else add_key(scan_to_scanascii[scancode].normal);
14		break;

I just have a rusty, casual familiarity with Pascal, so don't depend on my "C" syntax...

Sorry for the trouble,

dvwjr

Hm, that's interesting. The main target keyboard is an enhanced
keyboard at the moment, so the current implementation should be ok.
On the long run, i'd like to change the keyboard behaviour to the
84-key variant for the old architectures (machine=cga,tandy,pcjr)
which ignores enhanced keys, and does the numlock stuff you
described differently, and so on.

interrestingly my laptop has 84 keys 😀 which explains my original implementation.

Thanks for figuring it out.

Qbix wrote:

interrestingly my laptop has 84 keys 😀 which explains my original implementation.

Thanks for figuring it out.

More than happy to help in any small way... The Microsoft document also indirectly alludes to this ancient behavior, but concentrates more on enhanced keyboard Scancode set #1 and Scancode set #2 (with complete drop of Scancode set #3) being used via USB and its keyboard implementation and WinKey Logo requirements etc etc.

The reason I was curious about this was that I have a USB to PS/2 adapter which will take an IBM model M keyboard and supposedly do the scan-code translation properly (one of the few that said to work OK) to allow the PS/2 port terminated IBM model M keyboard to be used with a USB port. I was getting some strange results so I went back to direct PS/2 and direct PC/AT connections/keyboards.

I also am working on revamping a fairly popular "cult" game out of the mid 90's for a very young newphew and wanted to make sure that DOSBOX with its keyboard implementation was working properly for this game in its low resolution video modes. The DOSBOX "heavy-debug" version has been very useful, can't wait until you get "break on memory access" added to your code-base.

Thanks again,

dvwjr

bp on memory acces. yeah one of my wishes as well.
Discusssed how to implement it in a fast way quite often with harekiet.
He had a good idea on how to do it. but I think it got lost in the large base of ideas we usually have.