View source for Talk:PS2Mouse

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 (ie: avoid messing up the keyboard scans).

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

@Bryce and Nocash:

Interesting. Well I still plan to read Amx mouse. Maybe do it tonight.. not sure.

I was planning to setup the keyboard hardware for reading the joystick and then doing lots of IN instructions to read the state and fill memory.
Then save the data to disc and look at it on the pc and work out what the interface is doing... I don't know if my code will effectively keep Com low or not.
But maybe I will answer some things???? Who knows. - Arnoldemu

:> when the Art package is running and you'll see it's not permanently low
:Okay, checked. True, it's pulsed at 300Hz. The reason is that the software does completely reconfigure the PPI and PSG (normally it would need to do that only after keyboard scanning). Other software may or may not do it the same way. Anyways - that's irrelevant, the circuit should work fine no matter if Com is pulsed or not.
:> Besides that, the software also reads the keyboard
:Yup, as I said.
:>the AY-8912 which is a latch
:It is a latch? For sure: it isn't! Or do you mean the output direction? Anyways, doesn't matter, too.
:>reference the 74LS145 Datsheet ... diode with ... 17K
:An open-collector output with 17K pull-up diode? What is that? I checked a bunch of datasheets, but couldn't find any mentioning such a bizarre thing. What datasheet was saying that???
:If you measure the Com pin at BASIC prompt: you'll see it's always LOW, with some short +1V edges. If you attach a pull-up, the signal looks inverse: Always HIGH (+5V), with some short 0V edges. As I said, the 74LS240 in your circuit might maybe work as pull-up, the 74LS145 in the CPC doesn't do so.
:>pull-up resistor to "sharpen the edges" of the signal isn't required.
:Makes sense for low frequencies. Though the inputs are read at falling edge, aren't they? Well, okay, you are right, the falling edge should be stable, only the raising one would be improved by pull-ups.
:> the circuit works perfectly well without it.
:Great.
:Just to be a pain... Did you think about worst case scenarios? Like one programmer reading the keyboard immediately after the mouse/joystick input... Maybe then the raising edge could be important :-) --[[User:Nocash|Nocash]] 16:53, 9 April 2010 (UTC)

Hi Nocash, as far as I know, the inputs of the AY-8912 io port are saved in a register? Maybe I'm wrong, but this is what I was referring to as a "Latch".
Also, regarding the Com pulses, if you try the Basic examples given in the AMX handbook, the Com port is then working at it's normal speed, so the mouse reacts differently. That was another reason why it was important that the CPC was controlling sample rate on my interface.

The diode in the 74LS145 isn't specifically there to pull the signal up, it just happens to have that effect.

Yeah, worst case scenarios, I tend to be a fanatical worst case scenario tester, because if it can happen, it will happen. I dropped the voltage on the CPC to 4.5V to simulate heavy hardware load, I added all the commercial interfaces I own to check if anything could cause an incompatibility, I added series resistors to each Joystick port pin, to simulate old/dirty connections, and even did a very basic (but not very scientific) EMC/EMV test to see if I could get the processor to reset from external interference. The interface worked no matter what I threw at it. And that's what really counts.

Also on the other side of the interface, I have tested around 40 different types of mouse up to now, everything from the simplest PS/2 mouse to 12 Button multi-speed gamer mice and even a selection of wireless mice. The only one's that don't work are Bluetooth wireless mice which can't be forced into PS/2 mode, everything else should work perfectly.

@ Arnoldemu: Have you built the interface? Let me know how your tests go.

:> Hi Nocash, as far as I know, the inputs of the AY-8912 io port are saved in a register?
:Reading the AY-8912 just returns the current input value, not an "old" latched values. If it'd be a latch, then it'd require a CLK or /WR pin or so, which it doesn't have.
:> was important that the CPC was controlling sample rate on my interface
:Ahhhhh... could it be possible, that the schematic on the DIY page isn't up to date? It doesn't show that feature, Com (joy.pin8) only connects to the /OE pins, not to the PIC.
:The idea isn't bad though, that way it becomes independed of whether or not software runs at 300Hz. Well, most or all software DOES run at 300Hz so that solution doesn't improve too much. It might fix problems where AMX Art disables IRQs and misses some interrupts.
:Only problem would be if Com isn't pulsed. A (rather rare) situtation where this could happen: If software is plain mouse controlled, and doesn't use sound/keyboard - then PPI/PSG would need to be initialized only once after power-up, and so Com won't pulse after that initialization.
:> The diode in the 74LS145 isn't specifically there to pull the signal up, it just happens to have that effect.
:Strange. Then it isn't OC at all. Do you really get Com=5V; when the mouse interface isn't connected? My CPC outputs only short 1V level, no long 5V levels. And can you upload the datasheet page somewhere? I'd bet two EPROMs that you've misread it... maybe the diode pulls down spikes above +5V or so?
:> I dropped the voltage on the CPC to 4.5V to simulate heavy hardware load...
:Wow, seriously? I never got so far when testing. Maybe that's why I am sometimes running into problems, with circuits that work on one computer, and not on another :-)
:Your tests didn't really cover timing stuff (ie. the situation where you need Com to get HIGH quickly), only voltage loads. --[[User:Nocash|Nocash]] 13:43, 10 April 2010 (UTC)

