[CSDb] - User Forums - Mouse driver

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > Mouse driver

2010-05-30 17:23

TWW

Registered: Jul 2009
Posts: 545

Mouse driver

right. I had one of these made a while ago but now i wanted to implement it in my "universal joy/mouse/keyb-routine".

to my great horror I discover that CCS64 and Vice handles mouse emulation differently.

VICE: Bits 1->6 (which I believe it should be)
CCS64: Bits 2->7

WTF?

... 12 posts hidden. Click here to view all posts....

2012-06-13 08:11

andym00

Registered: Jun 2009
Posts: 45

Regarding the mention of changing mouse speeds and stuff, I'm running Windows7 64bit, Vice2.3 I've been through every speed setting and can't get a stable mouse for the life of me..

Is there a solution to the mouse stuff in any of the Vice builds for Windows ?

I've tried TWW's test program here and I get much the same results as my own attempts at trying to read the mouse, ie: it doesn't work very well under Vice..

All I can get from Vice when running 1351 emulation is move the mouse, it sort of works, then everything settles down when I stop, then a few frames later, pop, it'll jump with no mouse input more often than not.. Plus symptoms of wrapping happening as well on sustained movements.. TWW's test program seems to exhibit the same kind of symptoms..

Frustrating me no end as I suddenly found the impetus to add a load of editing stuff to the SuperSaw stuff, and then boom mouse emulation appears rogered..

Is there a solution for this ? And no, Linux isn't an option ;)

2012-06-13 11:47

soci

Registered: Sep 2003
Posts: 480

I've did a mouse emulation update on VICE post 2.3 (around Apr.2012). Actually the Linux version was more broken as far as I could see from the code, I couldn't draw a non-jagged diagonal line unless moving super slow.

As for the TWW test program. It's loosing movement accuracy due to aggressive filtering of slow movements of +/-1. This is clearly visible when the real mouse pointer is not hidden for reference. Sure a +/-1 movement should be ignored because of measurement accuracy, however it does not mean that several +1 movements should be all be ignored in a row just like nothing happened...

Also if I move the mouse fast in a small area this driver is prone to jump around huge distances for some reason (incorrect wraparound handling?). This does not happen with another driver, where the movement is correctly followed even on huge distances when the wrap around is guaranteed.

If your mouse driver jumps around even if the mouse itself is not moved, I would better check if the keyboard scan does not interfere with the port. This is a popular mistake to do when writing 1351 mouse drivers.

If the mouse emulation feels different to a real 1351, it's probably due to the mouse acceleration feature of the OS. Switch it off then it's more close to the real thing.

I think you should try a recent (after Apr.2012) VICE version for testing. Range and bit depth is corrected now, and it supports things like middle mouse button.

2012-06-13 13:27

andym00

Registered: Jun 2009
Posts: 45

I grabbed Win32 version of 2.3.17.. That's changed the behaviour a fair bit :)

The rapid jittering has gone, but there's still this weird once per second movement happening.. Both in my code, and in TWW's test program..

I move the mouse, but once per second (or so) it gets a mind of it's own and moves in the opposite direction (it appears), regardless of the speed, so moving very slow or very fast gives the same result, and regardless of the amount of time I keep it moving.. And the amount it moves back seems proportional to the amount it's just moved..

My mouse stuff, which is basically the Codebase64 code, which is TWW's anyway)
- It has the Kernel keyboard stuff switched off..
- I scan the keyboard myself (I even took my keyboard stuff out to ensure it wasn't that screwing things up)
- I do select which mouse port I want to sample correctly, and leave > 512 cycles between selecting the port and reading the sampled value.. Actually more like 150 raster lines, but I don't think that's an issue..

Here's what I'm running, with all the keyboard reading taken out, if you want to see the weird 'per second' moving back behaviour thing going on, since it's slightly different behaviour to TWW's test program.. And is fixed to 1351 only on Port 2..
sites.google.com/site/andym00/files/mouse_test.prg

2012-06-13 14:36

soci

Registered: Sep 2003
Posts: 480

Actually there's a kind of keyboard scanner in your main loop at $111a which makes the trouble.

Sure you select port B in the first interrupt around line 50, but then in the main loop this routine is switching the mouse port to port A, and it also enables both ports sometime later.

Now comes the second interrupt around 250 where the mouse is either on port B, maybe port A, or more likely on both. No wonder it jumps around.

Why not put this scanning in the first interrupt, set some flags based on the key presses, then select port B at the end and don't fiddle with $dc00 it in the main loop at all?

2012-06-13 15:14

andym00

Registered: Jun 2009
Posts: 45

Bah, I forgot about the specific checks for the function keys and space bar.. Bugger...

The whole ordering for sampling the mouse was just a quick try to get this thing running.. The master plan was to sample several times per frame, say 4 or so..

That said, it's not made any difference to what I see in Vice 2.3.17 at all.. I still get exactly the same behaviour of move the mouse, then it moves back in the opposite direction..

This is the same as before, but with the left over keyboard stuff not being called..
sites.google.com/site/andym00/files/mouse_test2.prg

Simple test I'm doing.. Start Vice up, mouse events not grabbed.. Autostart this.. Grab mouse events..
Immediately the mouse will dive down/right diagonally..
From then on all movements I make, are seemingly replayed, but inverted at 1 second ish intervals.. I move the mouse sharp right (without it overflowing), then 1 second after the move begins, it moves back left..

Okay, now I know I'm not going totally mad..
I've just tested it in the latest build of Micro64 (1.00.2012.06.13 Build 685) the one that came out today (I can't speak for earlier versions), but it works absolutely perfectly in there! Also TWW's mouse test program functions perfectly in there as well..

