Date:	Mon, 31 Mar 1997 07:25:42 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc:	djgpp AT delorie DOT com
Subject:	Re: lword moves to/from video buffer fail
In-Reply-To:	<333A6B34.2C26@rug.ac.be>
Message-ID:	<Pine.SUN.3.91.970331071050.16552B-100000@is>
MIME-Version:	1.0

On Thu, 27 Mar 1997, Vik Heyndrickx wrote:

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

AFAIK, the chipset on your motherboard is the solution to this puzzle.  It
is responsible for breaking a 32-bit DWORD into 2 16-bit WORD writes which
are then written serially into consecutive addresses of the video RAM
(unless your SVGA sits on a 32-bit bus, like VLB or PCI, in which case the
DWORD is written in one piece).  In addition, I think the address decode
logic on the VGA itself also has part in this.  In any case, the 32-bit
accesses work on all the machines I've seen (and Shawn seems to tell he
has similar experience).  If your machine has trouble with that, I would
suggest to fiddle with the CMOS setup to see whether any option there can
make it work for you; if not, replace the VGA and/or the motherboard. 

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

It seems unjustified to punish the vast majority of DJGPP users (32-bit 
writes are *much* faster, especially if your VGA sits on a 32-bit-wide 
bus) because of such rare cases.
  
> 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!

This is even mentioned in the FAQ (section 18.4), but when I wrote that, I 
had in mind peripherals other than VGA (like a memory-mapped DSP board or 
such likes), because VGA and chipset vendors are usually very aware of all 
kinds of optimization techniques applied in video-oriented software, and 
so make these techniques work; whereas a data-collection board vendor 
doesn't always have the same level of expertise and resources. 

- Raw text -