::PS. You are right, in normal speaking "register" means storing information. But in computer language it very often used as synonym for "I/O ports", which usually do have a storage function, but not always. I've never noticed that saying "register" could be wrong in that cases.
::Anyways, how did we get there? The thing we were talking about was the output (directly from the PIC, not from the 74LS240).
::The cpcwiki page says 1/300s, but in the forum you said 2/300s. Which one is correct? --[[User:Nocash|Nocash]] 16:04, 12 April 2010 (UTC)
::PPS. Added info on the corresponding keyboard keys, okay? I think they are good choice since they don't conflict with hotkeys, which would be more likely mapped to letters, not to 5 and 6.

Hi all, back after some relaxing Snowboarding in the alps :) Regarding the timing: Even if the COM pin stayed low all the time, the output of the 74LS240 would still permanently change if the mouse were moved. So my adapter would still react like the original AMX mouse. No idea what would happen inside the CPC though. The schematic in the Wiki is the latest version and won't be changing, the COM pin is only connected to the 74LS240, not to the PIC, the PIC is getting an almost permanent flow of information from the mouse (can't remember the exact timing, would have to check the firmware), but it was most certainly faster the the 1/300s that the CPC could manage. The only difference between the real AMX mouse and my interface is that the original AMX mouse would have had a fixed rate of pulses per millimetre (of mouse movement), which would obviously effect the "feel" of the mouse. Unfortunately I don't have a real AMX mouse to measure this, so I chose a rate that felt right. The CPC side of the interface (sample rate etc) is identical to what the AMX mouse did, so the CPC side will react just like the original.

Regarding the requirement for a pull-up resistor. If you open a standard JY-1/2 Joystick, you'll see that they also don't have a pull-up resistor, but still work perfectly with the configuration within the CPC Joy Port, my schematic is no different in this effect.

Bryce.

:Yup, the original rate is unknown, so nobody could expect that you use the same rate :-) the [[AMX Mouse]] page includes a notice that the hardware is (likely) not producing exact 1/300s pulses. A similar notice on your page would be fine, at the moment it says 1/300s.
:The COM pin is low anytime when keyboard matrix row9 is selected, ie. anytime when reading from joystick (and possibly at times when not reading, but row9 still being selected). That's perfectly okay.
:The joysticks do have a pull-up (at the input side inside of the CPC) (for joysticks, COM is used only to drag-down that inputs).
:A more realistic worst-case: Say somebody reads mouse direction (COM=LOW), and immediately thereafter the scroll wheel (COM2=LOW). In that case you may have only 10-20 clock cycles, so COM would need to raise relative fast, else the 74LS240 would be still selected when reading the wheel. With pull-up it'd be be plenty of time, but if it gets pulled up "through the air" it could be a problem.
:Anyways, I haven't tried, so maybe there's no problem at all. Until some days ago I didn't even knew that COM and COM2 are open collector outputs, so I guessed many people could be trapped there, expecting stable HIGH levels on that pins. Ciao, --[[User:Nocash|Nocash]] 19:11, 18 April 2010 (UTC)

Hi Nocash, Yes, that exact situation you describe, could cause a misread and in that case the AY could read a 1 instead of a 0 (or vice versa), but only at the start or end of every movement, that means, if you move the mouse across the screen, say, 200pixels, then worst case, it had 2 misreads (misreads "mid-movement" aren't possible because the bit didn't change). Even if it did misread (on the very first or last pulse), then the cursor moved 199 pixels, instead of 200 pixels, is that really a big deal? Is anyone even going to notice? I very much doubt it, and removing this tiny flaw would cost additional hardware, so it's really not worth the bother. And as I've said before, my goal is to create easy projects, that anyone can build and most importantly - don't cost very much.