|
|
| (27 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | 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. --[[User:Nocash|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.
| |
