A closer look at NEWPAD subrom routine

Page 1/2
| 2

By Danjovic

Expert (78)

Danjovic's picture

27-08-2019, 07:30

After spent some time unsuccessfully looking for precise information about the Mouse protocol used by MSX computers I got a subrom binary to disassemble and take a look.

Mouse reading is performed by NEWPAD subroutine at address 0x1ad but the reading effectively occurs after addres 0x3509:

The Mouse routine reads 6 nibbles (0..5) in sequence, cadenced by the (toggling of) pin 8. Delay loops are inserted between readings .

The routine may end by updating the X and Y displacement coordinates with either the packing of nibbles [1.2] (XSAVE) and [3.4] (YSAVE) for a Mouse or a signal extended nibble [0] (XSAVE) and nibble [1] (YSAVE) for a Trackball.

Either one or another possible subroutine ending depends upon the value of the last nibble read (nibble 5). I stll have to figure out how exactly does the code below works
Values 8 and 9 will return as a mouse. Remaining values will return as a trackball.

....
xor 008h    ; invert bit 3 of nibble 5  
sub 002h    ; ?
cp 00dh     ; ?     
jr c,returnMouse ; return mouse
;
returnTrackBall:
....

I haven't found information anywhere about the purpose of the brief positive pulse issued after all nibbles are read.

Login or register to post comments

By ro

Guardian (4118)

ro's picture

27-08-2019, 07:39

wow, it's been a long time since I've seen some-one using the word "nibble" to address half an octet Smile So are we talking LSB or MSB nibbles here?

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

28-08-2019, 01:54

Danjovic wrote:

I haven't found information anywhere about the purpose of the brief positive pulse issued after all nibbles are read.

Well... You almost cracked the question your self. Smile

When we talk about mouse, nibbles 0 & 1 return X and nibbles 2 & 3 return Y... and that is practically all of the story: The End

So... in this particular case nibbles 4 & 5 return again X, but then we run in to a problem... If we don't have dummy "nibbles 6 & 7" then on next read nibbles 0 & 1 would return Y... and in real life that would be very unfortunate.

Please see this page for more details:
https://www.msx.org/wiki/Mouse/Trackball

By Danjovic

Expert (78)

Danjovic's picture

28-08-2019, 06:53

Quote:

. If we don't have dummy "nibbles 6 & 7" then on next read nibbles 0 & 1 would return Y.

Ok that makes sense, then the last pulse is a dummy reading. Nevertlheless I suppose that the mouse provides some resynchronizing mechanism like a timeout.

Source code of OpenMSX brings more info over the trackball/mouse selection by nibble 5 value:

Quote:

// ... the BIOS routine GTPAD to read mouse/trackball (more specifically PAD(12) and
// PAD(16) has an heuristic to distinguish the mouse from the trackball
// protocol. I won't go into detail, but in short it's reading the
// mouse/trackball two times shortly after each other and checks
// whether the offset of the 2nd read is centered around 0 (for mouse)
// or 8 (for trackball). There's only about 1 millisecond between the
// two reads, so in reality the mouse/trackball won't have moved much
// during that time. ....

However if you assume that the mouse/trackball will latch either value on a signal edge, then the time between consecutive readings of the second X nibble (rising edges) is around 200us instead of 1ms.

And I didn't get very well the meaning of " centered around 0 (for mouse) or 8 (for trackball) ". I know by the results of a small test program that when the value of the 5th nibble is 8 or 9 the code will assume that we have a mouse, otherwise it will return as a trackball, but I wonder that there may be some condition where such heuristic might fail, for instance one could not differentiate a steady trackball from a mouse, not even a trackball rolling solely over its Y axis from a mouse.

The schematic of the GB-7 trackball is available online and it added a lot of info, but so far I haven't found a datasheet for the M60226chip. That would help a lot to figure out how do the hardware work.

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

28-08-2019, 10:09

Danjovic wrote:

Ok that makes sense, then the last pulse is a dummy reading. Nevertlheless I suppose that the mouse provides some resynchronizing mechanism like a timeout.

Yes, very good assumption... It is there, but I don't know when this mechanism is triggered... There is also nothing that prevents user for making tight loop like "Execute NEWPAD, move sprite, repeat" although such makes no much sense.

Quote:

