| |
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? |
|
| |
AlexC
Registered: Jan 2008 Posts: 299 |
Seems like the emulator bug. Don't remember right now - have to check it - but I think VICE got it right. Maybe there was a thirdparty hardware that acted differently? |
| |
TWW
Registered: Jul 2009 Posts: 545 |
They both Emmulate the: C1351 Mouse and VICE has it right.
But still...
WTF??? |
| |
Krill
Registered: Apr 2002 Posts: 2980 |
What's so WTF about a mere emulator bug concerning a rarely-used feature? |
| |
TWW
Registered: Jul 2009 Posts: 545 |
It ain't so rarely used and it ain't half as used as it should be!
A lot of SW could benefit gratly from this now when more and more users uses emmulators instead of real HW due to availability.
However if it only works in some places it will remain unused.... |
| |
null Account closed
Registered: Jun 2006 Posts: 645 |
Do people actually still use CCS64? I thought most people ditched it in favour of Vice/Hoxs by now.
------------------------------------
http://zomgwtfbbq.info |
| |
Mr. SID
Registered: Jan 2003 Posts: 424 |
So CCS64 is close to being outdated? ;)
Seriously, some people are still using Frodo. What gives? |
| |
AlexC
Registered: Jan 2008 Posts: 299 |
If you use GEOS mouse emulation isn't something you can't benefit from. Other than that I seem to remember some gfx tools using mouse but can't find their names right now (wasn't Art Studio one of them?). Anyway this is a feature some users use often. |
| |
TWW
Registered: Jul 2009 Posts: 545 |
Actually the last version of CCS64 is V3.8 and is dated 8'th of march 2010.
So I don't think it's terribly outdated... |
| |
enthusi
Registered: May 2004 Posts: 677 |
ManiacMansion Gold \o/ *ehem....* supports mouse and it was hell to implement since the vice 'back then' had very bad mouse support. I think its still quite different from a real 1351...
Though I hear things change... |
| |
TWW
Registered: Jul 2009 Posts: 545 |
I have tested the standard c1351 emulation on both VICE and CCS64 using the standard Commodore Mouse Driver and it works like a charm on both with the exception of the fucked up ASL of the bits on CCS64.
I have also tested an enhanced version of the driver containing self calibration (but still based on the C= driver) and it also rocks. |
| |
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 ;)
|
| |
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.
|
| |
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
|
| |
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?
|
| |
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 :) |
| |
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.
|
| |
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 :) |
| |
andym00
Registered: Jun 2009 Posts: 45 |
Quoting TWWI 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 ? |
| |
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.
|
| |
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..
|
| |
vedos Account closed
Registered: Jul 2003 Posts: 33 |
Is there a test program for Neos Cheese Mouse? it seems easier to find at fleamarkets than C1351. Also does any games support it (eg. Maniac Mansion Gold)?
Edit: Here's list of some supported games -> "The neos mouse is also supported in these programs: Arkanoid , Arkanoid II - Revenge of Doh, Operation Wolf(these is the ones i know of so far)" |
| |
andym00
Registered: Jun 2009 Posts: 45 |
Soci: It's working now.. No idea why, or how, except I experimented with NEOS mouse mode out of curiousity, then I changed the settings back to 1351 and now 1351 emulation is working as it should be.. I know that sounds highly implausible.. But I also have rebooted the machine in the mean time, so not entirely sure which of these events made any actual change to this weirdness..
It's also now strangely working in the 2.3 build I had, the 2.3.17 build and your 2.3.18..
I appreciate the effort you put in, and sorry that it appears to have been some wild goose chase!! Unless it really is related to selecting the NEOS option at some point..
Anyway that said, your version you uploaded is quite a lot nicer in the speed of the mouse than the previous versions :)
Right, full steam ahead then :)
|