Reading palette

Reading PRMs, I had an idea that the palette is a device with 16 four-digit binary registers. Is this correct ? (Especially for RPi).
I tried to read the palette. OS_ReadPalette simply returns back my entry values. With ColorTrans_ReadPalette I did so:
10 DIM buf% 255
20 SYS “ColorTrans_ReadPalette”,1,1,buf%,256,0 TO R2,R3
30 PRINT R2,R3
The answer was ‘Internal error: abort on data transfer at &FC1C20A4’.
Is there an opportunity to read palette on RPi?

Which mode are you trying to read the palette for?
You seem to be reading it for Mode 1
Also ColorTrans is not the correct spelling! It should be ColourTrans.
Also ‘TO R2,R3’ is returning r0 & r1. It should be ‘TO ,,R2,r3’

Mode 28.
Spelling corrected, thanks.
10 SYS “OS_ReadPalette”,1,16 TO ,,R2,R3
20 PRINT R2,R3
returns 286331152 286331152. Too big number!
ColourTrans_ReadPalette returns error anyway.

I’m confused, you seem to have changed between one post and the next.
OS_ReadPalette reads the colour sent to the hardware in terms of bits of blue, green and red (working from bit 31 down to bit 8) as per PRM entry

SYS “OS_ReadPalette”,1,16 TO ,,R2,R3 will return the details of one logical colour (colour 1)
like SYS “OS_ReadPalette”,2,16 TO ,,R2,R3 would be logical colour 2

The value isn’t a number per se, it’s a set of bits representing a mix of blue green and red.
Convert the number returned to binary and you will see it isn’t using the full bit 0 to bit 31 bit set.

ColourTrans_ReadPalette reads the screen palette or sprite palette.

I see a discrepancy in the description of OS_ReadPalette.
‘Exit R0’ and farther in the text ‘Notes If R2=R3 on exit…’
May be ‘Exit R2, R3’?

The Exit register list for OS_ReadPalette doesn’t even list R2, R3 as being possible exit registers. It needs correcting (which I’m working on as we speak).

EDIT: Now updated, assuming behaviour hasn’t changed since RO3.x

Did anyone figure out how to make this work?

I am in a C16M mode. I want to read the VDU 4 palette.

I understand that I can set the text foreground to one of 256 colours by a combination of
VDU 17,x
and
VDU 23,17,0,x|

I would like to find out the &RRGGBB00 value for each of these 256 colours.

If I try OS_ReadPalette as above I get back what I put in, e.g. &01010110 for 1. If I try ColourTrans_ReadPalette I get “Not supported in this depth of display”.

Ok, I think palettes are a red herring for what I want. Correct me if I’m wrong but it seems palettes aren’t in use in 32bpp modes.

To read out the current mode colour numbers for the 256 possible GCOLs (same thing as text colours) from the VDU drivers we can do

DIM colours% 256 * 4

FOR I% = 0 TO 63 STEP 1
  FOR J% = 0 TO 3 STEP 1
    colnum% = (I% << 2) + J%
    VDU 17, I%
    VDU 23, 17, 0, J% << 6|
    REM OS_SetColour R0 OR &80 gives read
    SYS "OS_SetColour",%11000000 TO ,colours%!colnum%
  NEXT
NEXT

The table colours% then gives colour numbers indexed by GCOLs 4_BGRT (i.e. %BBGGRRTT)

Where does the actual conversion from 8-bit to 24-bit happen? The kernel generates a 24-bit value for a VDU 17 in the routine ConvertGCOLToColourNumber and then uses ColourTrans_RetrunColourNumber to get the appropriate physical colour. (The temptingly named ColourTrans_GCOLToColourNumber gives the 8-bit colour number regardless of mode.)

Yeah, RISC OS’s palette handling is pretty convoluted. In 32bpp modes there isn’t a palette, but because a lot of the APIs originated on the Archimedes & BBC Micro (or maybe even the Atom?), most of them are restricted to byte-wide colour values (or less – like the fact that you have to set the two GCOL ‘tint’ bits in a separate VDU sequence to the main colour).

GCOLs can map to the default 256 colour palette that was used on the Archimedes (but it’s not a direct mapping, due to the funky way that the 256 colour modes were implemented – the Archimedes only had 16 palette registers, so for each pixel four bits are used to index the palette and the remaining four are used to provide some of the RGB bits directly).

Extra confusion arrived with RISC OS 3.5, which introduced 16bpp & 32bpp true-colour modes, which lack a hardware palette. So some of the APIs which used palette indices (like VDU 17) now interpret the palette index as a GCOL number when in a true-colour mode. Also in true colour modes some of the palette APIs are actually used to control the gamma table, which I think is why OS_ReadPalette was returning the values you were seeing. Really the gamma table should have been put under a new API, but I guess it’s a bit late for that.

I don’t think the wiki fully covers all the nuances (and neither does the StrongHelp manual I’m looking at), so it’s generally a case of learning by experimentation.

Where does the actual conversion from 8-bit to 24-bit happen?

Inside ConvertGCOLToColourNumber. The %TTBBGGRR input gets expanded out to %BBTTBBTTGGTTGGTTRRTTRRTT00000000.

ColourTrans_ReturnColourNumber then converts that to the actual value that will get written to screen memory. This value can then be passed directly to OS_SetColour (for setting either the text or graphics colour). Or ColourTrans_SetTextColour will accept a 32bpp colour value directly.

(edited to remove the inaccurate statement that ColourTrans_SetTextColour maps things down to GCOL values – that’s an old code path for the Archimedes)

I seem to remember that I found it difficult to use colour values that worked equally well in both 16 and 256 colour modes when plotting using EOR. Some machines would give a 16 colour mode and some a 256 colour mode as they couldn’t handle the other… The programme concerned was Fruit Machine which also had to operate on Pico.

Ok, I think palettes are a red herring for what I want. Correct me if I’m wrong but it seems palettes aren’t in use in 32bpp modes.
To read out the current mode colour numbers for the 256 possible GCOLs (same thing as text colours) from the VDU drivers we can do"

Not only are palettes are a red herring in 16M colour modes, but so are the old GCOL and COLOUR numbers. If using BASIC just use the new RGB aware keywords. For graphics set the colour using GCOL red,green,blue and for text COLOUR red,green,blue.