Talk:PS2Mouse - Revision history

Bryce: Blanked the page

2010-06-02T14:03:49Z

Blanked the page

Show changes

Bryce at 08:00, 19 April 2010

2010-04-19T08:00:31Z

Bryce at 07:59, 19 April 2010

2010-04-19T07:59:16Z

Bryce at 07:39, 19 April 2010

2010-04-19T07:39:18Z

Nocash at 00:01, 19 April 2010

2010-04-19T00:01:58Z

Bryce at 20:22, 18 April 2010

2010-04-18T20:22:21Z

Bryce at 20:18, 18 April 2010

2010-04-18T20:18:50Z

Nocash at 19:11, 18 April 2010

2010-04-18T19:11:41Z

Bryce at 12:55, 18 April 2010

2010-04-18T12:55:41Z

Nocash at 16:14, 12 April 2010

2010-04-12T16:14:49Z

← Older revision		Revision as of 08:00, 19 April 2010
Line 160:		Line 160:
	Rather than adding a correction, it's probably more accurate to just say that the mouse replies when the sofrtware asks. As you know, when you control the AMX mouse in Basic the pulses are every 1/50s, so it's variable depending on the software, just as the real AMX mouse was.		Rather than adding a correction, it's probably more accurate to just say that the mouse replies when the sofrtware asks. As you know, when you control the AMX mouse in Basic the pulses are every 1/50s, so it's variable depending on the software, just as the real AMX mouse was.

−	:> Ok, I removed the 1/300s bit from the Table, as the page only describes the hardware and not the software, this is probably the most accurate. The mouse sampling rates should be mentioned on the Art package / OS pages that support mouse input.	+	Ok, I removed the 1/300s bit from the Table, as the page only describes the hardware and not the software, this is probably the most accurate. The mouse sampling rates should be mentioned on the Art package / OS pages that support mouse input.

← Older revision		Revision as of 07:59, 19 April 2010
Line 159:		Line 159:

	Rather than adding a correction, it's probably more accurate to just say that the mouse replies when the sofrtware asks. As you know, when you control the AMX mouse in Basic the pulses are every 1/50s, so it's variable depending on the software, just as the real AMX mouse was.		Rather than adding a correction, it's probably more accurate to just say that the mouse replies when the sofrtware asks. As you know, when you control the AMX mouse in Basic the pulses are every 1/50s, so it's variable depending on the software, just as the real AMX mouse was.
		+
		+	:> Ok, I removed the 1/300s bit from the Table, as the page only describes the hardware and not the software, this is probably the most accurate. The mouse sampling rates should be mentioned on the Art package / OS pages that support mouse input.

← Older revision		Revision as of 07:39, 19 April 2010
Line 155:		Line 155:
	:> that bit on the Wiki Page about 1/300s was added by you not me ;)		:> that bit on the Wiki Page about 1/300s was added by you not me ;)
	: Yes, that's why I was trying to correct that part :-) but you removed the correction :-( okay, the correction saying "not ideal" may have sounded negative - there was no bad intention, and don't think the real AMX mouse hardware is closer to the optimal software timings. --[[User:Nocash\|Nocash]] 00:01, 19 April 2010 (UTC)		: Yes, that's why I was trying to correct that part :-) but you removed the correction :-( okay, the correction saying "not ideal" may have sounded negative - there was no bad intention, and don't think the real AMX mouse hardware is closer to the optimal software timings. --[[User:Nocash\|Nocash]] 00:01, 19 April 2010 (UTC)
		+
		+	Oh, ok, no that won't happen either, the OE pin is pulled high fast enough so that this doesn't happen, as I said before, although the COM pin is an open collector, it rises fast enough so that this isn't an issue.
		+
		+	Rather than adding a correction, it's probably more accurate to just say that the mouse replies when the sofrtware asks. As you know, when you control the AMX mouse in Basic the pulses are every 1/50s, so it's variable depending on the software, just as the real AMX mouse was.

← Older revision		Revision as of 00:01, 19 April 2010
Line 149:		Line 149:

	Oh, and by the way, that bit on the Wiki Page about 1/300s was added by you not me ;) I never claimed that the hardware had a particular a clock rate, I just said it answers to the CPCs requests ;) You may of course edit the page if you wish.		Oh, and by the way, that bit on the Wiki Page about 1/300s was added by you not me ;) I never claimed that the hardware had a particular a clock rate, I just said it answers to the CPCs requests ;) You may of course edit the page if you wish.
		+
		+	:> then the cursor moved 199 pixels, instead of 200 pixels
		+	:Uh, that wasn't exactly (not at all) what I meant. The worst-case (without pullup) thing I described would result in receiving data on the mouse wheel input, even when the wheel isn't moved at all.
		+
		+	:> that bit on the Wiki Page about 1/300s was added by you not me ;)
		+	: Yes, that's why I was trying to correct that part :-) but you removed the correction :-( okay, the correction saying "not ideal" may have sounded negative - there was no bad intention, and don't think the real AMX mouse hardware is closer to the optimal software timings. --[[User:Nocash\|Nocash]] 00:01, 19 April 2010 (UTC)

← Older revision		Revision as of 20:22, 18 April 2010
Line 147:		Line 147:

	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.		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.
		+
		+	Oh, and by the way, that bit on the Wiki Page about 1/300s was added by you not me ;) I never claimed that the hardware had a particular a clock rate, I just said it answers to the CPCs requests ;) You may of course edit the page if you wish.

← Older revision		Revision as of 20:18, 18 April 2010
Line 145:		Line 145:
	: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.		: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)		: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.

← Older revision		Revision as of 19:11, 18 April 2010
Line 139:		Line 139:

	Bryce.		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)

← Older revision		Revision as of 12:55, 18 April 2010
Line 133:		Line 133:
	::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)		::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.		::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.

@@ Line 130: / Line 130: @@
 ::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, and not anything more distant inside of the CPC).
+::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.