Hyperkin SNES Mouse cannot software-cycle sensitivity
Moderator: Moderators
Re: Hyperkin SNES Mouse cannot software-cycle sensitivity
Something related is part of the standard PS/2 mouse protocol (see "2:1 scaling"), so I assume they just carried it over...
Re: Hyperkin SNES Mouse cannot software-cycle sensitivity
[You may be able to find the manual on Internet Archive or RomHacking.net. Linking it here might bring bad attention from the powers that be. --MOD]
Whoever created the PDF file gave each page an appropriate page "name": In Adobe Reader, you can actually enter 4-6-6 in the page number box and it will go to the correct page. If that doesn't work with your reader, it's page 360 of 413.
In book2.pdf, page 4-6-6 includes a diagram with the statement "D6-D0 change with the amount of mouse displacement. (Max. 3F)"nocash wrote:Which diagram says 6bit?
Whoever created the PDF file gave each page an appropriate page "name": In Adobe Reader, you can actually enter 4-6-6 in the page number box and it will go to the correct page. If that doesn't work with your reader, it's page 360 of 413.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Hyperkin SNES Mouse cannot software-cycle sensitivity
Ah, interesting.lidnariq wrote:Something related is part of the standard PS/2 mouse protocol (see "2:1 scaling"), so I assume they just carried it over...
That's cool! I should probably give this thing a read.Bavi_H wrote:FYI everyone: From the link Rainwarrior provied, click "see other formats" at the top to get to the PDF version or other formats
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Hyperkin SNES Mouse cannot software-cycle sensitivity
KHan showed me something interesting today. Apparently the Hyperkin mouse requires a small delay (~100μs? need to test) between the 16th and 17th read, i.e. between the 2nd and 3rd bytes read. I hadn't run into this because my read routines have been a bit leisurely, reading $4016 and $4017 in tandem, etc. but a more focused direct read routine can easily run into this problem.
Thwaite seems to get lucky here by doing a little bit of extra work to track mouse button state after reading the 2nd byte.
This problem does not affect the original SNES mouse.
I'm guessing it has some 16-bit shift register internally that it tries to update between the 16th and 17th reads. Apparently Mario Paint has a very long delay there, but I'm curious if this causes incompatibility with any of the surprisingly large library of SNES mouse games... though I haven't heard of any incompatibilities from everything I'd read about the mouse elsewhere. (I don't own an SNES to test it myself.)
I'll try to write a proper demonstration ROM for this later, as I can't share what I tested it with (currently private).
Thwaite seems to get lucky here by doing a little bit of extra work to track mouse button state after reading the 2nd byte.
This problem does not affect the original SNES mouse.
I'm guessing it has some 16-bit shift register internally that it tries to update between the 16th and 17th reads. Apparently Mario Paint has a very long delay there, but I'm curious if this causes incompatibility with any of the surprisingly large library of SNES mouse games... though I haven't heard of any incompatibilities from everything I'd read about the mouse elsewhere. (I don't own an SNES to test it myself.)
I'll try to write a proper demonstration ROM for this later, as I can't share what I tested it with (currently private).
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Hyperkin SNES Mouse cannot software-cycle sensitivity
Here's a test ROM for inspecting the read delay limitations.
I found in my test that it can be read no faster than 14 cycles per bit, and between bytes 2 and 3 required at least 28 cycles.
The fastest bit read I tried was 11 cycles per bit (unrolled LDA $4017, ROR, ROL zp), and it gave chaotic read results. 12 was mostly stable with the occasional glitch. 14 was completely stable.
The 16-bit gap was fully stable at 28 cycles. The X/Y values were complete garbage at 24 or fewer cycles. In between there were sparse glitches.
(Wondering if this is sorta revealing the clock speed of some internal microcontroller...?)
The SNES Mouse, on the other hand was fine at all speeds.
I guess the short story is: don't unroll your $4016/4017 reads and you'll be fine for the bit speed limit, and you might need a handful of NOPs in between byte 2 and 3 if your read code is relatively lean.
I found in my test that it can be read no faster than 14 cycles per bit, and between bytes 2 and 3 required at least 28 cycles.
The fastest bit read I tried was 11 cycles per bit (unrolled LDA $4017, ROR, ROL zp), and it gave chaotic read results. 12 was mostly stable with the occasional glitch. 14 was completely stable.
The 16-bit gap was fully stable at 28 cycles. The X/Y values were complete garbage at 24 or fewer cycles. In between there were sparse glitches.
(Wondering if this is sorta revealing the clock speed of some internal microcontroller...?)
The SNES Mouse, on the other hand was fine at all speeds.
I guess the short story is: don't unroll your $4016/4017 reads and you'll be fine for the bit speed limit, and you might need a handful of NOPs in between byte 2 and 3 if your read code is relatively lean.
- Attachments
-
- mset_delay.zip
- (63.65 KiB) Downloaded 499 times
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact: