For normal video (not inversed) the result is simple.

we AND the mask against the screen resulting in 110010

in code this would be

Code: Select all

```
LDA ScreenByte
AND Mask
```

So whilst 110110 AND 110011 will be 110010 it will appear as 001101 which is clearly wrong.

So we deal with inversed screen separately to invert the bits before masking.

So we invert 110110 to get 001001 then mask with 110011 to get 000001 then invert again

to get 111110 which appears on the screen as 000001 which is correct.

In code this is

Code: Select all

```
LDA ScreenByte
BMI ScreenIsInverse
AND Mask
...
ScreenIsInverse
EOR #63
AND Mask
...
```

Trawling back through the above for normal video graphics we take the screen byte 110110

and AND with 110011 to get 110010 then OR with the sprite byte of 001100 to get 111110

And this is where things get tricky. Once we start dealing with inverse on inverse then

some may argue we should just replace the screen inverse byte, rather than attempt to merge

them.

If the inverse is in order to attain white on blue and the sprite byte is 000000

then the virtual black will look ok.

However (using AIC mode (split line technique)) we may be using inverse to attain white on red.

and a background of red is too bright and looks wrong.

Placing a contingency around which alternate line we are working on would then be the answer but

at what cpu cost?

Like...

Code: Select all

```
LDA ScreenByte
BMI ScreenIsInverse
AND Mask
SendDirect
...
ScreenIsInverse
BIT AltLineFlag
BVS SendDirect
EOR #63
AND Mask
...
```