keenmaster486 wrote on 2025-04-29, 23:06:

Well, I'm not selecting any read planes.

Which means you likely always read plane 0. So the masking you do is most likely pointless, because the EGA masking works as intended, and the EGA card ignores the masked pixels.

keenmaster486 wrote on 2025-04-29, 23:06:

[…]
Show full quote

Copy code to clipboard

1			vmem[m + i] = (vmem[m + i] & ~this->data[t][maskDataPos + i])|this->data[t][dataPos + offs + i];

This obviously works by reading the 4 planes to the latch(es), then adding the bits you want for the selected plane, and writing just the selected plane back to EGA memory. I guess your issue was that you did not acutally read from EGA memory to fill the latches, because in your other attempt, the compiler noticed that you don't use the value you read from EGA memory, and optimized the read access away. You can likely prevent the compiler from "optimizing" your EGA memory access by declaring the vmem pointer as "pointer-to-volatile", like "volatile unsigned char far* vmem". Omit far if you are not in a 16-bit program.

mkarcher wrote on 2025-04-29, 23:14:

This obviously works by reading the 4 planes to the latch(es), then adding the bits you want for the selected plane, and writing just the selected plane back to EGA memory. I guess your issue was that you did not acutally read from EGA memory to fill the latches, because in your other attempt, the compiler noticed that you don't use the value you read from EGA memory, and optimized the read access away. You can likely prevent the compiler from "optimizing" your EGA memory access by declaring the vmem pointer as "pointer-to-volatile", like "volatile unsigned char far* vmem". Omit far if you are not in a 16-bit program.

Sure enough, this is exactly what was happening. Thanks for the tip. Changing the vmem pointer to volatile fixed the bizarre behavior.