ALL_BLACK and ALL_WHITE appear to be implemented wrongly for raster copy functions

[mfro0]

vro_cpyfm() calls utilizing the ALL_WHITE (0) or ALL_BLACK (15) logic op constants appear to be interchanged: ALL_WHITE gives black while ALL_BLACK gives white at least with the 16 and 32 bit drivers (Aranym) and the FireBee driver that seems to have inherited the same behaviour (others I can't test currently).

[chrisridd]

Assuming fvdi just passes the logic op straight through to aranym native code, then aranym seems to be calling this on each pixel (?):

uint32 VdiDriver::applyBlitLogOperation(int logicalOperation,
    uint32 destinationData, uint32 sourceData)
{
    switch(logicalOperation) {
        case ALL_WHITE:
            destinationData = 0;
            break;
        case S_AND_D:
            destinationData = sourceData & destinationData;  
            break;
        case S_AND_NOTD:
            destinationData = sourceData & ~destinationData;
            break;
        case S_ONLY:
            destinationData = sourceData;
            break;
        case NOTS_AND_D:
            destinationData = ~sourceData & destinationData;
            break;
/*
        case D_ONLY:
            destinationData = destinationData;
            break;
*/
        case S_XOR_D:
            destinationData = sourceData ^ destinationData;
            break;
        case S_OR_D:
            destinationData = sourceData | destinationData;
            break;
        case NOT_SORD:
            destinationData = ~(sourceData | destinationData);
            break;
        case NOT_SXORD:
            destinationData = ~(sourceData ^ destinationData);
            break;
        case D_INVERT:
            destinationData = ~destinationData;
            break;
        case S_OR_NOTD:
            destinationData = sourceData | ~destinationData;
            break;
        case NOT_S:
            destinationData = ~sourceData;
            break;
        case NOTS_OR_D:
            destinationData = ~sourceData | destinationData;
            break;
        case NOT_SANDD:
            destinationData = ~(sourceData & destinationData);
            break;
        case ALL_BLACK:
            destinationData = 0xffffffffUL;
            break;
    }

    return destinationData;
}

Looking at how colour seems to work elsewhere in the aranym code, ALL_WHITE (0) will be black and ALL_BLACK (0xffffffffUL) will be white.

But if firebee's misbehaving too perhaps I'm mistaken about aranym's native code.

[mfro0]

this is what tos.hyp says:

_ALL_WHITE 0 D := 0 ... ALLBLACK 15 D := 1

which is correct for plane-organised screens where you set the color index in the bit plane (and not the direct color). Color index 0 is supposed to be white there and color index 1 black. With high and full color screens, you don't set the color index, but the color itself instead and the value needs to be 0xffffffff and 0, respectively (at least that's what I strongly assume, as documentation doesn't explicitly say so).

I have fixed that for the 16bit driver. It appears that for Aranym, it should to be fixed in the Aranym code itself?