It is currently Tue Sep 17, 2019 1:19 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Wed Jan 23, 2019 3:04 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8559
Location: Seattle
rainwarrior wrote:
What was how they worked?
Sorry, indefinite antecedent. Having an "internal timebase" to handle irregular polling.

I think it even technically counts as necessary when the reported mickeys is superlinear with counts.

... Digging into some old PS/2 mouse protocol stuff, one could configure them in two modes: "remote" and "stream". When in "remote" mode it had to accumulate the values in a useful way. Regardless of whether it was in "remote" mode or "stream" mode, it still aggregated its internal values on a regular timebase:
Ralf Brown's x86 ports list wrote:
Code:
(Table P0387)
Values for Mouse functions (for PS/2-like pointing devices):
Value   Count   Description
 E6h    sngl    set mouse scaling to 1:1
 E7h    sngl    set mouse scaling to 2:1
 E8h    double  set mouse resolution
                (00h=1/mm, 01h=2/mm, 02h=4/mm, 03h=8/mm)
 E9h    sngl    get mouse information
                read two status bytes:
                  byte 0: flags (see #P0388)
                  byte 1: resolution
 EAh    sngl    set mouse to stream mode (mouse sends data on any changes)
 EBh    sngl    get mouse data (from mouse to controller) (see #P0389)
                on reading, each data packet consists of 8 bytes:
 ECh    sngl    reset mouse wrap mode (to normal mode)
 EEh    sngl    set wrap mode
 F0h    sngl    set remote mode (instead of stream mode), mouse sends data
                  only on issueing command EBh.
 F2h    sngl    read mouse ID (read one, two?? ID bytes)
                00h=mouse
 F3h    double  set mouse sample rate in reports per second
                0Ah=10/s           50h= 80/s
                14h=20/s           64h=100/s
                28h=40/s           C8h=200/s
                3Ch=60/s
 F4h    sngl    enable mouse (in stream mode)
 F5h    sngl    disable mouse (in steam mode), set default parameters
 F6h    sngl    reset to defaults: 100/s, scaling 1:1, stream-mode, 4/mm,
                  disabled
 FEh    sngl    resend last mouse data (8 bytes, see EBh)
 FFh    sngl    reset mouse
Notes:   must issue command D4h to PORT 0064h first to access mouse functions
         all commands except ECh and FFh are acknowledged by FAh (ACK) or
           FEh (Resend); get mouse ID (F2h) returns mouse ID.


Older RS232 mice don't seem to do this. Both the Mouse Systems and "Microsoft" mouse protocols don't seem to have any significant computer-to-mouse communication ability.

Quote:
or if it is a sum why it never exceeds the maximum table value?
And that's a good question too.


Top
 Profile  
 
PostPosted: Wed Jan 23, 2019 3:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Though, re: the internal time theory, I wasn't seeing any regularity of when it happened. It could be seconds apart or only a few frames between. Kinda hard to test since I have to be moving the mouse to have a chance of spotting one. Once or twice I saw a 4 on consecutive frames (sensitivity 1). So if there is an internal timer that's doing something here it's probably not close to 60Hz. Presumably a fair bit higher?

I wish I had a treadmill or a belt sander that I could just hold the mouse against for an even speed...


Top
 Profile  
 
PostPosted: Wed Jan 23, 2019 11:37 pm 
Offline

Joined: Sun Mar 03, 2013 1:52 am
Posts: 120
Location: Texas, USA
Rainwarrior, thank you for measuring the ball, roller, and counting the holes on the wheel. I was thinking about it often at work today. You already came up with similar results as below (the measurements suggest about 50 counts per inch), but I wanted to chime in with a different way of explaining how to get there:

How the mouse encoder wheel works: There's two infrared LEDs aligned with two infrared detectors for each wheel. The LEDs and detectors are set up so that when the wheel moves, the detectors change in the following loop:

00
01
11
10

A sequence going down the loop indicates one direction, a sequence going up the loop indicates the opposite direction. The number of detector changes per complete revolution of the wheel is 4 times the number of holes on the wheel. But I don't know if the mouse maps every detector change to 1 count in its report. When I searched for information about mouse encoder wheels, I ended up finding descriptions of quadrature encoders which say that the count could be triggered on one edge of one detector, both edges of one detector, or both edges of both detectors. So 1 count in the report might represent 1, 2, or 4 detector changes?*

Also, after I thought about it some more, I think it doesn't matter what the size of the ball is, only that the ball is snug in the chamber and smoothly rolls the roller consistently. If the ball moves 1 inch along an axis, the corresponding roller's circumference has also rolled 1 inch. So to determine the mouse resolution in counts per inch, I think we just need to divide the number of counts generated by one revolution of the roller by the roller's circumference in inches.

So if we start with Rainwarrior's measurements:

Wheel: 20 holes
Roller diameter: 0.27 inches

Since there are three possible ways to generate counts per hole:

1 count per hole (1 count per 4 detector changes)
2 counts per hole (1 count per 2 detector changes)
4 counts per hole (1 count per detector change)

I think that means this particular SNES ball mouse has one of these possible resolutions:

20 holes * 1 count per hole : pi * 0.27 inches = about 24 counts per inch
20 holes * 2 counts per hole : pi * 0.27 inches = about 47 counts per inch
20 holes * 4 counts per hole : pi * 0.27 inches = about 93 counts per inch

I guess it's probably the middle one, about 47 counts per inch -- based on Rainwarrior's tests (60 Hz poll at linear sensitivity resulted in a displayed count of 1 representing about 1 inch per second, meaning about 60 counts per inch) and nocash's document (says the SNES mouse resolution is 50 counts per inch +/- 10%).

* I even thought about the possibility of removing an encoder wheel, manually placing and removing small slips of plastic in front of the detectors in the loop sequence above, then manually triggering a mouse read to confirm exactly when a count is triggered. (1 detector change, read mouse, was count 0 or 1? 2 detector changes, read mouse, was count 0 or 1? 4 detector changes, read mouse, was count 0 or 1?) But that might be too difficult or end up damaging the mouse for not much benefit.


Top
 Profile  
 
PostPosted: Thu Jan 24, 2019 12:00 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Bavi_H wrote:
Also, after I thought about it some more, I think it doesn't matter what the size of the ball is, only that the ball is snug in the chamber and smoothly rolls the roller consistently. If the ball moves 1 inch along an axis, the corresponding roller's circumference has also rolled 1 inch. So to determine the mouse resolution in counts per inch, I think we just need to divide the number of counts generated by one revolution of the roller by the roller's circumference in inches.

Yes, I think you're right. Reviewing that calculation...

20 holes x (ball circumference / roller circumference) = ~72 holes per revolution of the ball
1 inch / ball circumference = ~0.33 revolutions of the ball per inch
72 holes per revolution / 0.33 revolutions per inch = ~24 holes per inch

...the size of the ball is used twice, cancelling itself out. What matters is the circumference of the roller and its hole count.


As for the way it counts internally, I don't know. I have to assume 2 individual counts per hole for this to make sense, but the specifics of how this is done I can't really say. Using two sensors like that is something I'd seen described somewhere, though there are probably other ways to do it. An encoder that ticks on each open and close seems quite plausible.

I don't really want to take this thing apart any further than I already have, though. I feel like some of these questions would require destructive disassembly to definitively answer, and I want to retain a working mouse for testing. My main goal was just to see how it responds to motion / user control versus its clone, though the rest of this is interesting to think about at least, and if there's something further you'd like me to test I can probably accomodate.


Top
 Profile  
 
PostPosted: Fri Jan 25, 2019 4:30 pm 
Offline
User avatar

Joined: Wed Mar 16, 2016 2:08 pm
Posts: 46
Location: World 9 - Warp Zone
The theme of the thread is very interesting. I have seen the list of games that you have tried in the first post of the thread. Have you thought about trying a NES licensed game that could be controlled using the SNES mouse? I think for example: "Maniac Mansion".

_________________
Projects:
HomeBrew Stuff (#2)(8bits/16bits/32bits)
HomeBrew Stuff (#1)(8bits/16bits/32bits)
J_GB Emulator (GB / GBC / SGB Emulator written in Java)
NES4J Emulator (NES / FAMICOM / FDS Emulator written in JAVA)


Top
 Profile  
 
PostPosted: Fri Jan 25, 2019 4:35 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
I don't think there's any plausible reason why a commercial era NES game would have SNES mouse support, but if you want to try for yourself FCEUX and Mesen both implement the SNES Mouse. I'm 100% certain you'll find they do nothing at all with it, though.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 5:14 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1005
book2 wrote:
7.4.1 Fast (10B)
The ratio of cursor displacement to mouse displacement is automatically adjusted between 6 levels, from 1:1 to 6:1.

How does that match up with the measured values?

PS. obscure theory: If they are literally handling the displacement: That would be
disp = sqrt(stepx^2 + stepy^2)
I doubt that the mouse supports anything like that, but if it does: That could also explain receiving unexpected values (if the mouse isn't moved in straight horizontal or vertical direction).


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 5:49 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
nocash wrote:
book2 wrote:
7.4.1 Fast (10B)
The ratio of cursor displacement to mouse displacement is automatically adjusted between 6 levels, from 1:1 to 6:1.

How does that match up with the measured values?

I don't know what that means. What is book2?

nocash wrote:
PS. obscure theory: If they are literally handling the displacement: That would be
disp = sqrt(stepx^2 + stepy^2)
I doubt that the mouse supports anything like that, but if it does: That could also explain receiving unexpected values (if the mouse isn't moved in straight horizontal or vertical direction).

A test I thought to do just now: I took the ball out and just spin one of the rollers directly by itself. Doing this I still get occasional outside-of-table values, so I don't think there's a cross-axis combination going on, I think they're independent.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 5:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Oh, I found "book2" here:
https://archive.org/stream/SNESDevManual/book2_djvu.txt

Well, no I don't think that really matches the table. You did the analysis yourself earlier in this thread, the highest multiplier seems to be 4x in the most sensitive mode, and I think 6 steps is wrong, but maybe if you're not counting 0 and only counting between 1 and maximum that's actually 6 steps in between? I dunno.

It's true at least that the mouse movement does scale non-linearly faster with progressively faster movement, at least until you hit that cap. I think most of the rest of the description seems true enough. "Slow" setting is 1:1 as it says. It seems to diagram only 6 bits for displacement output (edit: I misread this), which agrees with the cap at 63 I saw.

I would say, though, that I think the tables were designed/tuned against 60hz output, since sampling less frequency still seems to use the same table, and the curve gets horribly saturated at lower polling rates (and vice versa for faster polling rates).


Last edited by rainwarrior on Wed Jan 30, 2019 9:40 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 7:40 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1005
Which diagram says 6bit? Page 4-6-2 and 4-6-6 and 4-7-3 all look like 7bit (+direction flag) for the data transfers.
But anyways, there might some restriction in the underlaying hardware causing the 7th bit to be always zero.

Yes, the 1:6 ratio doesn't seem to match with the hardware, maybe they just thought that the hardware would support that.
It could make some sense if the translation table would contain values for 0..15. But was accidentally cropped to "if index>7 then index=7".
If entry[15] would be 15*4 for medium speed and 15*6 for fast speed, then they'd also reach values close to or exceeding the slow max=63 value.

How does the max=21 and max=28 feel in practice, when actually moving a mouse arrow?
Is it noticeable that the speed is getting cropped, and feels as if the mouse doesn't react well to user interactions?
I mean in normal daily use, when you would want to move the mouse arrow with a quick move - not corner cases like spinning the wheels as fast as possible for finding the technically supported max values.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 8:13 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
nocash wrote:
Which diagram says 6bit? Page 4-6-2 and 4-6-6 and 4-7-3 all look like 7bit (+direction flag) for the data transfers.

In the link I have above under 4-7-2 there are things that say "1 1 1 1 1 1" underneath "Displacement in Y direction".

nocash wrote:
But anyways, there might some restriction in the underlaying hardware causing the 7th bit to be always zero.

In the slowest/linear setting it's not really normal to produce values more than about 20 with sane motion of the mouse. 63 was very difficult to do, at that point you're kinda past the ball's ability to grip a surface.

nocash wrote:
How does the max=21 and max=28 feel in practice, when actually moving a mouse arrow?

It's okay. TBH I much prefer the hyperkin's linear but wider output, but it also has much higher effective DPI. With the SNES ball mouse you can't move as finely so i can see why they needed to expand the usable range. I think it accomplishes that. On the mid/high speed settings 21/28 is an okay cap, it just means that cursor motion is kind of at a fixed speed whether you're moving moderately fast or very fast... it's a fairly low speed max-out (~7 inches per second). It's the fine/slow motion is more problematic and uneven, but it's still usable too.

But if you use this as "pixels per frame" then 21/28 works just fine at 60Hz. That's about as fast as you'd ever want to go anyway? Since all 3 outputs have identical linear access to the lowest couple of values all of them are capable of the finest control too.

So... I guess I think it's a fairly decent implementation for the limited resolution of the hardware they were working with.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 8:47 pm 
Offline

Joined: Fri Feb 24, 2012 12:09 pm
Posts: 1005
Oh, I didn't notice that you were linking to a txt file - better look at the book2.pdf version.
The "1 1 1 1 1 1" in the txt version is supposed to be seen as six vertical lines, separating the seven bit cells.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 9:13 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 4208
Location: A world gone mad
Attachment:
Capture.PNG
Capture.PNG [ 111.46 KiB | Viewed 7685 times ]


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 9:36 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Ah I see, okay well that was just misunderstood then.

It's probably sensible to tell software to expect values can be as high as 127 anyway, whether or not it can actually deliver them. Leaves room for other/future variations of hardware that might produce them.

Like this doesn't need to document how to build the mouse or what its exact specs are. It needs to document the interface and tell you what to write software to accept/use. Otherwise they need the leeway to revise things to meet engineering or other practical needs.


Top
 Profile  
 
PostPosted: Wed Jan 30, 2019 9:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7582
Location: Canada
Though... maybe what's curious to me is that it seems trivial to just do the table lookup in software. Why'd they bother building this feature into the mouse itself?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 35 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group