Atari-ST mouse adapter - Revision history

TFM: /* Timings */

2015-10-20T18:59:02Z

Timings

← Older revision		Revision as of 18:59, 20 October 2015
Line 27:		Line 27:
	== Timings ==		== Timings ==

	The Atari/Amiga mice do output low-level signals, directly coming from the motion sensors. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse is moved too fast.		The Atari/Amiga mice do output low-level signals, directly coming from the motion sensors. Ideally, software should check the signals ''more than 500 times per second''. FutureOS does that, but not the firmware. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse is moved too fast.

	Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.		Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.

TFM: /* Schematic */

2011-11-14T19:10:08Z

Schematic

← Older revision		Revision as of 19:10, 14 November 2011
Line 5:		Line 5:
	[[File:Atari-ST mouse adapter.gif]]		[[File:Atari-ST mouse adapter.gif]]

	The schematic was released in ~~german~~ magazine "Schneider Magazin, 07/1988", apparently using 5 diodes and a 4.5V battery.		The schematic was released in German magazine "Schneider Magazin, 07/1988", apparently using 5 diodes and a 4.5V battery.

	Aside from Atari-ST mice, the circuit should also work for Amiga mice, which are basically the same, but with XB/YA/YB connected to other pins, which could be resolved at software side (or at hardware side).		Aside from Atari-ST mice, the circuit should also work for Amiga mice, which are basically the same, but with XB/YA/YB connected to other pins, which could be resolved at software side (or at hardware side).

Polluks: /* Schematic */ see below

2011-10-26T11:29:02Z

Schematic: see below

← Older revision		Revision as of 11:29, 26 October 2011
Line 7:		Line 7:
	The schematic was released in german magazine "Schneider Magazin, 07/1988", apparently using 5 diodes and a 4.5V battery.		The schematic was released in german magazine "Schneider Magazin, 07/1988", apparently using 5 diodes and a 4.5V battery.

	Aside from Atari-ST mice, the circuit should also work for Amiga mice, which are basically the same, but with ~~XA/~~XB/YA/YB connected to other pins, which could be resolved at software side (or at hardware side).		Aside from Atari-ST mice, the circuit should also work for Amiga mice, which are basically the same, but with XB/YA/YB connected to other pins, which could be resolved at software side (or at hardware side).

	CPC Joy Port Atari-ST Mouse Amiga Mouse		CPC Joy Port Atari-ST Mouse Amiga Mouse

TFM: /* Software supporting the ST-Mouse */ expanded & sorted

2011-04-05T00:52:46Z

Software supporting the ST-Mouse: expanded & sorted

← Older revision		Revision as of 00:52, 5 April 2011
Line 49:		Line 49:
	* [[G-Paint]] 2.0 (Günter Radestock)		* [[G-Paint]] 2.0 (Günter Radestock)

	[[Category:~~Input Device~~]] [[Category:~~Peripherals~~]] [[Category:~~DIY~~]]		[[Category:DIY]] [[Category:FutureOS]] [[Category:Input Device]] [[Category:Peripherals]]

TFM: /* Software supporting the ST-Mouse */ alphabetically sorted

2011-04-05T00:51:42Z

Software supporting the ST-Mouse: alphabetically sorted

← Older revision		Revision as of 00:51, 5 April 2011
Line 46:		Line 46:
	== Software supporting the ST-Mouse ==		== Software supporting the ST-Mouse ==

			* [[FutureOS]]
	* [[G-Paint]] 2.0 (Günter Radestock)		* [[G-Paint]] 2.0 (Günter Radestock)
	* [[FutureOS]]

	[[Category:Input Device]] [[Category:Peripherals]] [[Category:DIY]]		[[Category:Input Device]] [[Category:Peripherals]] [[Category:DIY]]

MacDeath at 17:10, 19 December 2010

2010-12-19T17:10:24Z

← Older revision		Revision as of 17:10, 19 December 2010
Line 49:		Line 49:
	* [[FutureOS]]		* [[FutureOS]]

	[[Category:Input ~~device~~]] [[Category:Peripherals]] [[Category:DIY]]		[[Category:Input Device]] [[Category:Peripherals]] [[Category:DIY]]

MacDeath at 17:05, 19 December 2010

2010-12-19T17:05:03Z

← Older revision		Revision as of 17:05, 19 December 2010
Line 49:		Line 49:
	* [[FutureOS]]		* [[FutureOS]]

	[[Category:~~Hardware~~]] [[Category:Peripherals]] [[Category:DIY]]		[[Category:Input device]] [[Category:Peripherals]] [[Category:DIY]]

TFM: /* Timings */ Error corrected

2010-11-01T14:33:52Z

Timings: Error corrected

← Older revision		Revision as of 14:33, 1 November 2010
Line 27:		Line 27:
	== Timings ==		== Timings ==

	The Atari/Amiga mice do output low-level signals, directly coming from the motion sensors. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse if moved too fast.		The Atari/Amiga mice do output low-level signals, directly coming from the motion sensors. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse is moved too fast.

	Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.		Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.

TFM: /* CPC Plus Compatibility */ Errors corrected

2010-11-01T14:31:09Z

CPC Plus Compatibility: Errors corrected

← Older revision		Revision as of 14:31, 1 November 2010
Line 23:		Line 23:
	=== CPC Plus Compatibility ===		=== CPC Plus Compatibility ===

	The circuit reportedly doesn't work on CPC Plus computers~~. Probably simply because of the missing Fire3 signal on the joystick port of the CPC Plus (this could be fixed easily, by connecting the missing pin inside of the computer)~~. There are ~~also~~ additional diodes in the CPC Plus, which ~~may drop the voltages a little, but probably~~ do ~~not~~ cause problems in this case.		The circuit reportedly doesn't work on CPC Plus computers. There are additional diodes in the CPC Plus which do cause problems in this case.

	== Timings ==		== Timings ==

Nocash: /* Timings */

2010-04-04T13:16:55Z

Timings

← Older revision		Revision as of 13:16, 4 April 2010
Line 27:		Line 27:
	== Timings ==		== Timings ==

	The Atari/Amiga mice do output low-level signals. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse if moved too fast.		The Atari/Amiga mice do output low-level signals, directly coming from the motion sensors. Ideally, software should check the signals ''more than 500 times per second''. Using the CPCs 300Hz interrupt to check the signals might be a bit slow; it would work, but may miss some signals when the mouse if moved too fast.

	Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.		Reading the mouse more often than 300 times per second would be better, but it'd require more CPU load since it can't be done via interrupts. Possibly best solution would be combination of IRQ and non-IRQ handling: Always check the mouse on 300Hz interrupts, and - if the program isn't busy with other tasks - additionally check it via polling.