The only issue with Micro64 is in windowed mode, but in full-screen mode it's perfect.. And that I can't seem to configure which joystick port the 1351 appears on, and apparently the answer is both, simultaneously :)

I'm really confused now :)

2012-06-14 02:51

soci

Registered: Sep 2003
Posts: 480

This version works without jumps for me, and there's no filtering issue like with the TWW driver. Unfortunately I can't test or debug the windows version of VICE. Please open a bug tracker entry with this version attached, maybe someone else could have a look.

The jump on grab is more or less normal. It's like a plug in, the position changes suddenly from 255 to the real one. Same on ungrab, but the opposite way.

2012-06-14 08:41

andym00

Registered: Jun 2009
Posts: 45

Quote: This version works without jumps for me, and there's no filtering issue like with the TWW driver. Unfortunately I can't test or debug the windows version of VICE. Please open a bug tracker entry with this version attached, maybe someone else could have a look.

The jump on grab is more or less normal. It's like a plug in, the position changes suddenly from 255 to the real one. Same on ungrab, but the opposite way.

Okay, so it's only the Windows build that's doing this then.. I'll make a bug report about it..

Thanks for clearing that up anyway :)

But regards the Windows behaviour, a little voice is saying that it feels like it's attempting to move the (hidden) windows cursor to keep it centered in the window, with some delay on it, but inadvertently sending the compensation moves to the 64 mouse.. At least that would explain the behaviour I see, but I somehow doubt it's trying to do it like that, the delay doesn't add up.. Anyway.. We'll see I guess :)

2012-06-14 09:12

andym00

Registered: Jun 2009
Posts: 45

Quoting TWW

I have also tested an enhanced version of the driver containing self calibration (but still based on the C= driver) and it also rocks.

Care to explain what you mean about the self-calibration ?
I mean, what exactly is there that needs calibrating given the simple means of reading the mouse on the 64 ?

2012-06-14 12:52

soci

Registered: Sep 2003
Posts: 480

Magic, after wasting tons of time on trying different ways I could finally cross compile VICE for win32. It's almost 25813, except I've matched the mouse speed with what I normally see on other platforms. Unfortunately the resolution is so low that the LSB will be always 0, but that is normally filtered out anyway.

http://singularcrew.hu/temp/x64_Eisoh5ee.zip

It's the x64.exe only, copy it to your VICE installation with a different name for testing. Actually I don't see any strange behaviour with your test program, and it's exactly how it works for me on Linux too. No jumps and automatic movement at all.

Self calibration is that it measures and uses the actual value range which is not exactly 64-191 on real hardware. It depends on PAL/NTSC clock frequency, mouse type (real 1351 or type of ps2 to 1351 converter), and other hardware tolerances.

2012-06-14 15:36

andym00

Registered: Jun 2009
Posts: 45

lol, you're going to hate me now :)

It does exactly the same thing as it did before.. Everything good, apart from the mirrored playback of the mouse moves, with the same weird delay..

I'm uploading a video of it.. I've been through all the mouse settings here in the windows control panel, and no speed options make any difference, nor do the enhanced precision stuff..

http://www.youtube.com/watch?v=uIVpaQ0o_eg

All I do in the video is..
2. Autostart the .prg
3. Enable grab events
4. Move mouse right.. And wait.. <magic happens>
5. Mouse mouse down.. And wait.. <magic happens>
6. And then move the mouse right in small steps..

You can see after the right move, and also the down move the mouse just heads back to it's start position.. And during the slower long move right it starts to move backwards after the same kind of time delay..

Previous - 1 | 2 | 3 - Next

Refresh

Subscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search for in
All times are CET.

Search CSDb

Advanced

Users Online

St0rmfr0nt/Quantum
JonEgg
Andy/AEG
krissz
daimansion
Martin Piper
Avalanche/Atlantis
algorithm
Thierry
Guests online: 95

Top Demos

1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)

Top onefile Demos

1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 Dawnfall V1.1  (9.5)
7 Rainbow Connection  (9.5)
8 Onscreen 5k  (9.5)
9 Morph  (9.5)
10 Libertongo  (9.5)

Top Groups

1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)

Top Musicians

1 Rob Hubbard  (9.7)
2 Mutetus  (9.7)
3 Jeroen Tel  (9.7)
4 Linus  (9.6)
5 Stinsen  (9.6)

Page generated in: 0.063 sec.