🚀 go-pugleaf

A few weeks ago, I posted a request for tips on how to set the screen cursor
position, totally under software control, then reassociating that position with
the mouse.  Eric Eide (u-eeide%ug.utah.edu@utah-cs.UUCP) kindly helped fill
in some information that Apple, for some reason, has chosen to leave out of
all its documentation (without even providing a ROM call to work around the
lack of low-memory information).  Before I start receiving flames: yes, I
know it's a bad idea to screw around with low memory, but one has no choice.


SO, here's a picture of relevant memory (courtesy Mr. Eide):

Variable MTemp, point (longword), $828.  You can get at it from Lightspeed
C by defining the variable
	extern point mtemp : 0x828;
somewhere in your program.  You can use the same syntax for all the variables
I discuss.  I'm not really sure what the variable does; it seems like an inter-
mediate counter to take care of non-sequential movements.  There are quite a few
data structures to handle cursor position, so this may not be correct.

Variable RawMouse, point (longword), $82C.  This is apparently the raw, input 
mouse position before processing by the vertical retrace interrupt manager (?).

Variable CrsrBusy, boolean (byte), $8CD.  Prevents the mouse handler routines
from doing anything to the cursor while we're messing around with it.

I initially tried the sequence (given a point I wished to move to):
	crsrbusy=TRUE;
	mtemp=mypoint;
	rawmouse=mypoint;
	crsrbusy=FALSE;
which didn't work.  That basically simulates "ObscureCursor()", i.e., it'll hide
the cursor until you move the mouse, then it'll jump to the desired location
on the screen.

Mr. Eide later pointed out that for total software control, using the "temp-
orary" variables", one needs another variable, CrsrNew.  This can then
be inserted right before the last crsrbusy assignment to inform the system
that the cursor needs updating.  The variable is located at $8CE, and is a
boolean (byte).  I have not tried this, though.

In the meantime, I searched for other ways, since I had to have absolute soft-
ware control of cursor position.  In a 1985 variable listing (fortunately, I
don't throw things away), I discovered variable Mouse, a point (longword), at 
location $830.  This is the "Mouse" position, such as "GetMouse()" might 
return.

I found that I was able to change the cursor position with simply
	mouse=mypoint;
but I still change the cursor busy state to be safe.  I haven't had a crash
since playing with this stuff.

Mild flame at Apple: most of the above is relatively undocumented.  It is not
in Inside Macintosh or any of the Tech Notes.  Mr. Eide got his information 
from a book by Scott Knaster.  I managed to fill in the rest from the afore-
mentioned variable list.  I can sympathize with the rationale in not wanting 
people to mess with cursor position, but to HIDE the information indicates a 
certain lack of trust in the judgement of developers (whether professional or
amateur).  The notion of not relocating mouse position isn't particularly deep
or difficult to understand, and I'd wager that anyone who has experienced a 
cursor jump (such as during a disk access) can testify to the faint feeling of 
disorientation it causes.  I doubt that you'd find anyone who will change 
cursor position haphazardly (I am only interested because, when I call hide-
cursor, I want the cursor to be where it disappeared when I call showcursor 
again).  Your omission cost me a lot of time tracking this down.

Incidentally, the above variables seem to work on the SE, as well as the 
Plus.  They probably work on older Mac's as well, but I haven't tried.


On to part two of this post.

The new Macs (Plus and beyond), as we all know, save several levels of mouse
scaling in Parameter RAM.  The location and nature of this scaling is complete-
ly undocumented in Inside Mac IV, and is disguised by a red herring 
from the documentation for the old ROM's (crsrthresh) that is completely 
unused by modern systems.

I have not been able to get scaling to work (and would appreciate any help from
people who know how).  All I've been able to determine is that the spvolctl
field (a variable byte at location $208) has been redefined under the 128K 
and 256K ROM's to now include the scaling threshhold that is actually used.  
Those of you with interest may wish to mark page II-372 of Inside Mac to in-
dicate that the bits 11-15 of the VolClik field (spvolctl is the high-order
byte of VolClik) are now used for scaling.  Problem is, the Control Panel only 
sets bits 11, 12, 13, and 14.  I don't know if bit 15 is reserved, or whether 
it's to indicate a level of sensitivity over and above "maximum" (it might be a
good idea on very large screens).  At any rate, one can determine the mouse sen-
sitivity after clearing bits 8-10, the sound level.  My problem: if I write in 
new values, nothing happens.  The cursor sensitivity goes to maximum.  Anyone 
who has clues as to why this is so, please contact me.

And a last flame at Apple: again, the tendency in "developer" support over the
last six months or so has been to assume we don't know what we're doing.  I
am well aware of the flames that the Mac is difficult to program, but I don't
feel that an undue proportion of resources should be dedicated to cranking out
tech notes noting the difference between such elementary concepts as a handle
and a point.  Instead, PLEASE try to keep the information as useful and
professional as possible.  If you can't publish information, don't publish.
It's not your responsibility to *teach* people how to program, yet there were
at least three tech notes last year which attempted to do precisely that.




-- 
Robert Dorsett                  {allegra,ihnp4}!ut-sally!ut-emx!
					walt.cc.utexas.edu!mentat
University of Texas at Austin	{allegra, ihnp4}!ut-sally!ut-emx!auscso!mentat