And I didn't get very well the meaning of " centered around 0 (for mouse) or 8 (for trackball) ". I know by the results of a small test program that when the value of the 5th nibble is 8 or 9 the code will assume that we have a mouse, otherwise it will return as a trackball, but I wonder that there may be some condition where such heuristic might fail, for instance one could not differentiate a steady trackball from a mouse, not even a trackball rolling solely over its Y axis from a mouse.

Your description of the routine is not quite accurate... Since trackball returns signed nibble, this means the return value is between -8 and +7... So, this "8/9 check" is actually for range -1 to +1
If you plan to move trackball in <150 μs more than 1 step, good luck. (Due to lack of return bits trackball is REALLY low resolution device... Around 13 DPI...) Same goes for moving mouse over 16 steps between reads... Not gonna happen in real life due to physical limitation of the mouse: I would say typical MSX mouse resolution is max 150 DPI... If I got my quick math correct that would translate to speed > 45km/h

By Danjovic

Expert (78)

Danjovic's picture

28-08-2019, 15:11

thanks for the explanation and for the extra data about DPI!
I am starting to figure out the whole thing and I'll come later with some sketches. I missed a very relevant difference vetwee. traxk ball and mouse: the latter presents inverted data bits ! then a zero count report will be $ff for a mouse ans $00 for a trackball.

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

29-08-2019, 07:55

Danjovic wrote:

thanks for the explanation and for the extra data about DPI!
I missed a very relevant difference vetwee. traxk ball and mouse: the latter presents inverted data bits ! then a zero count report will be $ff for a mouse ans $00 for a trackball.

No, that is not correct. The zero movement is reported as 0 on mouse... When reading mouse, you may very well receive constant $ff value, but that just means your computer can't see the mouse at all. (Check your connector contacts first) How ever when you use this NEWPAD-routine the up/down & left/right directions are swapped, so the outcome value in this case will be 1

I think here is the root cause for your misunderstanding:
NEG <> CPL
NEG == CPL, INC A

By Danjovic

Expert (78)

Danjovic's picture

30-08-2019, 04:33

That's right, I took NEG by CPL.
I did repeat the tests on the code that checks whether the device is a mouse or a trackball. I checked that function twice now on a debugger.

Values 7,8,9 return as a mouse, other values return as a trackball

That still makes no sense for me unless mouse put nibbles using an unsigned value with zero displacement being represented by 128.

0111 0000 15 steps back
0111 1111 one step back
1000 0000 zero displacement
1000 0001 one step further
1001 0000 16 steps further

but applying the NEG would still make no sense....

1000 0001 one step back
0000 0000 zero displacement
0111 1111 one step further

Any clues? I know that the diy adpaters that have been built so far do work (including yours, thanks!) but something is missing and that bothers me. I may be bothering everyone else too, lol!!!

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

30-08-2019, 08:30

Danjovic wrote:

Values 7,8,9 return as a mouse, other values return as a trackball

No, you got it upside down again... 7,8,9 == -1, 0, +1 for trackball (==Trackball !)

Quote:

That still makes no sense for me unless mouse put nibbles using an unsigned value with zero displacement being represented by 128.

No, it is just a regular two's complement number, so...

0000 0010 (=+2) two steps back
0000 0001 (=+1) one step back
0000 0000 (=0) zero displacement
1111 1111 (=-1) one step further
1111 1110 (=-2) two steps further
...

Quote:

but applying the NEG would still make no sense....

NEG only swaps the sign between + and -, so without it the mouse just moves to opposite direction you wanted. (You roll left -> the mouse goes right, you roll up -> the mouse goes down)

You can think it as "fix" for the "gear effect" (When ball rotates clockwise the sensor rotates counterclockwise)

By NYYRIKKI

Enlighted (5382)

NYYRIKKI's picture

30-08-2019, 09:02

By Danjovic

Expert (78)

Danjovic's picture

30-08-2019, 23:01

Hi NYYRIKKI

Quote:

No, you got it upside down again... 7,8,9 == -1, 0, +1 for trackball (==Trackball !)

Ooops, tested that again... You're absolutely right!
So, the Trackball uses an inverted sign bit, being 0 for negative numbers and 1 for positive!
I've finally got it!! Running Naked in a Field of Flowers

.

Quote:

You can think it as "fix" for the "gear effect" (When ball rotates clockwise the sensor rotates counterclockwise)

Indeed! I think the same!
.
Thanks again for the information and especially for the patience!

Page 1/2
| 2