[Date Prev][Date Next][Subject Prev][Subject Next][
Date Index][
Subject Index]
Tame
- Subject: Tame
- From: "Martin J. Osborne" osborne@xxxxxxxx
- Date: Mon, 02 Dec 2002 10:22:12 -0500
Here's my report on Tame.
My system: XyWrite for DOS version 4.018; W2K SP3.
I'm running XyWrite from a LNK. (Hence I don't set "Idle detection".)
The pre-Tame problem: There is a slight delay after a key is pressed,
before the appropriate character appears on the screen. If you hold a
key down for a few seconds, there is at first a slight delay; then
several characters appear, and then there is another pause before more
characters appear, and so on (somewhat like connecting to the computer
via a 300 baud modem).
Tame's solution: Installing Tame with the default settings reduces the
problem immensely for me. For regular typing, I regard the problem as
solved. One can see that Tame hasn't *completely* eliminated the
problem by holding down the "cursor down" key for a while, until the
displayed file starts to scroll up the screen. The scrolling is not
quite smooth, and after the key is released the scrolling continues for
a fraction of a second, indicating that there is still some delay in the
system. But for normal typing, everything appears essentially instantly
and smoothly.
I couldn't detect any change in performance when I used xywrite.reg to
change Tame's settings. (However, I don't know how to go back to
non-xywrite.reg, and without being able to go
back and forth it's hard to tell if there is any difference.)
Comments:
1. Robert Holmgren and Paul Breeze report problems with the display of
line-end characters using the Lucida fonts. There appears to be no
problem with the raster fonts.
2. Tame, with its default setttings, does not eliminate the problem in
all the other DOS programs I have. However, it can be fine tuned for
individual programs (as I understand it)---I need to try that out.
Further, loading one of my other programs while XyWrite is running
causes the problem to reappear in XyWrite, at least to an extent
significant enough to be annoying. However, after running xywrite.reg,
this feature has essentially disappeared---that is, screen response in
XyWrite is smooth even when the troublesome DOS programs are running.
Still, if you need to run another DOS program while running XyWrite you
might check to see how Tame performs for you before committing to it.
3. Apparently any key with a key assignment starting with the NI
function call is not trapped by Tame, and continues to exhibit jerky
screen response under Tame. For example, if I have
103=NI,CR
in my keyboard file, the cursor key produces jerky movement on the
screen. A solution is to eliminate the NI before the CR:
103=CR
works fine---Tame makes the cursor right key echo smoothly on the
screen. Of course, this raises the question of why NI was there to
begin with. So far I haven't found why it is there for the regular
cursor keys (like 103), but I do see its rationale for the alt-cursor
keys. I use these for the function calls NW (next word) and PW
(previous word). (I don't know if this is the default---my keyboard is
completely customized.) That is, in TABLE=ALT I have
103=NI,NW
If I remove the NI in this case the key moves the cursor forward one
word AND puts a spurious character on the screen. This spurious
character is the one you would get if you pressed alt + the cursor right
key on the number pad within Windows.
[For example: press alt-[number pad 6][number pad 6] in Windows and you
get "B" [ASCII 66]; if you assign 103=NW and press alt-[curor
right][cursor right] you get a "B" on the screen and the cursor moves
two words to the right.]
So there is a reason for the NI in this case, and one seems to currently
have a choice between a jerky response and spurious characters. I have
lots of NIs in my kbd file---before most of
the keys above 70 for any table with an ALT in it. I believe that what
they do is to hide the keys from Windows. I don't know if Tame can be
fine-tuned to deal with this problem.
4. Tame seems to clear up some display bugs in XyWrite that manifest
themselves when one shells out to DOS and returns, and the screen has
more than the standard number of lines. I haven't pinned this down
well, but when I shelled to DOS in pre-Tame days, ran a DOS program, and
exited back to XyWrite, some odd bits of the screen display from the DOS
program remained on the screen until I took an action in XyWrite that
caused the relevant part of the screen to be refreshed. Those problems
seem to have disappeared after I installed Tame.
Bottom line: for me, Tame is worth several times its price!
--
Martin J. Osborne
Department of Economics
150 St. George Street
University of Toronto
Toronto
M5S 3G7
Canada
http://www.economics.utoronto.ca
martin.osborne@xxxxxxxx
http://www.economics.utoronto.ca/osborne