Since the 2.4 version the mouse emulation is broken.
I use the mouse at port 2 (haven't tested port 1).
When you'll move a mouse to the right it's expected that the potx will walk from $40 to $bf and then wrap around.
But since 2.4 the wrap is made in 4 frames which made any mouse code unusable.
I've sampled (per frame) a mouse movement to the right (potx) : $ba, $bc, $be, $9f, $80, $61, $43, $44.
The same applies to poty.
I've tested port 1 with 3 different software and it's ok here on XAW. When it was last changed it was tested on win32 as well. I sampled port 2 with custom code as described above and it's wrapping around ok, even on high speeds.
Which platform is this, OSX, Amiga? Is it possible to have a look on the mouse code in question?
It's on OS X. (and I've checked the win port, that works)
ok, assigning to christian then :)
Mouse Sampling has changed in VICE 2.4.
Unfortunately, the scale values of older VICE releases don't apply anymore.
You can fix this by either resetting all values to factory defaults or you make sure that the "Scale X" and "Scale Y" options in Resource Inspector path "Peripherals/Mouse" are both set to 2.
soci has supposedly fixed it in svn, can you re-test please? :)
did
$ svn co ....
$ ./autogen.sh
$ ./configure --with-cocoa
$ make x64
got
mousedrv.m:105: error: ‘x’ undeclared (first use in this function)
after fixing that ([xy] -> pointer[XY]) it did compile well and the mouse bug is gone.
and a general note about the mouse emulation in x64: I find it a bad idea to "remember" the mouse movement and "deliver" it when asked. a real c64 does not do that. and when I copy the current pot[xy] to the internal buffer then the remaining mouse movement is "absorbed" (on a real c64, not vice)
I just fixed soci's fix. osx and unix mouse sampling should be the same now...
"and a general note about the mouse emulation in x64: I find it a bad idea
to "remember" the mouse movement and "deliver" it when asked. a real c64
does not do that. and when I copy the current pot[xy] to the internal
buffer then the remaining mouse movement is "absorbed" (on a real c64, not
vice)"
See r26592 for a fix for this. Works fine on unix, no idea for the others...