Mega Mouse Usage

[SegaDev]

Hi,

I was wondering if anyone knew how the mega mouse worked and if anyone could provide source code to get the muse working, preferably something we can add to the framework would be greatly appreciated.

Sincerely,

SegaDev

[Apocalypse]

Both Sega Mouse (2 buttons + 1 on the ball) and Mega Mouse (North American market, 3 buttons, no clickable ball, + Start button) use a dedicated protocol to communicate with the MD.

Charles MacDonalds doc on the Genesis IO, where you find this:


Sega Mega Mouse

This is a three button mouse (left, middle, right) with an extra button (Start) located near the thumb position. It uses a PIC16C54
microcontroller which manages the buttons and position tracking.
The Sega Mega Mouse that is distributed in North America is incompatible with the European version of Populous 2. The mouse
functions normally but has Y axis inverted so up is down and vice-versa. It may have been designed for the Japanese Mega Drive
mouse, which is a different product with 2 buttons and unique physical appearance.
The protocol works as follows: TH and TR are outputs which tell the microcontroller to stop or start a data transfer, and to
acknowledge received data. TL is an input which returns a busy flag for the microcontroller. D3-D0 are inputs that return the data.

Here's a table showing the communication process:
Write TH TR TL D3 D2 D1 D0 Description
$60 1 1 1 0 0 0 0 Request data
$20 0 1 1 0 0 0 0 ID #0 ($0)
$00 0 0 1 1 0 1 1 ID #1 ($B)
$20 0 1 0 1 1 1 1 ID #2 ($F)
$00 0 0 1 1 1 1 1 ID #3 ($F)
$20 0 1 0 Y Over X Over Y Sign X Sign Axis sign and overflow
$00 0 0 1 Start Middle Right Left Button state
$20 0 1 0 X7 X6 X5 X4 X axis MSN
$00 0 0 1 X3 X2 X1 X0 X axis LSN
$20 0 1 0 Y7 Y6 Y5 Y4 Y axis MSN
$00 0 0 1 Y3 Y2 Y1 Y0 Y axis LSN

Write #$60 when you are done polling to stop the data transfer. If you continue to poll the mouse after collecting all the data by
writing $20 / $00, the Y axis LSN will always be returned. Sega advises polling beyond this point will make the mouse behave
abnormally. It's possible that the PIC code in some versions of the Mega Mouse may have problems if the poll sequence is too
long.
The X/Y overflow flags are supposed to be set if the mouse is moved over a distance greater than can be measured. I can't get
them to become set, maybe the mouse supports a fairly wide range of movement.
You need a considerable delay between writing new values to TH/TR. I think the intention is to poll TL until the microcontroller
returns 'not busy', but I can't get this to work reliably. Sega's mouse reading code also has a timeout when checking TL which
would indicate it may get stuck in a certain state.
All buttons (start, left, middle, right) are active-high logic, so they return '1' when pressed and '0' when released.

[KanedaFr]

perhaps I'm wrong, but SGDK handle mouse no ?
Chilly Willy added the code for it...

ps: I move this topic to the right forum

[djcouchycouch]

According to joy.h in the SGDK, it does indeed support the mouse.

[ComradeOj]

Sort of piggybacking on this thread, but I didn't want to make a new one since I basically have the same question.

Does anyone have an assembly language driver for the mouse? I want to add mouse support to a game of fine, but I can't find any example code for reading a mouse.

I saw the joy.h file in the Genesis SKD, but it's written in C so I can't make use of it in my game which is all in assembly language.

[gasega68k]

I did a demo to test the mouse when I was adding support for Wolf3D, the code is based on the source code for mouse for Wolf32x of Chilly Willy, but I made some small modifications with the help of Chilly Willy and Barone (from sega -16), because I have no mouse and they had two different versions of the mouse, American(Chilly Willy) and Japanese(Barone).
you can see the discussion on this here:
http://www.sega-16.com/forum/showthread ... post686869

And after several tests, the version "mouse_test9.bin" was the version that worked for both versions (american and japanese):
In this rar file you will find it:
http://www.mediafire.com/download/oerrq ... _10_mm.rar

And "mouse_test9" source code(in asm):
http://www.mediafire.com/download/h7rc0 ... source.rar

[ComradeOj]

^Thank you very much!

I was able to re-use some of that code in my game, and I was able to get the mouse working!
I think the game is way better with a mouse than a controller!
https://www.youtube.com/watch?v=BNR0vnZ8R6k

