This is a bug of a specific program... So you should tell us its name...

Mirek

Thanks for reply !

The name of the program is ActsipH; it is a PLC-Programming application.
The keys are working in XP-Command prompt. But I want to use DOSBOX because the serial communication is much better then.
Thanks.
Hans.

Ctrl-Up/Down do not have a distinct key name/number. The mapper remaps whole keys, not key combinations.

One thing you could try is to remap up/down to somewhere else, like S/X. If Ctrl-S then works like Ctrl-Up, your operating system is to blame.

If Ctrl-S doesn't work either, it looks like a bug in your app or in DOSBox. Unfortunately DOSBox is meant for running games, not business applications. You can find someone to help you, but people here may not me terribly inclined to help you. It really depends on their mood 😉

Dos4ever wrote:

I have to use the arrow keys/ cursor keys up and down in combination with the Control key to draw a vertical line in a specific […]
Show full quote

I have to use the arrow keys/ cursor keys up and down in combination with the Control key to draw a vertical line in a specific DOS program. But only left and right keys work.
I tried using mapper but I don't know the key name and the key number.
Can anyone help me please ?
Thanks . Hans.

Try one of the current CVS versions. If you are using the offical DOSBOX v0.63 version the CTRL-LeftArrow and CTRL-RightArrow do function, but the CTRL-UpArrow and CTRL-DownArrow were incomplete and not functional.

However, the CTRL-UpArrow and CTRL-DownArrow do function exactly as does MSDOS or the WinXP NTVDM emulation in the latest CVS releases.

Your problem is already solved.

dvwjr

Thanks for reply dvwjr,
I can't find other CVS versions. Can you give me a URL/link to these versions please ?
Thanks. Hans.

Guest, check my sig for a link.

I tried the CVS build of 2006-02-01. This did not help. The program Actsip-H has debug information and the used CVS build reported the computer as a PC AT. The Ctrl+arrows stil did not work, the access to the serial port either 😢 . This is the real reason why I use Dosbox under W2K and WXP is for the fine serial port support, better then the NTVDM 😀 .
Is it an option to mail the Dos-program for testing?
Is the serial port support not in the CVS build?
By the way not only the Ctrl-Up and Ctrl-Down dit not work. Ctrl-Left and Ctrl-Right either.

The serial port has new config strings in CVS.

[serial]
serial1=directserial realport:com1

dos4ever wrote:

I tried the CVS build of 2006-02-01. This did not help. . . . By the way not only the Ctrl-Up and Ctrl-Down dit not work. Ctrl- […]
Show full quote

I tried the CVS build of 2006-02-01. This did not help.
.
.
.
By the way not only the Ctrl-Up and Ctrl-Down dit not work. Ctrl-Left and Ctrl-Right either.

OK. Let's be systematic. Go to this VOGONS post and download the file ScanCodeInfo.zip which is an attachment to the first message in the thread. Un-zip the file to extract the SCODE.COM file. Run this file in your CVS version of DOSBOX to see what CTRL-↑/CTRL -↓/CTRL-↓/CTRL-→ display for the hexadecimal results for AX and BIOS .

Now compare the results with the two screen-shots of the same test for the WinXP NTVDM environment and a late November CVS compile of DOSBOX. Post a screen-shot of your results and we shall know if it is a keyboard scancode problem in DOSBOX or your application has other problems.

dvwjr

Hello dvjr,
I have tested with the mentioned dosbox cvs release 1 feb 2006.
At first it seemed to work okay with this version. However when sharing this with my friend dos4ever. It did not work okay. It seems to make a difference is dosbox is started with numlock on or off.
With the NTVDM the results are the same under W2K an WXP, with numlock on when opening the dosbox and with numlock off. This image is NTVDM_numlock_off_at_launch.
The first 4 key presses are the Ctrl-arrow keys (inverted T on keyboard) with numlock off. The next 4 with numlock on.
Then the next 2 screenshots are from dosbox.
Screenshot dosbox_numlock_on_at_launch.gif is with first 4 key presses are the Ctrl-arrow keys (inverted T on keyboard) with numlock on. The next 4 with numlock off.
Screenshot dosbox_numlock_off_at_launch.gif with first 4 key presses are the Ctrl-arrow keys (inverted T on keyboard) with numlock off. The next 4 with numlock on.
I see some differences. Maybe this will help.

nipperds

Hello h-a-l 9000,
Thx for your hint considering the serial port setting. I had the setting under the section [bios]. At first it did not work, but after rereading I saw the difference in the section name.
Serial communication now works fine.

