|
|
| (21 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.
| |
| − |
| |
| − | :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. --[[User:Nocash|Nocash]] 19:05, 8 April 2010 (UTC)
| |
| − |
| |
| − | -
| |
| − |
| |
| − | Ok, to explain it differently, if the output should be low, the PIC sets the correct bit low and sends it to the 74LS240 (ie: the buffer), the 74LS240 will only set the outputs to the CPC when the Com pin coming from the CPC goes low which triggers the output enables of the buffer. So the pin that should be low for exactly 1/300s will be only for 1/300s because that's how long the Com pin went low for. Can that be more exact?
| |
| − |
| |
| − | Bryce
| |
| − |
| |
| − | :You got me confused, I just woke up and had my first coffee, and then this! No, the buffer isn't a latch - it doesn't memorize anything. And the Com pin has no effect at all on the timings.
| |
| − | :The Com pin could theoretically indicate when the software reads the port, but that'd require that software deselects the joystick line after each read, which you can't trust on.
| |
| − | :More commonly Com changes at 1/50s rate (when reading the keyboard; which is read only each 6th interrupt). If the software reads only the joystick port, without keyboard, then Com would stay LOW forever.
| |
| − | :Oh, just noticed a bug in your circuit :-) the Com pin is an open collector output, so there should be a pull-up in your schematic... unless the 74LS240 is having internal pull-ups on the /OE pins(?)
| |
| − |
| |
| − | Hi Nocash,
| |
| − | hope you enjoyed the coffee. Firstly as you know, the Com pin normally only goes low when the CPC is reading the Joystick or keyboard Y10 (at 1/50s as you stated). Theoretically yes, the z80 could set the 8255 pin (to the 74LS145) and the Com pin would remain low forever, but that's not what it does. Stick an oscilloscope on the Com pin when the Art package is running and you'll see it's not permanently low, so I CAN trust on this, because I didn't assume it, I measured it. So the pin going low IS indicating when the software is reading the port. Besides that, the software also reads the keyboard, so setting this pin low all of the time would mess up the keyboard scanning.
| |
| − |
| |
| − | Correct, the buffer isn't a latch, but it doesn't need to be, the outputs of the 74LS240 are being read by IOA of the AY-8912 which is a latch, the reason for the 74LS240 is to ensure that highs and lows are only present when the Com port goes low.
| |
| − |
| |
| − | Regarding the "bug" in the circuit: Technically correct, an open collector output should usually have a pull-up resistor, but in this case it is not really required, if you reference the 74LS145 Datsheet (one which shows the internal equivalent circuits), you'll see that the outputs are internally strapped to Vcc through a diode with a nominal resistance of 17K, which is enough to keep the circuits' high and low levels happy, and at the relatively low frequencies in this application, using a pull-up resistor to "sharpen the edges" of the signal isn't required. I had a pull-up resistor on my original prototype, but I removed it because it was overkill and the circuit works perfectly well without it.
| |
| − |
| |
| − | Bryce
| |
