| |
DjS
Registered: Jul 2003
Posts: 47 |
Mouse Issues
Hi All!
I've got a question about some mouse issues I'm having. In my latest project I have integrated mouse control, I tested my code in Vice and all worked fine. Some days ago I wanted to test the same code in CCS V3.0 and noticed that the mouse acted different then it did in Vice. After doing some checks I noticed that both Vice aswell as CCS use 7 bits in the $d419 and $d41a registers, only Vice uses bits 1 to 7 and CCS uses bit 2 to 8 which explaned the difference in behaviour.
I thought that the real C64 used all 8 bits instead of the 7 that the emu's use so I wanted to check that. Since I've got no real C1351 mouse but thought I rememberd atari mouses work on Commodore aswell I tested it on my SX.
Result; Pluging the mouse in causes the keyboard to Jam. I unplugged the mouse and tried it in the other port which was just as bad as the first.
In port I the mouse did give some output when moved around, about the same as a joystick does when plugged in the same port.
I unplugged the mouse again and wrote some lines to print out the $d419 and $d41a registers, started the loop, plugged mouse back in and nothing...
Is it the Atari mouse? or am I doing something wrong? I want my program to be as compatible as possible but if I get 3 different read-outs on the real thing and 2 emu's I think I have a problem Houston.. ;)
Can anyone help me with this?
|
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
atari and amiga mice work entirely different than the commodore 1351 mouse. |
| |
DjS
Registered: Jul 2003
Posts: 47 |
Ok, good to know... This means I would have to get a 1351 mouse somewhere to test this... |
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
The original manual tells me that bits 1 to 6 are used (they are counted from 0 to 7).
Have a look at
http://www.esw-heim.tu-clausthal.de/~marco/smorbrod/DuoDriver/ |
| |
DjS
Registered: Jul 2003
Posts: 47 |
6 Bits only on a real 64? Like #%01111110 ?
I'm really confused now because the ref guide says
D419 54297 Analog/Digital Converter: Game Paddle 1 (0-255)
D41A 54298 Analog/Digital Converter: Game Paddle 2 (0-255)
I don't need the mouse driver itself, I got a relative value driver up and running. What I wanted to do is control a 4 bit value whith the mouse when mouse button is pressed.
Easiest seemed something like
lda $d419
lsr
lsr
lsr
sta valuebyte
Which works fine in Vice but not in CCS since in CCS all bits are shifted left one step compared to Vice and thus CCS would need an extra lsr.
Another smaller issue is that because of this in CCS the mousepointer moves 2 pixels at the time
|
| |
Zagon
Registered: Apr 2002
Posts: 14 |
In a real c64 with a 1351-mouse the least significant bit
is not stable so you'll have to shift that away if you don't want a shaking pointer.
Doing this will also have the side-effect of removing the differences between the emulated behaviour of Vice and CCS I think.
Note that just right-shifting a signed two-component value causes rounding downwards, not towards zero. This will make the pointer drift upwards/left if you move the mouse around.
One way of compensating for this is by increasing the value by one if it is positive before shifting. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
my 1351 seems to output values between $44 and $C1. remember it is analogue so it may be different for different mice.
mouse button can be polled at $DC01. bit 0 is right mouse button, bit 4 is left mouse button. |
| |
DjS
Registered: Jul 2003
Posts: 47 |
Thanks for that info! I think I'll have to start over with a new approach.. Think the 4 bit value I want to control has to be made relative aswell I guess...
|
| |
wulong
Account closed
Registered: Jan 2004
Posts: 1 |
Hi "The Git"
If you like to code a mouse driver for the 1351 and compatibles, you have to take in count the complete range of 8bit ($d419, $d41a). Only Bit0 contains no information because of noise. This bit can be masked out or you do a logical right-shift. The absolute range of the analog values is totaly different for different mouse models. But the ABSOLUTE range is not the point of interest. The RELATIVE change of the values is the only important thing.
|
| |
DjS
Registered: Jul 2003
Posts: 47 |
Thanks for your reply :)
I know how to solve this problem now and I know Vice gives out wrong data (Only bit 0 to 6(lsr by itself)) and CCS masks bit0 by itself...
Now the next problem arises; how to make the mouse work the same on both emu's?
|
| |
Hoogo
Registered: Jun 2002
Posts: 102 |
I think you might enjoy a look at McBacons DouDriver :-) Not for using it to move a Sprite around the screen, but for the way he calculates the movement of the mouse. |
| |
Krill
Registered: Apr 2002
Posts: 2825 |
Quote: Thanks for your reply :)
I know how to solve this problem now and I know Vice gives out wrong data (Only bit 0 to 6(lsr by itself)) and CCS masks bit0 by itself...
Now the next problem arises; how to make the mouse work the same on both emu's?
i coded several emulator check routines (you might want to check the emufuxx0r thread in here), and some of them failed only on ccs or only on vice, so this might be an option. but still, this is a vice BUG, so better tell the team or so. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
i dont think its a bug. actually the range is the same as the real 1351: ~128. my mouse has ~$40 to ~$C0 but ~$00 to ~$80 is also valid. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
In VICE the pot registers wrap several times before they stop, I guess they continue wrap as long as there are space left to move the invisible mousepointer on the real PC screen.
Question: Does the POTs wrap on a real C64, or are the values always bounded within 00-FF (different ranges for different mouses as mentioned earlier)? In orhter words actually, is the 1351 mouse a relative or absolute device on the real thing?
|
| |
Mace
Registered: May 2002
Posts: 1799 |
The pots can't wrap, as they contain the resistance-value between two pins on the joyports. |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
It's not that clear when they wrap on a real C64. The voltage range differs from mouse to mouse, so you have to deal with multiple ranges anyway. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Yep, ok. Problem is actually with VICE. VICE on linux stop wrapping the POTs when the invisible PC-mouse pointer hits the PC-screen edge. So, worst case this edge is hit when the C64 pointer still hasn't reach the C64 screen-edge. DANG!
|
| |
Mace
Registered: May 2002
Posts: 1799 |
In the SNES emu they solved this in another way, IIRC.
The mousepointer in the emu only moves when the real pointer is withing the bounderies of the emu window.
So actually, the PC pointer becomes the emu pointer. |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Ok.. after some digging in VICE. It seems that the 1351 mouse emulation is correct in windows, it uses POT values between 00-7F, but bit0 is always 0. It also never stops wrap, I.e. it's truly relative.
On linux however (non gnome gui) it really an ugly hack. It's so borked it actually depends on if double size pixels are enabled or not. What it does is simply hide PC mouse pointer and constrain it to the VICE window. So, if you have non doubled pixels you only get the half amount of wraps etc. I plan to modify the VICE mouse driver for linux to use truly relative mouse values. A simple but ugly way to acheive this is to use XWarpPointer() to move the pointer to the center of the VICE screen every time the mouse moves, thus you get unconstrained relative motion, which is all we want... |
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
Ok... just fixed correct relative mouse motion for the X11 version of VICE 1.20. PM me if you want a patch.
Now it behaves exactly like the windows version. \o/ |
| |
Style
Registered: Jun 2004
Posts: 498 |
why would it be different in the first place then?
|
| |
JackAsser
Registered: Jun 2002
Posts: 1987 |
@Style: Because the linux mouse driver simply calls XGrabPointer which gives you exclusive rights to the pointer, problem is the pointer is confined withing the window who grabbed it, so, when the invisible PC mouse reaches the window boundaries the POT values reported to the C64 stops, in other words, it's not truly relative. But more like absolute coordinated with some kind of relative fake on top of it which stops when the pointer hits the boundaries.
What I simply fixed was that when you receive a mouse event I warp back the pointer to the center of the window, hence you never reach the boundaries. Then I modified to that it reports delta movements instead of absolute movements.
On the windows version however they grab the mouse using directinput which will give you true relative coordinates directly from the mouse device.
|
| |
Black
Registered: Dec 2002
Posts: 12 |
Hello All,
sorry for necroing the thread.
First time I'm trying to use a mouse with 64 but no luck. It is a two-button Commodore mouse with A1600... serial number on the bottom but no model number.
When its plugged to port#1, keyboard doesn't respond at all.
Mouse shows some activity on DC00/DC01, but doesn't work in GEOS/FC3/1351 testdisk.
Is it for Amiga, or am I doing wrong something?
Thanks in advance. |
| |
bugjam
Registered: Apr 2003
Posts: 2476 |
Sounds indeed like an Amiga mouse.
Try this to confirm: Mousetest V2 |
| |
Black
Registered: Dec 2002
Posts: 12 |
Thanks for the tip! Practically all sprites were moving, but yes, it seems I have an Amiga mouse... |
| |
chatGPZ
Registered: Dec 2001
Posts: 11100 |
They will all move eventually - the sprite that moves correctly tells you what you have :) |
