Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums

Forums > C64 Coding > Mouse Issues
2005-01-04 11:51

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?

... 15 posts hidden. Click here to view all posts....
2006-11-30 12:59

Registered: Jun 2002
Posts: 1931
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!
2006-11-30 13:51

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.
2006-12-01 10:27

Registered: Jun 2002
Posts: 1931
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...
2006-12-01 10:59

Registered: Jun 2002
Posts: 1931
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/
2006-12-01 11:50

Registered: Jun 2004
Posts: 496
why would it be different in the first place then?
2006-12-01 12:00

Registered: Jun 2002
Posts: 1931
@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.

2022-11-23 13:46

Registered: Dec 2002
Posts: 5
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.
2022-11-23 18:57

Registered: Apr 2003
Posts: 2329
Sounds indeed like an Amiga mouse.
Try this to confirm: Mousetest V2
2022-11-24 19:09

Registered: Dec 2002
Posts: 5
Thanks for the tip! Practically all sprites were moving, but yes, it seems I have an Amiga mouse...
2022-11-24 19:24

Registered: Dec 2001
Posts: 10487
They will all move eventually - the sprite that moves correctly tells you what you have :)
Previous - 1 | 2 | 3 - Next
RefreshSubscribe 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
Users Online
Da Snake
Guests online: 81
Top Demos
1 Edge of Disgrace  (9.6)
2 Coma Light 13  (9.6)
3 Uncensored  (9.6)
4 Bromance  (9.6)
5 Still Rising  (9.5)
6 E2IRA  (9.5)
7 Unboxed  (9.5)
8 Comaland 100%  (9.5)
9 Memento Mori  (9.5)
10 The Shores of Reflec..  (9.5)
Top onefile Demos
1 Copper Booze  (9.6)
2 Hellofiends  (9.6)
3 Raising Snakes  (9.6)
4 Barry Boomer - Trapp..  (9.5)
5 Dawnfall V1.1  (9.5)
6 Daah, Those Acid Pil..  (9.5)
7 Tribute to Ben - Las..  (9.5)
8 Pandemoniac Part 1 o..  (9.5)
9 To Norah  (9.5)
10 Lovecats  (9.4)
Top Groups
1 Booze Design  (9.4)
2 Censor Design  (9.3)
3 Maniacs of Noise  (9.3)
4 Crest  (9.3)
5 Performers  (9.2)
Top Crackers
1 Mr. Z  (9.9)
2 Antitrack  (9.8)
3 Mr Zero Page  (9.8)
4 Faayd  (9.8)
5 Erhan  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2022
Page generated in: 0.056 sec.