B-Em, GEM, Windows and Mouse

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Coeus
Posts: 418
Joined: Mon Jul 25, 2016 11:05 am

B-Em, GEM, Windows and Mouse

Postby Coeus » Mon Mar 27, 2017 10:47 pm

I have been working my way through the co-processors to add hooks into the B-Em debugger and have got as far as the 80186 as used in the Master 512. To check I haven't broken the processor emulation in any major way I thought I'd have a play with DOS Plus and GEM.

To start with, working on Linux, I found the mouse would only move in the X direction. Having corrected what seemed like an obvious error I had GEM working fine. Moving to Windows I find that something, possibly Allegro, tries to "capture" the mouse. After it has done that the mouse does not move in GEM at all. If I press Ctrl-End, as suggested in the title bar, to release the mouse then it does move as I move the real mouse but as soon as I click on anything to activate it the mouse gets captured again.

Has anyone has any success with using the mouse under Windows?

User avatar
hoglet
Posts: 6486
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em, GEM, Windows and Mouse

Postby hoglet » Tue Mar 28, 2017 6:38 am

Coeus wrote:Has anyone has any success with using the mouse under Windows?

It seems to work for me (in both directions), as long as AMX Mouse is unticked in the Mouse menu.

If AMX Mouse is ticked, it only works in the X direction.

Dave

Coeus
Posts: 418
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em, GEM, Windows and Mouse

Postby Coeus » Tue Mar 28, 2017 8:35 am

Dave, which version were you testing?

The issue of the Y direction not working is one I came across, hence the latest commit to master. If you look at https://github.com/stardot/b-em/blob/a7 ... rc/mouse.c, for some strange reason the tests for the two directions are different. Fixing that so that they are both like the X direction seems to have resolved that for me, hence https://github.com/stardot/b-em/blob/3c ... rc/mouse.c

What I don't understand is why AMX mouse being selected should make any difference. Looking at that code the mouse emulation for curtube == 3 should take priority over AMX mouse.

Back to the question I started this thread with, what seems to be happening when I try this on Windows is when the mouse is captured, the get_mouse_mickeys call starts returning the mouse position within the window rather than how far the mouse has moved. What I am not sure about is whether that is a feature of my setup or something that happens generally. I am testing with Windows running inside VirtualBox and to avoid the whole mouse capture issue VirtualBox is telling windows I have a graphics tablet rather than a mouse. That means VirtualBox can tell Windows the position of the pointer within the VirtualBox window, i.e. the position on the Windows desktop, rather than how far it has moved and it is possible Allegro may be just picking this up because it doesn't understand the difference between a tablet and a mouse.

User avatar
hoglet
Posts: 6486
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em, GEM, Windows and Mouse

Postby hoglet » Tue Mar 28, 2017 9:06 am

Coeus wrote:Dave, which version were you testing?

This version I think:

Code: Select all

commit 8f7c5d50bb883fa552ffda7661d09ae6764e413e
Author: Steve Fosdick <steve@fosdick.me.uk>
Date:   Fri Mar 17 21:35:16 2017 +0000

    debugging: fix debugger deadlock on windows

Coeus wrote:The issue of the Y direction not working is one I came across, hence the latest commit to master. If you look at https://github.com/stardot/b-em/blob/a7 ... rc/mouse.c, for some strange reason the tests for the two directions are different. Fixing that so that they are both like the X direction seems to have resolved that for me, hence https://github.com/stardot/b-em/blob/3c ... rc/mouse.c

I don't understand the point of the

Code: Select all

