wsincc@eutrc3.urc.tue.nl (Wim van Dorst) (04/09/90)
Hello *,
I have been trying to find out what is the exact cause of the Elle and
1.5.5 /etc/termcap and Hercules display problems. All kinds of people
have reacted so far, and I think a good summary is appropriate. The
problems are triple:
1. Garbage on Herc screen (old problem)
As Tim Bunnell pointed out, in all termcaps a 'delete-line
(dl)' entry is given (\E[M). /usr/bin/man uses this to scroll the
screen. The result of this scrolling is garbage on the screen like
(|<|<|<|<|<|<|<) on mine.
Peter Housel found out it is caused by the Hercules hardware,
which uses video memory above 4K, which it shouldn't. The vid-copy
routines are all-right, the scroll-up and scroll-down aren't, says
Peter. I noticed kernel/console.c uses scr_up for \E[M.
Mark Becker indicated that there is a way to make the Hercules
hardware use only the first memory page (port_out(0X03BF,0)), but that
is no solution to this problem (I tested it), because that first page
is still about 32K large.
The problem is not shown when in software scrolling mode, but then you
loose the fast scrolling too.
2. Insert/overstrike in Elle
As I found out myself the new 1.5.5 termcap has a new entry
'delete-character (dc)' added by Glen Overby. This entry (\E[P) is
used by Elle apparently, and causes the normal display of inserted
characters to go wrong: it is done overstriking (sometime). Also a new
page (the Elle ^v/^z commands) may have some bits and pieces left of
the previous displayed page.
I tracked to kernel/console.c and found out that it uses also
scr_up for the \E[P sequence. These two sequences (esc [ M and esc [
M) are the only two sequences which use scr_up.
The problem only occurs in hardware scrolling mode, but the
software scrolling mode on my machine is rather slow. (I _can_ live
with it, but I'd rather something better).
3. Elle next page in spurts
I found out that the above mentioned 'dc'-sequence makes my
Elle do a next page (the said ^v/^z commands) _very_ slowly in spurts
of about 20 characters. Normally a new page flashes on my screen in
about half a second (rough guess), because of this problem it takes
about four times as much.
The problem occurs in hardware scrolling mode _and_ in software
scrolling mode. I have no idea were it comes from, nobody has
mentioned it before. It is very irritating.
--
This summarizes the problems with the Hercules display adapter I and
others have encountered sofar.
The first two probably can be fixed by adapting the scr_up routine.
Peter Housel started on this, he wrote. Please Peter, give it another
try. I think this is a serious problem, which should be tackled asap.
The latter is a problem which is not pinpointed on anything yet, and
needs to be researched further. It may be indirectly dependent on the
scr_up thing. Although this problem is only annoying and therefore I'm
not in serious trouble, it made me do away with the 1.5.5 termcap
(sorry Glen) and I would love to have it solved too.
So:
There are three problems, apparently not with the termcap, but with the
implementation of the Hercules hardware scroll-up (maybe scroll-down
too) routine in kernel/console.c. Any real gurus to fix it, please?
Met vriendelijke groeten, Wim 'Blue Baron' van Dorst
--------------------------------------------------------------
Blue Baron = Wim van Dorst, voice (+31) 074-443937 02152-42319
wsincc@tuerc3.urc.tue.nl (and maybe ever baron@wiesje.home.nl)
This sentence have three erors.
--
Met vriendelijke groeten, Wim 'Blue Baron' van Dorst
__________________________________________________________________
wsincc@tuerc3.urc.tue.nl (and maybe ever baron@wiesje.home.nl)
"This sentence have three erors."bunnell@udel.edu (H Timothy Bunnell) (04/09/90)
In article <1675@tuegate.tue.nl> wsincc@eutrc3.urc.tue.nl (Wim van Dorst) writes: > >Hello *, > >I have been trying to find out what is the exact cause of the Elle and >1.5.5 /etc/termcap and Hercules display problems. All kinds of people >have reacted so far, and I think a good summary is appropriate. ... I thought it might be good to add a few comments to this summary related to similar problems on non-Hercules (EGA/VGA) systems. I've been tracking a problem with elle scrolling on my system (a 286 running in protected mode with cheap VGA controller). The problem is this: 1. When elle scrolls the screen it sometimes works fine and other times causes the display to do a brief dance before settling into something that is _usually_ correct. 2. When paging, elle sometimes leaves stray characters from previous screens in the current screen. 3. When paging, elle sometimes deletes characters that should be present in the current screen. 4. items 2 & 3 also can occur when inserting or deleting lines in a screen. Here's what I'm finding about this: 1. It is not related to the presence/absence of "am" in termcap. 2. It is not related to the status of the kernel LINEWRAP feature (with or without "am"). 3. It happens only when features in termcap allow elle to call the routines scr_up and scr_down. These are part of klib.x and use the 80x86 string move instruction to rapidly shift data about in video ram. 4. It happens whether on not (!!!) software scrolling is enabled. 5. At least most of the time (see below) the addresses and word counts that console.c passes to scr_up/down are correct: there seems to be no error in the logic of the insert/delete line code of console.c. 6. The "dancing display" thingy happens when specific lines within a given file are scrolled into the display -- it is place specific. 7. The dancing display does not depend in any way on the sequence of operations used to get to the critical place. 8. Disabling interrupts during the string moves within scr_up/down does not help. What is elle doing? I put some debugging code into console.c that prints the addresses and word counts passed to scr_up/down when it is called. Most of the time, elle scrolls the screen by deleting one line at the top of the screen and inserting one line just above the "status bar" at the bottom of the screen. This requires scr_up to move the contents of all of video memory (up to the end of the visible display) down by 160 bytes (1 line) then copy the last to 320 bytes back up again (lower memory locations are toward the top of the display screen). The debug code lets me see that scr_up/down are given correct args for this. It may be important that sometimes on my system this causes a visible flicker in the status bar and other times it does not. Every once in a while, still scrolling one line at a time, elle switches over to a different scheme: it indulges in a real orgy of screen scrolls, often to/from the center of the screen. There are too many scrolling commands sent thru scr_up/down for me to follow the sequence with the debugging code (it scrolls off the screen :-). Elle always does this at the same points in a given file. These points correspond to the points where the screen does its dance. Although unnecessary, it's not clear that what elle does at these points if really wrong. I'm now wondering if I have an ideosyncratic problem with my video controller card. It is clearly not exactly the same as the hercules problem. Is there anybody else seeing something similar? Is a video controller compatability report/survey warrented? I would be willing to compile that list if there is sufficient interest and if it does not really belong with the hardware compatability list already being maintained. Tim Bunnell <bunnell@henry.asel.udel.edu>
gcs@nucleus.mi.org (Gary C. Strauss) (04/10/90)
bunnell@udel.edu (H Timothy Bunnell) writes: [ stuff deleted ... ] >I'm now wondering if I have an ideosyncratic problem with my video controller >card. It is clearly not exactly the same as the hercules problem. Is there >anybody else seeing something similar? Is a video controller compatability >report/survey warrented? [ more stuff deleted ... ] >Tim Bunnell ><bunnell@henry.asel.udel.edu> The problems that you describe are exactly the same as the ones that I see. I am running 1.5.5 on a Compaq 386/20e with a built in VGA controller. I also see the problem on a Sperry MicroIT using a ATI VGA controller. It really doesn't appear to be a problem with the video controller. Gary -- Gary C. Strauss gcs@nucleus.mi.org | Anywhere but here! Vickers Inc. | It's a shell game My opinions are probably my own!