[Eke]

Sorry to bump this thread but anyone here having a Sega/Mega Mouse could test this ROM on hardware (with mouse controller plugged in port 2) and report output values ?

I'm trying to figure the acknowledge latency of the mouse protocol, as it seems to be (involuntarily ?) needed by a few game routines.

[Chilly Willy]

Is it supposed to update, or just show one list of readings? I get

PORT 2 = 0x60 -> 70 70 70
PORT 2 = 0x40 -> 50 50 50
PORT 2 = 0x60 -> 70 70 70
PORT 2 = 0x00 -> 1B 1B 1B
PORT 2 = 0x20 -> 3B 3B 3B
PORT 2 = 0x00 -> 1B 1B 1B

and then it just sits there doing nothing. This is repeatable - running it multiple times gives the same result.

EDIT: Hmm - this time I got

PORT 2 = 0x60 -> 70 60 60

for that second line. So there does seem to be the occasional variance.

[Eke]

Thanks for this quick test. And yes, it's just a one shot write sequence , it's not supposed to update itself.

Results are interesting but definitively not what is expected from games (and quite different from what you get in emulators). I suspect the reason is I'm switching TR output too fast for the mouse (i.e before previous handshake cycle has been completed).

I made another test ROM which this time counts the number of reads until TL input is switching its state according to TR output state.

Could you please give it a go when you got some time ?

Thanks again

[Chilly Willy]

Not a problem. It's Sunday and I'm just sitting here right next to my SEGA and it only takes a couple seconds to copy the file onto an SD card.

Okay, I'll just list the waits since you know the sequence...
0
2
2
18
2
oo
0
oo
0
19

The values seem stable over multiple runs. I'm guessing the oo means it timed out?

[Eke]

I'm guessing the oo means it timed out?

Yes. It seems to indicate the mouse does not respond to handshake request when TH is low unless it was properly reseted (60h followed by 20h or possibly 00h).

If you don't mind, I added a few write sequences for completeness in this test ROM. This should be the last one hopefully.

[Chilly Willy]

The new one is
0
3
2
18
1
oo
0
oo
0
19
3
2
1
0
4
3

I can't really tell what you're doing from the values, but 3-line handshake is simple: start with unselected (0x60), then toggle back and forth between the two selected states (0x20 and 0x00) to get nibbles (0x20 first). That's all there is to it. When you're done, deselect the mouse again (0x60). It's explained pretty well in the Saturn manual since most Saturn controllers use the 3-line handshake. In fact, you could use Saturn controllers on the Genesis with a proper adapter.

[Sik]

Since we're at it, any chance to test the possible range of the coordinates?
viewtopic.php?f=23&t=2559

[Eke]

I can't really tell what you're doing from the values, but 3-line handshake is simple: start with unselected (0x60), then toggle back and forth between the two selected states (0x20 and 0x00) to get nibbles (0x20 first). That's all there is to it. When you're done, deselect the mouse again (0x60). It's explained pretty well in the Saturn manual since most Saturn controllers use the 3-line handshake. In fact, you could use Saturn controllers on the Genesis with a proper adapter.

Yes, I know about the protocol, it's fairly well documented and works fine for most games in emulators with this basic implementation.

However, there are some games (Cannon Fodder and Shanghai 2 for example) which have bugged mouse routines that only work by chance with real hardware because in reality TL input state does not change immediately to reflect TR state (as confirmed by your tests).
In Genesis Plus GX (and in Fusion), this is handled by delaying TL state change by one read.

This works fine for all games except one Sega CD game (Star Blade), that also uses an unusual mouse acquisition routine which get locked if you delay TL state 0->1 change by one read when output state changes from 0x40 to 0x60.

From my tests with above test ROMs, Fusion handle this by delaying TL state change EXCEPT when output state changes from 0x40 or 0x00 to 0x60 but the above results show this is incorrect and the reason Star Blade mouse support works fine on real hardware is again that the routine luckily fits with the acknowledge latency timings (using a two-reads delay instead of just one-read delay fixes it in emulator).

The results above actually show that:

1) when switching TR from 0 to 1 or from 1 to 0, there is a delay before TL state reflect the changes (ACK delay)
2) if you switch TR state when TH is low, TL remains forced to 1 until mouse acquisition sequence is properly reinitialized (state=0x60)
3) ACK delay is notably longer just after mouse initialization (state=0x60)