Some time ago, I said in response to a note by Gary Jackson that we were more
bold (or brash) than HP and that we would specify the year as well as the
month that we would absolutely guarantee that the first rough draft of QCTerm
would be available for downloading. The month and year that I specified then
was May, 1997.

In keeping with all of the recent discussion on calendars, I would today like
to announce the creation of a new calendar. Just as Julius Ceasar adopted
Sosignes' solar calendar in 45 BC and Pope Gregory adopted the Vatican
Council's modified Julian calendar in 1582, I would like to announce today
the advent of the Atmarian New World calendar. In this new calendar, today is
May 56, 1997 -- and the month will stay May until we finally are able to
release a satisfactory version of the terminal. Only then will the month
change.

The holdup has been getting a satisfactory display. The display is the
keystone section bit of code for the terminal. Every thing else about a
terminal is relatively simple and straightforward. We have rewritten
(redesigned) the display architecture three times now -- and we're getting
ready to do it for a fourth time. Each rewrite has improved both the speed
and the psychological attributes of the display -- but we're still not up to
what I consider completely competitive standards and I don't want to release
the emulator until we are.

QCTerm is programmed up completely in Visual Basic. VB, like almost like
languages, can be essentially as efficient as any other language -- if it is
acting as nothing more than a API sequencer, calling one API (intrinsic-like)
routine after another. In this situation, there truly isn't much performance
penalty to a VB-like language. The place where a tokenized interpreter truly
suffers in comparison to native mode compiled code is when it must perform
computationally intensive operations in the VB code itself.

As I've mentioned before, while Vickie Kurtz has been putting QCTerm
together, I have become increasingly more and more impressed with the quality
of Reflection. It is an extremely well designed program. An HP terminal
emulator is probably the most complex piece of PC client software that anyone
would ever write. Nonetheless, that having been said, we're not going to quit
until QCTerm is essentially fully competitive with Reflection (for all those
attributes we choose to incorporate).

At the moment, we have achieved the following display speeds on a 100MHz
Pentium, Windows 95 machine. Two different screens, filled almost completely
with display enhancements, were used for these tests:

Time to draw Screen A (19.2Kbaud serial input):

     Reflection = 0.85 seconds
     QCTerm = 1.1 seconds
     HP700/92 = 1.3 seconds

Time to draw Screen B (19.2Kbaud serial input)

      Reflection = 1.14 seconds
      QCTerm = 1.4 seconds
      HP700/92 = 2.1 seconds

As you can see, we're now faster than a standard HP terminal, but we're still
slower than Reflection -- and we may always be, so long as we stay in VB. The
processes in which we become slower than Reflection are precisely those where
a significant degree of computation is required in the VB code itself. Unless
and until we rewrite the terminal emulator in a lower level language, we will
probably always be slower than Reflection in this part of the processing.

However, I now consider us to have passed the minimally acceptable
performance point. Moreover, adopting Microsoft's standard approach -- which
is not all that unreasonable (although it generates a lot of jokes) -- the
distance gap in performance between QCTerm and a standard HP terminal will
only increase as PC processor power continues to increase, even if we do
nothing at all to further increase performance. I do expect bottom-end PC
prices to fall to around $800 nearly universally within a year. I also expect
that these machines will have at least a 150MHz Pentium processor, 16MB of
RAM, a lanic card, and at least a 65,000 color display. In this environment,
I expect a zero-cost, high-quality terminal emulator to be a relatively "big
seller."

All of this mucking around with getting the fastest possible display with the
least possible CPU impact (and memory usage) has delayed putting in a great
number of the additional features that you may consider part and parcel of a
standard terminal emulator. Some subset of these features are certain not to
make it into the first  rough draft release. But don't worry. They all will
eventually appear.

Our original time table to have a completely finished terminal emulator has
always been towards the end of the year. I tend to believe that we're still
on track for that schedule -- but as you can readily see, I am certainly not
the world's best prognosticator. Indeed, at this point, all that I can claim
is that I am the inventor of a new calendar.

Wirt Atmar