Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!ames!indri!nero!blake!uw-beaver!tektronix!tekcrl!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.binaries.ibm.pc.d
Subject: Re: nnansi problems
Keywords: nnansi, bugs
Message-ID: <5362@tekgvs.LABS.TEK.COM>
Date: 15 Jun 89 14:41:59 GMT
References: <311@ohs.UUCP>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 67

In article <311@ohs.UUCP> mday@ohs.UUCP (Matthew T. Day) writes:
>I have had a few problems with the new nnansi.sys replacement recently
>posted to c.b.i.p.  It is blazing fast, but fails to work properly in the
>following situations: I'm using "filec", a file completion TSR, and my prompt
>disappears after I do a ^D, and when using Procomm Plus, I do a shell escape
>(just fine) but when I return to on-line my cursor is two lines below my
>prompt (on-line prompt).

I don't know about the filec problem, since I don't have it (I use anarkey,
which works fine with NNANSI).  The Procomm Plus problem can be solved by
doing a "cls" before returning to P+.

The "problem" is that in order to get maximum speed, NNANSI scrolls the
display by using the builtin (the hardware display controller) facility
rather than scrolling by moving all of the character back 160 bytes back
in the buffer, which is very slow.  It was a major flaw (one of many stupid
mistakes, alas) that IBM, when they wrote the BIOS code, didn't scroll this
way in the first place. 

Hardware supporting is supported by the BIOS, even though it does not use
it.  There is a location in RAM, 40:4E, that holds the start address,.  To
scroll a line, 160 is added to that location, and the hardware display
start register is bumped by 80 (it is effectively a word, rather than byte,
address).  Existing BIOS functions, and some application programs, honor
that address.

The problem comes with programs that access the display directly (rather
than via BIOS or DOS calls) and make the (false) assumption that the display
starts at B800:0000.  In order to co-exist with most of these programs,
NNANSI resets the scroll region if any application either clears the display
(via the BIOS call to erase a display region) or does the bios call to get
the display mode (presumable to decide if the display adapter is monochrome,
starting at B000:0000, or color, starting at B800:0000).  Unfortunately,
there are a small number of programs that do neither of these.

As you have said, Procomm works fine except when returning from a DOS shell.
I have found that most programs behave this way -- the dispay gets scrolled
while in the shell, but upon return the terminal emulator doesn't do the
bios call since it knows the display type.

The only permanent solution is to compile nnansi with the not-so-drastic
option, the "nice" options in nnansi_d.asm.

>
>This is after about 20 minutes of playing around, so I'm sure there's more
>bugs to it.  

Maybe, but I sure haven't found any after 6 months of use by myself and a
few others.  You just have to decide for yourself if the speedup is worth
the hastles.  The graphics cursor is another can of worms -- most applications
work best when it is off, but  crude programs improve with it on.

Naturally I appreciate any bugs found.  I really appreciate bug fixes too!
(Debugging a broken display driver is not easy, as you might imagine!)

>Perhaps the author(s) are listening?  

Yes I am.

>Otherwise, it sure is
>faster than the nansi I'm using right now!  Thanks.

Yep.  That's why I submitted it.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply