Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!bunnell From: bunnell@udel.edu (H Timothy Bunnell) Newsgroups: comp.os.minix Subject: Re: Elle, the 1.5.5 termcap and Hercules: a summary Keywords: Elle termcap Hercules scr_up summary PC/XT Message-ID: <16279@nigel.udel.EDU> Date: 9 Apr 90 16:09:35 GMT References: <1675@tuegate.tue.nl> Sender: usenet@udel.EDU Reply-To: bunnell@udel.edu (H Timothy Bunnell) Organization: University of Delaware Lines: 80 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