🚀 go-pugleaf

in article <338@stag.UUCP>, syntel!dal@stag.UUCP (Dale Schumacher) says:

> #define	MOUSEX		*((WORD  *)((char  *)aline + -344L))
> #define	MOUSEY		*((WORD  *)((char  *)aline + -342L))
> #define	MOUSESTATE	see below
> 
> The mouse buttons appear to be (MOUSESTATE & 1) for left and (MOUSESTATE & 2)
> for right.  The higher order bits of MOUSESTATE seem to hacve something to
> do with the mouse being moved.  If anyone can expand on this information,
> (or make corrections) please do.

The mousex and mousey values above are correct (if a little over-casted).
But the button state can better be read from MOUSE_BT, at offset -596L
from the "aline" base.  This variable doesn't have any bits except the
button state bits (bit 0 = button 0, bit 1 = button 1), so there's
nothing else to check.

#define MOUSE_BT *((WORD  *)((char  *)aline + -596L))

This one is a word, not a byte.  Also, you can't cast the constant to a
(char *): it's OK to add a constant to a character pointer, but adding
two pointers is undefined in C.  Subtracting two pointers gives the
distance between them, but adding two pointers is illegal.  (Naturally,
the Alcyon compiler not only doesn't tell you this is an error, but at
least it generates correct code for what you wanted it to do.  The
defines in the quote from dal have been edited by me to reflect this.)

Note that these values are READ ONLY.  If you write to them, bad things
will happen and the system will lose track of the mouse state. 

All of these "negative line-A variables" were published in the developer
section of CompUServe some time ago.  They work for all ROMs.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt