Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!tuegate.tue.nl!eutrc3!wsincc From: wsincc@eutrc3.urc.tue.nl (Wim van Dorst) Newsgroups: comp.os.minix Subject: Elle, the 1.5.5 termcap and Hercules: a summary Keywords: Elle termcap Hercules scr_up summary PC/XT Message-ID: <1675@tuegate.tue.nl> Date: 8 Apr 90 21:32:30 GMT Sender: news@tuegate.tue.nl Lines: 86 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."