Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shelby!rutgers!apple!tecot
From: tecot@Apple.COM (Ed Tecot)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ADB Internals; would DTS get an answer?
Message-ID: <30699@apple.Apple.COM>
Date: 15 May 89 04:51:37 GMT
References: <6996@saturn.ucsc.edu>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 27

In article <6996@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes:
>1) the darn procs Apple supplies use A3 instead of A0.
>(they do MOVE.W $164(A3), D1 and such instead of MOVE.W (A0),D1)

The problem here is that the service routines in ROM were written before the
interface was designed.  When the interface was completed, the mouse routine
wasn't modified (the keyboard one was and uses A0 - if you have an example
to the contrary let me know).  In any case, this has been noticed and will
be fixed in future ROMs.  As to your work-around - use A0, but don't change
it.  You can stuff new values in the buffer that is passed to the routine.

>2) if no ADB devices are really hooked up to the target Mac, then
>how do I obtain pointers to the service procs (especially since
>6.0.X patches the mouse proc only if a mouse is connected...)?

Currently, the ROM makes a slot for the keyboard and mouse, even if one is
not connected.  Although you shouldn't depend upon this, it should ease
your worries.  Besides, what good is faking out the driver if the device
doesn't exist?

A final note:  I strongly suspect that your strategy will be your undoing.
The data passed to the service routines are in their raw format.  In
different environments, your code will have unexpected results, for example,
in Japan, where they keys have different meanings, or if the user alters
his or her mouse speed.

						_emt