sanny Posted July 20, 2018 Share Posted July 20, 2018 Hi, I've looked at https://www.c64-wiki.com/wiki/Mouse_1351 and as I understand it, the movement information is transferred to the computer with the "paddle" inputs of the joystick port. But it appears that I cannot get any real input from the mouse. I was using a simple BASIC progam for testing (see below). When connecting real paddle controllers I can see changes in the values when I turn the paddle knobs. With the 1351 I'm always getting value "3" for both directions, without change when I move the mouse. What could be wrong here? Mouse works fine on a C64. regards, chris Quote Link to comment Share on other sites More sharing options...
+Stephen Posted July 20, 2018 Share Posted July 20, 2018 Is it possible that the 1351 mouse uses "grey-code" rather than analog values? This would be what the 2600 driving controller (NOT the paddle controller) uses. Quote Link to comment Share on other sites More sharing options...
Rybags Posted July 21, 2018 Share Posted July 21, 2018 (edited) https://www.c64-wiki.com/wiki/Mouse_1351 http://www.commodore.ca/manuals/funet/cbm/manuals/1351-mouse.txt It's got 2 modes, joystick mode is selected if it's powered up with the right button held down. Joystick mode emulates a joystick, not grey code. From what I can gather, 6 bits of positional info are generated on the pots every 512 microseconds and returned as values in bits 1-6. Note that C64 pot value ranges are different to Atari - they use 255 values based on a 500K resistance range where Atari uses 228 values based on a 1000K range, so in fact there'll likely be less than the full 6 bits of precision. The 512 microsecond thing bothers me - you might need to put Pokey into fast Pot Scan mode for it to work. For movement, do comparison of present vs previous reading. From the second linked doc, it appears 50/60 Hz read intervals should be sufficient. Edited July 21, 2018 by Rybags 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted August 8, 2018 Author Share Posted August 8, 2018 Hmm, I'm still just getting "3" even in fast scan mode. Program is like this: Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 8, 2018 Share Posted August 8, 2018 When you write to SSKCTL you also need to write it to the hardware register - it's not regularly copied by the OS, only during certain operations e.g. SIO calls. 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted August 8, 2018 Author Share Posted August 8, 2018 Still doesn't work. I'm wondering why the value I'm reading back is always 3. Regardless of movement of the mouse. Quote Link to comment Share on other sites More sharing options...
Swami Posted August 9, 2018 Share Posted August 9, 2018 Still doesn't work. I'm wondering why the value I'm reading back is always 3. Regardless of movement of the mouse. I'm unclear whether you are in proportional mouse mode or joystick mode, but in joystick mode you are using the four joy pins 1-4 and pin 9 is the right button. In proportional mode, the pots at pin 5 and 9 are used for x and y and there is no right button right button is pin one. See the pinout here: http://www.ntrautanen.fi/computers/hardware/misc/1351_pinout.htm Quote Link to comment Share on other sites More sharing options...
sanny Posted August 9, 2018 Author Share Posted August 9, 2018 I guess I'm in "mouse mode". I didn't press any mouse button during turn-on of the computer. Hmm, I could extend the test program to show joystick buttons to be 100% sure that the mouse isn't in "joystick-mode". Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 9, 2018 Share Posted August 9, 2018 (edited) don't forget that this weird commodore mouse operates in proportional mode... like a cx22 to some degree.... possible re wiring to act like one... didn't this mouse only go so far in either direction when used with geos and then get stuck... can't remember... always used trackball, amiga st mice, or converted bus mouse.... make sure it works in geos on a commodore. this mice fail, in order understand how this one works and some fixes read the following link https://cyborgyn.blogspot.com/2014/12/repairing-commodore-1351-mouse.html and to get the full range out of it read this fun fix https://c65gs.blogspot.com/2017/11/1351-mouse-progress-accuracy-better.html still a pain after all these years between the two you can get an idea whats going on with it.. pulse length and voltages what a pain. Edited August 9, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Swami Posted August 9, 2018 Share Posted August 9, 2018 I guess I'm in "mouse mode". I didn't press any mouse button during turn-on of the computer. Hmm, I could extend the test program to show joystick buttons to be 100% sure that the mouse isn't in "joystick-mode". I don't think the 1351 proportional mouse mode output is compatible with ataris. I think you need a special driver or converter to use a 1351 proportional mouse as a proportional mouse on an Atari. The 1350 joystick mode is directly compatible, though. Atari mice speak through the four joy pins even in proportional mode, while the C64 speaks through pins 5 and 9. Could be the 1351 pot range is shifted out of the atari's range or the arrangement of the pot contacts is different than the Atari paddles. Quote Link to comment Share on other sites More sharing options...
Swami Posted August 9, 2018 Share Posted August 9, 2018 I guess I'm in "mouse mode". I didn't press any mouse button during turn-on of the computer. Hmm, I could extend the test program to show joystick buttons to be 100% sure that the mouse isn't in "joystick-mode". Maybe this is helpful. The last paragraph talk about the pot signals, but it is related to use on a C64 rather than an atari. https://groups.google.com/forum/#!topic/comp.sys.cbm/set0JJgFk9U ...and here is something else that says the 1351 mouse outputs square wave signals to pins 5 and 9. Inside,, the 1351 has optical rotary encoders like the Atari and Amiga mice. I'm not sure if it uses actual pots at all to generate output. http://personalpages.tds.net/~rcarlsen/cbm/repairs/ctrlport.txt Quote Link to comment Share on other sites More sharing options...
_The Doctor__ Posted August 9, 2018 Share Posted August 9, 2018 (edited) since pulse width and measured voltage is at issue, provided the mouse is working, could the supplied output be out of range... might it also be the caps are not charged and reset by our Atari as it would seem the 64 does? Lastly since it has some thing in common with the Amiga mouse perhaps it could be adapted back to that mode of operation with the left right axis flipped..... edit* those links provided by swami are dead on... who knows maybe someone will take it on as a hack Edited August 9, 2018 by _The Doctor__ Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 10, 2018 Share Posted August 10, 2018 The problem/s I see after reading the 1351 doc... The 1351 is generating a variable pulse to suit the SID rate of scanning which equates to 4 scanlines to reach the threshold 2.5 V where Pokey fast mode is 2 scanlines to reach 5. Possibly Pokey cant work with PWM or that being generated is too weak to work in fast mode & too strong for slow mode. Proposal - do loopback testing with a PIA output feeding a POT then test the effects of various PWM rates & cycles. But even then, the current level might be too low to emulate what the 1351 is doing. 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted August 11, 2018 Author Share Posted August 11, 2018 Thanks, Rybags, but I have to admit, I don't understand your post completely. (I'm a software person, not hardware). What does "PWM" stand for? And what exactly do you want me to try out in your "proposal" sentence above? Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 11, 2018 Share Posted August 11, 2018 PWM is pulsewidth modulation which is a technique that generates a fraction of the input voltage depending on the pulsewidth. In this place you'll see it thrown around in digital audio threads sometimes. Generally it's done at a high frequency and the duty cycle controls the resultant voltage. Usually there's a capacitor somewhere after the output stage that filers the wave such that a smooth voltage output is seen at the other end. So, it's an alternate method of generating a variable voltage vs potentiometer (which is usually manually controlled directly e.g. in a paddle or old style radio volume control) or resistor ladder (e.g. being Atari's luma output from GTIA) or DAC chip (which in some cases adds more cost and can take up more room). If I get the time I'll see about writing a quick program to allow testing. One theory of the failure is that the C= mouse is likely working on timing that's fixed on powerup. On the Atari side, maybe doing quick scan mode and varying the timing might reap better results. Quote Link to comment Share on other sites More sharing options...
Irgendwer Posted August 11, 2018 Share Posted August 11, 2018 Possibly Pokey cant work with PWM or that being generated is too weak to work in fast mode & too strong for slow mode. Actually my first try for the CMI08 (http://atariage.com/forums/topic/134949-advance-orders-for-cmi08-ps2-mouse-interface/?do=findComment&comment=1625642) was a much simpler design, trying to work with PWM from the µC only. This worked only in a very limited range (AFAIR about 1/5) and Pokey left most of the range undetected. 1 Quote Link to comment Share on other sites More sharing options...
sanny Posted August 23, 2018 Author Share Posted August 23, 2018 I wrote a test in assembler, and there I'm getting different values. They also seem to change a bit (most of the time just the low nibble of the POT values). Since this appeared strange and the mouse also felt "somehow bad" when moving, I've tried it again on a C128. And, yes, it seems it doesn't work as intended. the mouse cursor on the cc65 mouse test program just moves a little bit in all directions. I guess I need to clean it and will also follow the repair video posted above (thanks Swami). Yep, I had written in my initial post, that it "works fine on C64". That's what I remember and what was the case a few (~4) years ago. For the curious I'm attaching my current test program. But for now it makes no sense to continue until I get it working again on the Commodore. regards, chris c1351-test.s Quote Link to comment Share on other sites More sharing options...
Rybags Posted August 26, 2018 Share Posted August 26, 2018 (edited) Have you pulled the mouse apart to see how it works? Possibly there's some off-the-shelf parts that still have equivalents that can be replaced. Edited August 26, 2018 by Rybags Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.