if (mx) {

and

Code: Select all

if (my) {

tests.

Also, I assume that mouse_x and mouse_y are maintained by allegro.
Coeus wrote:What I don't understand is why AMX mouse being selected should make any difference. Looking at that code the mouse emulation for curtube == 3 should take priority over AMX mouse.

I concur, but I've just re-checked and it does make a difference. The broken Y behaviour is only present when AMX Mouse is ticked.
Coeus wrote:Back to the question I started this thread with, what seems to be happening when I try this on Windows is when the mouse is captured, the get_mouse_mickeys call starts returning the mouse position within the window rather than how far the mouse has moved. What I am not sure about is whether that is a feature of my setup or something that happens generally. I am testing with Windows running inside VirtualBox and to avoid the whole mouse capture issue VirtualBox is telling windows I have a graphics tablet rather than a mouse. That means VirtualBox can tell Windows the position of the pointer within the VirtualBox window, i.e. the position on the Windows desktop, rather than how far it has moved and it is possible Allegro may be just picking this up because it doesn't understand the difference between a tablet and a mouse.

The only issue I'm seeing in Windows (when AMX Mouse is deselected) is sometimes the windows mouse cursor and gem mouse cursor are both enabled, and are in different places on the screen.

Dave

User avatar
hoglet
Posts: 6486
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em, GEM, Windows and Mouse

Postby hoglet » Tue Mar 28, 2017 9:11 am

OK, I do now understand the point of the if (mx) and if (my) tests! Just being dim this morning.

User avatar
hoglet
Posts: 6486
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em, GEM, Windows and Mouse

Postby hoglet » Tue Mar 28, 2017 9:23 am

Sorry Steve, I've played a bit more, and I now don't think the AMX Mouse option makes any difference.

Sometimes when the mouse is not captured it does seem the Y direction stops working. I guess that's the bug you have fixed.

Let me update to the latest code.

Dave

User avatar
hoglet
Posts: 6486
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em, GEM, Windows and Mouse

Postby hoglet » Tue Mar 28, 2017 9:49 am

I've rebuilt using the current master, and that seems to work fine.

Back to your original question, there are no issues with the mouse stopping moving when captured (by clicking in the window).

FYI, I get a build error on Windows on the sf/debugging branch:

Code: Select all

gcc.exe -O3 -Wall -DBEM -DVERSION=\"Win32\" -DINCLUDE_DEBUGGER -DUSE_MEMORY_POINTER -c x86.c
x86.c: In function 'x86_dbg_disassemble':
x86.c:190:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t' [-Wformat]
x86.c:196:4: error: 'for' loop initial declarations are only allowed in C99 mode
x86.c:196:4: note: use option -std=c99 or -std=gnu99 to compile your code
make: *** [x86.o] Error 1

Dave

Coeus
Posts: 418
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em, GEM, Windows and Mouse

Postby Coeus » Tue Mar 28, 2017 10:35 am

Dave, thanks for that. I think in my case this must be down to VirtualBox emulating a tablet.

On the debug message warning that's probably a 64bit/32bit thing. I'll either fix that or remove it.

User avatar
fordp
Posts: 890
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em, GEM, Windows and Mouse

Postby fordp » Tue Mar 28, 2017 11:57 am

hoglet wrote:I've rebuilt using the current master, and that seems to work fine.

Back to your original question, there are no issues with the mouse stopping moving when captured (by clicking in the window).

FYI, I get a build error on Windows on the sf/debugging branch:

Code: Select all

gcc.exe -O3 -Wall -DBEM -DVERSION=\"Win32\" -DINCLUDE_DEBUGGER -DUSE_MEMORY_POINTER -c x86.c
x86.c: In function 'x86_dbg_disassemble':
x86.c:190:4: warning: format '%ld' expects argument of type 'long int', but argument 4 has type 'size_t' [-Wformat]
x86.c:196:4: error: 'for' loop initial declarations are only allowed in C99 mode
x86.c:196:4: note: use option -std=c99 or -std=gnu99 to compile your code
make: *** [x86.o] Error 1

Dave


This will be the pattern:

for (int Count = 0; Count < Max; Count++)

This is not supported in older compilers. The compiler says it needs to be in c99 mode to compile that code, so the gcc parameters need to be updated.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Coeus
Posts: 418
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em, GEM, Windows and Mouse

Postby Coeus » Tue Mar 28, 2017 2:55 pm

fordp wrote:This will be the pattern:

for (int Count = 0; Count < Max; Count++)

This is not supported in older compilers. The compiler says it needs to be in c99 mode to compile that code, so the gcc parameters need to be updated


Thanks Simon - I had not noticed that. Interestingly it seems to be accepted by my gcc on Linux but that's a newer version - I guess they have changed the default compliance level. Another one to fix.


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 3 guests