Recent Posts

Pages: [1] 2 3 ... 10
1
Games / Re: DOS VDM - USB and Game port Gamepad support
« Last post by Wim Brul on Today at 01:14:30 pm »
Hi Jochen,

I don't know when I can get to it, but I will look into it.
Thank you. For starters I tried and modified SDL_os2joystick.c myself. I could send the modified source code to you or append it here. Please advice.

I replaced lines 440 thru 442 with the following:
Code: [Select]
                        joystick->hwdata->transaxes[i].offset = ((SDL_JOYSTICK_AXIS_MAX + SDL_JOYSTICK_AXIS_MIN)>>1) - SYS_JoyData[index].axes_med[i];
                        joystick->hwdata->transaxes[i].scale1 = (float)SDL_abs((SDL_JOYSTICK_AXIS_MIN/SYS_JoyData[index].axes_min[i]));
                        joystick->hwdata->transaxes[i].scale2 = (float)SDL_abs((SDL_JOYSTICK_AXIS_MAX/SYS_JoyData[index].axes_max[i]));

I replaced lines 550 thru 560 with the following:
Code: [Select]
                value = pos[i];
                if (value < SYS_JoyData[index].axes_med[i])
                {
                        value = (transaxes[i].offset - value) * transaxes[i].scale1;
                        if (value < SDL_JOYSTICK_AXIS_MIN) value = SDL_JOYSTICK_AXIS_MIN;
                }
                else
                {
                        value = (value - transaxes[i].offset) * transaxes[i].scale2;
                        if (value > SDL_JOYSTICK_AXIS_MAX) value = SDL_JOYSTICK_AXIS_MAX;
                }
 
What I am after is that you build an SDL1 test version of DOSBox for us to try out.
I regard this still very experimental, so not yet suitable for an official release.
2
If it's a crash in PMMERGE.DLL, have you tried the OS/4 team's patched PMMERGE.DLL?

Obviously it won't be supported by Arca Noae in any way, so backup your current .DLL first!

http://os4.team/os4/pmmerge/pmmerge6111.zip
3
Games / Re: DOS VDM - USB and Game port Gamepad support
« Last post by Mark Szkolnicki on May 21, 2022, 07:49:00 pm »
Heh Lars!

Hope your having a fine weekend - the long Victoria Day weekend here.


It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.

In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).

Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.

So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.


Thanks for the detailed explanation.

As mentioned I'm not a programmer myself, but I appreciate when someone will explain not just that there is a problem, but what it may be as well as its implications. It also assists greatly in testing at the moment, to analyze  exactly what I did that made it trigger.

In this case I'm simply acting as a tester and reporting anything I may see, that may be of significance or interest, hopefully in a way useful to you, Wim, Jochen or anyone else participating or observing.

However, in my emergency / environmental consulting practice, as well as my senior roles in both government and corporate in my career, I've been a senior project manager leading teams of hundreds - I always appreciated being informed by my staff as to potential roadblocks, pitfalls or problems, and what may need to be done, in a way I can comprehend, as being forewarned allows planning to proceed smoothly. Analysis is key to success, as well as being methodical IMHO.

I've learned a lot in this what I consider a "project" - it is fascinating to look "under the hood" so to speak as to what actually makes up a device driver and how it operates.

Best!

M
4
Programming / Re: getting a single keypress?
« Last post by Dave Yeo on May 21, 2022, 07:21:31 pm »
Hi Rich, the test program was written by Thomas the maintainer, based on the mpg123 code. It does run on the same thread so the DosSleep()  is required and the file itself is term_posix.c with HAVE_TERMIOS a requirement and Thomas did add the comment,
Code: [Select]
#ifdef __OS2__
// Hoping for properly working termios in some future (?!), but until then,
// we need keyboard access bypassing that.

It does seem to work well.
5
Programming / Re: getting a single keypress?
« Last post by Rich Walsh on May 21, 2022, 06:44:21 pm »
Dave, I saw your post a few days ago but was unable to respond until now. I'm glad you recognized that using select() to get a keystroke on OS/2 is just a crazy-bad idea. And, since this will never be ported back to *nix, the use of KbdCharIn() may be the simplest possible to way avoid using 'stdin' (a method I would never have thought of!).

The good news is that it allows you discard just about every other line of code in your test program. There's no need to open anything - notice that it doesn't require a file descriptor. Unless termio is required elsewhere in the app, it's totally unnecessary as well. The only question I have is whether keyboard input occurs on the same thread as 'mpg123's decode/play code. If they're on separate threads, there's no need for a pointless polling loop - just let it block until a keystroke comes in, no DosSleep() needed. The final version of 'test.exe' should require no more than 8-10 lines of actual code, mostly just to display the keystroke on the console.
6
Programming / Re: getting a single keypress?
« Last post by Dave Yeo on May 21, 2022, 05:32:15 pm »
It didn't seem to work while a program was running.
7
Games / Re: DOS VDM - USB and Game port Gamepad support
« Last post by Jochen Schäfer on May 21, 2022, 11:00:18 am »
Hallo Jochen,
What would be the correct algorithm? Since we have the code, we could fix that. Most likely the code in SDL2 is also wrong, because it is a straight port of the SDL1 code.
I think that my proposed algorithm is the correct algorithm. See my original post.

First the calculation of the offset, scale1 and scale2:
Code: [Select]
offset = axis_center
scale1 = SDL_JOYSTICK_AXIS_MIN / (axis_lower - axis_center)
scale2 = SDL_JOYSTICK_AXIS_MAX / (axis_upper - axis_center)

Followed by the recalculation for all axes:
Code: [Select]
if (axis < axis_center)
then axis = (axis - offset) * scale1
else axis = (axis - offset) * scale2

This has of course to be substituted in SDL_os2joystick.c at the right places. Too difficult for me to do.

Cheers,
Wim.
Hi Wim.

I don't know when I can get to it, but I will look into it.
8
Games / Re: DOS VDM - USB and Game port Gamepad support
« Last post by Lars on May 21, 2022, 09:32:43 am »
I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!

M

It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.

In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).

Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.

So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.

9
Programming / Re: getting a single keypress?
« Last post by Lars on May 21, 2022, 07:26:45 am »
And why can't you use the standard RTL function "getchar"? Is that not available?
10
Games / Re: DOS VDM - USB and Game port Gamepad support
« Last post by Mark Szkolnicki on May 21, 2022, 04:26:01 am »

I'm actually running tests on a tower, with an AMD hexcore processor and 3 Gb of usable memory installed (actually 8 GB in the system, but ArcaOS is not seeing the rest). Occasionally after installing the gamepad package previous to 2022-05-17 and with the current one, I've gotten a black screen trap, attempting to start a game with one of the xevents packages active.

I've attached a photo of the trap screen, if it is of any help - I have not determined a particular reason why it happens at the moment as I've only seen it four times and Best!


Hi Mark, that is a weird trap as it is a breakpoint, probably code that should never be reached and perhaps worth opening an issue with Arca Noae, especially if you could get a system dump of it. Unluckily if it is only occasionally trapping, it'll be hard to get a good dump as rally you should lower your memory, 3GB dump is big.

Heh Dave!

As I have not seen a lot of it, other than in this thread, I think I would give it a miss - if I can find a reason for it that would affect everyone I certainly would report it, if it is the system and not what we are testing - I think I would like to know why first and a fine weekend, as always!

M
Pages: [1] 2 3 ... 10