Date: Mon, 31 Mar 1997 07:25:42 +0300 (IDT) From: Eli Zaretskii To: Vik Heyndrickx 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: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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.