Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!asuvax!ncar!mephisto!bloom-beacon!eru!luth!sunic!mcsun!ukc!harrier.ukc.ac.uk!jbww
From: jbww@ukc.ac.uk (J.B.W.Webber)
Newsgroups: comp.sys.atari.st
Subject: Re: The 'PHANTOM TYPIST'
Message-ID: <3832@harrier.ukc.ac.uk>
Date: 13 Feb 90 10:50:09 GMT
References: <900204.10484196.021631@SFA.CP6> <17814@laurel.athertn.Atherton.COM> <1990Feb8.181949.6042@ccu.umanitoba.ca> <173@raider.MFEE.TN.US> <13352@watcgl.waterloo.edu>
Reply-To: jbww@ukc.ac.uk (J.B.W.Webber)
Organization: Physics Lab, University of Kent at Canterbury, UK.
Lines: 33

In article <13352@watcgl.waterloo.edu> wsflinn@watcgl.waterloo.edu (Scott Flinn) writes:
>
>Has anybody else noticed any correlation between rapid sequences of
>keystrokes (involving multiple backspaces) and the appearance of the Phantom?
>

YES, also multiple mouse clicks as menus drop ...

1)	how about a problem with EventMulti  (as a first guess)
		(new interupt while processing first one)
	- comes back to previously suggested problem of spending too long
	  in an interrupt - because of two interrupts ???
else, 
2)	how does keyboard uP react to interrupts when already handling one ?
	
fairly easy to check which is at fault : 
	put a hardware monitor (scope, monostable with LED) on the serial data
	to the 6850 in the ST, look for transitions when the Phantom is typing.

Presumably the long delay bewteen keystrokes is caused by a counter
getting out of the expected range, and then having to wrap round.

i.e., suppose a buffer is being emptied (until 'low-water mark' is reached)
if  an equality test is missed due to interleaving interrupts, the counter
will have to wrap round (via 64k/.../...) to reach equality.

	The cure may be as simple as changing an equality test
	for an `equal or less than' test.  (somewhere!)

probably totally wrong, just my best guess to date.

cheers
 	beau webber	jbww@ukc.ac.uk