From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: RHIDE screen problems, for all which have this problems
Date: Wed, 30 Apr 1997 12:35:13 +0200
Organization: University of Ghent, Belgium
Lines: 40
Message-ID: <33672061.3131@rug.ac.be>
References: <Pine DOT BSF DOT 3 DOT 95q DOT 970425140229 DOT 4348A-100000 AT usm DOT md> <3365A6D9 DOT 34DF2A2E AT Mathematik DOT tu-chemnitz DOT de>
NNTP-Posting-Host: eduserv1.rug.ac.be
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Precedence: bulk

Robert Hoehne wrote:
> 
> Yesterday I placed on my website RHIDE 1.2b. In this version I have
> enabled now a new commandline switch '-S'. This forces RHIDE
> to use for writing/reading the video memory not the fast movedata
> function, but it reads/writes only in 16bit chunks.
> I made this, because an other user found, that this was the
> solution for his problem.
> 
> Because I have no documentation about it I cannot say what the correct
> way is and/or if the hardware is wrong. He said, that it is not
> correct, to read/write to the video ram in 32bit chunks (which
> is done with movedata).
> 
> Is there someone out there, who has exact knowlage about that topic?
> I ask this because if it is true, that access to the video ram
> is allowed (or guaranteed) only for 16bit access, then we should
> change also some libc library function (ScreenUpdate(), ...) to
> reflect this.

If the slightest possibility exists that this might cause problems on
some hardware, shouldn't it be better to change it to 16bit access, no
matter how big the group is that has this problem. An important reason
for this is that even in high resolution text mode, say 132x60, still
not more than about 16Kb has to be written to the video ram for a FULL
screen update. Even with the slowest computers that are able to run
DJGPP (386SX-8) the difference in speed will not be noticable for that
matter.

BTW, I'm that user. In the mean time I upgraded to a more performant
system, and I don't have this problem anymore. However, there may be a
potential large group that still cope with this problem. People who
develop (for) DJGPP most of the time have performant equipment and do
not have to cope with this. These problems remain out of their view.

-- 
+----------------+
| Vik Heyndrickx |
+----------------+