Mouse: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
m (capital MAY)
(Express the meaning of "MUST" as defined by RFC 2119 using "does not conform" as opposed to the disputed terminology from RFC 2119)
Line 56: Line 56:
   sty $4016
   sty $4016
</pre>
</pre>
Some revisions of the mouse's microcontroller [http://problemkaputt.de/fullsnes.htm#snescontrollersmousetwobuttonmouse reportedly] power up in an unknown state and may return erratic values before the sensitivity is changed for the first time.
Some revisions of the mouse's microcontroller [http://problemkaputt.de/fullsnes.htm#snescontrollersmousetwobuttonmouse reportedly] power up in an unknown state and may return useless values before the sensitivity is changed for the first time.
A mouse detection routine should cycle through the sensitivities anyway to ensure that the connected device is in fact a mouse and not half of a [[Four Score]].
A mouse detection routine should cycle through the sensitivities anyway to ensure that the connected device is in fact a mouse.
Failure to do so is likely to cause things that are not a mouse to be detected as a mouse, such as half of a Four Score if player 3 or 4 is holding Right.


Using more than two mice on an AV Famicom is not recommended for two reasons:
Using more than two mice on an AV Famicom is not recommended for two reasons:
Line 63: Line 64:
* Changing player 1's sensitivity also affects player 3's, and changing player 2's sensitivity also affects player 4's.
* Changing player 1's sensitivity also affects player 3's, and changing player 2's sensitivity also affects player 4's.


A program should not play [[APU DMC|DPCM samples]] and read the mouse at the same time, as sample playback causes occasional double reads on $4016 and $4017, deleting a bit from the stream read back. The re-reading solution that can be used for the [[standard controller]] fails here, because each latch pulse sent to a mouse will clear its count of accumulated movement.
A program that plays [[APU DMC|DPCM samples]] and reads the mouse at the same time will occasionally read useless values.
Sample playback causes occasional double reads on $4016 and $4017, deleting a bit from the stream read back.
The re-reading solution that can be used for the [[standard controller]] fails here because each latch pulse sent to a mouse will clear its count of accumulated movement.
Nor is there a known way to reliably detect corrupted data.
Therefore, a program that uses the mouse and DPCM samples simultaneously does not conform to this specification.


A program could read the mouse while using the DMC as a interval timer, as long as the mouse is read in the IRQ handler so that the mouse reading subroutine can avoid the sample fetch.
A program could read the mouse while using the DMC as a interval timer, as long as the mouse is read in the IRQ handler so that the mouse reading subroutine can avoid the sample fetch.


[[Category:Controllers]][[Category:Super NES]]
[[Category:Controllers]][[Category:Super NES]]

Revision as of 00:24, 27 May 2015

The Super NES Mouse (SNS-016) is a peripheral for the Super NES that was originally bundled with Mario Paint. It can be used with an NES through an adapter, made from an NES controller extension cord and a Super NES controller extension cord, that connects the respective power, ground, clock, latch, and data pins.

As with the standard controller, the mouse is read by turning the latch ($4016.d0) on and off, and then reading bit 0 or bit 1 of $4016 or $4017 several times, but its report is 32 bits long as opposed to 8 bits. Bit 0 goes to the standard controller ports on an NES or AV Famicom; bit 1 goes to the Famicom 4-player adapter.

Some documents about interfacing with the mouse recommend reading the first 16 bits at one speed, delaying a while, and reading the other 16 bits at another speed, following logic analyzer traces from a Super NES console. However, these different speeds are merely an artifact of the main loop of Mario Paint, and the mouse will give a correct report when read at any reasonable speed. For example, a program could read 8 bits, wait a couple thousand cycles, and then read the other 24.

The first byte of the report is all zeroes and may be ignored. The other three bytes are sent most significant bit first:

76543210  Second byte of report
||||++++- Signature: 0001
||++----- Current sensitivity (0: low; 1: medium; 2: high)
|+------- Left button (1: pressed)
+-------- Right button (1: pressed)

76543210  Third byte of report
|+++++++- Vertical displacement since last read
+-------- Direction (1: up; 0: down)

76543210  Fourth byte of report
|+++++++- Horizontal displacement since last read
+-------- Direction (1: left; 0: right)

The displacements are in sign-and-magnitude, not two's complement. For example, $05 represents five mickeys (movement units) in one direction and $85 represents five mickeys in the other. To convert these to two's complement, use negation:

  ; Convert to two's complement
  lda third_byte
  bpl :+
  eor #$7F
  sec
  adc #$00
:
  sta y_velocity

  lda fourth_byte
  bpl :+
  eor #$7F
  sec
  adc #$00
:
  sta x_velocity

The mouse can be set to low, medium, or high sensitivity. To change the sensitivity, send a clock while the latch ($4016.d0) is turned on:

  ldy #1
  sty $4016
  lda $4016,x
  dey
  sty $4016

Some revisions of the mouse's microcontroller reportedly power up in an unknown state and may return useless values before the sensitivity is changed for the first time. A mouse detection routine should cycle through the sensitivities anyway to ensure that the connected device is in fact a mouse. Failure to do so is likely to cause things that are not a mouse to be detected as a mouse, such as half of a Four Score if player 3 or 4 is holding Right.

Using more than two mice on an AV Famicom is not recommended for two reasons:

  • A mouse draws 50 mA, which is much more current than the standard controller draws.
  • Changing player 1's sensitivity also affects player 3's, and changing player 2's sensitivity also affects player 4's.

A program that plays DPCM samples and reads the mouse at the same time will occasionally read useless values. Sample playback causes occasional double reads on $4016 and $4017, deleting a bit from the stream read back. The re-reading solution that can be used for the standard controller fails here because each latch pulse sent to a mouse will clear its count of accumulated movement. Nor is there a known way to reliably detect corrupted data. Therefore, a program that uses the mouse and DPCM samples simultaneously does not conform to this specification.

A program could read the mouse while using the DMC as a interval timer, as long as the mouse is read in the IRQ handler so that the mouse reading subroutine can avoid the sample fetch.