mday@ohs.UUCP (Matthew T. Day) (06/13/89)
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). This is after about 20 minutes of playing around, so I'm sure there's more bugs to it. Perhaps the author(s) are listening? Otherwise, it sure is faster than the nansi I'm using right now! Thanks. -- +----------------------------------------------------------+-----------------+ | Matthew T. Day, Orem High School, Orem, Utah | "He who laughs, | | Internet: mday@ohs.uucp UUCP: ..!uunet!iconsys!ohs!mday | lasts." | +----------------------------------------------------------+-----------------+
cth_co@tekno.chalmers.se (CHRISTER OLSSON) (06/15/89)
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). > > This is after about 20 minutes of playing around, so I'm sure there's more > bugs to it. Perhaps the author(s) are listening? Otherwise, it sure is > faster than the nansi I'm using right now! Thanks. I have seen same problems with early versions of AD_VIDEO.SYS (coming soon in comp.binaries.ibm.pc). PCPLUS and som other programs (BRIEF etc) uses very special types of instructions with graphic cards and most EGA-cards don't work well. NNANSI.SYS is unusable for me. I'm waiting for a bug-fix or a fixed version.. /Christer Olsson CTH_CO@tekno.chalmers.se Sweden, Europe
tom@mims-iris.uucp (Tom Haapanen) (06/15/89)
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). Same type of problem when you do a shell escape from MKS vi. At first I thought it was vi, but this confirms my suspicions. > ... it sure is faster than the nansi I'm using right now! ... and it lets me have 33 (readable) lines on the screen, even in DOS! \tom haapanen "now, you didn't really expect tom@mims-iris.waterloo.edu my views to have anything to do watmims research group with my employer's, did you?" university of waterloo
toma@tekgvs.LABS.TEK.COM (Tom Almy) (06/15/89)
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
sme@computing-maths.cardiff.ac.uk (Simon Elliott) (06/16/89)
We run Novell Netware here, and some of the net management utilities have
a (very pretty) menu interface that appears to write direct to video ram.
These very quickly pointed out a problem with NNANSI, and (reluctantly) i've
reverted to NANSI -- I do like the speed of the new version.
Because the new NNANSI.SYS performs a hardware scroll by changing a register
strange things happen with programs that do direct video writes as the
screen memory is no longer where the program thinks it is.
It's not _really_ a bug in NNANSI -- programs writing to video ram should
check the base address register, but I wonder how many do?
--
--------------------------------------------------------------------------
Simon Elliott Internet: sme%v1.cm.cf.ac.uk@nsfnet-relay.ac.uk
UWCC Computer Centre JANET: sme@uk.ac.cf.cm.v1
40/41 Park Place UUCP: {backbones}!mcvax!ukc!reading!cf-cm!sme
Cardiff, Wales PHONE: +44 222 874300wwc@boole.ece.wisc.edu (William W. Carlson) (06/16/89)
Well, I have a bug, even after setting the "nice" option. It is demonstrated by procomm plus, but I'd bet it shows up elswhere. To repeat, set the nice option, recompile, reboot, go into procomm plus, and type exit (Alt-X). Notice that the lines surrounding the box asking you to exit are not quite right. The vertical lines are made of the wrong characters! Any Ideas? This is on an AT clone with an EGA display Bill Carlson wwc@boole.ece.wisc.edu wwc%boole.ece.wisc.edu@cs.wisc.edu
toma@tekgvs.LABS.TEK.COM (Tom Almy) (06/20/89)
In article <WWC.89Jun16102728@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes: > >Well, I have a bug, even after setting the "nice" option. It is >demonstrated by procomm plus, but I'd bet it shows up elswhere. To >repeat, set the nice option, recompile, reboot, go into procomm plus, >and type exit (Alt-X). Notice that the lines surrounding the box >asking you to exit are not quite right. The vertical lines are made >of the wrong characters! Any Ideas? This is on an AT clone with an >EGA display I don't have Procomm+ to check, but it could be caused by the option takeBIOS being TRUE. In this case, nnansi processes BIOS calls to write characters (and processes ANSI escape sequences). If Procomm+ is writing to the screen using the BIOS call, but expects the ESC character to print as what-ever IBM special character is a 27, then things will be messed up! Not that if you turn takeBIOS off, as well as turning off fast, you will also have to turn off the graphic cursor simulator, since it will not work properly in these conditions. The whole subject of display driver software is a real can of worms... Tom Almy toma@tekgvs.labs.tek.com I wrote it (from nansi.sys)
saj%yipeia@Sun.COM (Windows Testing) (06/20/89)
In article <5385@tekgvs.LABS.TEK.COM> toma@tekgvs.LABS.TEK.COM (Tom Almy) writes: >In article <WWC.89Jun16102728@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes: >> >>Well, I have a bug, even after setting the "nice" option. It is >>demonstrated by procomm plus, but I'd bet it shows up elswhere. To >>repeat, set the nice option, recompile, reboot, go into procomm plus, >>and type exit (Alt-X). Notice that the lines surrounding the box >>asking you to exit are not quite right. The vertical lines are made >>of the wrong characters! Any Ideas? This is on an AT clone with an >>EGA display I have an AT clone with a VGA setup. I get the right characters, but in the wrong colors (This is just on the double vertical bars that are used in the Procomm+ menus and window borders. Sorry, I forgot the character code and I don't have a reference with me). I noticed strange color behavior in other programs as well. I have been using QUIKANSI without any problems. Any clues?!? >I don't have Procomm+ to check, but it could be caused by the option >takeBIOS being TRUE. In this case, nnansi processes BIOS calls to write >characters (and processes ANSI escape sequences). If Procomm+ is writing >to the screen using the BIOS call, but expects the ESC character to print >as what-ever IBM special character is a 27, then things will be messed up! > > >Tom Almy >toma@tekgvs.labs.tek.com >I wrote it (from nansi.sys) I would like to commend Tom on his good work. NNANSI is VERY fast and I finally found something that invokes 43 line mode that works! /########################################################\ | Scott A. Jordahl | | UUCP: saj@yipeia.sun.com | | PHONE: WK: [415] 336-5463 | | HM: [408] 270-5619 | \########################################################/ /########################################################\ | Scott A. Jordahl | | UUCP: saj@yipeia.sun.com | | PHONE: WK: [415] 336-5463 | | HM: [408] 270-5619 | \########################################################/
zu@ethz.UUCP (Urs Zurbuchen) (06/22/89)
In article <WWC.89Jun16102728@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes: > >Well, I have a bug, even after setting the "nice" option. It is >demonstrated by procomm plus, but I'd bet it shows up elswhere. To >repeat, set the nice option, recompile, reboot, go into procomm plus, >and type exit (Alt-X). Notice that the lines surrounding the box >asking you to exit are not quite right. The vertical lines are made >of the wrong characters! Any Ideas? This is on an AT clone with an >EGA display On my VGA-equipped 386 computer this happens not only with the exit window but with all other windows as well. There's one difference to the bug reported above: the characters seem right, but they are painted in the wrong color. But to make it a little bit more complicated some vertical bar characters are ok. I have to admit I slightly changed my copy of nnansi. I changed the color definitions so the default color everything gets written to the screen is green on black. And that's the color the vertical bars have. But I did the same to the old nansi.sys and everything worked fine with it. ...urs UUCP (dumb): {backbone}!mcvax!cernvax!ethz!zu (smart): zu@norad.UUCP or netto@norad.UUCP or zu@ethz.UUCP Fido: 2:302/801.36
maa@nbires.nbi.com (Mark Armbrust) (06/23/89)
In article <1363@ethz.UUCP> zu@bernina.UUCP (Urs Zurbuchen) writes: >In article <WWC.89Jun16102728@boole.ece.wisc.edu> wwc@boole.ece.wisc.edu (William W. Carlson) writes: >> >>Well, I have a bug, even after setting the "nice" option. It is >>demonstrated by procomm plus, but I'd bet it shows up elswhere. To >On my VGA-equipped 386 computer this happens not only with the exit >window but with all other windows as well. There's one difference to the >bug reported above: the characters seem right, but they are painted in >the wrong color. But to make it a little bit more complicated some >vertical bar characters are ok. > The problem is that NNANSI is interpreting the INT 10 Write TTY call and is displaying the characters in the color as set by ANSI escape sequences. PROCOMM used other INT 10 calls to set the character attributes in the command window to the color that it wanted the characters to be. There are different INT 10 calls that are used to put up the characters that are correct. The solution is to recompile NNANSI with "takeBIOS equ FALSE". -- Mark Armbrust maa@nbires.nbi.com maa@nbires.UUCP
rogers@falcon.SRC.Honeywell.COM (Brynn Rogers) (06/23/89)
I have some problems with nnansi that no one has mentioned yet.
1) goeslings emacs has the cursor a couple of lines away from inserted text.
[my boss uses this because he needs mock lisp. is there any other
emacs that uses lisp or mock lisp on a PC??]
2) I have a Orchid Prodesigner (now +) and it has a number of usefull text
modes supported by BIOS. I can throw it into a 40x100 mode
(800x600 with a 8x16 character) plus a number of others.
[download a 8x8 font in the 40x100 mode and you get 75x100 !!!]
BUT, in these modes (and 132 column modes) every line on the
screen begins and ends with a blinking block. [I use epsilon which is happy
in any mode]
Brynn Rogers Honeywell S&RC rogers@src.honeywell.com
nic.MR.net!srcsip!rogerstoma@tekgvs.LABS.TEK.COM (Tom Almy) (06/26/89)
THE AUTHOR SPEAKS. In article <24452@srcsip.UUCP> rogers@falcon.UUCP (Brynn Rogers) writes: >I have some problems with nnansi that no one has mentioned yet. >1) goeslings emacs has the cursor a couple of lines away from inserted text. > [my boss uses this because he needs mock lisp. is there any other > emacs that uses lisp or mock lisp on a PC??] One of the following usually fixes these problems: 1. Do a CLS first. 2. Recompile with TakeBIOS set to 0. 3. Recompile with fast set to 0 (but only as a last resort). >2) I have a Orchid Prodesigner (now +) and it has a number of usefull text > modes supported by BIOS. [...] > BUT, in these modes (and 132 column modes) every line on the > screen begins and ends with a blinking block. [I use epsilon which is happy > in any mode] EXPLAINATION OF WHATS GOING WRONG: nnansi needs to know if the display is in a character or graphic mode. Currently it checks memory location 40:49H (crt_mode) and if it has a value greater than 3 then it assumes graphics. The various cards that I have here when placed into high res character modes (132 column modes, for instance) would put a "3" into 40:49, even though that was not the mode. Just today I got an Orchid Prodesigner, and sure enough, it puts the actual mode at location 40:49. This means that nnansi treats these high res character modes like graphic modes, which is a *very bad thing*. FIX FOR ORCHID OWNERS, AND POSSIBLY OTHERS: Well, since none of these modes are standard, I can't simply change nnansi to check out the individual mode numbers and call them character or graphic. But on the other hand *YOU* can! The easiest fix, that at first attempt seems to work is to write a little program which sets 40:49 to "3", and run it immediately after setting a high res character mode. When I tried this, the problems went away, and the display performance became very fast (as it should be). The harder fix is to edit file nnansi.asm. There is one place in this file that sets gmode_flag based on the value in 40:49. It is your job, if you accept it, to modify that code so that the hires charcter modes set gmode_flag to zero, yet the hires graphic modes set it non-zero. Good luck! BTW, you won't have to change the place in nnansi_f.asm that sets the flag. Tom Almy toma@tekgvs.labs.tek.com Standard Disclaimers Apply, except as noted above.