[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: No more XP lag with Tamedos



At 12/27/2004 04:21 PM -0500, Robert Holmgren wrote:
Change the last line of INT from
 NR BC BX DIRQ2 
to something like this:
 NR BC BX DIRQ2 >>>
*If* (if!) a keystroke is coming from somewhere, it is going to be captured by
permanent S/G 100, and then INT is going to terminate normally, and the *first
key* you hit manually will be displayed on screen. In this case, you can then
analyze the content of S/Gs 100-102 for clues (which will probably nail the
problem) as to where this keystroke is originating -- from a LOADfile or from
"outside" (external environment). Conversely, if my theory is BS and this is
NOT the problem, and there is no keystroke incoming, then the first key you hit
will *not* be displayed (it will, instead, be captured by S/G 100, the key
number that you hit will go into S/G 101, and the scancode will go into S/G 102
-- so if you hit "k", for example, and S/G 100 proves to contain "k", then my
theory is bunk). But I'll wager that I am right, and that those three S/Gs
will tell you exactly where this key is coming from.
You were indeed right, but, as I said in the previous post, I got lucky and
your injunction to think about *toggle* keys led me right away to the
problem. But this indeed goes in my tool box. TAME exposed a miss-assigned
key, 69=AS; I had copied my keyboard file over from W98 to XP; the W98
setup 9sans TAME, of course) apparently tolerated the *error*, but since
TAME automatically toggles NUMLOCK to deal with a NUMLOCK problem in
windows, it *read* the func AS, as it were, and forced XY to toggle to
Window 2. Xy behaved perfectly, did as it was told. I was just telling it
the wrong thing. At least that's how I understand all this.
Lots of lessons here about moving from one system and one platform to
another. I have a few *transition* issues left, but for the moment, again,
thanks very much.

Michael Norman