Re: No more XP lag with Tamedos

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Michael Norman  on Mon, 27 Dec
2004 10:39:34 -0500

Debugging STARTUP.INT (continued)
---------------------

> Here's my current startup. (please let me know if you spot any errors):

No. Looks fine.

OK: Vanilla (no INT), Window 1. No Tame, Window 1. With INT + Tame, but no
KBD, Window 1.

> RESULT: XY comes up in Window 2, and that window is blank. The DIR display
> is in Window 1.

The DIR display is in Window 1...! Now, ordinarily, the act of LOADING a
loadfile is a pretty passive thing; yes it loads it into memory, but it doesn't
actually *do* anything -- LOADing the KBD file does not, for example, issue any
keystroke. So my preliminary conclusion would be that there is some extraneous
artifact in one of these LOAD files, or something fundamental that is missing,
that XyWrite only reacts to _after_ STARTUP.INT terminates (STARTUP is, after
all, an XPL program, which at no point issues a command [, ] to accept
a keystroke). Because something, somewhere, is poking a stray keystroke, an
extra keystroke; and that keystroke is sitting in the keyboard buffer of this
memory space, waiting to be accepted by a program that accepts a keystroke (get
it? its a two part process: a program pokes a keystroke *into* the buffer,
but it doesn't go anywhere until another program, or the same program, requests
a keystroke *from* the buffer, which completes the keystroke's journey). And
the very first moment that XyWrite is prepared to accept a keystroke -- into
Editor's text window -- is when INT terminates -- you follow me here? There is
no other explanation, period, for why you get DIR display in Window 1, but end
up in Window 2, given that the DIR command is the dead last command INT issues
before it EXits. And yes, here I agree, that poker could conceivably be Tame
-- the Numlock toggle you mentioned disabling, then reenabling, yesterday.
Didn't you say that Numlock was also getting turned on -- or something, I
forget exactly what?

You ask how to debug this, and following is the answer. But understand, that
what you have here is a *very rare* problem, so this is not the first thing
anyone would be likely to try. But when stray/unexpected artifacts appear, it
is one technique for the toolbox:

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.

Do that experiement -- it should be diagnostic. Poll the values like this from
the CMline:

VA/NV @100

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------