From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Newsgroups: comp.os.msdos.djgpp
Subject: lword moves to/from video buffer fail
Date: Thu, 27 Mar 1997 13:42:28 +0100
Organization: student at University of Ghent, Belgium
Lines: 57
Message-ID: <333A6B34.2C26@rug.ac.be>
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

Hi to you all!

My question is whether lword (double word) memory access instructions
can/should be used to address video memory. In my case, this produces
problems: sometimes data isn't written at all, sometimes it ends up at
the wrong place in video memory. Usually, I don't have any problems with
my video card at all.

I encountered these problems first with RHIDE, TEXINFO and EMACS which
have other than normal text-based output. This is mainly the reason why
I started this discussion in this newsgroup.

As many of you may know, video memory is different from normal RAM that
is on the address bus, in that it is controlled by the VGA graphics
controller. The memory is conceptually divided into 4 different planes.
These planes accesses are restricted by latches (temporary holding
registers). In text modes plane 0 is used for the character and plane 1
for the attribute. Planes 2&3 are not directly used for video data (they
contain character bitmaps). When normally a word is written the least
significant byte ends up in the character plane and the most significant
byte in the attribute plane. Plane 2&3 are masked out and remain
unchanged. 

What actually happens is the following: 
When a word is written, 
the latches are undefined (they usually hold the contents of some
previously read character cel somewhere in the video memory), the data
word is applied to it, and the latches are written back to the right
address in video memory. 
But what happens when an lword is written?
The latches can hold only ONE character/attribute combination at a time,
and to get it right two writes are needed to update 2 adjacent
characters, the CPU does only ONE (lword) write, so ...  
On my system this non-standard VGA (ill)-feature results in undefined
behaviour: sometimes it gets it right, sometimes not. (with sometimes I
mean per video memory write, so many thousand times per seconds,
...sometimes). On other systems this causes no problems at all,
...never. 

Now what I would like to ask is whether other people have similar
problems, whether there are (assembly/system) programmers that agree
with me that this is undefined behaviour and therefore that code that
use this technique (mainly in the standard libraries provided with
DJGPP, and also RHIDE) should be modified to use word writes and reads
instead of lwords. 
 
Will it have the expected results after all?
Yes, it would. I changed all movedata calls into _movedataw, which
effectively moves words (ofcourse), in the source code of RHIDE and the
problem disappeared!

In the hope to start a meaningful discussion which will solve this
problem...

Thanks for your time, 
 Vik