nipperds

nipperds wrote:

Hello dvjr, I have tested with the mentioned dosbox cvs release 1 feb 2006. . . . I see some differences. Maybe this will help. […]
Show full quote

Hello dvjr,
I have tested with the mentioned dosbox cvs release 1 feb 2006.
.
.
.
I see some differences. Maybe this will help.

Longer answer to follow later today.

There is a problem with DOSBOX current CVS compile that you are using for your ActSip-H application. There is a short-term workaround which is to use the CTRL-SHFT pair on the RIGHT side of the keyboard instead of just the CTRL key. The NumLock key may be (on or off) when you use the inverted-Tee arrows, the functionality should be the same.

So you want to do CTRL-↑, do a R.CTRL-R.SHFT-↑instead.

More later,

dvwjr

Should be fixed by using

1} else if( ((flags1 &0x3) != 0) || ((flags1 &0x20) != 0) ) {

(or instead of xor so NUM toggles the normal keys to shifted ones)
and swapping this line with the line

1} else if (flags1 &0x04) {

for the extended keys.
(both things in bios_keyboard.cpp)

shift and numlock should be xorred. having both active results in regular codes.

The numeric keys on the numblock? My keyboard does not
behave like this.

hmm i recall that on my laptop that numlock and shift were mutually exclusive. Just as capslock and shift.
But then again it's a laptop. Not sure how much faith can be put into those.

perharps ctrl is handled before shift and numlock.

Should be consistent now, please test if the program works.

wd wrote:

Should be consistent now, please test if the program works.

To: DOXBOX Developers
From: dvwjr
Subject: IBM PC-AT/PS2 Keyboard emulation

The concerns the current DOSBOX CVS compiled version that exhibits some anomolies, some of which you have been made aware by this message thread. Also attached to this message is a ZIP file with ten GIF files which are screen captures comparing the WinXP (SP2) NTVDM keyboard output with a current DOSBOX CVS release.

Also enclosed in the ZIP file is a modified version of ScanCode Show version 2.2 by Mr. Paul Postuma. The modified version is labeled on-screen as version 2.21 followed by my initials. Previous versions are now deprecated. I had to modify his keyboard diagnostic utility to reflect the proper display precedence order for the keyboard modifer keys when multiple modifiers are simultainiously depressed. The "ScanCode Show" utility always displayed the proper decimal/hexadecimal keyboard scancodes, however the key-stroke interpretation displayed on the left side of the screen incorrectly displayed with multiple keyboard modifiers depressed at the same time by having SHFT over-ride CTRL over-ride ALT. The proper display order in the multi-modifer situation is ALT over-ride CTRL over-ride SHFT. Now the version "2.21" of the utility displays what is expected.

The problem with the current CVS releases of DOXBOX concerns the ten PC-AT/PS2 'gray' keys: INSERT, DELETE, HOME, END, PAGE UP, PAGE DOWN,↑ , ↓, ←, →. There appear to be three errors with the current DOSBOX CVS key-modifier code.

First error is the keyboard modifier key precedence order. It should be the highest priority of ALT, then CTRL, then SHFT and finally CAPSlock/NUMlock. It appears that the current DOSBOX CVS has the modifier order as ALT, then SHFT, then CTRL and finally CAPSlock/NUMlock with these ten keys ONLY. This leads to a CTRL-SHFT modifier combination improperly providing SHFT only scancodes for these ten gray keys. The modifier precedence order appears to be correct for all other keys.

The second error error noted is that when the NUMlock key is OFF, the RIGHT SHFT does not the modify the output of any of the ten gray keys that is depressed, nor does it properly set the bit 0 of the Keyboard BIOS variable at address 0040:0017. This can be seen with the use of the v2.21 ScanCode Show utility. When the NUMlock key is ON, the RIGHT SHFT functions properly with the ten gray keys.

The third error appears to be the function of the SHIFT keys as related to the eleven white keys of the numeric keypad. The WinXP (SP2) NTVDM emulation appears to have any SHIFT key OR'd with the NUMlock key toggle status for these eleven keys, while the CTRL key is XOR'd with NUMlock key toggle status and resulting scancodes provided. The DOSBOX CVS appears to have XOR'd both the SHFT and CTRL with the NUMlock key toggle status so that CTRL or CTRL-SHFT works properly, but SHFT mistakenly reverses the NUMlock key status for the scancodes of the eleven white numeric pad keys.

Hope this helps,

dvwjr

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