afoster@ogccse.ogc.edu (Allan Foster) (08/17/89)
References : Sender: Reply-To: afoster@ogccse.UUCP (Allan Foster) Followup-To: Distribution: Organization: Oregon Graduate Center, Beaverton, OR Keywords: multitasking, jerkey mouse In article <866@bridge2.ESD.3Com.COM> ngg@bridge2.3Com.com (Norman Goodger) writes: >>> - While printing a background job, I often have a hard time keeping >> control of the mouse pointer -- it's like using the mouse as a >> slingshot. Very annoying. > >The problem is disk access in the background, unless Apple includes DMA for >SCSI in the future, mouse motions will always be jerky in some operations. > > No no not true. The disk access does indeed make the mouse a little jerky, but that is not the reason. The real reason is in the ADB drivers. When Andy Hertzfeld wrote the mouse drivers for the old mac he went to great pains to make sure that the mouse acted RIGHT. The engineers who implemented the ADB just SCREWED UP. The ADB chip collects all the info about mouse movements and stores it as one change since the last poll by the CPU. If the CPU is busy then the figures stored as to how much the mouse has moved becomes large. OK, so what is the fix? Simple. Patch the ADB drivers for the mouse device so that if the mouse has moved more than a threshold value since the last time it was read, then ignore it. This will make the mouse behave exactly like the old mac plus mouse. Some experimenting would be in order to see exactly what should happen. This works. (I have done the mod on my machine...) but I cannot find the patch. If there is demand for it I can always disassemble my resources and find out what I did! Regards Allan Foster MicroPhone II Development Team -- Allan Foster UUCP : tektronix!ogcvax!afoster UseNet: afoster@cse.ogc.edu GEnie : A.FOSTER AppleLink : D1663 MacNet : FOSTER
pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) (08/18/89)
In article <4254@ogccse.ogc.edu> afoster@ogccse.ogc.edu (Allan Foster) writes: >[stuff about why the cursor jumps all over with ADB mice and why] >OK, so what is the fix? Simple. Patch the ADB drivers for the mouse device >so that if the mouse has moved more than a threshold value since the last time >it was read, then ignore it. This will make the mouse behave exactly like the >old mac plus mouse. Some experimenting would be in order to see exactly >what should happen. >This works. (I have done the mod on my machine...) but I cannot find the >patch. If there is demand for it I can always disassemble my resources >and find out what I did! Start dissassembling (consider this a 'demand'). I too prefer the way the pre-ADB mouse/cursor worked, and I'm sure there are a few more of us out there. I would appreciate it if this patch could be e-mailed to me, and I'm sure other people on the net would like to see it too, so maybe the patch could be posted here. Anxiously awaiting my 'slow' mouse! M. A. Pasek Switching Software Development NCR Comten, Inc. (612) 638-7668 CNG Development 2700 N. Snelling Ave. pasek@c10sd3.StPaul.NCR.COM Roseville, MN 55113 (612) 638-768
jones@optilink.UUCP (Marvin Jones) (08/19/89)
In article <1449@ncrcce.StPaul.NCR.COM>, pasek@ncrcce.StPaul.NCR.COM (Michael A. Pasek) writes: > In article <4254@ogccse.ogc.edu> afoster@ogccse.ogc.edu (Allan Foster) writes: > >[stuff about why the cursor jumps all over with ADB mice and why] > > Start dissassembling (consider this a 'demand'). I too prefer the way the > pre-ADB mouse/cursor worked, and I'm sure there are a few more of us out > there. > Please count me in on this distribution if you EMail the patch to people. We haven't been getting comp.binaries.mac for ages around here due to someone upstream cutting it. So please Email, or post here in comp.sys.mac. Thanks millions! I'm glad someone took the time to figure this one out! -- Marvin Jones {pyramid, pixar, tekbspa}!optilink!jones Optilink Corp. ATT-net: 707-795-9444 X 206 1310 C Redwood Way CI$: 71320,3637 Petaluma, CA 94952
tecot@Apple.COM (Ed Tecot) (08/30/89)
In article <4254@ogccse.ogc.edu> afoster@ogccse.ogc.edu (Allan Foster) writes: >No no not true. The disk access does indeed make the mouse a little jerky, but that >is not the reason. > >The real reason is in the ADB drivers. When Andy Hertzfeld wrote the mouse >drivers for the old mac he went to great pains to make sure that the mouse >acted RIGHT. All of the original mouse code was written by Bud Tribble, not Andy Hertzfeld. None of the effort you describe went into it. >The engineers who implemented the ADB just SCREWED UP. The ADB chip collects >all the info about mouse movements and stores it as one change since the last >poll by the CPU. If the CPU is busy then the figures stored as to how much >the mouse has moved becomes large. Oh, really? Actually, what this demonstrates is that additional I/O processors do not necessarily improve a system. As it turns out, the errors in ADB are far fewer than the original mouse code, but the TYPE of errors are far less tolerable. On a Macintosh Plus and older machines, floppy access (which diables interrupts) would effectively shut the mouse down. No one seemed to mind. These days, when interrupts are diasabled on the CPU, all the other input devices keep chugging along; they have their own processors. When the CPU "wakes up", the mouse reports the new movement, causing the cursor to appear "jerky". The latter is more accurate, but less desirable. >OK, so what is the fix? Simple. Patch the ADB drivers for the mouse device >so that if the mouse has moved more than a threshold value since the last time >it was read, then ignore it. This will make the mouse behave exactly like the >old mac plus mouse. Some experimenting would be in order to see exactly >what should happen. That's a reasonable fix. We've developed something similar, which you should see sometime in the future (probably System 7). _emt
pepke@loligo (Eric Pepke) (08/30/89)
In article <34413@apple.Apple.COM> tecot@Apple.COM (Ed Tecot) writes: >down. No one seemed to mind. These days, when interrupts are diasabled >on the CPU, all the other input devices keep chugging along; they have >their own processors. When the CPU "wakes up", the mouse reports the new >movement, causing the cursor to appear "jerky". The latter is more accurate, >but less desirable. No, this would be acceptable, if that's all that were happening. What I think is really happening is this: 1) CPU goes to sleep for a while. 2) The ADB devices keep humming blithely along. 3) CPU wakes up. 4) CPU gets the new coordinates from the mouse. 5) CPU wrongly assumes that it always polls the mouse at regular intervals and runs these new x and y deltas through its cursor speed scaling routines. 6) The cursor jumps WAY out of proportion to the actual mouse movement. Now, I don't really know any of this, because I don't work for Apple, and I haven't cared enough to disassemble the code. However, it is consistent with the behavior I have observered. The tablet cursor, which does not do mouse scaling, works just fine when interrupts are disabled. It is step 5 that causes the jerkiness which I find unpleasant. The fix is pretty simple. Just change the CPU routines so that they have some basic awareness of how long it has been since the last time they did anything and scale what they do to this time period. Eric Pepke INTERNET: pepke@gw.scri.fsu.edu Supercomputer Computations Research Institute MFENET: pepke@fsu Florida State University SPAN: scri::pepke Tallahassee, FL 32306-4052 BITNET: pepke@fsu Disclaimer: My employers seldom even LISTEN to my opinions. Meta-disclaimer: Any society that needs disclaimers has too many lawyers.