Nice project - only one thing is missing: it'd be nice if you'd explain how it works! I mean, what is a AMX mouse, and how does it transfer the data to the CPC?
I've had a look at the original AMX Art software. At first glance, it seems to be joystick compatible... so my first question would be:
Is that all about it? It works like a simple joystick? Or did I miss something important? Like a mouse-detection which switches between special-mouse-protocol-mode and normal-joystick-mode?
If it's really simply using the joystick-style protocol. What I've found out is that it seems to check the joystick port once every 300Hz, and seems to treat joystick up/down/left/right signals as mickeys in the corresponding direction(s). So I guess, on vertical movement, the mouse interface generates a LOW pulse of 1/300s duration (per mickey) on UP or DOWN joystick input.
Oh, and how does the scroll wheel work exactly? The document says it connects to "5" (joy2up) and "6" (joy2down). First of, isn't that vice-versa? 6=up, 5=down?
And, concerning scrolling, the terms "up" and "down" are rather confusing... If you move UP-wards in a document, then text scrolls DOWN-wards on the screen. So "Move DOWN" could have opposite meaning as "Scroll DOWN". I guess "turn wheel away from user" and "towards user" would be much more precise.
Finally, a lisz of the buttons would be nice, like
Joy1Fire2 (X) = which button Joy1Fire1 (Z) = which button Joy1Fire3 (-) = which button (middle?)
Whereas, looking at the documentation (pdf file) for the original AMX mouse, left and right buttons seem to have been arranged/used confusingly. There's a strange drawing that looks as if the Right Button is used as Execute Button... ie. much like PC mouse in left-handed mode? Although, the drawing is top-down, so the right button is actually on the left side in the drawing... though I guess that wasn't the way how one should use the mouse, with the buttons & cable pointing towards the user? :-) - Martin
Regarding: * Note: The above "1/300s" timing would be the ideal value (the existing AMX Mouse software reads the joystick port inputs at 300HZ rate). The real AMX Mouse interface, and this DIY project may not exactly match that timings." I've removed this sentence because, if you'd gone to the bother of building the circuit, you'd know that the statement is completely untrue, or what are the facts that you base this claim on? - Bryce
- Why did you removed it? That sentence was important. The only thing that was misleading was saying "MAY not match". As far as I remember, you said the circuit "DOES not match" the 1/300s values - or did you change that?
- Yup, I haven't built the circuit, don't need a mouse for my CPC. Even if I would have built it. How would that prove that the sentence was "completely untrue"? Did you read the sentence before removing it? Again, step-by-step:
- 1) - 1/300s" timing would be the ideal value (the existing AMX Mouse software reads the joystick port inputs at 300HZ rate) - if you have disassembled the software, or trust other people who did so - this sentence is obviously correct, isn't it?
- 2) - The real AMX Mouse interface may not exactly match that timings. - seems correct, too. Judging from the new photos, it doesn't include any precision timers that could generate exact 1/300s pulses, right?
- 3) - this DIY project may not exactly match that timings. - as far as I remember, you confirmed that you do not use 1/300s, so it's correct, too. --Nocash 18:12, 8 April 2010 (UTC)
Yes, parts of it are true but very misleading. Because the Mouse/Interface, Real or DIY isn't controlling the sample rate, the CPC is. So both the real and DIY mouse just ensure that there is always data on the buffer, so that when the CPC asks, there's data there to read. How often the buffer data changes, depends completely on whether and how much the user has moved the mouse (in both the real and DIY mouse). If you don't move the mouse the buffer won't change, so the "change rate" on the mouse side of the buffer would be zero. If you move the mouse fast enough, the buffer could theoretically change on every sample read from the CPC. But both the real and the DIY interfaces can easily supply the data much faster than 1/300s so that in both cases the CPC is the limiting factor.
Bryce.
- What why buffer changes?
- Ah, guess I know what you mean: On hardware, the signal may change after each mickey (unless the mouse is moved so fast that the joystick signal is always LOW).
- Okay, but, the software doesn't check for changes at all. It only checks if the input is LOW, and if so, it moves a step.
- So, looking at the software side, the mouse protocol has nothing to do with changes. It does only rely on LOW levels. The problem is that the duration of the LOW levels isn't clear:
- On software side they should be 1/300s in length. On hardware side they unlikely to match that value. The protocol isn't perfect. You may blame AMX on that, but I think you shouldn't try to hide that facts in the documentation.
- NB you still have this on the page:
Row9.Bit0 Joy1up LOW for 1/300s per mickey, when mouse moved up
Row9.Bit1 Joy1down LOW for 1/300s per mickey, when mouse moved down
Row9.Bit2 Joy1left LOW for 1/300s per mickey, when mouse moved left
Row9.Bit3 Joy1right LOW for 1/300s per mickey, when mouse moved right
- If you hardware does 1/300s then it's all fine. Otherwise... do whatever you want... change the specs from "1/300s" to "a short moment" or something like that. Or put the deleted sentence back in. Maybe add a note that the AMX protocol as such isn't allowing 100.000% perfect timings. Or add some note that says that it feels perfectly satisfying or so. --Nocash 19:05, 8 April 2010 (UTC)