COLOUR has never worked

I can’t be bothered looking for this right now. In 256 colours and above, the following does not produce white-on-black text as you would expect:

COLOUR128TINT0:COLOUR63TINT255
PRINT"White on black?"

However, this does:

COLOUR129
COLOUR128TINT0:COLOUR63TINT255
PRINT"White on black!"

Something’s not being initialised properly. I think it’s always done it. Nobody uses TINT anyway. Go away nemo.

PRINT "The current colours are (allegedly):"
DIM b% 36
b%!0  = 153: b%!4  = 154: b%!8  = 155: b%!12 = 156
b%!16 = 157: b%!20 = 158: b%!24 = 159: b%!28 = 160
b%!32 = -1
SYS "OS_ReadVduVariables", b%, b%
PRINT "Graphics FG" b%!0  " (TINT" b%!16 ")"
PRINT "Graphics BG" b%!4  " (TINT" b%!20 ")"
PRINT "Text FG    " b%!8  " (TINT" b%!24 ")"
PRINT "Text BG    " b%!12 " (TINT" b%!28 ")"

SYS "OS_ReadModeVariable", -1, 9 TO ,,l2bpp%
mask% = -1 >>> (32 - (1<<l2bpp%))
PRINT ' "The current colours are actually:"
SYS "OS_SetColour", (1<<7), b%
PRINT "Graphics FG" !b% AND mask%
SYS "OS_SetColour", (1<<7)+(1<<4), b%
PRINT "Graphics BG" !b% AND mask%
SYS "OS_SetColour", (1<<7)+(1<<6), b% TO ,r1%
PRINT "Text FG    " r1% AND mask%
SYS "OS_SetColour", (1<<7)+(1<<6)+(1<<4), b% TO ,r1%
PRINT "Text BG    " r1% AND mask%

In a 16 million colour mode this produces:

The current colours are (allegedly):
Graphics FG        -1 (TINT       255)
Graphics BG         0 (TINT         0)
Text FG      16777215 (TINT       255)
Text BG             0 (TINT         0)

The current colours are actually:
Graphics FG         0
Graphics BG  16777215
Text FG             0
Text BG      16777215

The VDU has the colours all wrong. It thinks the text background is already 0 so it doesn’t do anything when you try to set it to 0. I would assume the Wimp is using ColourTrans_SetGCOL when it sets up the command window. The problem is that OS_SetColour and ColourTrans_Set* don’t update VDU variables 153-160.

You might wonder why I ANDed the R1 values returned by OS_SetColour with mask%. Well…

MODE 27
FOR i% = 0 TO 15
  COLOUR i%
  SYS "OS_SetColour", (1<<7)+(1<<6) TO ,r1%
  COLOUR 7
  PRINT ;~r1%;" ";
NEXT

Output:

1 2 3 4 5 6 77777777 8 9 A B C D E F

This is marvellous Edward, thank you.

PRINT ’ “The current colours are actually:”
SYS “OS_SetColour”, (1<<7), b%

This doesn’t do what you think it does. Not your fault, it’s always been terribly documented (as is… well, everything).

The actual logic is this:

If b7
    if b6       Return text colour number as R1
    else        Read ECF into [R1] buffer
else
    if b6       Set text colour number to R1 (RO3.7+)
    else if b5  Set ECF from [R1] buffer
    else        Set graphics colour number to R1

So you’re reading the ECF, not the colour number.

The entry and exit conditions are:

=> r0 = flags
   r1 = (if r0b7=1 and r0b6=0)     8 word buffer
        (else if r0b6=1 or r0b5=0) colour number or palette entry
        (else)                     pointer to ECF pattern (8 words)
<= R0 = (if r0b7=1)                GCOL action and flags
        (else)                     preserved
   R1 = (if r0b7=1 and r0b6=1)     palette entry
        (else)                     preserved

I know. Exciting isn’t it?!

Not your fault, it’s always been terribly documented (as is… well, everything).

Would you like that shovel gold plated, or were you thinking platinum with a transparent carbon encrustation? :)

I come to bury Caesar, not to praise him.

So you’re reading the ECF, not the colour number.

Sorry, I didn’t explain that clearly. I know I’m reading ECF patterns for the graphics colours. I made the assumption it would be set to a solid colour. A few lines after that I did read the text colours, and I still needed to mask them.

This might better demonstrate the problem with reading the text colours:

MODE 27
COLOUR 6
SYS "OS_SetColour", (1<<7) + (1<<6) TO ,r1%
PRINT ~r1%:REM => 6
SYS "OS_SetColour", (1<<7) + (1<<6) TO ,r1%
PRINT ~r1%:REM => 66666666

It reads the text colour twice—without changing it in between—but gets a different result each time.
If nothing has been printed since the last text colour change, then OS_SetColour returns the colour number as expected. If something has been printed you get the colour number but it’s been repeated to fill the whole word. This looks like a bug to me. It’s certainly not what I expected it to do.