For the right alt you're missing bit 3 of 0x40:0x17 (either alt pressed).
Don't know if it would work then, this type of key faking is only useful
for a limited number of cases.

OMG! It works! 😁

I did read the description of all of the keyboard bits(0040:0017,18,96,97) carefully, but I never imagined I'll need BOTH 'Right_Alt' and 'Both_Alt' together, never mind, as long as it works I'm happy.

Zillions of thanks wd 😀

Hm no, maybe you misunderstood that. There's one bit for left alt,
one for right alt, and one bit that's set if either of the two is active.
So either the game doesn't mind with alt key is pressed (thus uses
the "any alt" flag) or they check the "any alt" bit at first and then
further determine which alt it was.

I thought it was the second option(first checks if either alt is pressed and then checks which one) because I remembered that pressing the left alt+right shift didn't work, but when I checked now, just to be sure, it turned out that I didn't remember correctly... So 'both_alt'+'right_shift' also works.

However, it seems that I hasted to be joyous too soon... The program does work, but not always, about 30% of the times it fails , with exactly the same settings... It just doesn't work randomly 😒

You said:

wd wrote:

this type of key faking is only useful
for a limited number of cases

Does that mean that there is a better way to do it?

[Moved]

Does that mean that there is a better way to do it?

No, because it works fine for the game.
But in general there are lots of ways to check for keys, and some are
nasty to "key-in". Moe put up a patch on sourceforge some time ago
that handles port access for key reading, too.

OK, I'll take a look at it.

Thanks again.

If I understand correctly, the ADDKEY command (I assume that is what you were referring to) is EXACTLY what I need! however, unfortunately, I do not have the skills to integrate this file:
dosbox-addkey-20050303.diff
Into the source OR even compile DOSBox anyway... So does anyone know of a Window$ CVS build with this patch?

Well no real need for that, as your solution about just modifying the
state variables seems to work fine.

Either you missed my comment about the current problem, or I didn't explain myself properly, anyway, I'll try to clarify. When I wrote:

Og wrote:

However, it seems that I hasted to be joyous too soon... The program does work, but not always, about 30% of the times it fails , with exactly the same settings... It just doesn't work randomly 😒

