Date:	Thu, 1 May 1997 13:16:37 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Robert Hoehne <Robert DOT Hoehne AT Mathematik DOT tu-chemnitz DOT de>
cc:	djgpp AT delorie DOT com, DJ Delorie <dj AT delorie DOT com>
Subject:	Re: RHIDE screen problems, for all which have this problems
In-Reply-To:	<3365A6D9.34DF2A2E@Mathematik.tu-chemnitz.de>
Message-ID:	<Pine.SUN.3.91.970501131541.3617H-100000@is>
MIME-Version:	1.0

On Tue, 29 Apr 1997, Robert Hoehne wrote:

> 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.

DJ, can you comment on that?

In my experience, this depends not only on the SVGA, but on the
motherboard chipset and BIOS as well (it is even mentioned in the
FAQ).  The chipset and the address decoding logic on the SVGA should
work together so that a 32-bit move is split into two 16-bit moves if
the interface so requires.  (Recall that many motherboards nowadays
have 32-bit PCI or VLB bus between the CPU and the SVGA, in which case
this problem does not even exist.)

Since such complaints are *extremely* rare, I think that most BIOSes
work as they should, and therefore this problem is largely a
non-issue.  For example, I have been using CL544x series for years
with two different motherboards, and never had any such problems (I
would see it instantly, since Emacs uses `ScreenUpdateLine').

For those poor souls who just happen to hit a buggy BIOS and won't
upgrade (for money or love), a command-line switch that will cause
RHIDE to use 16-bit moves (`_movedataw' instead of `movedata') should
be all the stopgap you will need.

- Raw text -