Mega Mouse with wheel

[Sik]

So I was thinking about the possibility that somebody may end up making either an adapter for USB mouses to Mega Mouse, or outright replacements for the Mega Mouse (since while it's still cheap, ball mouses honestly are awful with their tendency to catch dirt). In the case of the latter, the obvious way would be to grab an off-the-shelf mouse and modify it.

The big issue: modern mouses all come with mouse wheels, and we don't have a way to map them (there's also the problem that most mouses lack a fourth button, but oh well). We could just ignore the wheel, but why not instead actually expose it? But we're gonna need to standarize on a packet format or everybody will do whatever they feel like it.

Anyway, here's my proposal for how to extend the data fed back by the mouse, considering what stuff existing games seem to ignore (note that only 3rd nibble is different from a stock Mega Mouse):

Code: Select all

1st -  1  0  1  1
2nd -  1  1  1  1
3rd -  1  1 WD WU
4th - Yo Xo Ys Xs
5th -  C  M  R  L
6th - X7 X6 X5 X4
7th - X3 X2 X1 X0
8th - Y7 Y6 Y5 Y4
9th - Y3 Y2 Y1 Y0

• X7-X0: X axis displacement (two's complement)
• Y7-Y0: Y axis displacement (two's complement)
• Xs: X axis sign extension
• Ys: Y axis sign extension
• Xo: 1 = X axis overflowed (invalid), 0 otherwise
• Yo: 1 = Y axis overflowed (invalid), 0 otherwise
• WU: 0 = wheel up, 1 otherwise
• WD: 0 = wheel down, 1 otherwise
• L: 1 = left button pressed, 0 otherwise
• R: 1 = middle button pressed, 0 otherwise
• M: 1 = right button pressed, 0 otherwise
• C: 1 = Start button pressed, 0 otherwise

If somebody wants to go further: some mouses have a second wheel, and some mouses have more than four buttons… I'd suggest cramming the former into bits 3-2 of the 3rd nibble (so it's the "wheel nibble") and the extra buttons in the 2nd nibble (low logic, which would make them inconsistent with the 5th nibble but oh well).

If anybody is looking into making a new mouse adapter, consider looking at this please?


EDIT: I may as well include how the packet would look with the full extensions:

Code: Select all

1st -  1  0  1  1
2nd - B7 B6 B5 B4
3rd - WR WL WD WU
4th - Yo Xo Ys Xs
5th -  C  M  R  L
6th - X7 X6 X5 X4
7th - X3 X2 X1 X0
8th - Y7 Y6 Y5 Y4
9th - Y3 Y2 Y1 Y0

• X7-X0: X axis displacement (two's complement)
• Y7-Y0: Y axis displacement (two's complement)
• Xs: X axis sign extension
• Ys: Y axis sign extension
• Xo: 1 = X axis overflowed (invalid), 0 otherwise
• Yo: 1 = Y axis overflowed (invalid), 0 otherwise
• WU: 0 = wheel up, 1 otherwise
• WD: 0 = wheel down, 1 otherwise
• WL: 0 = wheel left, 1 otherwise
• WR: 0 = wheel right, 1 otherwise
• L: 1 = left button pressed, 0 otherwise
• R: 1 = middle button pressed, 0 otherwise
• M: 1 = right button pressed, 0 otherwise
• C: 1 = Start button pressed, 0 otherwise
• B4: 0 = 5th button pressed, 1 otherwise
• B5: 0 = 6th button pressed, 1 otherwise
• B6: 0 = 7th button pressed, 1 otherwise
• B7: 0 = 8th button pressed, 1 otherwise

Also other suggestions:

• Avoid the value -0 (treat it like +0)
• Avoid the value -256 (treat it like overflow)
• Maybe even replace overflow with a clamped value instead (works around bugs in one game with a seemingly broken mouse routine)

[PinoBatch]

I'd second the elimination of overflow from new devices, seeing as the Super NES Mouse seems to get along fine with clamping instead. For comparison:

Code: Select all

 1- 8  0  0  0  0  0  0  0  0
 9-16 RB LB A1 A0  0  0  0  1
17-24 YU Y6 Y5 Y4 Y3 Y2 Y1 Y0
25-32 XL X6 X5 X4 X3 X2 X1 X0

• RB, LB: buttons
• A1-0: Current acceleration curve (0: none/turtle; 1: mild/rabbit; 2: strong/cheetah)
• YU: Y displacement sign (1: up; 0: down)
• Y6-0: Y displacement magnitude
• XL: X displacement sign (1: left; 0: right)
• X6-0: X displacement magnitude

(Note: Unlike Mega Mouse, Super NES Mouse displacements are sign and magnitude, not two's complement.)

[Chilly Willy]

I like your extended mouse spec. While I like the idea of clamping the mouse move rather than having overflow, you need to keep the overflow bits for backwards compatibility. On mice that clamp rather than overflow, those bits will simply always be 0.

[Sik]

Well yeah, a mouse that does clamping will have to act like overflow never happens, I mentioned it just to help account for that one edge case (blurgh). Besides, the usual way to handle overflow is to drop the packet, while clamping at least doesn't completely drop the motion (and you could even spread the motion across multiple packets if this happens, at the expense of some "lag" if it takes really long but that's unlikely).

The overflow flags could still remain useful to report an error I guess (e.g. something went wrong and mouse is unable to return valid data right now so it just returns a bogus packet with overflow flags set).

[H1ghju1ce2]

Hi,

I saw this thread mentioned on RetroRGB, and wondered if anyone had tried this

So the 9-pin connector is shared with many other consoles and computers, the Amiga being one of them.

I have a 9-pin -> USB mouse afapter for my Amiga "Rys MKII"

https://retro.7-bit.pl/?lang=en&go=proj ... me=RYSMKII

Since it does HID and Ps/2 modes, and has a Firmware, I wonder if this might already work / be very close to working?

I have An amiga, a MegaDrive, an Everdrive and one of these adapters, so when I get a chance to try the setup I'll post back here with my results

[Sik]

DO NOT TRY IT, you may end up burning something, the pin assignment isn't the same.

To make that work you'd need custom firmware (since there doesn't seem to be any Mega Drive firmware available) and even then you need to be able to change which pins get VCC and GND (no idea if that adapter can change the pin connections). I can see where your idea is coming, but this particular product probably isn't a suitable one unless you can somehow do those two things.

[Chilly Willy]

The main issue with switching controllers between the Amiga and SEGA consoles is SEGA swapped pins 5 and 7 compared to all other 9-pin controllers to avoid patent issues. Yes, the original 9-pin DIN controller interface everyone (but SEGA) used was patented. I've moved SEGA controllers over to the Amiga successfully by swapping the pins, or by just soldering a pull-up resistor between the pins (not as good as swapping the pins). I recently completely rewired a SEGA 3-button pad for the Atari. You can find that here:

https://atariage.com/forums/topic/29417 ... ntrol-pad/

Note that the Amiga mouse (and other controllers) work fine on Atari or C64, but need that pin swap for SEGA. If you don't want to swap the wires on the device itself, you could always make a 9-pin male to female adapter that has the pins swapped and plug it inline with the device. Note that you'd still need special support for Amiga devices on the Genesis as Amiga (and ST ) mice are not remotely compatible (in a software sense) to MD mice. Nor are the pads... well, the pads are somewhat compatible, but not entirely. Amiga/Atari/C64 pads are more like the Master System pads (with the power pin swapped). Once you get to the MD, the changes get much greater.

[H1ghju1ce2]

DO NOT TRY IT, you may end up burning something, the pin assignment isn't the same.

To make that work you'd need custom firmware (since there doesn't seem to be any Mega Drive firmware available) and even then you need to be able to change which pins get VCC and GND (no idea if that adapter can change the pin connections). I can see where your idea is coming, but this particular product probably isn't a suitable one unless you can somehow do those two things.

Phew, thanks for the warning

Seems like a little bit of "knowledge" really is dangerous :O

Shame that device isnt open source, since it would be great to just have a variant of it that worked on the MD/Genesis

[H1ghju1ce2]

I messaged the maker/Dev of the Rys adatper, and he already has plans to make a megadrive version of it

so keep an eye on his page!

[Sik]

Well, that's encouraging.

May as well point to this thread so they implement the enhancements :​P (the trial version of Arkagis Revolution does have some mouse wheel code)