I meant that the program I wrote only works sometimes, well, it's probably doing what it's supposed to do all the time, but the TSR that's supposed to react to Alt+Shift doesn't always react *correctly* to the program I wrote(sometimes it's fine and others it shows some erratic behaviour), also, if I run the program once, manually pressing alt+shift afterwards displays the same erratic behaviour...

If you want to look at the code, I've attached it, but I really think `moe`'s ADDKEY is the best option I have, because lets face it, I'm no coder... maybe an ametur at best.

1#include <stdio.h>
2#include <dos.h>
3#include <conio.h>
4
5void set4017(unsigned char bits)
6{
7 char far *kbds0 = (char far*)0x00400017UL;
8 *kbds0 |= bits;
9}
10
11void clear4017(unsigned char bits)
12{
13 char far *kbds0 = (char far*)0x00400017UL;
14 *kbds0 &= bits;
15}
16
17/**********************************/
18
19void main()
20{
21 if(1==0) printf("Copyright Og August 2007. Made for www.<CENSORED>.org");
22 set4017(9); // simulates alt+right_shift in order to change text direction: right to left
23 getch();    // wait for user input (pause), also acts as a necessary delay
24 clear4017(246); // free bits 0 and 3 of 40:17(stop pressing keys)
25 delay(50);     // not really necessary
26 set4017(10);   // now press alt+left_shift in order to return text direction to the normal L2R
27 delay(300);   // wait for hebrew.com to check the bits
28 clear4017(245); // clear bits 3 and 1 of keyboard_flag_0 (0040:0017)
29 delay(50);  // not really necessary but can't hurt either...
30 clrscr();  // destroy the evidence  :)
31}

Hm yes, randomness is no good...

How do you start the program? Maybe add a delay at the front, so no
keys are in the queue. Also the delay300 might not be enough for the
tsr to cath up (depends on their checking interval of course).

GOD you're fast!
Well, I also tried delay(500);, but according to the help file the value of delay(); is in milliseconds, so 300 is almost a third of a second... surely a human presses a key quicker than that, no? 😖

I'm gonna check with the delay at the beginning of main(). BRB.

Nah, still doesn't work. It's odd, seems like everytime I run the program it gets less functional... now it hardly ever works...

Maybe I'll take another shot trying to compile the CVS with `moe`'s ADDKEY (I have no idea how to do either(compile OR add the patch), but I'll try...). It would be cool if I'd succeed, could also add the precache core while I'm at it(need it for FIFA 94).

Then again, maybe not ... 😒

Think ykhwong's builds incorporate the ADDKEY command.

So it seems 😀
However, I can seem to find a list of available keys... The patch submission comment states:

`moe` wrote:

As the other enhancements are already in CVS, here is the ADDKEY code again, standalone. Syntax has been improved to be easier, […]
Show full quote

As the other enhancements are already in CVS, here is the ADDKEY
code again, standalone. Syntax has been improved to be easier, and
problems with some changes to key handling have been resolved. Just
an example to show the easier syntax:

ADDKEY d e m o . e x e enter f2 enter p1000 l200 y p10000 c-c

(Enter "demo.exe" followed by enter, then press f2, then enter, wait a
second, press 'y' for 200msec, wait 10 seconds, press ctrl-c)

There are no longer 2 modes of operation or anything, just this syntax:
any char is just that char. special keys are recognized (Enter, PgUp,
left, f11, and so on), p<number> waits some milliseconds, l<number>
makes keys pressed the given amount of msecs. Works like a charm
to skip configuration questions and similar startup input.

But what are the keys for alt? Left or right shift?
All that the readme says is:

8. ADDKEY [key]
It generates artifical(SIC) keypresses. It was created by Moe.

Also looked at mapper.txt but the naming there doesn't work...
Am I missing a manual somewhere? 😕

[edit]
*can't seem to find

Usually when your question is being ignored, it means you didn't put enough effort in the search for an answer, but I doubt this the case here... I spent hours searching for the list of possible keys for Moe's ADDKEY command in ykhwong's build. Some of the files I checked were:

*ETC_EN.txt (ykhwong's CVS build readme)
*mapper.txt
*The ADDKEY patch page
*Both of the diff files from the previous link
*\include\bios.h
*\include\keyboard.h
*\include\mapper.h
*\src\dos\dos_keyboard_layout.cpp
*\src\dos\dos_keyboard_layout_data.h
*\src\gui\sdl_mapper.cpp
*\src\hardware\keyboard.cpp
*\stc\ints\bios_keyboard.cpp
*Searched the forum for the keyword: "addkey"

I also thought that no one answers because this is the wrong forum(milliways) and `Moe` and ykhwong just don't check messages here, but when I tried to open a new thread pointing to this one in "DOSBox Patches" I got a message telling me only mods can post there 😒 .

So, ahmm... Help? 😐

Well it *might* be that nobody had yet the time to look at the diff
if it supports adding non-printable characters to the queue.

damn it's been one day and you are allready complaigning and sending pm to busy people.
This is all done in free time and isn't payed in anyway.
Don't forget that or you might end up without acces to this forum.

Nah, it does, the ADDKEY patch page clearly states that, I'll quote an extract from it in a minute but first I have to say I didn't mean to upset you. You helped me greatly here and in other problems I had too and I'm really thankful for it. My last post was not directed at you, on the contrary - I was sure you didn't answer simply because you never tried the patch and therefore don't know the answer, I was just wondering how come nobody replied to a question which I thought was simple for such a long time, but now that I look at the dates, I see that only a day passed since my previous post... It sure seemed longer 😖 So basically it was my mistake, now I'll wait patiently for several days (but do expect a bump then 😜 )
And the extract, as promised:

The second mode of operation uses the dosbox keyboard handler to add keypresses. It is able to fool any and all programs (some […]
Show full quote

The second mode of operation uses the dosbox keyboard
handler to add keypresses. It is able to fool any and all
programs (something which pure dos tools, including 4DOS's
keystack, can't do), but has a more complicated syntax.
It works by generating keypress and keyrelease events with
user-specifiable timings. By default, a given key is pressed
immediately and then released again with no delay:
ADDKEY 52
would simulate the Enter key. The number is a dosbox keysym.
basically, 0x1 = 1, 0x2 = 2, ..., 0x9 = 9, 10 = 0, 11 = q, 21 = a,
and so on. 52 is Enter. You have to use "0x1" instead of "1", as
"1" is used by simple mode above.
However, many programs need some time until they start to
read the keyboard. So using this syntax, you cann add pauses:
ADDKEY p1000 52 p500 52
would simulate the enter key after 1 second (1000 ms), and
another enter key press after another pause of half a second
(1.5 seconds after the command was executed).
I haven't come across this yet, but some programs might also
be sensitive to key press duration, so there is a syntax to
configure it:
ADDKEY l100 52
would simulate an enter key press for 100ms. The duration is
kept for all subsequent keys until changed. This allows you to
simulate Shifted keypresses (or Alt/Control):
ADDKEY l100 54 l40 21
would be Alt-A (press left alt for 100 ms, and almost
immediately press the "a" key for 40ms)
This can be mixed freely:
ADDKEY 52 p1000 l100 54 l0 21 p100 52
would be:
Press Enter immediately, wait a second, press left-alt for
100ms, press "a" immediately thereafter with a duration of 0ms
(which is the default), wait 100ms (until left-alt has been
released), then press Enter again.