How to use "AND," "OR," and "XOR" modes for VGA Drawing

Question

I've been trying to implement a blitter in MS-DOS, but before I do that I wanted to test the various graphics modes of the VGA graphics card. (I'm emulating using DOSBox.) According to this paper on VGA, normal drawing to the bitmap screen is done in "replace mode," where data written to VRAM simply overwrites what is currently stored there. There are three other modes which are supposedly accessed by OUTing the correct control code to port 03CEh, but I can't get them to work. From the website:

mov ax,1803h
mov dx,03CEh
out dx,ax

will set the VGA card write mode to XOR.

Unfortunately I can't get this to work. The code below fills the screen with VGA color 09 in replace mode, then in XOR mode, which should result in a black screen since any number XORed with itself equals 0. Yet, the screen just ends up filled with the color I chose at the start. I turned to the OSDev wiki for further guidance but all I could find was this chart which I have trouble understanding.

Is the quote from the first link correct on changing modes? If so, what am I doing wrong? If the reference material is wrong, how do I invoke the other drawing modes?

I've provided the source code below in case I made a mistake and just can't see it:

mov ax,@data
mov ds,ax

mov ax,0A000h
mov es,ax       ;vga vram


mov ax,13h
int 10h

mov al,09h
mov cx,VGA_VRAMSIZE
mov di,0
rep stosb
mov di,0

push ax
push dx
    mov ax,1803h
    mov dx,03CEh
    out dx,ax       ;VGA "XOR" MODE
pop dx
pop ax

mov al,09h
mov cx,VGA_VRAMSIZE
mov di,0
rep stosb
mov di,0

Answer 1

Running your code as-is on a real 286/VGA (Cirrus Logic CL-GD5420) produces this image:

Inserting one dummy read before the second fill cycle (just mov ax, es:[0]) gives the image you were expecting:

So it would seem that at least there might be a difference between the DOSBox implementation and the real hardware. If it does implement logic operations, then see @dirkt’s hint on populating the latch register. Perhaps it just remains zeroed in DOSBox, so xor-ing your 09h with the latched value of zero gives impression the xor is not there at all. While on real hardware it gets something as a byproduct of the previous activity of the system.

Answer 2

The 16-color modes on the VGA use a hardware design borrowed from the EGA. On the EGA (and VGA), the bitwise drawing modes don't act upon memory directly, but instead act upon values stored in four eight-bit registers, each of which holds a byte of data from one of four color planes. Reading any byte of data from the display will load each of the four latches with the contents of a byte from its associated plane. Writing a byte of data when using a Boolean mode, will for each color plane that is enabled for writing, combine the latched value in its register with the value that being written by the CPU, and store the result to the corresponding byte in memory.

The net effect is that it's possible for the CPU to perform a Boolean operator on one byte in all four planes by performing a byte read followed by a byte write. Requiring the CPU to "manually" read each byte (likely ignoring the result) before each write imposed a non-trivial speed penalty, but allowed simpler hardware than would have been needed to perform the read-modify-write cycle automatically. Unfortunately, this design aged rather badly rather quickly. Use of this complicated latching circuitry improves performance when using an 8-bit display card on a CPU that is slow or has cannot afford to keep a copy of display contents in main memory, but it cannot be used effectively on faster machines because of a few problems:

1. It is necessary to read and write back each byte before proceeding to the next one. Even when using an 8-bit bus, this degraded performance compared with what would have been possible using 16-bit operations. Even if a 16-bit access to the VGA would have required two bus operations, the number of other operations on the main memory bus would have been cut in half.

2. Because memory is shared between the CPU and the circuitry that feeds display contents to the monitor, the former can only access it at moments when the latter isn't. Any request by the former must wait until the display hardware has a spare moment available. Although early display cards made the CPU wait on every operation whether it was reading or writing, it didn't take long for card manufacturers to recognize that they could improve performance by a latch which would immediately capture a write request and release the CPU to perform other operations. The display card could then write the data at its leisure and only make the CPU wait if it asked to write another byte while the first byte was still pending. While this greatly improved the performance of write operations, this approach wasn't possible with reads because the CPU needed to know the results of a read request before it could proceed with anything else. What's ironic is that code that was performing read-modify-write operations wouldn't care what value was returned by the read operations, but the CPU would have to spend most of its time waiting for data it was going to ignore.

Incidentally, the original EGA cards, like many other systems, used banks of eight single-bit-wide DRAM chips, and such banks can easily be adapted to allow selective writing of bits within each byte. A lot of circuitry could have been replaced with five eight-bit-wide latch chips, a couple of quad-NAND chips, and a small amount of circuitry to control when those latches are enabled, and such a design would have allowed software to either write data normally or else interpret written data as a bit mask to selectively write bits of memory with a 32-bit (8 bits on each of four bit planes) pattern, without having to use read-modify-write operations. I'd be curious whether any DRAM-based memory systems (whether used as display cards or for any other purpose) supported bit-masked operations in such fashion. While such a design would be locked into using 32 discrete DRAM chips rather than using higher-density 64Kx4 or 256Kx4 chips when they became available, both price and performance would be better than the far more complicated approach used by the VGA.